<div dir="ltr">On Wed, Oct 26, 2016 at 9:36 AM, Sebastian Berg <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br>><br>> On Mi, 2016-10-26 at 09:29 -0700, Robert Kern wrote:<br>> > On Wed, Oct 26, 2016 at 9:10 AM, Julian Taylor <jtaylor.debian@google<br>> > <a href="http://mail.com">mail.com</a>> wrote:<br>> > ><br>> > > On 10/26/2016 06:00 PM, Julian Taylor wrote:<br>> ><br>> > >> I prefer for the full functionality of numpy to stay available<br>> > with a<br>> > >> stack of community owned software, even if it may be less powerful<br>> > that<br>> > >> way.<br>> > ><br>> > > But then if this is really just the same random numbers numpy<br>> > already provides just faster, it is probably acceptable in principle.<br>> > I haven't actually looked at the PR yet.<br>> ><br>> > I think the stream is different in some places, at least. And it's<br>> > not a silent backend drop-in like np.linalg being built against an<br>> > optimized BLAS, just a separate module that is inoperative without<br>> > MKL.<br>><br>> I might be swayed, but my gut feeling would be that a backend change<br>> (if the default stream changes, an explicit one, though maybe one could<br>> make a "fastest") would be the only reasonable way to provide such a<br>> thing in numpy itself.<br><br>That mostly argues for distributing it as a separate package, not part of numpy at all.<br><br>--<br>Robert Kern</div>