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.
>
> Thoughts/advice/criticisms/etc?
Possibly the least-worst solution.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
