Stefan Behnel <stefan...@behnel.de> added the comment:
> I really don't know why you would desire a different result. I found it surprising that a comparison uses a different method of conversion than the (obvious) user-side conversion, with a different outcome. This seems to be implementation details leaking into the user side. > "That's also what the code says." I wasn't referring to a specific comment. What I meant was that the code in float_richcompare() goes to great length trying to convert the integer to a float in a safe way so that it can compare the two values. https://github.com/python/cpython/blob/985ac016373403e8ad41f8d563c4355ffa8d49ff/Objects/floatobject.c#L403 I now see that it goes the other way at the end, though. If both values have the same order of magnitude, then it actually converts the float to a PyLong instead, thus choosing one of the integer values out of the value range that the float spans and comparing that. That's where the difference originates. > If you want to compare values approximately as floats, you should explicitly > convert them to floats. As I wrote, "I'm not sure if I should consider this a bug", because it's an area that we could just define as "out of bounds behaviour" and "user, you're on your own". The net effect is that some integers will never equal a floating point value, even though the floating point value does its very best to represent that integer. I can live with considering the current behaviour "as good as it gets, because there is no right way to do it". Thank you for your comments. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44054> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
