On 10/26/2016 06:00 PM, Julian Taylor wrote:
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.

But then if this is really just the same random numbers numpy already provides just faster, it is probably acceptable in principle. I haven't actually looked at the PR yet.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to