[Numpy-discussion] nan, sign, and all that

[Charles R Harris]

On Thu, Oct 2, 2008 at 1:42 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, Oct 2, 2008 at 02:37, Stéfan van der Walt <stefan at sun.ac.za>
> wrote:
> > Hi Charles,
> >
> > 2008/10/2 Charles R Harris <charlesr.harris at gmail.com>:
> >> In [3]: a = array([NAN, 0, NAN, 1])
> >> In [4]: b = array([0, NAN, NAN, 0])
> >>
> >> In [5]: fmax(a,b)
> >> Out[5]: array([  0.,   0.,  NaN,   1.])
> >>
> >> In [6]: fmin(a,b)
> >> Out[6]: array([  0.,   0.,  NaN,   0.])
> >
> > These are great, many thanks!
> >
> > My only gripe is that they have the same NaN-handling as amin and
> > friends, which I consider to be broken.
>
> No, these follow well-defined C99 semantics of the fmin() and fmax()
> functions in libm. If exactly one of the arguments is a NaN, the
> non-NaN argument is returned. This is *not* the current behavior of
> amin() et al., which just do naive comparisons.
>
> > Others also mentioned that
> > this should be changed, and I think David C wrote a patch for it (but
> > I am not informed as to the speed implications).
> >
> > If I had to choose, this would be my preferred output:
> >
> > In [5]: fmax(a,b)
> > Out[5]: array([  NaN,   NaN,  NaN,   1.])
>
> Chuck proposes letting minimum() and maximum() have that behavior.
>

Yes. If there is any agreement on this I would like to go ahead and do it.
It does change the current behavior of maximum and minimum.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20081002/bb8316ab/attachment.html>