Incidentally, note: $ python ... >>> nan = float("nan") >>> nan nan >>> nan is nan True >>> nan == nan False
In article <4de1e3e7$0$2195$742ec...@news.sonic.net> John Nagle <na...@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
-- http://mail.python.org/mailman/listinfo/python-list