[Jeff Epler]

[I apologize that I'm not adding this information to the bug report, but I'm not able to log into SF right now, the login page hangs while loading]

1==float('nan') (2004-02-17) http://python.org/sf/899109 opened by Arman Bostani

I'm sure Tim can explain this better,

No, but I can give a simpler <wink> explanation: it's all accidents, and can (and does) vary across platforms. To start with, that float('nan') didn't raise an exception is an accident already. On Windows, e.g., it does raise an exception.

but what happens is this: 1 is coerced to float for comparison. Then, the following C expression is evaluated Objects/floatobject.c:float_compare): return (i < j) ? -1 : (i > j) ? 1 : 0;

Provided you get that far, yes.

Because NaN is "unordered", 1

Another pair of accidents. C89 says nothing about the behavior of NaNs, so what any particular C compiler does with them is another pile of platform accidents. C99 doesn't require C implementations to do better than that, but does specify what C implementations must do if they *choose* to advertise support for 754 gimmicks (it's not mandatory).

and so python returns 0 from float_compare.

That is one possible outcome <wink>. Here on 2.3.3, but on Windows:

...

...

inf = 1e500 inf 1.#INF nan = inf-inf nan -1.#IND cmp(1, nan) -1 cmp(nan, 1) -1 1 == nan False nan == nan False nan < nan True 1 < nan True nan < 1 True inf < nan True nan < inf True

That's under MSVC 6. I know an earlier version of the MS compiler gave different results. BTW, non-accidental support for IEEE-754 oddballs (infs, NaNs, signed zeroes) is a wishlist item in PEP 42. Come next year, that standard will be 20 years old -- yet basically unusable despite near-universal HW support because languages just won't play along (in fairness, "playing along" in SW isn't easy, and nobody will pay for it -- how the HW manufacturers got roped into it remains something of a mystery to me, cuz it's not cheap or easy in HW either).

[Jeff Epler]

Thanks for reminding me that this all varies from machine to machine. I guess that what I was trying to say in my message is this:

On my platform, I get the same result. Here's why.

The term "unordered" came from me reading an x86 architecture reference and trying to use the same words the grown-ups use.

That manual got "unordered" from the IEEE-754 floating point standard, and it's a fine word to use. The problem is that the 754 standard (which also goes under a number of different names now) has no defined relationship to the C89 standard, so when talking about C code it doesn't matter at all what the 754 standard says: "unordered" just isn't a C89 concept. 754 does have a defined relationship to the newer C99 standard.

It's too bad you can get infinity and nan other than by using float('os-specific mumbo-jumbo'), because if that weren't the case we could just force Python's syntax for floating-point literals on the argument to float(), never passing it to the platform atof() if it doesn't conform. That would, uh, completely solve all problems python programmers ever encounter with floats.

It would be easier to just remove floats from Python for 2.4 <wink>.

[Michael Hudson]

Would it make (more) sense to implement rich comparisons for floats?

Not much. There are 32 distinct theoretical binary comparison operators under 754 semantics (16 for which subset of {<, =, >, unordered} you're interested in, and then each of those comes in two flavors depending on whether you want a signaling NaN comparand to, or not to, raise an exception), and the standard "recommends" implementing something like 26 of them.

I'm not enthusiastic about the patch that got pasted into the bug report.

That's dead on arrival -- apart from the dubious semantics it's trying to invent, it doesn't even work under MSVC 6 (which I've explained in the bug report). There's no reliable cross-platform C support for any of this stuff, therefore there's nothing Python can do about 754 oddballs without masses of platform-specific code (see fpectlmodule.c for a taste of that approach).

[Michael Hudson]

...

...

Would it make (more) sense to implement rich comparisons for floats?

[Tim]

...

Not much.

[Michael]

But a little bit? It might at least make the results closer to what the underlying C compiler does (modulo bugs in same, of course).

The intended behavior of NaNs is covered precisely by standards. Moving Python's nonsense behavior closer to the platform C's nonsense behavior doesn't scream "useful" to me. But I don't object to it either, if someone can't think of something better to do with their time <wink>. At least gcc users would get something much closer to what the standard intends (although their Python wouldn't be portable in these respects). OTOH, by pure accident, NaN==NaN *happens* to return the intended False today under Windows Python, and if that's changed, via rich comparison, to return True (which MSVC returns for the C expression NaN==NaN), then we've also managed to break currently-working code on Windows. 754 really isn't friendly to half-assed support.

[Tim]

...

At least gcc users would get something much closer to what the standard intends (although their Python wouldn't be portable in these respects). OTOH, by pure accident, NaN==NaN *happens* to return the intended False today under Windows Python, and if that's changed, via rich comparison, to return True (which MSVC returns for the C expression NaN==NaN), then we've also managed to break currently-working code on Windows.

[Michael Hudson]

Is MSVC 7 any different here? I did try to poke around msdn.microsoft.com and found:

This version of Visual C++ is not conformant with the C99 standard.

which (a) was in a section about the library specifically and (b) doesn't answer the question. Oh, hang on:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndeepc/htm l/deep05282002.asp

suggests (very much) that this *has* changed. But "someone" should check (I can't).

I don't have 7 running here either, but that article flat-out says NaN comparisons work correctly now. I believe it -- after all, it's published on a Microsoft site, and so is reviewed by 79 major governments for lawsuit fodder <wink>.

(I certainly wasn't proposing this change for release23-maint).

We (Python) never promised anything about NaN behavior, so I don't really care if the "currently working" (by perverse accident) NaN==NaN result changes under MSVC 6.

...

754 really isn't friendly to half-assed support.

Indeed. But I think were the underlying compiler implements C99 semantics, it's unfriendly of Python to hide them.

That gets more involved; e.g., float operations should never raise exceptions then, not even division by 0 (although real 754 support includes ways to control whether exceptions get raised). I'm +1 on applying the patch for 2.4 regardless.