[Numpy-discussion] min() of array containing NaN

[Robert Kern]

On Wed, Aug 13, 2008 at 14:37, Joe Harrington <jh at physics.ucf.edu> wrote:
>>On Tue, Aug 12, 2008 at 19:28, Charles R Harris
>><charlesr.harris at gmail.com> wrote:
>>>
>>>
>>> On Tue, Aug 12, 2008 at 5:13 PM, Andrew Dalke <dalke at dalkescientific.com>
>>> wrote:
>>>>
>>>> On Aug 12, 2008, at 9:54 AM, Anne Archibald wrote:
>>>> > Er, is this actually a bug? I would instead consider the fact that
>>>> > np.min([]) raises an exception a bug of sorts - the identity of min is
>>>> > inf.
>>>
>>> <snip>
>>>
>>>>
>>>> Personally, I expect that if my array 'x' has a NaN then
>>>> min(x) must be a NaN.
>>>
>>> I suppose you could use
>>>
>>> min(a,b) = (abs(a - b) + a + b)/2
>>>
>>> which would have that effect.
>
>>Or we could implement the inner loop of the minimum ufunc to return
>>NaN if there is a NaN. Currently it just compares the two values
>>(which causes the unpredictable results since having a NaN on either
>>side of the < is always False). I would be amenable to that provided
>>that the C isnan() call does not cause too much slowdown in the normal
>>case.
>
> While you're doing that, can you do it so that if keyword nan=False it
> returns NaN if NaNs exist, and if keyword nan=True it ignores NaNs?

I'm doing nothing. Someone else must volunteer.

But I'm not in favor of using a keyword argument. There is a
reasonable design rule that if you have a boolean argument which you
expect to only be passed literal Trues and Falses, you should instead
just have two different functions. Since we already have names staked
out for this alternate version (nanmin() and nanmax()), we might as
well use 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