Re: [eigen] Bug in the Cholesky/Core module?

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

On Fri, Aug 22, 2008 at 7:58 PM, Timothy Hunter <tjhunter@xxxxxxxxxxxx> wrote:
> You are welcome. I am amazed by the rate at which bugs are fixed!
> I am currently writing a convex optimization solver using Eigen. Do
> you have any small tutorial/style recommendation on how to write code
> for it? In my case, I want to write some matrix specializations
> (tridiagonal, bock diagonal and block tridiagonal).

that looks interesting. So far for tridiagonal matrices (used in
Tridiagonalisation and EigenDecomposition) I simply used two vectors,
one for the diagonal and one for the subdiagonal (if the matrix is not
symmetric you need a third superdiagonal vector). This scheme is
compatible with Lapack. Of course it would be cool to have a
TridiagonalMatrix class to glue those vectors together and make it
looks like a matrix... Perhaps with some additional functions to
access the coefficient efficiently such as:
tridiag.diagCoeff(i);
tridiag.superdiagCoeff(i);
tridiag.subdiagCoeff(i);

For the block matrices I don't really know what would be the best to
do.... I guess all blocks have the same size, (perhaps it is even
known at compile time) ? Then maybe it would probably be cool to have
BlockMatrixBase class with some additional methods such as:
 - blocksPerRow()
 - blocksPerCol()
 - block(i,j)  where i,j represents block coordinates
and then you might have a BlockDiagonalMatrix class which would
internally store a blocksize x matrixsize matrix representing the
block diagonal and pick sub matrices in it. And same for
BlockTridiagonalMatrix

Another different approach would be to have a recursive approach
nesting matrices. For instance a block diagonal matrix would be:
Vector<Matrix4f>(matrix_size/4).asDiagonal();
and a block tridiagonal:
TridiagonalMatrix<Matrix4f>
however this is currently not possible.

Also, if you want very good perf, the size of the block should be
known at compile time, and block(i,j) would returns a fixed-size Block
expression. But then the issue is how to handle boundaries ? unless it
is always guaranteed that the size of the matrix is a multiple of the
block size ?

anyways, it was just some random thoughts, perhaps not helpful at all
! Also if you come up with good Matrix classes for such use cases it
would be great to include them in the Sparse module of Eigen, though I
don't know if that's possible from your side.

cheers,
gael.