[Numpy-discussion] nan, sign, and all that

[Stéfan van der Walt]

2008/10/2 Robert Kern <robert.kern at gmail.com>:
>> My only gripe is that they have the same NaN-handling as amin and
>> friends, which I consider to be broken.
>
> No, these follow well-defined C99 semantics of the fmin() and fmax()
> functions in libm. If exactly one of the arguments is a NaN, the
> non-NaN argument is returned. This is *not* the current behavior of
> amin() et al., which just do naive comparisons.

Let me rephrase: I'm not convinced that these C99 semantics provide an
optimal user experience.  It worries me greatly that NaN's pop up in
operations and then disappear again.  It is entirely possible for a
script to run without failure and spew out garbage without the user
ever knowing.

>> Others also mentioned that
>> this should be changed, and I think David C wrote a patch for it (but
>> I am not informed as to the speed implications).
>>
>> If I had to choose, this would be my preferred output:
>>
>> In [5]: fmax(a,b)
>> Out[5]: array([  NaN,   NaN,  NaN,   1.])
>
> Chuck proposes letting minimum() and maximum() have that behavior.

That would be a good start, which would be complemented by educating
the user via some appropriate mechanism (I still don't know if one
exists; there is no NumPy Paperclip TM that states "You have decided
to commit scientific suicide.  Would you like me to cut your
wrists?").  That's meant only half-tongue-in-cheekedly :)

Thanks for your comments,

Cheers
Stéfan