Why not FP for Money?

[Al Christians]

I've done plenty of numerical work for financial institutions using 
floating point,  and, as far as I have ever experienced, you are 
correct.  My work has involved insurance (including getting actuarial 
calculations approved by the pickiest insurance regulators), doing a
data systems conversion on over a $billion in customer accounts without
losing a cent, lending (programming calculation of terms of consumer 
loans),  and accounting work (preparing financial statements audited by 
the major accounting firms).  This work, however, has all been in the 
USA.  None of the numbers, in dollars, are big enough to make it very 
likely that you will ever lose a penny using floating point numbers of 
64-bits (~16 digits),  but using the 80-bit (~18 digits) extended 
precision numbers that the Intel architecture and a few programming 
languages support is a little bit better.

If it's illegal(!) to overcharge on a loan by $0.01, you have a floating 
point algorithm that is right 99.999999% of the time, and you are 
programming for an operation that writes 10,000 loans a year, are you 
OK?  Of course, the knotty problems like this all involve compound 
interest calculations including expressions with non-integer exponents. 
And everyone who exponentiates anymore trusts a machine at some stage in 
their calculations.  Which do you trust more, the Intel hardware doing 
floating point with a trivially small chance of losing a bit that would 
flip the answer by a penny, or a fixed-point exponentiation routine in 
someone's COBOL runtime library that works who-knows-how?

Two possible drawbacks:

1. You have to remember to re-round after every calculation.  Instead of
"a = a + b" you have to write "x = round_money(a + b)".  When just about 
every statement is decorated like this, you can see that your 
programming language is missing something at a low level that you really 
might want it to have. OTOH, the rounding rules are very often 
domain-specific, so having one particular set of rules built into the 
language might be more of a nuisance than a help.

2. I've heard that there are domains where floating point accuracy is 
not acceptable, although  I've not encountered them.  I don't know what 
rules apply to settlement calculations in the U.S. securities markets 
and if there are big penalties for losing a penny when you settle on a 
$10 million bond. It seems crazy, but IDK.  Similarly, I've seen posts 
somewhere that said that rules for currency conversions (in Europe?) 
specifically require something like 26-digit accuracy.

3. There are cases where (numerous) transaction between separate 
entities are handled by some kind of electronic interchange, where the 
arrangements between the entities are spelled out by contract,  and 
where systems will choke when the odd penny difference between firm A 
and firm B occurs.  It surely is easier to spell out things in terms of
ordinary decimal math, and that makes it easier to get everyone singing 
off the same sheet.


Al

John Burton wrote:
> "Chris Barker" <Barkmann at gmail.com> wrote in message 
> news:cc887c1d.0409202325.76ec2227 at posting.google.com...
> 
>>Hi all,
>>
>>I promise this is not a troll... Really, it's embarassing, because
>>this is one Engineer that DID take a Numerical Analysis course, and
>>from William Kahan, no less, and I still don't really get it. (and
>>yes, Alex, I could have gotten my degree without it)
>>
>>I've seen it suggested various times that one should use fixed point
>>for money, perhaps micro cents represented as integers. However, if
>>you do that, you need to make sure you do all the rounding correctly.
> 
> 
> 
> On my version of python:
> 
> # I spent £1 and 13 pence
> p = 1.13
> 
> # How many pence is that?
> print int(p*100)
> 112
> 
> # Oops
> 
> You don't need quadrillions of dollars before you run into a value which 
> can't be represented in a floating point value to such a degree that the 
> rounding comes out wrong.  Yes you could probably "fix" the rounding to make 
> it work in practice but the problems is that it is simply not possible to 
> represent the value 1.13 in a floating point variable exactly and when 
> dealing with money you want to represent it exacctly, particularly as it's 
> so easy to do. 
> 
>