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) array (or 2-tuple)? How would the user then reconstitute the exp(1j*x) result efficiently? If the use case is that important, I would just make exp(1j*x) into its own ufunc and have it use the C sincos() function internally. -- Robert Kern