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. > So the proposition is, sign, max, min return nan when any of the arguments is nan. +1 Complex numbers are more complicated because we first compare the real parts, then the imaginary. Arguably 1 > 0 + nan*1j. I propose that the sign of a complex number containing nans should be nan, but I can't decide what should happen with max/min Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
