On Mon, Sep 29, 2008 at 20:22, Charles R Harris <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 29, 2008 at 4:28 PM, Robert Kern <[EMAIL PROTECTED]> wrote: >> >> On Mon, Sep 29, 2008 at 17:13, Charles R Harris >> <[EMAIL PROTECTED]> wrote: >> > >> > On Mon, Sep 29, 2008 at 3:52 PM, Charles R Harris >> > <[EMAIL PROTECTED]> wrote: >> >> >> >> Hi All, >> >> >> >> I've been cleaning up the ufunc loops and the sign function currently >> >> doesn't have a defined behavior for nans. This makes the results depend >> >> on >> >> the order/type of comparisons in the code, which looks fragile to me. >> >> So >> >> what should it return? I vote for nan but am open for suggestions. >> > >> > And while we're at it, lets decide how to treat max/min when nans are >> > involved. Or should we just say the behavior is undefined. >> >> When feasible, I would like float(s)->float functions to return NaN >> when given a NaN as an argument. At least as the main versions of the >> function. Specific NaN-ignoring functions can also be introduced, but >> as separate functions. I don't know what exactly to do about >> float->int functions (e.g. argmin). I also don't know how these should >> interact with the current seterr() state. > > OK, maximum, minimum, and sign now return NaN.
Oops! F.9.9.2 The fmax functions 1 If just one argument is a NaN, the fmax functions return the other argument (if both arguments are NaNs, the functions return a NaN). 2 The body of the fmax function might be {return (isgreaterequal(x, y) || isnan(y)) ? x : y; } If we want to follow C99 semantics rather than our own NaN-always-propagates semantics, then we should do this instead. -- 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