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

Robert Kern robert.kern at gmail.com
Thu May 2 11:43:41 EDT 2013


On Thu, May 2, 2013 at 3:57 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
> On Thu, May 2, 2013 at 8:40 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Thu, May 2, 2013 at 3:28 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> > On Thu, May 2, 2013 at 7:47 AM, Robert Kern <robert.kern at gmail.com>
>> > wrote:
>> >>
>> >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris
>> >> <charlesr.harris at gmail.com> wrote:
>> >> >
>> >> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern <robert.kern at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> 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.
>> >> >
>> >> > I would assume the basic return type would be complex, i.e., the
>> >> > cos/sin
>> >> > adjacent. The cos/sin parts would then be real/imag views into the
>> >> > array.
>> >>
>> >> You mean that the implementation of cossin (to make things easier on
>> >> ourselves) would create an (N,2) contiguous array, fill it with the
>> >> cos and sin results, then reshape it to return the expected (2,N)
>> >
>> > Just return the transpose.
>>
>> Yes, that's what I was getting at with that sentence. I don't doubt
>> that that is possible. The problem I was pointing out was in the
>> following sentence, which you snipped:
>>
>>   "How would the user then reconstitute the exp(1j*x) result efficiently?"
>>
>> Please show me the code that the user would write to compute exp(1j*x)
>> using np.cossin() without memory copies. My suspicion is that it will
>> be non-intuitive enough that it should always be hidden away into a
>> well-commented utility function. In that case, I think we should just
>> provide an np.exp1j() ufunc that just uses the C sincos() function
>> internally and let np.sincos()/np.cossin() do whatever is most natural
>> and consistent with other nout>1 ufuncs freed from the constraints of
>> this use case.
>
> As you say, have two functions, one of which would use the other with a
> view/transpose, whatever. For instance, given exp1j(), have another function
> that returns the real/imag parts. The question is what the underlying
> function should be and for that I think exp1j() would be a good choice.

I don't see why we would bother. Just implement them both as ufuncs
that use a C sincos() function internally and be done with it.
Implementing one in terms of the other requires that the other is not
a ufunc (a minor irritation) and always returns non-contiguous arrays
(a more substantial irritation). There isn't anything to be gained by
implementing one in terms of the other.

--
Robert Kern



More information about the NumPy-Discussion mailing list