float("nan") in set or as key

Chris Torek nospam at torek.net
Sun May 29 20:02:02 EDT 2011


Incidentally, note:

    $ python
    ...
    >>> nan = float("nan")
    >>> nan
    nan
    >>> nan is nan
    True
    >>> nan == nan
    False

In article <4de1e3e7$0$2195$742ec2ed at news.sonic.net>
John Nagle  <nagle at animats.com> wrote:
>    The correct answer to "nan == nan" is to raise an exception, because
>you have asked a question for which the answer is nether True nor False.

Well, in some sense, the "correct answer" depends on which question
you *meant* to ask. :-)  Seriously, some (many?) instruction sets
have two kinds of comparison instructions: one that raises an
exception here, and one that does not.

>    The correct semantics for IEEE floating point look something like
>this:
>
>       1/0             INF
>       INF + 1         INF
>       INF - INF       NaN
>       INF == INF      unordered
>       NaN == NaN      unordered
>
>INF and NaN both have comparison semantics which return
>"unordered". The FPU sets a bit for this, which most language
>implementations ignore.

Again, this depends on the implementation.

This is similar to (e.g.) the fact that on the MIPS, there are two
different integer add instructions ("addi" and "addiu"): one
raises an overflow exception, the other performs C "unsigned"
style arithmetic (where, e.g., 0xffffffff + 1 = 0, in 32 bits).

>Python should raise an exception on unordered comparisons.
>Given that the language handles integer overflow by going to
>arbitrary-precision integers, checking the FPU status bits is
>cheap.

I could go for that myself.  But then you also need a "don't raise
exception but give me an equality test result" operator (for various
special-case purposes at least) too.  Of course a simple "classify
this float as one of normal, subnormal, zero, infinity, or NaN"
operator would suffice here (along with the usual "extract sign"
and "differentiate between quiet and signalling NaN" operations).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html



More information about the Python-list mailing list