[eigen] Plans for a Eigen 2

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

Hi List,

This is something that's been brewing in my head for a bit of time and that's 
been first discussed yesterday on #koffice:

*** Where we are : Eigen 1 **************************************************

Eigen as it currently stands fails to cover the needs of most of the projects 
it wants to help, because it's too limited. When we started, we believed we 
should make Eigen as small and simple as possible, and later the CRTP-based 
design led me to cut even more functionality (restricting to square 
matrices). As a result Eigen 1 looks more like a course in efficient C++, 
than like a useful library. It also turns out that we underestimated the 
needs of applications.

Here's a state of the projects using Eigen or considering to:
- Kalzium/Avogadro and Franz's student project seem to be happy with Eigen 1.
- OpenBabel needs eigenvalue computation and could benefit from a sparse 
solver.
- KSpread seems to need rectangular matrices.
- Krita needs a sparse solver and sparse least squares, and currently uses GMM
  for that. However it might also use Eigen for other stuff,
  so providing a single library would be best.

*** Plans for Eigen 2 ******************************************************

I have a pretty clear idea of what I'd like to do, only I lack some time 
currently, so this is mostly to:
 - gather feedback in case I forgot something
 - tell you that I'm thinking about your needs
 - hopefully some of you can give me a helping hand

The main ideas for Eigen 2 are:
 - separate three types of matrices/vectors:
   - fixed-size
   - dynamic-size dense
   - dynamic-size sparse

 - The fixed-size classes should be the Matrix and Vector templates from Eigen
   1, except that they should allow rectangularness. The dynamic-size classes
   should be wrappers around GMM classes.

 - don't try to let different types share code, and no CRTP anymore.

 - provide a uniform API across the different types, as far as applicable

 - Eventually we'll add copy-on-write to the dynamic-size classes, but
   that's only a performance issue so not an immediate priority.

 - As for the directory structure in kdesupport/, it would mean moving gmm/
   back inside eigen/.

 - As to staying simple for simple things, I think it could be achieved by
   clearly separating the various types in the documentation, and by providing
   plenty of examples.

I have a question to KDE people: as a template library, will Eigen have to 
preserve compatibility for the whole KDE4 lifecycle ?

Cheers,
Benoit

PS. If you want to subscribe to this list, send a mail with 
subject "subscribe" to eigen-request@xxxxxxxxxxxxxxxxxxx

PS. Bensch: I know this contradicts what I used to say, that Eigen should stay 
simple and you should use GMM instead for advanced stuff, but you guessed how 
insecure I felt about that. I guess I lacked time for a big rework of Eigen, 
so I wanted to find excuses for that.

PS. Bensch: do you think we could restrict to one single type of sparse 
matrices, like column-compressed? Or is it useful to expose all the types GMM 
has? What types have you used so far?

Attachment: pgpcXPZsk6c8t.pgp
Description: PGP signature