|[eigen] Re: tvmet: licensing question for a project based on tvmet source code|
[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]
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
Description: This is a digitally signed message part.
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|