Skip to content

[3.12] gh-104479: Update outdated tutorial floating-point reference (GH-104681) #104960

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 26, 2023
Merged

[3.12] gh-104479: Update outdated tutorial floating-point reference (GH-104681) #104960

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 13 additions & 10 deletions Doc/tutorial/floatingpoint.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,7 +148,7 @@ Binary floating-point arithmetic holds many surprises like this. The problem
with "0.1" is explained in precise detail below, in the "Representation Error"
section. See `Examples of Floating Point Problems
<https://jvns.ca/blog/2023/01/13/examples-of-floating-point-problems/>`_ for
a pleasant summary of how binary floating point works and the kinds of
a pleasant summary of how binary floating-point works and the kinds of
problems commonly encountered in practice. Also see
`The Perils of Floating Point <https://www.lahey.com/float.htm>`_
for a more complete account of other common surprises.
Expand All @@ -174,7 +174,7 @@ Another form of exact arithmetic is supported by the :mod:`fractions` module
which implements arithmetic based on rational numbers (so the numbers like
1/3 can be represented exactly).

If you are a heavy user of floating point operations you should take a look
If you are a heavy user of floating-point operations you should take a look
at the NumPy package and many other packages for mathematical and
statistical operations supplied by the SciPy project. See <https://scipy.org>.

Expand Down Expand Up @@ -268,12 +268,14 @@ 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.

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 is not exactly representable as a binary fraction. Since at
least 2000, almost all machines use IEEE 754 binary floating-point arithmetic,
and almost all platforms map Python floats to IEEE 754 binary64 "double
precision" values. IEEE 754 binary64 values 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)

Expand Down Expand Up @@ -308,7 +310,8 @@ by rounding up:
>>> q+1
7205759403792794

Therefore the best possible approximation to 1/10 in 754 double precision is::
Therefore the best possible approximation to 1/10 in IEEE 754 double precision
is::

7205759403792794 / 2 ** 56

Expand All @@ -321,7 +324,7 @@ 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:
above, the best IEEE 754 double approximation it can get:

.. doctest::

Expand Down