Is there special significance to 16331239353195370.0?

Using import numpy as np I've noticed that


gives the number in the title and not np.inf


I'm curious about this number. Is it related to some system machine precision parameter? Could I have calculated it from something? (I'm thinking along the lines of something similar to sys.float_info)

EDIT: The same result is indeed reproducible in other environments such as Java, octace, matlab... The suggested dupe does not explain why, though.

pi isn't exactly representable as Python float (same as the platform C's double type). The closest representable approximation is used.

Here's the exact approximation in use on my box (probably the same as on your box):

    >>> import math
    >>> (math.pi / 2).as_integer_ratio()
    (884279719003555, 562949953421312)

To find the tangent of that ratio, I'm going to switch to wxMaxima now:

    (%i1) fpprec: 32;
    (%o1) 32
    (%i2) tan(bfloat(884279719003555) / 562949953421312);
    (%o2) 1.6331239353195369755967737041529b16

So essentially identical to what you got. The binary approximation to pi/2 used is a little bit less than the mathematical ("infinite precision") value of pi/2. So you get a very large tangent instead of infinity. The computed tan() is appropriate for the actual input!

For exactly the same kinds of reasons, e.g.,

    >>> math.sin(math.pi)

doesn't return 0. The approximation math.pi is a little bit less than pi, and the displayed result is correct given that truth.


There are several ways to see the exact approximation in use:

    >>> import math
    >>> math.pi.as_integer_ratio()
    (884279719003555, 281474976710656)

math.pi is exactly equal to the mathematical ("infinite precision") value of that ratio.

Or as an exact float in hex notation:

    >>> math.pi.hex()

Or in a way most easily understood by just about everyone:

    >>> import decimal
    >>> decimal.Decimal(math.pi)

While it may not be immediately obvious, every finite binary float is exactly representable as a finite decimal float (the reverse is not true; e.g. the decimal 0.1 is not exactly representable as a finite binary float), and the Decimal(some_float) constructor produces the exact equivalent.

Here's the true value of pi followed by the exact decimal value of math.pi, and a caret on the third line points to the first digit where they differ:

    true    3.14159265358979323846264338327950288419716939937510...
    math.pi 3.141592653589793115997963468544185161590576171875

math.pi is the same across "almost all" boxes now, because almost all boxes now use the same binary floating-point format (IEEE 754 double precision). You can use any of the ways above to confirm that on your box, or to find the precise approximation in use if your box is an exception.


Back to homepage or read more recommendations: