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
