This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients mark.dickinson, rhettinger, scoder
Date 2021-05-06.09:47:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1620294473.58.0.212364469829.issue44054@roundup.psfhosted.org>
In-reply-to
Content
I'm not sure if I should consider this a bug, but I'd at least frown at the behaviour, so I thought I'd bring this up here.

Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
>>> 2**53 == float(2**53)
True
>>> float(2**53+1) == float(2**53+1)
True
>>> 2**53+1 == float(2**53+1)
False

This probably has something to do with the 52bit exponent of double precision floats. But the way I would have expected this to work is that a comparison of an integer to a float would first convert the integer to a float, and then compare the two floating point values. That's also what the code says. However, comparing the actual two floating point values gives the expected result, whereas letting the comparison do the conversion internally leads to a different outcome. The code in float_richcompare() uses a vastly more complex implementation than PyLong_AsDouble(), which is likely the reason for this difference in behaviour.

I found this on the system Python on 64bit Ubuntu 20.04, but also tried with a self-built 3.10a7+, giving the same result. I'm only setting the target to 3.10/11 since a potential behavioural change would likely not find its way back to 3.9 and earlier any more.
History
Date User Action Args
2021-05-06 09:47:53scodersetrecipients: + scoder, rhettinger, mark.dickinson
2021-05-06 09:47:53scodersetmessageid: <1620294473.58.0.212364469829.issue44054@roundup.psfhosted.org>
2021-05-06 09:47:53scoderlinkissue44054 messages
2021-05-06 09:47:53scodercreate