+3  A: 

It has to do with how decimal values are converted to binary floating point numbers. 1/10 turns into a repeating decimal in binary, so the number is not perfectly represented, and repeated operations can expose the error.

JavaScript uses IEEE-754 floating point numbers, for the record. Some other languages have the same problem.

How to deal with it? In your case, maybe toPrecision().

Nosredna
A: 

http://docs.sun.com/source/806-3568/ncg_goldberg.html

What everyone should know about floating point numbers.

+3  A: 

The Mantissa portion (the part after the decimal point) of Floating point numbers are stored as a sum of fractions. They are calcualted by adding a series of fractions. The order of the fractions is:

1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, ... etc

The binary representation is stored as 0s and 1s which indicate yes/no. For example, 001010 would be 0 * 1/2 + 0 * 1/4 + 1 * 1/8 + 0 * 1/16 + 1 * 1/32.

This is a rough example of why floating points cannot be exact. As you add precision (float -> double -> long double) you get more precision to a limit.

The underlying binary data stored is split into two pieces - one for the part that appears before the decimal point, and the other for the part after the decimal. It's an IEEE standard that has been adopted because of the speed at which calculations can be performed (and probably other factors on top).

Check this link for more information: http://docs.sun.com/source/806-3568/ncg_goldberg.html

Kieveli
Some floating point numbers can be converted exactly between binary and decimal. .125 obviously maps to 0.001.
Nosredna
And other trivial floats don't convert. I think 3.135 Couldn't convert for me - or something equally simple.
Kieveli