Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1
0.99999999999999989
>>> 0.1 * 10
1.0
>>> (0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1) - 1.0
-1.1102230246251565e-16
>>> import math
>>> (math.e ** math.pi) - math.pi
19.99909997918947
1001100110011001100110011001100110011001100110011010
You're right, Openoffice should be rounding the numbers after some amount of decimal places. The floating point numbers use base 2, so it's mantissa\(\times 2^{exponent}\). That means that you need an integer that divided by \(2^{something}\) equals 0.1, which doesn't exists, right?It's a known flaw with IEEE754 floating point numbers!
Python uses the double, 64-bit IEEE754 floating point format, which is about as precise as you can get. You can get 80-bit long double formats on x86 and some other processors, but these are not portable.
The problem stems from the fact that 0.1 cannot be represented exactly in binary. The result, when converted into binary, is:
Note it is recurring... it is impossible to represent exactly using a finite binary sum.Rich (BB code):1001100110011001100110011001100110011001100110011010
OpenOffice is probably rounding-to-nearest, which is fine, but it adds roundoff error sometimes.
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 0.1
0.10000000000000001
>>> 0.2
0.20000000000000001
>>> 0.3
0.29999999999999999
>>> 0.4
0.40000000000000002
>>> 0.5
0.5
>>> 0.6
0.59999999999999998
>>> 0.7
0.69999999999999996
>>> 0.8
0.80000000000000004
>>> 0.9
0.90000000000000002