[Numpy-discussion] Apropos ticked #913

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Wed, Mar 4, 2009 at 1:57 PM, Pauli Virtanen <pav at iki.fi
> <mailto:pav at iki.fi>> wrote:
>
>     Wed, 04 Mar 2009 13:18:55 -0700, Charles R Harris wrote:
>     [clip]
>     > There are python max/min and their behaviour depends on the
>     scalar type.
>     > I haven't looked at the numpy scalars to see precisely what they do.
>     >
>     > Numpy max/min are aliases for amax/amin defined when the core is
>     > imported. The functions amax/amin in turn map to the array methods
>     > max/min which call the maximum.reduce/minimum.reduce ufuncs, so
>     they all
>     > propagate nans, i.e., if the array contains a nan, nan will be the
>     > return value.
>     >
>     > The nonpropagating comparisons are the ufuncs fmax/fmin and
>     there are no
>     > corresponding array methods. I think fmax/fmin should be renamed
>     > fmaximum/fminimum before the release of 1.3 and the names fmax/fmin
>     > reserved for the reduced versions to match the names amax/amin.
>     I'll do
>     > that if there are no objections.
>
>     Aren't the nonpropagating versions of `amax` and `amin` called
>     `nanmax`
>     and `nanmin`? But these are functions, not array methods.
>
>     What does the `f` in the beginning of `fmax` and `fmin` stand for?
>
>
> The functions fmax/fmin are C standard library names, I assume the f
> stands for floating like the f in fabs. Nanmax and nanmin work by
> replacing nans with a fill value and then performing the specified
> operation. For instance, nanmin replaces nans with inf. In contrast,
> the functions fmax and fmin are real ufuncs and return nan when *both*
> the inputs are nans, return the non-nan value when only one of the
> inputs is a nan, and do the normal comparisons when both inputs are valid.

Thanks for the clarification. I agree fmax/fmin is better because of the
C convention. We should clearly document the difference between those
function, though. Would you have time to implement something similar for
sort (sort is important for correct and relatively efficient support of
nanmedian I think) ? If not, that's ok, we'll do without for 1.3 series,

thanks,

David