What Every Computer Scientist Should Know About Floating-Point Arithmetic

Not a bug, it's an artifact of a finite number of bits being used to represent an infinite concept. It's also covered in perlfaq4 under the heading "Why am I getting long decimals (eg, 19.9499999999999) instead of the numbers I should be getting (eg, 19.95)?"

And if you want excrutiating detail on the issue, look at perlnumber.

...but when money is involved it needs to be 100% correct

If you store your currency as whole numbers of pennies/cents etc, then you will never get roundoffs and have total accuracy upto $/£/? 9 trillion (see machine accuracy).

For a simple explanation of why floating point doesn't give exact results, see Re: Re: Re: Bug? 1+1 != 2.

Even using whole numbers, you still run into problems when you need to compute exchange rates or percent-off discounts. The company I work for has had to take a really close look at all of our rounding methods to make sure we don't have any pricing discrepancies.

Once you move to storing your prices in pence/cents etc., and roundoff through division will be decimal pence/cents and it's usually ok to round these amounts up or down to the nearest whole pence/cents in favour of the customer without dramatically affecting your bottom line.

The caveat is that you should accumulate all your sums and perform your discounting/exchange rate calculations on the total, not on each individual value prior to totalling.

For example, if your customer is buying 10,000 widgets @ 10 pence each and is entitled to a 17.5% discount.

$unitPrice = 10.0;
$discount = 0.175;
$units = 10_000;

$totalPayable = int( $unitPrice * ( 1 - $discount ) * $units ); ## Cor
+rect way
printf "Total: £%.2f\n", $totalPayable / 100;

##Total: £825.00

$totalPayable = int( $unitPrice * ( 1 - $discount ) ) * $units; ## WRO
+NG!
printf "Total: £%.2f\n", $totalPayable / 100;
## Total: £800.00
[download]

I once sat through a 3 hr long lecture on (UK) accounting conventions related to a very similar problem, the upshot of which was that you should always total up before applying any conversion that required division. The rules probably vary dependant upon where you live or pay taxes.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

The Problem lies in the fact, that numbers on computers are in binary format. 1/10 is a binary number that can not be displayed (or stored) exactly in a storage with finite memory.

If you try to add binary fractions you will never end: 1/16 + 1/32 + ...

Sorry if I miss the right english words for that, I'm not a native speaker...

So to get exact results, do all your calculations in integers, and divide by 100 for display purposes.

So to get exact results, do all your calculations in integers, and divide by 100 for display purposes.

Or, more transparently: use bignum - for example:

perl -Mbignum -e "print (100.10-100);"

gives the correct answer 0.1

---

s^^unp(;75N=&9I<V@`ack(u,^;s|\(.+\`|"$`$'\"$&\"\)"|ee;/m.+h/&&print$&

but when money is involved it needs to be 100% correct.

No it doesn't! Use this to your advantage and skim the remainders... Like in Office Space or Superman 3.

The problem is a simple one - representing fractions in binary.

As I'm sure most will be aware, a decimal integer, can be represented as a sum of powers of two.

Eg.

100 = 64 + 32 + 4 = 2 ^ 6  + 2 ^ 5 + 2 ^ 2
                  = 1100100
[download]

The problem appears when we try and represent a fraction in binary.

In order to represent non-integer numbers, clearly we need a binary point (not decimal :)).

So we can have 1000.1010. The 'rule' for numbers to the right of the point, is that the 'powers' are negative. Eg. in decimal

10 ^ -1 = 0.1 
10 ^ -2 = 0.01
10 ^ -3 = 0.001
[download]

If we continue to work in binary, the same logic applies. Unfortunately:

2 ^ -1 = 1/2
2 ^ -2 = 1/4
2 ^ -3 = 1/8
binary 1010.1010 = 2 ^ 3 + 2 ^ 1 + 2 ^ -1 + 2 ^ -3 = decimal 10.625
[download]

As you can see, there are quite a few decimal fractions (eg. 0.1) that become recurring fractions when represented as a binary number.

This is the source of that particular quirk you noticed.

Floating point numbers are functionally similar to fixed point in this regard.

The weakness of fixed point becomes quickly obvious - if you 'reserve' 4 bits for the integer, and the other 4 for the mantissa then you end up with an 8 bit number being from 0 to 16 rather than the 0-256 range you'd have normally.

The workaround was to use floating point. Essentially, the 8 bit number gets cut up into 3 parts. The integer, the mantissa and the exponent. The exponent is a multiplier of 'powers of 2' of the binary number.

Although I'll leave it there, because there's many better explanations of floating point numbers on the net.

Essentially, the problem in your calculation comes from rounding errors when converting to/from binary fractions.

You can use the sprintf function to round your numbers to 2 decimal places, something like this:.

I just tried out the behaviour of Perl in this case and found this:
perl -e "print 1/10"
gives the result 0.1

Also does
perl -e "print 1.0 / 10"
and
perl -e "print 1.0 / 10.0".

But
perl -e "print 100.1 - 100.0"
gives the well known 0.0999999999999943.

(All under ActiveStates Perl 5.8.0 under Windows 2000.)

Is there a special mechanism in Perl that "saves" the fraction? Or do I miss something else?

Try this:

printf "%.32f\n", 1/10;
0.10000000000000001000000000000000
[download]

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon