[Numpy-discussion] performance matrix multiplication vs. matlab

Benoit Jacob jacob.benoit.1@gmail....
Sun Jan 17 14:40:02 CST 2010

2010/1/17 Robert Kern <robert.kern@gmail.com>:
> On Sun, Jan 17, 2010 at 13:18, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
>> 2010/1/17 Robert Kern <robert.kern@gmail.com>:
>>> On Sun, Jan 17, 2010 at 12:11, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
>>>> 2010/1/17 Robert Kern <robert.kern@gmail.com>:
>>>>> On Sun, Jan 17, 2010 at 08:52, Benoit Jacob <jacob.benoit.1@gmail.com> wrote:
>>>>>> 2010/1/17 David Cournapeau <cournape@gmail.com>:
>>>>>>> There are several issues with eigen2 for NumPy usage:
>>>>>>>  - using it as a default implementation does not make much sense IMHO,
>>>>>>> as it would make distributed binaries non 100 % BSD.
>>>>>> But the LGPL doesn't impose restrictions on the usage of binaries, so
>>>>>> how does it matter? The LGPL and the BSD licenses are similar as far
>>>>>> as the binaries are concerned (unless perhaps one starts disassembling
>>>>>> them).
>>>>>> The big difference between LGPL and BSD is at the level of source
>>>>>> code, not binary code: one modifies LGPL-based source code and
>>>>>> distributes a binary form of it, then one has to release the modified
>>>>>> source code as well.
>>>>> This is not true. Binaries that contain LGPLed code must be able to be
>>>>> relinked with a modified version of the LGPLed component.
>>>> This doesn't apply to Eigen which is a header-only pure template
>>>> library, hence can't be 'linked' to.
>>>> Actually you seem to be referring to Section 4 of the LGPL3, we have
>>>> already asked the FSF about this and their reply was that it just
>>>> doesn't apply in the case of Eigen:
>>>> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html
>>>> In your case, what matters is Section 5.
>>> You mean Section 3. Good.
>> Section 3 is for using Eigen directly in a C++ program, yes, but I got
>> a bit ahead of myself there: see below
>>> I admit to being less up on the details of
>>> LGPLv3 than I was of LGPLv2 which had a problem with C++ header
>>> templates.
>> Indeed, it did, that's why we don't use it.
>>> That said, we will not be using the C++ templates directly in numpy
>>> for technical reasons (not least that we do not want to require a C++
>>> compiler for the default build). At best, we would be using a BLAS
>>> interface which requires linking of objects, not just header
>>> templates. That *would* impose the Section 4 requirements.
>> ... or rather Section 5: that is what I was having in mind:
>>  " 5. Combined Libraries. "
>> I have to admit that I don't understand what 5.a) means.
> I don't think it applies. Let's say I write some routines that use an
> LGPLed Library (let's call them Routines A). I can include those
> routines in a larger library with routines that do not use the LGPLed
> library (Routines B). The Routines B can be under whatever license you
> like. However, one must make a library containing only Routines A and
> the LGPLed Library and release that under the LGPLv3, distribute it
> along with the combined work, and give notice about how to obtain
> Routines A+Library separate from Routines B. Basically, it's another
> exception for needing to be able to relink object code in a particular
> technical use case.
> This cannot apply to numpy because we cannot break out numpy.linalg
> from the rest of numpy. Even if we could, we do not wish to make
> numpy.linalg itself LGPLed.

Indeed, that seems very cumbersome. I will ask the FSF about this, as
this is definitely not something that we want to impose on Eigen


> --
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

More information about the NumPy-Discussion mailing list