Re: [eigen] Solving a tridiagonal linear system

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/11/26 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> 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.

Sorry, I misread your mail, mixed up TridiagonalMatrix and Tridiagonalization.

I meant: make TridiagonalMatrix internal.

> Internally the Tridiagonalization class stores a
> dense matrix plus a vector of householder reflector coefficients.

I know :) sorry for the confusion.

And so, I don't have any point about "Hessenberg". I was thinking
about a special HessenbergMatrix class, but we don't have any.

Sorry,
Benoit

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