# NaN, Null, and Sorting

Steven D'Aprano steve+comp.lang.python at pearwood.info
Fri Jan 13 23:54:46 EST 2012

```On Fri, 13 Jan 2012 11:04:48 -0800, Ethan Furman wrote:

> With NaN, it is possible to get a list that will not properly sort:
>
> --> NaN = float('nan')
> --> spam = [1, 2, NaN, 3, NaN, 4, 5, 7, NaN] --> sorted(spam)
> [1, 2, nan, 3, nan, 4, 5, 7, nan]
>
> I'm constructing a Null object with the semantics that if the returned
> object is Null, it's actual value is unknown.
>
> From a purist point of view if it is unknown then comparison results
> are also unknown since the actual value might be greater, lesser, or the
> same as the value being compared against.

>From a purist point of view, NANs are unordered with respect to numbers,
and so one of two behaviours should occur:

(1) nan OP x should raise an exception, for all comparison operators
except == and !=

(2) nan OP x should return False for all OPs except !=

I believe the current version of the standard supports operators for both
sets of behaviour; the 1990s version of Apple's numeric framework (SANE)
included both.

I think Python chooses the second behaviour, although it may be version
and platform dependent. This is from Python 2.6:

>>> float('nan') < 0
False
>>> float('nan') > 0
False

I would expect the same behaviour for your Null objects. But as you say:

> From a practical point of view a list with Nulls scattered throughout
> is a pain in the backside.

And this is why sorting should be defined in terms of a separate sorting
operator, not < or >, so that lists containing unordered values like NANs,
Nulls, and complex numbers, can be sorted. "Sorted" is a property of the
list, not the values within the list.

> So I am strongly leaning towards implementing the comparisons such that
> Null objects are less than other objects so they will always sort
> together.
>