[Numpy-discussion] Intel random number package
Todd
toddrjen at gmail.com
Thu Oct 27 11:57:17 EDT 2016
It would still be compatible with SciPy, it would "just" mean that SciPy
(and anything else that uses numpy) would be effectively GPL.
On Thu, Oct 27, 2016 at 11:42 AM, Robert McLeod <robbmcleod at gmail.com>
wrote:
> Releasing NumPy under GPL would make it incompatible with SciPy, which may
> be _slightly_ inconvenient to the scientific Python community:
>
> https://scipy.github.io/old-wiki/pages/License_Compatibility.html
>
> https://mail.scipy.org/pipermail/scipy-dev/2013-August/019149.html
>
> Robert
>
> On Thu, Oct 27, 2016 at 5:14 PM, Julian Taylor <
> jtaylor.debian at googlemail.com> wrote:
>
>> On 10/27/2016 04:52 PM, Todd wrote:
>>
>>> On Thu, Oct 27, 2016 at 10:43 AM, Julian Taylor
>>> <jtaylor.debian at googlemail.com <mailto:jtaylor.debian at googlemail.com>>
>>> wrote:
>>>
>>> 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>
>>> <mailto: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>
>>> <mailto: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>
>>> <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>
>>> <mailto: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>
>>> <mailto: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.
>>>
>>>
>>> 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
>>>
>>>
>> Yes it would make numpy GPL, but that is not a concern for a lot of
>> users. Users for who it is a problem can still use the non-GPL version.
>> A more interesting debate is whether our binary wheels should then be GPL
>> wheels by default or not. Probably not, but that is something that should
>> be discussed when its an actual issue.
>>
>> But to clarify what I said, it would be accepted if the value it provides
>> is sufficient compared to the code maintenance it adds. Given that pyfftw
>> already exists the value is probably relatively small, but personally I'd
>> still be interested in code that allows switching the fft backend as that
>> could also allow plugging e.g. gpu based implementations (though again this
>> is already covered by other third party modules).
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
>
>
> --
> Robert McLeod, Ph.D.
> Center for Cellular Imaging and Nano Analytics (C-CINA)
> Biozentrum der Universität Basel
> Mattenstrasse 26, 4058 Basel
> Work: +41.061.387.3225
> robert.mcleod at unibas.ch
> robert.mcleod at bsse.ethz.ch <robert.mcleod at ethz.ch>
> robbmcleod at gmail.com
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20161027/0dbba6e2/attachment.html>
More information about the NumPy-Discussion
mailing list