Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

2020-02-05 Thread Ralf Gommers
On Wed, Feb 5, 2020 at 12:14 PM Eric Wieser wrote: > > scipy.linalg is a superset of numpy.linalg > > This isn't completely accurate - numpy.linalg supports almost all > operations* over stacks of matrices via gufuncs, but scipy.linalg does not > appear to. > > Eric > > *: not lstsq due to an un

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

2020-02-05 Thread Eric Wieser
> scipy.linalg is a superset of numpy.linalg This isn't completely accurate - numpy.linalg supports almost all operations* over stacks of matrices via gufuncs, but scipy.linalg does not appear to. Eric *: not lstsq due to an ungeneralizable public API On Wed, 5 Feb 2020 at 17:38, Ralf Gommers

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

2020-02-05 Thread Ralf Gommers
On Wed, Feb 5, 2020 at 10:01 AM Andreas Mueller wrote: > A bit late to the NEP 37 party. > I just wanted to say that at least from my perspective it seems a great > solution that will help sklearn move towards more flexible compute engines. > I think one of the biggest issues is array creation (i

Re: [Numpy-discussion] NEP 37: A dispatch protocol for NumPy-like modules

2020-02-05 Thread Andreas Mueller
A bit late to the NEP 37 party. I just wanted to say that at least from my perspective it seems a great solution that will help sklearn move towards more flexible compute engines. I think one of the biggest issues is array creation (including random arrays), and that's handled quite nicely with

Re: [Numpy-discussion] manylinux upgrade for numpy wheels

2020-02-05 Thread Matthew Brett
Hi, On Tue, Feb 4, 2020 at 10:38 PM Nathaniel Smith wrote: > > Pretty sure the 2010 and 2014 images both have much newer compilers than that. > > There are still a lot of users on CentOS 6, so I'd still stick to 2010 for > now on x86_64 at least. We could potentially start adding 2014 wheels for