On Dec 8, 7:44 pm, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Mon, 08 Dec 2008 10:20:56 -0800, Rhamphoryncus wrote: > > 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, > > It's hardly mythical. > > http://ieeexplore.ieee.org/ISOL/standardstoc.jsp?punumber=4610933
I consider it to be mythical because most knowledge of it is indirect. Few who use floating point have the documents available to them. Requiring purchase/membership is the cause of this. > > 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*. > > Unordered means that none of the following is true: > > x > NaN > x < NaN > x == NaN > > It doesn't mean that comparing a NaN with something else is an error. Robert Kern already clarified that. My confusion was due to relying on second-hand knowledge. -- http://mail.python.org/mailman/listinfo/python-list