[Numpy-discussion] What is the sign of nan?

Charles R Harris charlesr.harris@gmail....
Mon Sep 29 18:10:03 CDT 2008


On Mon, Sep 29, 2008 at 4:54 PM, Charles R Harris <charlesr.harris@gmail.com
> wrote:

>
>
> On Mon, Sep 29, 2008 at 4:40 PM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Mon, Sep 29, 2008 at 4:28 PM, Robert Kern <robert.kern@gmail.com>wrote:
>>
>>> On Mon, Sep 29, 2008 at 17:13, Charles R Harris
>>> <charlesr.harris@gmail.com> wrote:
>>> >
>>> > On Mon, Sep 29, 2008 at 3:52 PM, Charles R Harris
>>> > <charlesr.harris@gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080929/99e84a67/attachment.html 


More information about the Numpy-discussion mailing list