Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On 3/9/2018 8:26 AM, Ralf Gommers wrote: So my suggestion is discussion should happen on the list, and NEP updates should be merged promptly, or just self-merged. Sound good? Agreed that overall (1) is better than (2), rejec

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Thu, 08 Mar 2018 20:22:29 -0800, Nathaniel Smith wrote: > 1. We merge updates to the NEPs as we go, so that whatever's in the > repo is the current draft. Anyone can go to the NEP webpage at > http://numpy.org/neps (WIP, see #10702) to see the latest version of > all NEPs, whether accepted, reje

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Not that I’m against different “levels” of ndarray granularity, but I just don’t want it to introduce complexity for the end-user. For example, it would be unreasonable to expect the end-user to check for all parts of the interface that they need support for separately. Keeping this in view; diffe

Re: [Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Thu, Mar 8, 2018 at 8:22 PM, Nathaniel Smith wrote: > On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk > wrote: > > Hi Nathaniel, > > > > Overall, hugely in favour! For detailed comments, it would be good to > > have a link to a PR; could you put that up? > > Well, there's a PR here: http

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Thu, Mar 8, 2018 at 5:54 PM Juan Nunez-Iglesias wrote: > On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: > > Marten's case 1: works exactly like ndarray, but stores data differently: > parallel arrays (e.g., dask.array), sparse arrays (e.g., > https://github.com/pydata/sparse), hypotheti

[Numpy-discussion] Where to discuss NEPs (was: Re: new NEP: np.AbstractArray and np.asabstractarray)

On Thu, Mar 8, 2018 at 7:06 AM, Marten van Kerkwijk wrote: > Hi Nathaniel, > > Overall, hugely in favour! For detailed comments, it would be good to > have a link to a PR; could you put that up? Well, there's a PR here: https://github.com/numpy/numpy/pull/10706 But, this raises a question :-).

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

On Fri, Mar 9, 2018, at 5:56 AM, Stephan Hoyer wrote: > Marten's case 1: works exactly like ndarray, but stores data > differently: parallel arrays (e.g., dask.array), sparse arrays (e.g., > https://github.com/pydata/sparse), hypothetical non-strided arrays > (e.g., always C ordered). Two other "hy

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 1:52 AM, Gregor Thalhammer wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy > > I found it useful to inject (some of) the fa

[Numpy-discussion] NumPy 1.14.2 release

Hi All, I'm looking to make a NumPy soonish, possibly at the beginning of next week. The only change planned is a fix for the printing problem that the astropy folks reported. The fix for that problem is also in master, so if you test against master you should be able check if the fix works for yo

Re: [Numpy-discussion] numpy.random.randn

On Wed, 7 Mar 2018 13:14:36, Robert Kern wrote: > > With NumPy I'm simply using the following random initilization code: > > > > np.random.randn(n_h, n_x) * 0.01 > > > > I'm trying to emulate the same behaviour in my Scala code by sampling > from a > > Gaussian distribution with mean = 0 and std

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi Nathaniel, Thanks for starting the discussion! Like Marten says, I think it would be useful to more clearly define what it means to be an abstract array. ndarray has lots of methods/properties that expose internal implementation (e.g., view, strides) that presumably we don't want to require as

Re: [Numpy-discussion] New NEP: merging multiarray and umath

I think part of the problem is that ufuncs actually have two parts: a generic interface, which turns all its arguments into ndarray (or calls `__array_ufunc__`) and an ndarray-specific implementation of the given function (partially, just the iterator, partially the inner loop). The latter could lo

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 9:20 AM, Charles R Harris wrote: > > > On Thu, Mar 8, 2018 at 2:52 AM, Gregor Thalhammer < > gregor.thalham...@gmail.com> wrote: > >> >> Hi, >> >> long time ago I wrote a wrapper to to use optimised and parallelized math >> functions from Intels vector math library >> geggo

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 4:52 AM, Gregor Thalhammer wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy > > I found it useful to inject (some of) the fa

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 2:52 AM, Gregor Thalhammer < gregor.thalham...@gmail.com> wrote: > > Hi, > > long time ago I wrote a wrapper to to use optimised and parallelized math > functions from Intels vector math library > geggo/uvml: Provide vectorized math function (MKL) for numpy >

Re: [Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi Nathaniel, Overall, hugely in favour! For detailed comments, it would be good to have a link to a PR; could you put that up? A larger comment: you state that you think `np.asanyarray` is a mistake since `np.matrix` and `np.ma.MaskedArray` would pass through and that those do not strictly mimi

Re: [Numpy-discussion] New NEP: merging multiarray and umath

Hi, long time ago I wrote a wrapper to to use optimised and parallelized math functions from Intels vector math library geggo/uvml: Provide vectorized math function (MKL) for numpy I found it useful to inject (some of) the fast methods into numpy via np.set_nu

[Numpy-discussion] new NEP: np.AbstractArray and np.asabstractarray

Hi all, Here's a more substantive NEP: trying to define how to define a standard way for functions to say that they can accept any "duck array". Biggest open question for me: the name "asabstractarray" kinda sucks (for reasons described in the NEP), and I'd love to have something better. Any idea

Re: [Numpy-discussion] New NEP: merging multiarray and umath

On Thu, Mar 8, 2018 at 12:47 AM, Eric Wieser wrote: > This means that ndarray needs to know about ufuncs – so instead of a clean > layering, we have a circular dependency. > > Perhaps we should split ndarray into a base_ndarray class with no arithmetic > support (add, sum, etc), and then provide a

Re: [Numpy-discussion] New NEP: merging multiarray and umath

This means that ndarray needs to know about ufuncs – so instead of a clean layering, we have a circular dependency. Perhaps we should split ndarray into a base_ndarray class with no arithmetic support (*add*, sum, etc), and then provide an ndarray subclass from umath instead (either the separate e

[Numpy-discussion] New NEP: merging multiarray and umath

Hi all, Well, this is something that we've discussed for a while and I think generally has consensus already, but I figured I'd write it down anyway to make sure. There's a rendered version here: https://github.com/njsmith/numpy/blob/nep-0015-merge-multiarray-umath/doc/neps/nep-0015-merge-multiar