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

> On 10/27/2016 04:30 PM, Todd wrote:
>
>> On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers <ralf.gomm...@gmail.com
>> <mailto:ralf.gomm...@gmail.com>> wrote:
>>
>>
>>     On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr
>>     <oleksandr.pav...@intel.com <mailto:oleksandr.pav...@intel.com>>
>> wrote:
>>
>>         Please see responses inline.
>>
>>
>>
>>         *From:*NumPy-Discussion
>>         [mailto:numpy-discussion-boun...@scipy.org
>>         <mailto:numpy-discussion-boun...@scipy.org>] *On Behalf Of *Todd
>>         *Sent:* Wednesday, October 26, 2016 4:04 PM
>>         *To:* Discussion of Numerical Python <numpy-discussion@scipy.org
>>         <mailto:numpy-discussion@scipy.org>>
>>         *Subject:* Re: [Numpy-discussion] Intel random number package
>>
>>
>>
>>
>>         On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr
>>         <oleksandr.pav...@intel.com <mailto:oleksandr.pav...@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]

[1] https://github.com/numpy/numpy/issues/3485
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to