[Numpy-discussion] nan, sign, and all that
Stéfan van der Walt
Thu Oct 2 03:10:49 CDT 2008
2008/10/2 Robert Kern <firstname.lastname@example.org>:
>> 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
>> 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 : fmax(a,b)
>> Out: 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,
More information about the Numpy-discussion