Rich Comparisons Gotcha

[Rhamphoryncus]

On Dec 8, 7:44 pm, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Mon, 08 Dec 2008 10:20:56 -0800, 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.
>
> > 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.