[Numpy-discussion] Intel random number package
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.
> [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>>
> 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
> 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