[issue33022] Floating Point Arithmetic Inconsistency (internal off-by-one)

[Tim Peters]

Tim Peters <tim at python.org> added the comment:

What did you expect?  The precision of Python ints is limited only by the amount of memory you have, but Python floats are IEEE-754 double precision numbers, and have only 53 bits of precision.

2**53 + 1 simply can't be represented exactly as a float:  it requires 54 significant bits.  It must be rounded back to 53 significant bits.  Because the exact value of 2**53 + 1 is exactly half-way between the adjacent representable floats 2**53 and 2**53+2, the IEEE "round to nearest/even" rule requires rounding to the closest representable value whose 53rd (the least) significant bit is 0, which is 2**53.

Note that the 53rd bit of 9007199254740994.0 (2**53 + 2) is odd (1):

>>> (9007199254740994.0).hex()
'0x1.0000000000001p+53'
                 ^

That's why the nearest/even rule _must_ pick 2**53 instead.

You'll see the same behavior in every other language (C, C++, Java, ...) supporting IEEE-754 double precision too.

Since this really has nothing to do with Python, and is working as intended, I'll close this.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33022>
_______________________________________