[Python-Dev] Weekly Python Bug/Patch Summary

Tim Peters tim.one at comcast.net
Wed Feb 18 21:35:18 EST 2004


[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<NaN and NaN<1 are both false,

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).




More information about the Python-Dev mailing list