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.