On Thu, Oct 2, 2008 at 1:42 AM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 2, 2008 at 02:37, Stéfan van der Walt <[EMAIL PROTECTED]> > wrote: > > Hi Charles, > > > > 2008/10/2 Charles R Harris <[EMAIL PROTECTED]>: > >> 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
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion