On Mon, Sep 29, 2008 at 4:54 PM, Charles R Harris <[EMAIL PROTECTED] > wrote:
> > > On Mon, Sep 29, 2008 at 4:40 PM, 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. >>> >> >> So the proposition is, sign, max, min return nan when any of the arguments >> is nan. >> >> +1 >> > > I also propose that all logical operators involving nan return false, i.e., > ==, !=, <, <=, >, >=, and, or, xor, not. > > Currently this is so except for !=. On my machine nan != nan is true. Looks like it is being computed in C as !(nan == nan). Hmm, anyone know of a C standard on this? Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
