Milestone changed to 1.4.0 by @cournape on 2009-11-25

@charris wrote on 2010-01-05

I think this ticket is pretty much done.

sorts:

sort/argsort - sorts nans to end
searchsorted - works with sorted arrays containing nans

max/min:

max, amax, min, amin - propagate nans
argmax, argmin - non-propagating nans
fmax, fmin - non-propagating nans
fmax.reduce, fmin.reduce - non-propagating nans versions of maximum/minimum

max/argmax, min/argmin have incompatible behaviour, this needs a decision.

@charris wrote on 2010-01-05

Reformat

• sorts
  • sort/argsort - sorts nans to end
  • searchsorted - works with sorted arrays containing nans
• max/min
  • max, amax, min, amin - propagate nans
  • argmax, argmin - non-propagating nans
  • fmax, fmin - non-propagating nans
  • fmax.reduce, fmin.reduce - non-propagating nans versions of maximum/minimum

max/argmax, min/argmin have incompatible behaviour, this needs a decision.

@rgommers wrote on 2010-07-18

The priority of this is set as blocker, considering Charles comments I'm assuming that's no longer the case?

@pv wrote on 2010-07-18

Let's try to nevertheless address the comparison-related issues for 1.5.0.

The argmin and argmax behavior should be harmonized by r8509, they now propagate nans. The previous behavior was actually undefined (cf. #2027), not non-propagating, so I think we can just change it as any code relying on the previous behavior is invalid.

***

The last question is what should be done with complex nans. I think they should be defined as

• (z, nan), (nan, z), (nan, nan), where z is any fp value, are all equivalent representations of "cnan", as far as comparisons, sort order, etc are concerned.
• The ordering between (z, nan), (nan, z), (nan, nan) is undefined. This means e.g. that maximum([cnan_1, cnan_2]) can return either cnan_1 or cnan_2 if both are some cnans.

I didn't check if sort handles cnans this way, but the other parts should be in place.

I changed the comparison operations to treat cnans according to the above way in r8508, since I don't think it makes sense for us to have

>>> np.complex64(complex(1,np.nan)) < np.complex64(complex(2,0))
True

This change also fixes a bug where maximum/minimum were not propagating complex nans properly.

Milestone changed to 1.5.0 by @pv on 2010-07-18

@charris wrote on 2010-07-18

Sorts and searchsorted don't handle cnans that way. They use the following comparison:

NPY_INLINE static int
@TYPE@_LT(@type@ a, @type@ b)
{
    int ret;

    if (a.real < b.real) {
        ret = a.imag == a.imag || b.imag != b.imag;
    }
    else if (a.real > b.real) {
        ret = b.imag != b.imag && a.imag == a.imag;
    }
    else if (a.real == b.real || (a.real != a.real && b.real != b.real)) {
        ret =  a.imag < b.imag || (b.imag != b.imag && a.imag == a.imag);
    }
    else {
        ret = b.real != b.real;
    }

    return ret;
}

So that (z,z), (z, nan), (nan, z), (nan, nan) are in order. See the release notes for 1.4.0.

@mwiebe wrote on 2011-03-24

This looks like it's been dealt with.

Milestone changed to Unscheduled by @mwiebe on 2011-03-24

Milestone changed to 1.6.0 by @mwiebe on 2011-05-31