nospam at torek
May 29, 2011, 5:02 PM
Post #22 of 107
>>> nan = float("nan")
>>> nan is nan
>>> nan == nan
In article <4de1e3e7$0$2195$742ec2ed [at] news>
John Nagle <nagle [at] animats> 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
> 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
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
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