On 10/26/2016 10:59 AM, Ralf Gommers wrote:
On Wed, Oct 26, 2016 at 8:33 PM, Julian Taylor <jtaylor.deb...@googlemail.com <mailto:jtaylor.deb...@googlemail.com>> wrote: On 26.10.2016 06:34, Charles R Harris wrote: > Hi All, > > There is a proposed random number package PR now up on github: > https://github.com/numpy/numpy/pull/8209 <https://github.com/numpy/numpy/pull/8209>. It is from > oleksandr-pavlyk <https://github.com/oleksandr-pavlyk <https://github.com/oleksandr-pavlyk>> and implements > the number random number package using MKL for increased speed. I think > we are definitely interested in the improved speed, but I'm not sure > numpy is the best place to put the package. I'd welcome any comments on > the PR itself, as well as any thoughts on the best way organize or use > of this work. Maybe scikit-random Note that this thread is a continuation of https://mail.scipy.org/pipermail/numpy-discussion/2016-July/075822.html I'm not a fan of putting code depending on a proprietary library into numpy. This should be a standalone package which may provide the same interface as numpy. I don't really see a problem with that in principle. Numpy can use Intel MKL (and Accelerate) as well if it's available. It needs some thought put into the API though - a ``numpy.random_intel`` module is certainly not what we want.
For me there is a difference between being able to optionally use a proprietary library as an alternative to free software libraries if the user wishes to do so and offering functionality that only works with non-free software. We are providing a form of advertisement for them by allowing it (hey if you buy this black box that you cannot modify or use freely you get this neat numpy feature!).
I prefer for the full functionality of numpy to stay available with a stack of community owned software, even if it may be less powerful that way.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion