Original Translation
14
and think it is a bug in Python. It's not. This has nothing to do with Python, but with how the underlying C platform handles floating point numbers, and ultimately with the inaccuracies introduced when writing down numbers as a string of a fixed number of digits.
15
The internal representation of floating point numbers uses a fixed number of binary digits to represent a decimal number. Some decimal numbers can't be represented exactly in binary, resulting in small roundoff errors.
16
In decimal math, there are many numbers that can't be represented with a fixed number of decimal digits, e.g. 1/3 = 0.3333333333.......
17
In base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. .2 equals 2/10 equals 1/5, resulting in the binary fractional number 0.001100110011001...
18
Floating point numbers only have 32 or 64 bits of precision, so the digits are cut off at some point, and the resulting number is 0.199999999999999996 in decimal, not 0.2.
19
A floating point number's ``repr()`` function prints as many digits are necessary to make ``eval(repr(f)) == f`` true for any float f. The ``str()`` function prints fewer digits and this often results in the more sensible number that was probably intended::
á é í ó ú ç ñ ü ¿ ¡
20
>>> 1.1 - 0.9 0.20000000000000007 >>> print(1.1 - 0.9) 0.2
21
One of the consequences of this is that it is error-prone to compare the result of some computation to a float with ``==``. Tiny inaccuracies may mean that ``==`` fails. Instead, you have to check that the difference between the two numbers is less than a certain threshold::
22
epsilon = 0.0000000000001 # Tiny allowed error expected_result = 0.4 if expected_result-epsilon <= computation() <= expected_result+epsilon: ...
23
Please see the chapter on :ref:`floating point arithmetic <tut-fp-issues>` in the Python tutorial for more information.