On Thu, May 2, 2013 at 3:57 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, May 2, 2013 at 8:40 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Thu, May 2, 2013 at 3:28 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, May 2, 2013 at 7:47 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Thu, May 2, 2013 at 2:38 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, May 2, 2013 at 7:28 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith <njs@pobox.com> wrote: > On 1 May 2013 23:12, "Charles R Harris" > <charlesr.harris@gmail.com> > wrote: >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root <ben.root@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