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

    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

    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

Reply via email to