[Numpy-discussion] Intel random number package

[Robert McLeod]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20161027/5df90422/attachment.html>