Re: [eigen] Solving a tridiagonal linear system

[ Thread Index | Date Index | More Archives ]

On Fri, Nov 26, 2010 at 3:48 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/11/26 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> On Fri, Nov 26, 2010 at 2:45 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> So I'm 100% OK to make UpperBidiagonalization and BandMatrix internal.
>>> For good measure we could also do it for Hessenberg.
>>> I remember that someone earlier objected against removing them (he was
>>> using Hessenberg IIRC) but making them internal should be OK, it's
>>> just a matter for him of doing internal::
>> yes I've also been thinking about making the Tridiagonalization and
>> HessenbergDecomposition classes internal but their current public API
>> is consistent with the rest of Eigen, and the internal storage is
>> LAPACK compatible.
> Since Tridiagonalization inherits publicly BandMatrix, if we don't
> make Tridiagonalization internal, then in effect we're not making
> BandMatrix's API internal at all. So I still think that we should make
> Tridiagonalization internal.

Actually Tridiagonalization has nothing to do with BandMatrix or
TridiagonalMatrix. Internally the Tridiagonalization class stores a
dense matrix plus a vector of householder reflector coefficients. The
dense matrix stores the tridiagonal matrix into its diagonal and
subdiagonal and the rest of the lower triangular part is used to store
the householder vectors.

So with such a storage format, Tridiagonalization cannot exploit our
TridiagonalMatrix class. In the future we'll need a kind of
TridiagonalView inheriting a common base class with TridiagonalMatrix,
but that's for the future.


> Then I don't have much of an opinion about Hessenberg but if we don't
> have a public Tridiag class, what's the point of having a public
> Hessenberg class. Seems like an inconsistent feature set.
> Benoit
>> So unless we want to change the internal
>> representation is the future (and lost LAPACK compatibility), I don't
>> see any reason to make them internal.
>> In the future me might add an Upper/Lower template option to
>> Tridiagonalization but source compatibility will be preserved my
>> assuming Lower by default. Same for SelfAdjointEigenSolver btw.
>> I'm only changing the current Tridiagonalization::matrixT() method
>> which currently returns a temporary dense matrix to return an abstract
>> "ReturnByValue" object. In the future we will still be able to return
>> a kind of self-adjoint BandView (or TridiagonalView) without breaking
>> source compatibility since the API of ReturnByValue is minimalistic.
>> gael

Mail converted by MHonArc 2.6.19+