[eigen] Re: tvmet: licensing question for a project based on tvmet source code

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

Hi Olaf,

I'm CC'ing the Eigen mailing list.

Sorry for the long e-mail. I'm very glad to hear back from you, as I've been 
trying to contact you at many e-mail addresses.

First of all, if you want to check out what I'm doing with your code, the SVN 
command is:
svn co svn://anonsvn.kde.org/home/kde/branches/work/eigen2

On Saturday 09 June 2007 08:20:58 Olaf Petzold wrote:
> hopefully this will close the gape for the linear algebra packages for
> small sizes. tvmet miss some functionality like lu decompostion etc. I
> never found the time to implement this (tvmet was developed over a
> couple of years).

LU decomposition for dense matrices is present in Eigen1. From GMM++, I'll 
take the code handling dynamic-size matrices (dense and sparse). It remains 
to be seen how to mix expression templates with sparse matrices.

The goal of Eigen2 is to cover all 3 kinds of vectors/matrices: tiny, dynamic 
dense, dynamic sparse. All the ingredients for a successful Eigen2 already 
exist in Tvmet, GMM++ and Eigen1, and there's no point in reinventing the 
wheel.

There is strong demand for such a unified library. Actually, Eigen has always 
been developed while listening carefully at the "demand". If we succeed, 
we're assured to be massively used in some major Free Software projects. 
Eigen1 is already used a little bit in some KDE and KOffice apps.

> > I am writing this to ask for your confirmation that I am allowed to
> > redistribute Eigen2 under the plain unmodified GNU LGPL license.
> >
> > I have seen that tvmet has an addendum to the LGPL. This addendum
> > contains an advertising clause (Clause 5). I want to redistribute Eigen2
> > without any advertising clause.
> > [SNIP]
>
> Mmh, the advertising clause has the task to advertise tvmet. The goal is
> clear I think. tvmet is well know but I never found a final software
> which used it. This is the other point.
>
> Well, I think Eigen2 derived from tvmet mentioned (with URL) at your
> home page (as you did before), this should be enough. Can you live with it?

Of course I can. Actually, I intend to do much more. I want to mention Tvmet 
at much more than one place in the website and documentation. When 
mentionning expression templates on the website (a major selling point!), 
I'll make sure to say that these are taken from Tvmet. And I'll also mention 
Tvmet in the documentation, when documenting expression templates.

I also have a few questions:
- Do you continue to develop Tvmet? As I couldn't reach you, I had ended 
making the assumption that Tvmet was not being further developed. Perhaps I 
was wrong?
- Assuming Tvmet is not being further developed, are you interested in joining 
the Eigen2 project? I don't know Tvmet and expression templates nearly as 
well as you do... I am currently making large changes in Eigen2's copy of 
Tvmet. Maybe I am doing mistakes, so your advice would be very useful!

Here are already a few questions and remarks:

- With Tvmet's expression templates, If I do
  double x = (matrix1 * matrix2)(row,column);
Is the whole matrix product (matrix1 * matrix2) computed? Or are your
expression templates clever enough to compute only what's needed to evaluate
the matrix element at position (row,column)? Does that depend on #defines
such as TVMET_OPTIMIZE? I tried looking at the assembly output but still
amn't sure.

- In NumericTraits, you define the sum_type to be a type holding a bigger 
precision. I understand that is better for numerical stability, but does that 
really outweigh the cost of conversions between types? I mean: if I 
understand well, when Tvmet computes the sum of two floats, it computes it as 
a double (stop me if I'm wrong). So if the user does v3=v1+v2 with 3D float 
vectors, there are 6 floating-point conversions involved. My preferred 
approach would be to say that the programmer must be aware himself of the 
limitations of the types he uses, and the library should guarantee that it 
doesn't bring that kind of overhead.

- In order to reduce the number of lines of code, I have removed the 
per-element math functions. Removing isnan and isinf also solved a 
portability problem that you had with the Intel compiler. Going further, I 
plan to remove support for many types, and keep only int, float, double and 
complex<T>. Do you know any use case for which is would be useful to keep 
long long, long double, char, short, or unsigned types?

- by the way I am completely banning unsigned types from the code. Using int 
instead of size_t. Hope you don't mind.

- as most of Eigen's users are inside KDE, I'm porting from autotools to CMake 
and from cppunit to QTestLib. Again, I hope you don't mind. The CMake port is 
a huge improvement; the QTestLib port is a less clear improvement as cppunit 
is already very good, but still it reduces the number of lines of code.

Cheers,
Benoit

Attachment: signature.asc
Description: This is a digitally signed message part.