[Numpy-discussion] nan, sign, and all that
Robert Kern
robert.kern@gmail....
Thu Oct 2 14:40:32 CDT 2008
On Thu, Oct 2, 2008 at 08:22, Charles R Harris
<charlesr.harris@gmail.com> wrote:
>
> On Thu, Oct 2, 2008 at 1:42 AM, Robert Kern <robert.kern@gmail.com> wrote:
>>
>> On Thu, Oct 2, 2008 at 02:37, Stéfan van der Walt <stefan@sun.ac.za>
>> wrote:
>> > Hi Charles,
>> >
>> > 2008/10/2 Charles R Harris <charlesr.harris@gmail.com>:
>> >> In [3]: a = array([NAN, 0, NAN, 1])
>> >> In [4]: b = array([0, NAN, NAN, 0])
>> >>
>> >> In [5]: fmax(a,b)
>> >> Out[5]: array([ 0., 0., NaN, 1.])
>> >>
>> >> In [6]: fmin(a,b)
>> >> Out[6]: array([ 0., 0., NaN, 0.])
>> >
>> > These are great, many thanks!
>> >
>> > 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.
>>
>> > 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.
>
> Yes. If there is any agreement on this I would like to go ahead and do it.
> It does change the current behavior of maximum and minimum.
I think the position we've held is that in the presence of NaNs, the
behavior of these functions have been left unspecified, so I think it
is okay to change them.
--
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