On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote: > > Rasmus Fogh wrote: > > >> Current behaviour is both inconsistent and counterintuitive, as these > >> examples show. > > >>>>> x = float('NaN') > >>>>> x == x > >> False > > > Blame IEEE for that one. Rich comparisons have nothing to do with that > > one. > > There is nothing to blame them for. This is the correct behaviour. NaNs > should *not* compare equal to themselves, that's mathematically > incoherent.
Mathematically, NaNs shouldn't be comparable at all. They should raise an exception when compared. In fact, they should raise an exception when *created*. But that's not what we want. What we want is a dummy value that silently plods through our calculations. For a dummy value it seems a lot more sense to pick an arbitrary yet consistent sort order (I suggest just above -Inf), rather than quietly screwing up the sort. Regarding the mythical IEEE 754, although it's extremely rare to find quotations, I have one on just this subject. And it does NOT say "x == NaN gives false". It says it gives *unordered*. It is C and probably most other languages that turn that into false (as they want a dummy value, not an error.) http://groups.google.ca/group/sci.math.num-analysis/browse_thread/thread/ead0392e646b7cc0/a5bc354cd46f2c49?lnk=st&q=why+does+NaN+not+equal+itself%3F&rnum=3&hl=en&pli=1 -- http://mail.python.org/mailman/listinfo/python-list