[Python-Dev] Rich comparisons [Was] redefining is (original) (raw)

Tim Peters tim.one at comcast.net
Fri Mar 19 18:14:14 EST 2004

[Andrew Koenig]

I believe that IEEE floating-point requires x == x to be False when x is NaN.

I'll just repeat a reply I made on comp.lang.python in a related thread:

[Andrew Koenig]

I'm pretty sure that IEEE floating point requires NaN to be defined in such a way that if x is NaN, then x == x must yield False.

Yes, but ... a conforming implementation of the standard requires all sorts of comparison operators, but it's not a language standard and doesn't have anything to say about how languages spell access to any of its facilities. So, e.g., there must be some way to spell an equality operator that doesn't consider a NaN to "be equal" to itself, but that doesn't need to be spelled "==" (not even in a language that has an "==" comparison operator). For example, it's fine if it needs to be spelled

ieee.equal_considering_nans_unequal_and_unexceptional(x, y)

[Erik Max Francis]

That's correct. Python itself doesn't do this, though:

All Python behavior wrt IEEE gimmicks is a platform-dependent accident -- nothing is promised.

Python 2.3.3 (#1, Dec 22 2003, 23:44:26) [GCC 3.2.3] on linux2 >>> a = 1e3000 >>> a inf >>> a/a nan >>> n = a/a >>> n == n True

While on Windows 2.3.3, the output looks very different, and the final result is False.

For Python 2.4, Michael Hudson has patched things so that Python's 6 float relationals deliver the same results the platform C compiler delivers for the spelled-the-same-way-in-C float relationals. There's still no cross-platform guarantee about what those will do (because C makes no guarantees here either), but at least NaN == NaN will be false on both gcc and MSVC7-based Pythons (MSVC6-based Pythons will say NaN == NaN is true then, but right now there are no plans to distribute an MSVC6-based Python 2.4).

More information about the Python-Dev mailing list