Rich Comparisons Gotcha

[Rhamphoryncus]

On Dec 8, 11:54 am, Robert Kern <robert.k... at gmail.com> wrote:
> Rhamphoryncus wrote:
> > On Dec 7, 4:20 pm, Steven D'Aprano <st... at REMOVE-THIS-
> > 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.


> > 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.