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
[download]

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
[download]

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
[download]

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":)

* 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.

VERY Informative... ++ and great discussion, thanks! I love this site.