[Numpy-discussion] Intel random number package

Julian Taylor jtaylor.debian at googlemail.com
Wed Oct 26 12:00:21 EDT 2016

On 10/26/2016 10:59 AM, Ralf Gommers wrote:
> On Wed, Oct 26, 2016 at 8:33 PM, Julian Taylor
> <jtaylor.debian at googlemail.com <mailto:jtaylor.debian at 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.

More information about the NumPy-Discussion mailing list