[Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8

Robert Kern robert.kern at gmail.com
Thu May 2 09:28:55 EDT 2013


On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On 1 May 2013 23:12, "Charles R Harris" <charlesr.harris at gmail.com> wrote:
>>
>> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root <ben.root at ou.edu> wrote:
>>>
>>> So, to summarize the thread so far:
>>>
>>> Consensus:
>>> np.nanmean()
>>> np.nanstd()
>>> np.minmax()
>>> np.argminmax()
>>>
>>> Vague Consensus:
>>> np.sincos()
>>>
>>
>> If the return of sincos (cossin?) is an array, then it could be reshaped
>> to be exp(1j*x), which together with exp(2*pi*1j*x) would cover some pretty
>> common cases.

It couldn't be a mere reshape, since the complex dtype requires the
real and imag components to be adjacent to each other. They wouldn't
be so if sincos's return type is an array (nor even the cossin
alternative). It always requires a memory copy (except in the "who
cares?" case of a scalar). Composition with an efficient
np.tocomplex(real, imag) implementation would cover those use cases
whether sincos returns tuples or arrays.

> Ufuncs already have some convention for what to do with multiple output
> arguments, right? Presumably whatever they do is what sincos should do. (And
> minmax/argminmax likewise, for consistency, even if they aren't ufuncs.
> Though they could be generalized ufuncs, or minmax could be
> minimummaximum.reduce.)
>
> I haven't checked, but I assume that what multiple output argument ufuncs do
> is to return a tuple. You can't use a single array in the general case,
> because the multiple output types might not be homogenous.

Correct.

[~]
|19> np.modf.nout
2

[~]
|20> np.modf(np.linspace(0, 1, 5))
(array([ 0.  ,  0.25,  0.5 ,  0.75,  0.  ]), array([ 0.,  0.,  0.,  0.,  1.]))

--
Robert Kern



More information about the NumPy-Discussion mailing list