[Numpy-discussion] sorting -inf, nan, inf

Tim Hochberg tim.hochberg at ieee.org
Tue Sep 19 15:21:56 CDT 2006

A. M. Archibald wrote:
> On 19/09/06, Tim Hochberg <tim.hochberg at ieee.org> wrote:
>> Keith Goodman wrote:
>>> In what order would you like argsort to sort the values -inf, nan, inf?
>> Ideally, -inf should sort first, inf should sort last and nan should
>> raise an exception if present.
>> -tim
> Mmm. Somebody who's working with NaNs has more or less already decided
> they don't want to be pestered with exceptions for invalid data.
Do you really think so? In my experience NaNs are nearly always just an 
indication of a mistake somewhere that didn't get trapped for one reason 
or another.

>  I'd
> be happy if they wound up at either end, but I'm not sure it's worth
> hacking up the sort algorithm when a simple isnan() can pull them out.
Moving them to the end seems to be the worst choice to me. Leaving them 
alone is fine with me. Or raising an exception would be fine. Or doing 
one or the other depending on the error mode settings would be even 
better if it is practical.

> What's happening now is that NaN<a, NaN==a, and NaN>a are all false,
> which rather confuses the sorting algorithm. But as long as it doesn't
> actually *break* (that is, leave some of the non-NaNs incorrectly
> sorted) I don't care.
Is that true? Are all of numpy's sorting algorithms robust against 
nontransitive objects laying around? The answer to that appears to be 
no. Try running this a couple of times to see what I mean:

n = 10
for i in range(10):
    for kind in 'quicksort', 'heapsort', 'mergesort':
             a = rand(n)
             b = a.copy()
             a[n//2] = nan
             assert alltrue(a[:n//2] == b[:n//2]), (kind, a, b)

The values don't correctly cross the inserted NaN and the sort is incorrect.


More information about the Numpy-discussion mailing list