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

Robert Kern robert.kern@gmail....
Tue Sep 30 00:20:28 CDT 2008

On Mon, Sep 29, 2008 at 20:22, 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.
> OK, maximum, minimum, and sign now return NaN.


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

More information about the Numpy-discussion mailing list