On Thu, May 2, 2013 at 7:28 AM, Robert Kern <robert.kern@gmail.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
On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith <njs@pobox.com> wrote: 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.
Ufuncs already have some convention for what to do with multiple output arguments, right? Presumably whatever they do is what sincos should do. (And minmax/argminmax likewise, for consistency, even if they aren't ufuncs. Though they could be generalized ufuncs, or minmax could be minimummaximum.reduce.)
I haven't checked, but I assume that what multiple output argument ufuncs do is to return a tuple. You can't use a single array in the general case, because the multiple output types might not be homogenous.
Correct.
[~] |19> np.modf.nout 2
[~] |20> np.modf(np.linspace(0, 1, 5)) (array([ 0. , 0.25, 0.5 , 0.75, 0. ]), array([ 0., 0., 0., 0., 1.]))
-- Robert Kern _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion