|Re: [eigen] patch for tridiagonal matrices in eigen|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] patch for tridiagonal matrices in eigen
- From: "Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>
- Date: Mon, 29 Dec 2008 14:16:50 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0cNIKo5rcJmi7ioYKgQqrEvdwCOrdt5BmdcHz7Jnero=; b=F7xxBavaJDncPtIkTXqvVlRKWmoYNCNLWuhnKGKWhiWKrdLlfRXQGbedLlT8A7bIb6 knkz0jMwmBO9eVqE6KFI8yPzs5pdiHrkiMDaUo8dQyS/Ho95FUck9lUzJHRkXvAJIpFJ JqDIVtQR3jLNPPhFGihXuMeIWdTgsxyGBJBPo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=cmAcYXFxGXzelk/q/1SealxaSLWXrWmcv5qIZZTuNzBOpYpuShDWU7+9/gYNpMjIhT RLUV7DBBS3ILjkYewjxc24p1Gf4szPp2aeX2jJv2F67sZ7o08d9/VeYqLa2qIVD9LVY+ haIF6I1G2EQutHhszJ7kpAU8AfgfMN2dzKREw=
>> 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>"
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.