[Numpy-discussion] Intel random number package

Julian Taylor jtaylor.debian at googlemail.com
Thu Oct 27 10:43:40 EDT 2016

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.

More information about the NumPy-Discussion mailing list