Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 3:35 PM Nathan Goldbaum wrote: > Ah, but what if the dtype modifies the interface? That might sound evil, > but it's something that's been proposed. For example, if I wanted to > replace yt's YTArray in a backward compatibile way with a dtype and

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

I guess my argument boils down to it being better to state that a function only accepts arrays and happily let it break on, e.g., matrix, than use `asarray` to make a matrix into an array even though it really isn't. I do like the dtype ideas, but think I'd agree they're likely to come with their

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 5:21 PM, Stephan Hoyer wrote: > On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum > wrote: > >> Would this issue be ameliorated given Nathaniel's proposal to try to move >> away from subclasses and towards storing data in dtypes? Or

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 12:42 PM Nathan Goldbaum wrote: > Would this issue be ameliorated given Nathaniel's proposal to try to move > away from subclasses and towards storing data in dtypes? Or would that just > mean that xarray would need to ban dtypes it doesn't know

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 5:09 PM, Benjamin Root wrote: > Duck typing is great and all for classes that implement some or all of the > ndarray interface but remember what the main reason for asarray() and > asanyarray(): to automatically promote lists and tuples and other >

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

My 2¢ here is that all code should feel free to assume certain type of input, as long as it is documented properly, but there is no reason to enforce that by, e.g., putting `asarray` everywhere. Then, for some pieces ducktypes and subclasses will just work like magic, and uses you might never have

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 9:45 AM wrote: > similar, scipy.special has ufuncs > what units are those? > > Most code that I know (i.e. scipy.stats and statsmodels) does not use only > "normal mathematical operations with ufuncs" > I guess there are a lot of "abnormal"

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Josef, Indeed, for some applications one would like to have different units for different parts of an array. And that means that, at present, the quantity implementations that we have are no good at storing, say, a covariance matrix involving parameters with different units, where thus each

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 12:23 PM, Ryan May wrote: > On Thu, Nov 2, 2017 at 6:46 AM, wrote: > >> >> >> On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum >> wrote: >> >>> I think the biggest issues could be resolved if

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 6:46 AM, wrote: > > > On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum > wrote: > >> I think the biggest issues could be resolved if __array_concatenate__ >> were finished. Unfortunately I don't feel like I can take that on

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

Hi Josef, astropy's Quantity is well developed and would give similar results to pint; all those results make sense if one wants to have consistent units. A general library code will actually do the right thing as long as it just uses normal mathematical operations with ufuncs - and as long as

Re: [Numpy-discussion] is __array_ufunc__ ready for prime-time?

On Thu, Nov 2, 2017 at 8:46 AM, wrote: > > > On Wed, Nov 1, 2017 at 6:55 PM, Nathan Goldbaum > wrote: > >> I think the biggest issues could be resolved if __array_concatenate__ >> were finished. Unfortunately I don't feel like I can take that on