Comparisons of incompatible types

[Steven D'Aprano]

On Wed, 08 Dec 2010 20:16:57 -0800, John Nagle wrote:

>     Here's an example where this issue produces invalid results in
>     Python.
> 
>  >>> NaN = float("nan")
>  >>> arr = [1.0, 4.0, 3.0, 2.0, 5.0, NaN, 6.0, 3.0, NaN, 0.0, 1.0, 4.0,
> 3.0, 2.0, 5.0, NaN, 6.0, 3.0, NaN, 0.0]
>  >>> sorted(arr)
> [0.0, 0.0, 1.0, 1.0, 2.0, 2.0, 3.0, 3.0, 3.0, 3.0, 4.0, 5.0, nan, 5.0,
> 6.0, nan, 4.0, nan, 6.0, nan]
> 
> The sorted numerical values aren't in order. Note the 4.0 near the end,
> after the 6.0.  "sort" has failed because it assumes that a < b and b <
> c implies a < c. But that's not a valid assumption here.
> 
> It's not good to break trichotomy.

It's perfectly fine to break trichotomy. People do it all the time -- 
they prefer chicken to pizza, pizza to steak, but prefer steak to 
chicken. (Modulo whatever foods you prefer. Or sports, or politicians, or 
any one of many things which don't make up an equivalence relationship.) 
Equivalence relationships make up only a tiny portion of relationships, 
and it is both useful and conventional to use the same operators in both 
situations. 

What's not good is to assume trichotomy when it doesn't apply, but that's 
no different from any other faulty assumption, e.g. a coder who assumes 
multiplication is always commutative may be puzzled why his matrix 
calculations are frequently wrong.

Python's sort assumes trichotomy, even when sorting floats. Perhaps it 
shouldn't. But one way or another, that's an issue with sort, not with 
the idea that there are data types where trichotomy doesn't apply. And 
like it or not, floats are one of those data types, just as neither 
commutativity nor associativity applies to floats -- even excluding NANs 
and INFs.



-- 
Steven