On Thu, Oct 2, 2008 at 08:22, Charles R Harris <[EMAIL PROTECTED]> wrote: > > 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.
I think the position we've held is that in the presence of NaNs, the behavior of these functions have been left unspecified, so I think it is okay to change them. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
