<
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.