[eigen] Re: Plans for a Eigen 2

["Schleimer, Ben" <bensch128@xxxxxxxxx>]

Hey Benoit,
   I'm glad to hear that ideas are brewing for eigen2. I'm glad to see that there are more use
cases for eigen and you're not going to be limited by "small and simple" anymore. I have
confidence that if there is a good API and good documentation (deoxygen is golden :)) then eigen2
will be much more used then eigen1.

Comments:
> - 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.

Indeed.

> 
>  - 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.

I think that expression templates would help lot here. Then you wouldn't have to differentiate
between 2,3,4d vector operation and (I believe) matrix operations because the expression template.
See http://osl.iu.edu/~tveldhui/papers/techniques/techniques01.html#l31 for an excellent writeup
on them.

>  - 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.

Yes, see gmm++'s documentation for an ok job at this. If you want to minimize maintainance, I
would suggest putting all of the examples into the appropriate .h file (see qt's documentation and
.h files)

> 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.
Ok. it's no problem. I'll take what i can get. If you come out with eigen2 in the future which
supports sparse matrices, I'll definitely use that. But please try to make the unit tests more
sane then gmm's. They're impossible to understand and/or add too.

> 
> 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?
> 
I started by using just gmm::row_matrix but I found that gmm::csr_matrix is MUCH faster inside of
the iterative solvers. I'm guessing its because csr/csc_matrix has better compression the
row/col_matrix and has causes cache misses. However, you cannot write to the entries of a
csr_matrix. So you'll need to leave both in. I think that it would be best to leave in all of the
types (and maybe add a diagonal major type if there is the need) so the user can decide which type
of matrix is best for him.

Cheers
Ben

PS. I saw your chat on #koffice and I believe that gmm::mult can be used as a operator* by
writing: (not tested!)

template<typename _T1, typename _T2, typename _T3> 
_T3 operator*(const matType1 & a, const matType2 & b) 
{ 
  _T3 ret(b.nCols(), a.nRows());
  gmm::mult(a, b, ret);
  return(ret);
}