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.