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

[Charles R Harris]

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.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130502/2b286039/attachment.html>