<br><br><div class="gmail_quote">On Thu, May 2, 2013 at 8:40 AM, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com" target="_blank">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, May 2, 2013 at 3:28 PM, Charles R Harris<br>
<div><div class="h5"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, May 2, 2013 at 7:47 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris<br>
>> <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
>> ><br>
>> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
>> >> > On 1 May 2013 23:12, "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root <<a href="mailto:ben.root@ou.edu">ben.root@ou.edu</a>><br>
>> >> >> wrote:<br>
>> >> >>><br>
>> >> >>> So, to summarize the thread so far:<br>
>> >> >>><br>
>> >> >>> Consensus:<br>
>> >> >>> np.nanmean()<br>
>> >> >>> np.nanstd()<br>
>> >> >>> np.minmax()<br>
>> >> >>> np.argminmax()<br>
>> >> >>><br>
>> >> >>> Vague Consensus:<br>
>> >> >>> np.sincos()<br>
>> >> >>><br>
>> >> >><br>
>> >> >> If the return of sincos (cossin?) is an array, then it could be<br>
>> >> >> reshaped<br>
>> >> >> to be exp(1j*x), which together with exp(2*pi*1j*x) would cover some<br>
>> >> >> pretty<br>
>> >> >> common cases.<br>
>> >><br>
>> >> It couldn't be a mere reshape, since the complex dtype requires the<br>
>> >> real and imag components to be adjacent to each other. They wouldn't<br>
>> >> be so if sincos's return type is an array (nor even the cossin<br>
>> >> alternative). It always requires a memory copy (except in the "who<br>
>> >> cares?" case of a scalar). Composition with an efficient<br>
>> >> np.tocomplex(real, imag) implementation would cover those use cases<br>
>> >> whether sincos returns tuples or arrays.<br>
>> ><br>
>> > I would assume the basic return type would be complex, i.e., the cos/sin<br>
>> > adjacent. The cos/sin parts would then be real/imag views into the<br>
>> > array.<br>
>><br>
>> You mean that the implementation of cossin (to make things easier on<br>
>> ourselves) would create an (N,2) contiguous array, fill it with the<br>
>> cos and sin results, then reshape it to return the expected (2,N)<br>
><br>
> Just return the transpose.<br>
<br>
</div></div>Yes, that's what I was getting at with that sentence. I don't doubt<br>
that that is possible. The problem I was pointing out was in the<br>
following sentence, which you snipped:<br>
<div class="im"><br>
  "How would the user then reconstitute the exp(1j*x) result efficiently?"<br>
<br>
</div>Please show me the code that the user would write to compute exp(1j*x)<br>
using np.cossin() without memory copies. My suspicion is that it will<br>
be non-intuitive enough that it should always be hidden away into a<br>
well-commented utility function. In that case, I think we should just<br>
provide an np.exp1j() ufunc that just uses the C sincos() function<br>
internally and let np.sincos()/np.cossin() do whatever is most natural<br>
and consistent with other nout>1 ufuncs freed from the constraints of<br>
this use case.<br></blockquote><div><br>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.<br>
<br>Chuck <br></div><br></div>