On Dec 8, 1:04 pm, Robert Kern <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote: > >> 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. > >> Well, there are explicitly two kinds of NaNs: signalling NaNs and quiet > >> NaNs, to > >> accommodate both requirements. Additionally, there is significant > >> flexibility in > >> trapping the signals. > > > Right, but most of that's lower level. By the time it reaches Python > > we only care about quiet NaNs. > > No, signaling NaNs raise the exception that you are asking for. You're right > that if you get a Python float object that is a NaN, it is probably going to > be > quiet, but signaling NaNs can affect Python in the way that you want. > > >>> 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/thr... > >> Table 4 on page 9 of the standard is pretty clear on the subject. When the > >> two > >> operands are unordered, the operator == returns False. The standard > >> defines how > >> to do comparisons notionally; two operands can be "greater than", "less > >> than", > >> "equal" or "unordered". It then goes on to map these notional concepts to > >> programming language boolean predicates. > > > Ahh, interesting. Still though, does it give an explanation for such > > behaviour, or use cases? There must be some situation where blindly > > returning false is enough benefit to trump screwing up sorting. > > Well, the standard was written in the days of Fortran. You didn't really have > generic sorting routines. You *could* implement whatever ordering you wanted > because you *had* to implement the ordering yourself. You didn't have to use a > limited boolean predicate. > > Basically, the boolean predicates have to return either True or False. Neither > one is really satisfactory, but that's the constraint you're under.
"We've always done it that way" is NOT a use case! Certainly, it's a factor, but it seems quite weak compared to the sort use case. I suppose what I'm hoping for is an small example program (one or a few functions) that needs the "always false" behaviour of NaN. -- http://mail.python.org/mailman/listinfo/python-list