Re: [Numpy-discussion] x.min() depends on ordering

[Charles R H. <cha...@gm...>]

On 11/11/06, Robert Kern <rob...@gm...> wrote:
>
> Keith Goodman wrote:
> > x.min() and x.max() depend on the ordering of the elements:
> >
> >>> x = M.matrix([[ M.nan, 2.0, 1.0]])
> >>> x.min()
> > nan
> >
> >>> x = M.matrix([[ 1.0, 2.0, M.nan]])
> >>> x.min()
> > 1.0
> >
> > If I were to try the latter in ipython, I'd assume, great, min()
> > ignores NaNs. But then the former would be a bug in my program.
> >
> > Is this related to how sort works?
>
> Not really. sort() is a more complicated algorithm that does a number of
> different comparisons in an order that is difficult to determine
> beforehand.
> x.min() should just be a straight pass through all of the elements.
> However, the
> core problem is the same: a < nan, a > nan, a == nan are all False for any
> a.
>
> Barring a clever solution (at least cleverer than I feel like being
> immediately), the way to solve this would be to check for nans in the
> array and
> deal with them separately (or simply ignore them in the case of x.min()).
> However, this checking would slow down the common case that has no nans
> (sans
> nans, if you will).


I think the problem is that the max and min functions use the first value in
the array as the starting point. That could be fixed by using the first
non-nan and returning nan if there aren't any "real" numbers.  But it
probably isn't worth the effort as the behavior becomes more complicated. A
better rule of thumb is to note that comparisons involving nans are
basically invalid because nans aren't comparable -- the comparison violates
trichotomy. Don't really know what to do about that.

Chuck