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.
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to