@@ -43,56 +43,45 @@ Why am I getting strange results with simple arithmetic operations?
4343See the next question.
4444
4545
46- Why are floating point calculations so inaccurate?
46+ Why are floating- point calculations so inaccurate?
4747--------------------------------------------------
4848
49- People are often very surprised by results like this::
49+ Users are often surprised by results like this::
5050
51- >>> 1.2 - 1.0
52- 0.199999999999999996
51+ >>> 1.2 - 1.0
52+ 0.199999999999999996
5353
54- and think it is a bug in Python. It's not. This has nothing to do with Python,
55- but with how the underlying C platform handles floating point numbers, and
56- ultimately with the inaccuracies introduced when writing down numbers as a
57- string of a fixed number of digits.
58-
59- The internal representation of floating point numbers uses a fixed number of
60- binary digits to represent a decimal number. Some decimal numbers can't be
61- represented exactly in binary, resulting in small roundoff errors.
54+ and think it is a bug in Python. It's not. This has little to do with Python,
55+ and much more to do with how the underlying platform handles floating-point
56+ numbers.
6257
63- In decimal math, there are many numbers that can't be represented with a fixed
64- number of decimal digits, e.g. 1/3 = 0.3333333333.......
58+ The :class: `float ` type in CPython uses a C ``double `` for storage. A
59+ :class: `float ` object's value is stored in binary floating-point with a fixed
60+ precision (typically 53 bits) and Python uses C operations, which in turn rely
61+ on the hardware implementation in the processor, to perform floating-point
62+ operations. This means that as far as floating-point operations are concerned,
63+ Python behaves like many popular languages including C and Java.
6564
66- In base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. .2 equals 2/10 equals 1/5,
67- resulting in the binary fractional number 0.001100110011001...
65+ Many numbers that can be written easily in decimal notation cannot be expressed
66+ exactly in binary floating-point. For example, after::
6867
69- Floating point numbers only have 32 or 64 bits of precision, so the digits are
70- cut off at some point, and the resulting number is 0.199999999999999996 in
71- decimal, not 0.2.
68+ >>> x = 1.2
7269
73- A floating point number's ``repr() `` function prints as many digits are
74- necessary to make ``eval(repr(f)) == f `` true for any float f. The ``str() ``
75- function prints fewer digits and this often results in the more sensible number
76- that was probably intended::
70+ the value stored for ``x `` is a (very good) approximation to the decimal value
71+ ``1.2 ``, but is not exactly equal to it. On a typical machine, the actual
72+ stored value is::
7773
78- >>> 1.1 - 0.9
79- 0.20000000000000007
80- >>> print(1.1 - 0.9)
81- 0.2
74+ 1.0011001100110011001100110011001100110011001100110011 (binary)
8275
83- One of the consequences of this is that it is error-prone to compare the result
84- of some computation to a float with ``== ``. Tiny inaccuracies may mean that
85- ``== `` fails. Instead, you have to check that the difference between the two
86- numbers is less than a certain threshold::
76+ which is exactly::
8777
88- epsilon = 0.0000000000001 # Tiny allowed error
89- expected_result = 0.4
78+ 1.1999999999999999555910790149937383830547332763671875 (decimal)
9079
91- if expected_result-epsilon <= computation() <= expected_result+epsilon:
92- .. .
80+ The typical precision of 53 bits provides Python floats with 15-16
81+ decimal digits of accuracy .
9382
94- Please see the chapter on :ref: `floating point arithmetic < tut-fp-issues >` in
95- the Python tutorial for more information .
83+ For a fuller explanation, please see the :ref: `floating point arithmetic
84+ <tut-fp-issues>` chapter in the Python tutorial .
9685
9786
9887Why are Python strings immutable?
0 commit comments