On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr < > oleksandr.pav...@intel.com> wrote: > >> Please see responses inline. >> >> >> >> *From:* NumPy-Discussion [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> >> *Subject:* Re: [Numpy-discussion] Intel random number package >> >> >> >> On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr < >> 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.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion