Afficher un message
Vieux 12/11/2007, 21h53   #132
Flash Gordon
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Bug/Gross InEfficiency in HeathField's fgetline program

Tor Rustad wrote, On 07/11/07 01:00:
> Flash Gordon wrote:
>> Tor Rustad wrote, On 06/11/07 11:38:

>
> [...]
>
>> This means that the only way to convert money from one currency
> > to another is to move it from one account to another, and

>
> We call this a transaction, which typically is done with double-entry
> bookkeeping.


Indeed. We talk about transactions as well :-)

>> at that point the rounding occurs as part of the conversion using
>> defined rules and a specified conversion rate,

>
> "I'm struggling to imagine any real-world double-entry-relevant
> calculation that /cannot/ be done exactly."
> -RH


If you consider the rounding to to be part of the conversion equation
rather than something that is done afterwards then the calculation *is*
done exactly.

>> and those rules specify *exactly* what will be credited to one account
>> and debited from the other.

>
> The whole point, is that this calculation uses rounding.


It is part of the calculation, so the calculation overall is done exactly.

> Do UK accounts
> have two decimal places?


Yes.

>>> The obvious requirement our UK bank has, will be to match each
>>> account at some cut-off times each day. This calculation should be
>>> done *exactly*. If the currency conversion has already been done at
>>> this point, there is no simple way to match the books *exactly*.

>>
>> Incorrect, it is easy as long as you follow the requirements above.

>
> Nothing you said, invalidated my statement here...


I think we have a scoping problem. I consider the equation (restated) to be
100 => 50
101 => 50
102 => 51

You consider it to be
101 => 50.5
With a rounding done after.

>> If anyone is interested enough I could ask one of my brothers who was
>> doing application support & maintenance for one of the large
>> organisations in the City of London that works with lots of currencies.

>
> I have been trying to leave this thread for some time...



Well, on the application my brother was involved in they did use
floating point variables because no other variable type could cope with
the range. They just accepted that there would be errors and ensured
that they were consistent. Personally I think that was the wrong
decision, but...


> Anyway, some details from an insider is very interesting. In particular,
> a related problem, how UK banks can implement SEPA w.r.t. double-entry
> bookkeeping and risk management.


That I don't know.

> In this case, the transactions will be in euro, while the EU payment
> scheme rulebook say nothing about possible currency conversion, or the
> related risks for the banks.


They probably use whatever method they used before the euro :-)

>> I don't think that Richard believes he is always correct.

>
> Neither did I. ;-)


OK, we are all agree Richard makes mistakes. Whether we are talking
about the same Richard is, of course, another matter ;-)
--
Flash Gordon
  Réponse avec citation
 
Page generated in 0,06081 seconds with 9 queries