Re: [eigen] patch for tridiagonal matrices in eigen

[ Thread Index | Date Index | More Archives ]

>> Then there is the story of tridiagonal symmetric matrices....
>> We should also come up with a mechanism to define TriagonalMatrix with their
>> own storage. For instance with DiagonalMatrix, one can currently do:
>> typedef DiagonalMatrix<NestByValue<VectorXf> > DiagonalMatrixXf;
>> to almost get a "real" diagonal matrix of float with dynamic size. I say
>> "almost", because we cannot set its size, resize it, etc... Well one can add
>> take a vector, and add a ".asDiagonal()" all the time, but, 1) that's not
>> super convenient, and 2) this would be even less convenient for
>> TridiagonalMatrix, so we really need to come up with something here.
> I do not follow. What's wrong with DiagonalMatrix<VectorXf>?

well, a "DiagonalMatrix<VectorXf>" object only stores a reference to a
VectorXf so cannot use this type as a "diagonal matrix type with
sparse storage". So currently, if you want to store a diagonal matrix
you need to declare a VectorXf, and then always use it with the
".asDiagonal()" suffix, or declare a "DiagonalMatrix<VectorXf>"
wrapper object.

Alternatively, you can enforce DiagonalMatrix to store the vector
object by value and not by reference. This is exactly the purpose of
the NestByValue expression, whence the
"DiagonalMatrix<NestByValue<VectorXf> >" type I suggested. However,
this is not plenty satisfactory because:
1) the type itself is not not intuitive,
2) we are missing important features such as ctors with only a size, a
resize function, a set function, some functions to access the internal
data, and many others...

So, perhaps, the current DiagonalMatrix class could be renamed
DiagonalMatrixExpr, that would allow us to add a DiagonalMatrix class
with storage in the future. Same for TriagonalMatrix.

>> About the QR module, I think that MatrixType is already square, isn't it ?
>> so I don't really follow you... About the "if", don't bother too much since
>> this need to be redesigned anyway (see the other thread), but your use case
>> (the matrix is already tridiagonal) will help to make the right choices...
> Yes, but is particular cases it is not assignable:
> SelfAdjointEigenSolver< TridiagonalMatrix<VectorXd, VectorXd, VectorXd> >
> fails because it defines m_eivec as a triangular matrix. But if you
> already have a tridiagonal matrix you do not want to cast it into a
> square matrix before.
> not counting that then the solver cannot understand that it can skip
> tridiagonalization unless is checks (n-1)(n-2) coefficients, while it
> could get that info from the compiler...
> The SquareMatrixType is the corresponding square type with assignable
> coefficients. so I think it is the correct type for m_eivec. Same idea
> could apply elsewhere.
> I hope that makes sense.

ok, makes sense.



Mail converted by MHonArc 2.6.19+