Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 3:57 PM, Charles R Harris wrote: > > On Thu, May 2, 2013 at 8:40 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 3:28 PM, Charles R Harris >> wrote: >> > >> > >> > On Thu, May 2, 2013 at 7:47 AM, Robert Kern >> > wrote: >> >> >> >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris >> >> wrote: >> >> > >> >> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern >> >> > wrote: >> >> >> >> >> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith >> >> >> wrote: >> >> >> > On 1 May 2013 23:12, "Charles R Harris" >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root >> >> >> >> 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. > > 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. I don't see why we would bother. Just implement them both as ufuncs that use a C sincos() function internally and be done with it. Implementing one in terms of the other requires that the other is not a ufunc (a minor irritation) and always returns non-contiguous arrays (a more substantial irritation). There isn't anything to be gained by implementing one in terms of the other. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 8:40 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 3:28 PM, Charles R Harris > wrote: > > > > > > On Thu, May 2, 2013 at 7:47 AM, Robert Kern > wrote: > >> > >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris > >> wrote: > >> > > >> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern > >> > wrote: > >> >> > >> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith > wrote: > >> >> > On 1 May 2013 23:12, "Charles R Harris" > > >> >> > wrote: > >> >> >> > >> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root > >> >> >> 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. > 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. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 3:28 PM, Charles R Harris wrote: > > > On Thu, May 2, 2013 at 7:47 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 2:38 PM, Charles R Harris >> wrote: >> > >> > On Thu, May 2, 2013 at 7:28 AM, Robert Kern >> > wrote: >> >> >> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: >> >> > On 1 May 2013 23:12, "Charles R Harris" >> >> > wrote: >> >> >> >> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root >> >> >> 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. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 7:47 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 2:38 PM, Charles R Harris > wrote: > > > > On Thu, May 2, 2013 at 7:28 AM, Robert Kern > wrote: > >> > >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > >> > On 1 May 2013 23:12, "Charles R Harris" > >> > wrote: > >> >> > >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root > 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. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 2:38 PM, Charles R Harris wrote: > > On Thu, May 2, 2013 at 7:28 AM, Robert Kern wrote: >> >> On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: >> > On 1 May 2013 23:12, "Charles R Harris" >> > wrote: >> >> >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 7:28 AM, Robert Kern wrote: > On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > > On 1 May 2013 23:12, "Charles R Harris" > wrote: > >> > >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root 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. > > > 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 > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, May 2, 2013 at 12:03 PM, Nathaniel Smith wrote: > On 1 May 2013 23:12, "Charles R Harris" wrote: >> >> On Wed, May 1, 2013 at 7:10 PM, Benjamin Root 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. > 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
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Thu, 2013-05-02 at 07:03 -0400, Nathaniel Smith wrote: > On 1 May 2013 23:12, "Charles R Harris" > wrote: > > > > > > > > On Wed, May 1, 2013 at 7:10 PM, Benjamin Root > 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. > > 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 think for sincos it makes sense, for an example a ufunc with multiple arguments is `np.modf`. But I doubt reductions are automatically defined for these, so minmax probably needs to be a generalized ufunc (can you have an axis argument with those?). - Sebastian > 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. > > -n > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On 1 May 2013 23:12, "Charles R Harris" wrote: > > > > On Wed, May 1, 2013 at 7:10 PM, Benjamin Root 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. 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. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
I have created a PR for the first two (and got np.nanvar() for free). https://github.com/numpy/numpy/pull/3297 Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 7:10 PM, Benjamin Root 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. No Consensus (possibly out of scope for this topic): > Better constructors for complex types > > I can probably whip up the PR for the nanmean() and nanstd(), and can > certainly help out with the minmax funcs. > > Cheers! > Ben Root > > Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
So, to summarize the thread so far: Consensus: np.nanmean() np.nanstd() np.minmax() np.argminmax() Vague Consensus: np.sincos() No Consensus (possibly out of scope for this topic): Better constructors for complex types I can probably whip up the PR for the nanmean() and nanstd(), and can certainly help out with the minmax funcs. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 6:52 AM, Benjamin Root wrote: > How about a tuple: (min, max)? > >> >> > I am not familiar enough with numpy internals to know which is the better > approach to implement. I kind of feel that the 2xN array approach would be > more flexible in case a user wants all of this information in a single > array, while still allowing for unpacking as if it was a tuple. > hmm, my thinking is that the min and max values really are two different results, so getting two separate arrays makes sense to me. however, you are right, Python's nifty generic sequence unpacking lets you use a (2X...) array similarly to a tuple of two arrays, so why not? Food for thought on one reason: min, max = np.minmax(arr) would result in two arrays, but they would be views on the same array, Not sure if that matters, though. -Chris -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 10:14 AM, Daπid wrote: > On 1 May 2013 03:36, Benjamin Root wrote: > > Are there any other functions that others feel are "missing" from numpy > and > > would like to see for v1.8? Let's discuss them here. > > I would like to have sincos, to compute sin and cos of the same number > faster. According to some benchmarks, it is barely slower than just > computing one of them. > > +1 Warren > > On 1 May 2013 07:13, Chris Barker - NOAA Federal > wrote: > >> Of course, the documentation for discussed before: np.minmax(). My > thinking is that it would return a 2xN array > > > > How about a tuple: (min, max)? > > Consider the case of np.minmax(matrix, axis=1), you will end up with a > tuple of two arrays. In that scenario, you probably want to do > computations with both numbers, so having them in an array seems more > convenient. > > If there is enough reason, we could always add a "unpack=True" flag > and then return a tuple. > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 4:22 PM, Daπid wrote: > On 1 May 2013 17:13, Todd wrote: >> Speaking of which, I think there should be a function to construct a complex >> array out of two identically-shaped floating-point arrays, as well as >> perhaps an np.i class that converts a real array to an imaginary one (using >> __mul__ and such). > > np.i would be exactly the same as array * 1j, or am I missing anything? I don't think we have a ufunc loop for multiply() that takes a float64 and a complex128 and returns a complex128. We just have a (complex128,complex128)->complex128. `x * 1j` first converts `x` to a complex128 array with the value in the real component, then multiplies that with 1j to move that value over to the imag component. A single operation that takes a float64 array and just makes a complex128 array with the values put in the imag component will reduce a temporary. > The same goes for constructing a complex, real + imag * 1j Similarly, we can eliminate two temporaries here. Both of the cases are probably best addressed by a single function. The syntactic sugar of an np.i object is unnecessary, IMO. imag = np.tocomplex(0.0, x) z = np.tocomplex(x, y) -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 5:22 PM, Daπid wrote: > On 1 May 2013 17:13, Todd wrote: > > Speaking of which, I think there should be a function to construct a > complex > > array out of two identically-shaped floating-point arrays, as well as > > perhaps an np.i class that converts a real array to an imaginary one > (using > > __mul__ and such). > > np.i would be exactly the same as array * 1j, or am I missing anything? > > The same goes for constructing a complex, real + imag * 1j > > > it would always produce a numpy array. So array*1j and array*np.i (or np.j if you prefer, perhaps both) would be the same, but list*1j and list*np.i would not. The function version would also probably allow you to specify the dtype, which 1j does not. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On 1 May 2013 17:13, Todd wrote: > Speaking of which, I think there should be a function to construct a complex > array out of two identically-shaped floating-point arrays, as well as > perhaps an np.i class that converts a real array to an imaginary one (using > __mul__ and such). np.i would be exactly the same as array * 1j, or am I missing anything? The same goes for constructing a complex, real + imag * 1j ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 4:06 PM, Zachary Ploskey wrote: > The sincos function is in the c standard library in math.h. I don't think it's part of the C99 standard. It appears to be provided in glibc as a non-standard extension. We would have to provide our own copy, but one is available in the Cephes library. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 3:36 AM, Benjamin Root wrote: > > Are there any other functions that others feel are "missing" from numpy > and would like to see for v1.8? Let's discuss them here. > As I mentioned before, I think numpy should have some equations for dealing with n-dimensional vectors (but would also work with complex dtypes). This would include n-dimensional equivalents of np.abs and np.angle, as well as a function to go back to an n-dimensional vector from the length and angle. Considering how critical vector analysis is to signal processing, I am surprised these don't already exist. There aren't even functions that work with 2-dimensional vectors, you have to construct a complex array first (which isn't that easy to do). Speaking of which, I think there should be a function to construct a complex array out of two identically-shaped floating-point arrays, as well as perhaps an np.i class that converts a real array to an imaginary one (using __mul__ and such). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
The sincos function is in the c standard library in math.h. On May 1, 2013 7:56 AM, "Juan Luis Cano" wrote: > On 05/01/2013 04:14 PM, Daπid wrote: > > On 1 May 2013 03:36, Benjamin Root wrote: > >> Are there any other functions that others feel are "missing" from numpy > and > >> would like to see for v1.8? Let's discuss them here. > > I would like to have sincos, to compute sin and cos of the same number > > faster. According to some benchmarks, it is barely slower than just > > computing one of them. > > Where does this `sincos` function come from? > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On 05/01/2013 04:14 PM, Daπid wrote: > On 1 May 2013 03:36, Benjamin Root wrote: >> Are there any other functions that others feel are "missing" from numpy and >> would like to see for v1.8? Let's discuss them here. > I would like to have sincos, to compute sin and cos of the same number > faster. According to some benchmarks, it is barely slower than just > computing one of them. Where does this `sincos` function come from? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On 1 May 2013 03:36, Benjamin Root wrote: > Are there any other functions that others feel are "missing" from numpy and > would like to see for v1.8? Let's discuss them here. I would like to have sincos, to compute sin and cos of the same number faster. According to some benchmarks, it is barely slower than just computing one of them. On 1 May 2013 07:13, Chris Barker - NOAA Federal wrote: >> Of course, the documentation for discussed before: np.minmax(). My thinking >> is that it would return a 2xN array > > How about a tuple: (min, max)? Consider the case of np.minmax(matrix, axis=1), you will end up with a tuple of two arrays. In that scenario, you probably want to do computations with both numbers, so having them in an array seems more convenient. If there is enough reason, we could always add a "unpack=True" flag and then return a tuple. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Wed, May 1, 2013 at 1:13 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > > Of course, the documentation for discussed before: np.minmax(). My > thinking is that it would return a 2xN array > > How about a tuple: (min, max)? > > I am not familiar enough with numpy internals to know which is the better approach to implement. I kind of feel that the 2xN array approach would be more flexible in case a user wants all of this information in a single array, while still allowing for unpacking as if it was a tuple. I would rather enable unforeseen use-cases rather than needlessly restricting them. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On Apr 30, 2013, at 6:37 PM, Benjamin Root wrote: > I can not think of any reason not to include these functions in v1.8. +1 > Of course, the documentation for discussed before: np.minmax(). My thinking > is that it would return a 2xN array How about a tuple: (min, max)? -Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
On 1 May 2013 03:36, Benjamin Root wrote: > There is one other non-trivial function that have been discussed before: > np.minmax(). My thinking is that it would return a 2xN array (where N is > whatever size of the result that would be returned if just np.min() was > used). This would allow one to do "min, max = np.minmax(X)". I had been looking for this function in the past, I think it is a good and necessary addition. It should also come with its companion, np.argminmax. David. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] nanmean(), nanstd() and other "missing" functions for 1.8
Currently, I am in the process of migrating some co-workers from Matlab and IDL, and the number one complaint I get is that numpy has nansum() but no nanmean() and nanstd(). While we do have an alternative in the form of masked arrays, most of these people are busy enough trying to port their existing code over to python that this sort of stumbling block becomes difficult to explain away. Given how relatively simple these functions are, I can not think of any reason not to include these functions in v1.8. Of course, the documentation for these functions should certainly include mention of masked arrays. There is one other non-trivial function that have been discussed before: np.minmax(). My thinking is that it would return a 2xN array (where N is whatever size of the result that would be returned if just np.min() was used). This would allow one to do "min, max = np.minmax(X)". Are there any other functions that others feel are "missing" from numpy and would like to see for v1.8? Let's discuss them here. Cheers! Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
