[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Maths: importing GMM into kdesupport/
From:       Benoit Jacob <jacob () math ! jussieu ! fr>
Date:       2007-01-22 14:38:07
Message-ID: Pine.LNX.4.64.0701221437400.18528 () galois1 ! math ! jussieu ! fr
[Download RAW message or body]

Hi kde-devel,

There is an increasing need for pretty advanced linear algebra in some 
parts of KDE. For instance, a new colorization filter that Ben intends to 
write for Krita depends on the ability to handle huge sparse matrices. 
Large matrices are ubiquitous in applied math, so it is reasonnable to 
expect other such needs to emerge.

After trying a dozen libraries, we have come across GMM, a LGPL C++ 
template library providing an advanced linear algebra framework:

http://www-gmm.insa-toulouse.fr/getfem/gmm_intro

It doesn't have quite all the algorithms that we need, but implementing 
these algorithms on top of GMM is doable, and seems to be our best bet. 
Moreover GMM might merge patches from us, so that we would be able to 
stick with the GMM mainline.

So would you agree with importing a copy of GMM into, say, kdesupport?

Now I guess you'll ask, where does that leave Eigen?

The answer is, Eigen and GMM do different things. There are 3 ways to 
represent matrices:

1) Fixed-size dense matrices, as in:

          float matrix[width*height];

Thanks to being fixedsize, this is by far the fastest kind of matrix (no 
dynamic memory allocation; loop unrolling). OpenGL matrices belong to this 
category.

2) Dynamic-size dense matrices, as in:

          float * matrix = new float[width*height];

3) Sparse matrices, i.e. huge matrices of which most of the entries are 
equal to zero. So one must represent them in a way that takes advantage of 
the fact that most of the entries are equal to zero -- the typical size of 
such a matrix can be 10^6 * 10^6, so representing it using 1) or 2) would 
be insane.

Eigen can do 1) and 2) in the case of square matrices, i.e. width==height. 
Eigen can't do 3) at all.

GMM can do 2) and 3) even for non-square matrices, but can't do 1) at all. 
Krita needs 3).

So we need to have Eigen and GMM side-by-side.

As these are template libraries, having two libraries instead of one does 
not mean any additional binary bloat.

Of course we are evaluating possibilities w.r.t. integration and API 
consistency -- ranging from adding a GMM wrapper to Eigen, to rewriting 
part of Eigen on top of GMM. In any case, the plain unmodified GMM would 
remain available for app developers who want it.

Benoit
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]