Read the replies to When 1000 is less than 1000.

The short version is that floating point values can not precisely represent decimal fractions like 0.1. The result is that small errors are present whenever you perform arithmetic in computers using floating point representations of decimal fractions. Those errors are often not shown because they are small, but lead to the sort of strange results you have seen.

If you are dealing with monetary values you can avoid the problem by performing all calculations in, for example, cents then convert to dollars and cents for display. Even then, if you perform mark up, discount, interest, tax or other calculations you will have to take care to round results at an appropriate point and always compare integer cents.

What might possibly cause this?

  DB<1> p 2008.000000000001
2008
  DB<2> p 2008.000000000001 == 2008

  DB<3> p 2008.000000000001 - 2008
9.09494701772928e-13
[download]

for (my $i = 0; $i<30; $i += 0.1) {
    print "$i ";
}
[download]

If you run that, you will notice frequently the numbers ARE NOT an even multiple of 0.1, eg, with 32 bit floats you get "5.9 5.99999999999999 6.09999999999999 6.19999999999999" "22.5 22.6000000000001 22.7000000000001 22.8000000000001", etc. In fact, they are NEVER an even multiple of 0.1, but this is not always clear since there is also a limit to the number of "decimal" places when the number is rendered in non-binary form.

This is not just a perl issue, and there are notorious legends of accounting software disasters because of it; it's why when you are programming applications involving dollars and cents and division, always:

use integer;
[download]

Then use cents, not dollars, and remember, this is rounded down -- if you want to include fractions of a cent, decide how many decimal places you need and use that fraction as a base unit. Money is not a floating point measure. It is of fixed precision.

Is using the integer pragma such a good idea? From the documentation:

   1.  use integer;
   2. $x = 10/3;
   3. # $x is now 3, not 3.33333333333333333
[download]

If only addition and subtraction are being used, should be fine - if other arithmetic operations are happening, wouldn't that result in a loss of precision?

Only if your units are not whole, indivisable units already. If you do all your calculations in cents and do not allow sub-cent amounts, then you won't need to care about rounding.

If you do fancy calculations, like repeatedly adding fractional parts of things, you need to give deep thought to all your calculations anyway, whether they are in floating point or integer numbers.

Well the first thing to try is to capture the equality, so maybe write some code using >= instead of >, and see what happens.

• Use only integer values i.e. use cents/pennies/bah instead of dollars/pounds/foo (already mentioned previously)
• The use of a module such as Math::BigInt might help here?
• Could potentially round the values, using sprintf and doing a string comparison - this may suffer from the same issue as you are already seeing.
• There may be arbitrary precision Math modules already out there? Anyone?

If this is a financial application, then the use of integer values, if possible, should be the way to go.

That should be cents/farthings/bah

Do they still have farthings? They're not worth a ... well, you know.

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

Using integer values, you're still stuffed. How do you calculate 17.5% of 100, using only integers?