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

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