|Re: [eigen] Solving a tridiagonal linear system|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Solving a tridiagonal linear system
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 26 Nov 2010 10:16:37 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=1fTLpLZeS/B3H+WvRaMJZpidXKawIWAaFjApxBOYsUQ=; b=BQH5qXZRt34seseub+pOsOHgN9BmTJUm4EyJBNzwl+q6JXQHHngBMGLt3h3wVl7rsU 2URwq9iQ8BnunxxRitRahqQ6oEt7A7ryVZzNbXK+fWJfAnUV8DmV7wLDkx/2JF9L2mDE jqN+YLk5YszJLG7Duk2ICG744NIwSZSp/W2MU=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B3SuOAtSpmkmdecf9z69hSk92ZdYiynbBJkg/nToOyz6HAwp9ze6x8Zv+Eu8c4+6TP fOIFbzBv+I65Cgr+BB8QXsVapTsJzjUfOOaufoG+JF8RwBrfrwfc0w+OcWUQrsCGyENa Ucf+1qHdC5j83TooLVmKDgMI1H75hpfhVD7sk=
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
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.
> 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.
>>> 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.