[Numpy-discussion] Intel random number package

[Julian Taylor]

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

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.