| Re: [eigen] Solving a tridiagonal linear system |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Solving a tridiagonal linear system
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 26 Nov 2010 16:10:52 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=gLfM3y+Ex8w3eiQK+a9qLDEaKsy7wV/SE2bZCiV4grU=; b=TM+yHaQIuEoYfRnxAJvXlBbyu3o/d7w/zinH9bzmme7JM+hPzO35WbXVwFCMMaVZ8L DsFhpVer/NSPoobcrrBfGeLhRdcSF6zmjU9JuoCgu+7FshV1r47kpyAH/kGnEzjjZXEL Y9wC6PPhSVzKH0n32AlDMVwVTzrcTNmcNgS0U=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=QwjVpldhrKXHlNanUGCu9ZRLVRfYHOT/2mU3wIta7JvBKXDsy1FhGs/vgQ/k5z7wV6 UQ9Vg5OVvhh0zzolqu82xj1t+klMZYtE0rWQay3QGkb0WW/5DIvfjuLIMqB15wWvDOdr qtFEfOd+IlzRL2dh9uKHgROV3j4zteFXUVrr4=
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.
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
>>
>>
>>
>
>
>