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
> 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
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
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
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