http://www.perlmonks.org?node_id=267145


in reply to Re: Re: Bug? 1+1 != 2
in thread Bug? 1+1 != 2

It's not a bug per se. It is an inherent limitation of using floating point math on a computer. At least those that use the IEEE standard for their floating point representation.

Essentially, floating point stores decimal numbers as binary encoded fractions. That is to say 5/8ths (0.625 decimal) is stored as (0.)101 in binary. The 0 and the decimal (actually binary) point aren't really stored as they can be implied. The '101' translates to

1 x 1/2 + 0 x 1/4 + 1 x 1/8 ----------- 5/8 = 0.625

which is great because it means that decimal fraction 0.625 can be represented exactly as a binary fraction, so no loss of accuracy.

However, many decimal fractions cannot be represented exactly in binary. This is the same as trying to express 1/3 as a decimal fraction. The best you can do is 0.333... but when you multiply 0.333... * 3 you get 0.999... No matter how many decimal places you add, it never quite adds up to 1.00 as it should. The same is true when it comes to representing many decimal fractions in binary. The representation is inexact. Eg. 0.1 decimal in binary

1/2 (0.500000000000) 0 1/4 (0.250000000000) 0 1/8 (0.125000000000) 0 1/16 (0.062500000000) 1 0.0625 1/32 (0.031250000000) 1 0.03125 1/64 (0.015625000000) 0 1/128 (0.007812500000) 0 1/256 (0.003906250000) 1 0.00390625 1/512 (0.001953125000) 0 1/1024 (0.000976562500) 1 0.0009765625 1/2048 (0.000488281250) 0 1/4096 (0.000244140625) 0 --------------------------------------------------- 0.0986328125

As you can see, using 12 significant digits (bits) of binary fraction (the limits of the display on my calculator:), representing decimal 0.1 is pretty poor. Luckily, perl uses many more (52) bits and so it can achieve much better accuracy.

perl> printf "%.32f\n", 0.1 0.100 000 000 000 000 010 000 000 000 000 00

But it is still not exact and never will be no matter how many more binary digits (bits) you used.

But to put that in perspective, the inaccuracy shown is one tenth, of one thousandth, of one billionth of whatever it is you are measuring.

In monetary terms, that's a 10 cents (dime or a nickel? (Who cares:)) in a trillion dollars.

In terms of the human population, that's one or maybe two of your eyelashes, from the whole mass of the human species.

Or another way of looking at it, its 10 microns of inaccuracy on the distance from here to the Moon.

For most everyday purposes, it's "close enough":)


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


Replies are listed 'Best First'.
Re: Re: Re: Re: Bug? 1+1 != 2
by Nkuvu (Priest) on Jun 19, 2003 at 18:04 UTC

    * sigh *

    Where were you when I was trying to explain this to some of our developers? I'm testing software, and raised a big red flag when I saw some logic that compared float values for equality. The values were results of other computation, and I tried for days to explain to the developers that this logic was a bad idea. I was nowhere near as eloquent as your post. Thankfully I wasn't the only one who understood the problem, and one of my co-workers was able to put it in terms that the developers grokked.

    Which is really odd if you think about it -- I thought this sort of thing was basic education for programmers. (All of the developers I'm referring to have at least BS degrees) But I digress. Thanks for your explanation.

Re: Re: Re: Re: Bug? 1+1 != 2
by JamesNC (Chaplain) on Jun 19, 2003 at 13:33 UTC
    VERY Informative... ++ and great discussion, thanks! I love this site.