diff options
Diffstat (limited to 'Doc/tutorial/floatingpoint.rst')
| -rw-r--r-- | Doc/tutorial/floatingpoint.rst | 155 |
1 files changed, 81 insertions, 74 deletions
diff --git a/Doc/tutorial/floatingpoint.rst b/Doc/tutorial/floatingpoint.rst index 29c7a660e7..4b955701fd 100644 --- a/Doc/tutorial/floatingpoint.rst +++ b/Doc/tutorial/floatingpoint.rst @@ -48,74 +48,82 @@ decimal value 0.1 cannot be represented exactly as a base 2 fraction. In base 0.0001100110011001100110011001100110011001100110011... -Stop at any finite number of bits, and you get an approximation. This is why -you see things like:: +Stop at any finite number of bits, and you get an approximation. - >>> 0.1 - 0.10000000000000001 +On a typical machine running Python, there are 53 bits of precision available +for a Python float, so the value stored internally when you enter the decimal +number ``0.1`` is the binary fraction :: + + 0.00011001100110011001100110011001100110011001100110011010 -On most machines today, that is what you'll see if you enter 0.1 at a Python -prompt. You may not, though, because the number of bits used by the hardware to -store floating-point values can vary across machines, and Python only prints a -decimal approximation to the true decimal value of the binary approximation -stored by the machine. On most machines, if Python were to print the true -decimal value of the binary approximation stored for 0.1, it would have to -display :: +which is close to, but not exactly equal to, 1/10. + +It's easy to forget that the stored value is an approximation to the original +decimal fraction, because of the way that floats are displayed at the +interpreter prompt. Python only prints a decimal approximation to the true +decimal value of the binary approximation stored by the machine. If Python +were to print the true decimal value of the binary approximation stored for +0.1, it would have to display :: >>> 0.1 0.1000000000000000055511151231257827021181583404541015625 -instead! The Python prompt uses the built-in :func:`repr` function to obtain a -string version of everything it displays. For floats, ``repr(float)`` rounds -the true decimal value to 17 significant digits, giving :: +That is more digits than most people find useful, so Python keeps the number +of digits manageable by displaying a rounded value instead :: - 0.10000000000000001 + >>> 0.1 + 0.1 -``repr(float)`` produces 17 significant digits because it turns out that's -enough (on most machines) so that ``eval(repr(x)) == x`` exactly for all finite -floats *x*, but rounding to 16 digits is not enough to make that true. +It's important to realize that this is, in a real sense, an illusion: the value +in the machine is not exactly 1/10, you're simply rounding the *display* of the +true machine value. This fact becomes apparent as soon as you try to do +arithmetic with these values :: -Note that this is in the very nature of binary floating-point: this is not a bug -in Python, and it is not a bug in your code either. You'll see the same kind of -thing in all languages that support your hardware's floating-point arithmetic -(although some languages may not *display* the difference by default, or in all -output modes). + >>> 0.1 + 0.2 + 0.30000000000000004 -Python's built-in :func:`str` function produces only 12 significant digits, and -you may wish to use that instead. It's unusual for ``eval(str(x))`` to -reproduce *x*, but the output may be more pleasant to look at:: +Note that this is in the very nature of binary floating-point: this is not a +bug in Python, and it is not a bug in your code either. You'll see the same +kind of thing in all languages that support your hardware's floating-point +arithmetic (although some languages may not *display* the difference by +default, or in all output modes). - >>> print str(0.1) - 0.1 +Other surprises follow from this one. For example, if you try to round the +value 2.675 to two decimal places, you get this :: -It's important to realize that this is, in a real sense, an illusion: the value -in the machine is not exactly 1/10, you're simply rounding the *display* of the -true machine value. + >>> round(2.675, 2) + 2.67 -Other surprises follow from this one. For example, after seeing :: +The documentation for the built-in :func:`round` function says that it rounds +to the nearest value, rounding ties away from zero. Since the decimal fraction +2.675 is exactly halfway between 2.67 and 2.68, you might expect the result +here to be (a binary approximation to) 2.68. It's not, because when the +decimal string ``2.675`` is converted to a binary floating-point number, it's +again replaced with a binary approximation, whose exact value is :: - >>> 0.1 - 0.10000000000000001 + 2.67499999999999982236431605997495353221893310546875 -you may be tempted to use the :func:`round` function to chop it back to the -single digit you expect. But that makes no difference:: +Since this approximation is slightly closer to 2.67 than to 2.68, it's rounded +down. - >>> round(0.1, 1) - 0.10000000000000001 +If you're in a situation where you care which way your decimal halfway-cases +are rounded, you should consider using the :mod:`decimal` module. +Incidentally, the :mod:`decimal` module also provides a nice way to "see" the +exact value that's stored in any particular Python float :: -The problem is that the binary floating-point value stored for "0.1" was already -the best possible binary approximation to 1/10, so trying to round it again -can't make it better: it was already as good as it gets. + >>> from decimal import Decimal + >>> Decimal(2.675) + Decimal('2.67499999999999982236431605997495353221893310546875') -Another consequence is that since 0.1 is not exactly 1/10, summing ten values of -0.1 may not yield exactly 1.0, either:: +Another consequence is that since 0.1 is not exactly 1/10, summing ten values +of 0.1 may not yield exactly 1.0, either:: >>> sum = 0.0 >>> for i in range(10): ... sum += 0.1 ... >>> sum - 0.99999999999999989 + 0.9999999999999999 Binary floating-point arithmetic holds many surprises like this. The problem with "0.1" is explained in precise detail below, in the "Representation Error" @@ -131,9 +139,9 @@ that every float operation can suffer a new rounding error. While pathological cases do exist, for most casual use of floating-point arithmetic you'll see the result you expect in the end if you simply round the -display of your final results to the number of decimal digits you expect. -:func:`str` usually suffices, and for finer control see the :meth:`str.format` -method's format specifiers in :ref:`formatstrings`. +display of your final results to the number of decimal digits you expect. For +fine control over how a float is displayed see the :meth:`str.format` method's +format specifiers in :ref:`formatstrings`. .. _tut-fp-error: @@ -141,24 +149,24 @@ method's format specifiers in :ref:`formatstrings`. Representation Error ==================== -This section explains the "0.1" example in detail, and shows how you can perform -an exact analysis of cases like this yourself. Basic familiarity with binary -floating-point representation is assumed. +This section explains the "0.1" example in detail, and shows how you can +perform an exact analysis of cases like this yourself. Basic familiarity with +binary floating-point representation is assumed. :dfn:`Representation error` refers to the fact that some (most, actually) decimal fractions cannot be represented exactly as binary (base 2) fractions. This is the chief reason why Python (or Perl, C, C++, Java, Fortran, and many others) often won't display the exact decimal number you expect:: - >>> 0.1 - 0.10000000000000001 + >>> 0.1 + 0.2 + 0.30000000000000004 -Why is that? 1/10 is not exactly representable as a binary fraction. Almost all -machines today (November 2000) use IEEE-754 floating point arithmetic, and -almost all platforms map Python floats to IEEE-754 "double precision". 754 -doubles contain 53 bits of precision, so on input the computer strives to -convert 0.1 to the closest fraction it can of the form *J*/2**\ *N* where *J* is -an integer containing exactly 53 bits. Rewriting :: +Why is that? 1/10 and 2/10 are not exactly representable as a binary +fraction. Almost all machines today (July 2010) use IEEE-754 floating point +arithmetic, and almost all platforms map Python floats to IEEE-754 "double +precision". 754 doubles contain 53 bits of precision, so on input the computer +strives to convert 0.1 to the closest fraction it can of the form *J*/2**\ *N* +where *J* is an integer containing exactly 53 bits. Rewriting :: 1 / 10 ~= J / (2**N) @@ -170,24 +178,24 @@ and recalling that *J* has exactly 53 bits (is ``>= 2**52`` but ``< 2**53``), the best value for *N* is 56:: >>> 2**52 - 4503599627370496L + 4503599627370496 >>> 2**53 - 9007199254740992L + 9007199254740992 >>> 2**56/10 - 7205759403792793L + 7205759403792793 -That is, 56 is the only value for *N* that leaves *J* with exactly 53 bits. The -best possible value for *J* is then that quotient rounded:: +That is, 56 is the only value for *N* that leaves *J* with exactly 53 bits. +The best possible value for *J* is then that quotient rounded:: >>> q, r = divmod(2**56, 10) >>> r - 6L + 6 Since the remainder is more than half of 10, the best approximation is obtained by rounding up:: >>> q+1 - 7205759403792794L + 7205759403792794 Therefore the best possible approximation to 1/10 in 754 double precision is that over 2\*\*56, or :: @@ -195,8 +203,8 @@ that over 2\*\*56, or :: 7205759403792794 / 72057594037927936 Note that since we rounded up, this is actually a little bit larger than 1/10; -if we had not rounded up, the quotient would have been a little bit smaller than -1/10. But in no case can it be *exactly* 1/10! +if we had not rounded up, the quotient would have been a little bit smaller +than 1/10. But in no case can it be *exactly* 1/10! So the computer never "sees" 1/10: what it sees is the exact fraction given above, the best 754 double approximation it can get:: @@ -207,13 +215,12 @@ above, the best 754 double approximation it can get:: If we multiply that fraction by 10\*\*30, we can see the (truncated) value of its 30 most significant decimal digits:: - >>> 7205759403792794 * 10**30 / 2**56 + >>> 7205759403792794 * 10**30 // 2**56 100000000000000005551115123125L meaning that the exact number stored in the computer is approximately equal to -the decimal value 0.100000000000000005551115123125. Rounding that to 17 -significant digits gives the 0.10000000000000001 that Python displays (well, -will display on any 754-conforming platform that does best-possible input and -output conversions in its C library --- yours may not!). - - +the decimal value 0.100000000000000005551115123125. In versions prior to +Python 2.7 and Python 3.1, Python rounded this value to 17 significant digits, +giving '0.10000000000000001'. In current versions, Python displays a value +based on the shortest decimal fraction that rounds correctly back to the true +binary value, resulting simply in '0.1'. |