[Numpy-discussion] Intel random number package

Todd toddrjen at gmail.com
Thu Oct 27 10:52:48 EDT 2016

On Thu, Oct 27, 2016 at 10:43 AM, Julian Taylor <
jtaylor.debian at googlemail.com> wrote:

> On 10/27/2016 04:30 PM, Todd wrote:
>> On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers <ralf.gommers at gmail.com
>> <mailto:ralf.gommers at gmail.com>> wrote:
>>     On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr
>>     <oleksandr.pavlyk at intel.com <mailto:oleksandr.pavlyk at intel.com>>
>> wrote:
>>         Please see responses inline.
>>         *From:*NumPy-Discussion
>>         [mailto:numpy-discussion-bounces at scipy.org
>>         <mailto:numpy-discussion-bounces at scipy.org>] *On Behalf Of *Todd
>>         *Sent:* Wednesday, October 26, 2016 4:04 PM
>>         *To:* Discussion of Numerical Python <numpy-discussion at scipy.org
>>         <mailto:numpy-discussion at scipy.org>>
>>         *Subject:* Re: [Numpy-discussion] Intel random number package
>>         On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr
>>         <oleksandr.pavlyk at intel.com <mailto:oleksandr.pavlyk at intel.com>>
>>         wrote:
>>             Another point already raised by Nathaniel is that for
>>             numpy's randomness ideally should provide a way to override
>>             default algorithm for sampling from a particular
>>             distribution.  For example RandomState object that
>>             implements PCG may rely on default acceptance-rejection
>>             algorithm for sampling from Gamma, while the RandomState
>>             object that provides interface to MKL might want to call
>>             into MKL directly.
>>         The approach that pyfftw uses at least for scipy, which may also
>>         work here, is that you can monkey-patch the scipy.fftpack module
>>         at runtime, replacing it with pyfftw's drop-in replacement.
>>         scipy then proceeds to use pyfftw instead of its built-in
>>         fftpack implementation.  Might such an approach work here?
>>         Users can either use this alternative randomstate replacement
>>         directly, or they can replace numpy's with it at runtime and
>>         numpy will then proceed to use the alternative.
>>     The only reason that pyfftw uses monkeypatching is that the better
>>     approach is not possible due to license constraints with FFTW (it's
>>     GPL).
>> Yes, that is exactly why I brought it up.  Better approaches are also
>> not possible with MKL due to license constraints.  It is a very similar
>> situation overall.
> Its not that similar, the better approach is certainly possible with FFTW,
> the GPL is compatible with numpys license. It is only a concern users of
> binary distributions. Nobody provided the code to use fftw yet, but it
> would certainly be accepted.

Although it is technically compatible, it would make numpy effectively
GPL.  Suggestions for this have been explicitly rejected on these grounds

[1] https://github.com/numpy/numpy/issues/3485
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20161027/568f7e3a/attachment.html>

More information about the NumPy-Discussion mailing list