[Numpy-discussion] Apropos ticked #913
David Cournapeau
david@ar.media.kyoto-u.ac...
Wed Mar 4 22:09:25 CST 2009
Charles R Harris wrote:
>
>
> On Wed, Mar 4, 2009 at 1:57 PM, Pauli Virtanen <pav@iki.fi
> <mailto:pav@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
More information about the Numpy-discussion
mailing list