| Re: [eigen] Generalized selfadjoint eigenvalues |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Generalized selfadjoint eigenvalues
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Wed, 16 Jun 2010 22:02:23 +0200
- 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=j5wxfY6GBc0hxJH5AbT+YzcCyFa0u/Lz/B+zioT30E8=; b=WZJ5Iv0GrjLkNx9zxog5YEHWbLkizWuewjnDQNGrqywKbBQQjP8KNRoeCo4+bbzt3N FkG4trpHW2i4Y+h+saLL846ufP8Hg3/47fTTYSMg0697JG48RiWYSYSxcvNMyMujPCXB kfvPXbZRERi2ApCD2SCjwDntCbSPv/+nApemQ=
- 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=OQlcQ6Z2oD1wkqnTW46NOYs58G6vzA+F+d7VaOTSloZC2pPUCxVe8L0kB7zgT6s23h 4wXfB+bKQUey7/YzNItiPwKL2JMUnovgdHHZ0b8aEAI5YebvNx/RejQ06+4jUiCTTV4V qxqx9n66TD18kHef7G8r0MWwSCogcYkdo1Ttg=
to keep us sync,: I'm doing these changes right now....
gael
On Fri, Jun 11, 2010 at 7:24 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
>
>
> Ok, so let's summarize:
>
> 1 - Introduce a new GeneralizedSelfAdjointEigenSolver class (wow that's a
> rather long name)
> 2 - Introduce a new set of option flags for the decompositions.
>
> Sounds good to me.
>
> gael
>
>
> On Thu, Jun 10, 2010 at 11:53 AM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>
> wrote:
>>
>> On Thu, 10 Jun 2010, Gael Guennebaud wrote:
>>
>>> I have some API concerns about the generalized selfadjoint eigenvalues.
>>
>> Oops, I postponed that part of the Eigenvalues module because I don't know
>> much about generalized eigenvalue problems and promptly forgot about it.
>>
>>> [...] 1 - we might also want to offer the possibility to solve the two
>>> other variants:
>>> BAx = lambda x
>>> ABx = lambda x
>>
>> Stupid question: why not compute the (non-generalized) eigenvalues of the
>> product BA or AB? If the normalization x^* B x = 1 is important, that can
>> easily be fixed afterwards?
>>
>>> 2 - It would be nice to avoid the use of meaningless boolean for the
>>> compute* parameter. This is not specific to the generalized eigenvalue
>>> problem. Shall we introduce a ComputeEigenvectors enum though it is quite
>>> long to write? What would be the contrary? DoesNotComputeEigenvectors?
>>> definitely too verbose !
>>
>> ComputeOnlyEigenvalues? Perhaps we can leave out the "Compute"?
>> eigensolver.compute(A, OnlyEigenvalues) seems pretty clear. The
>> constructor is more of a problem though.
>>
>>> So perhaps we could have an options parameter of or-ed flags shared by
>>> all decompositions:
>>
>> So perhaps that's best.
>>
>>> 3 - Last concern: maybe it would be better to introduce a new
>>> GenSelfAdjointEigenSolver class built on top of SelfAdjointEigenSolver.
>>
>> Yes, I agree with that.
>>
>>> Indeed, the generalized pb requires to compute (and then store) a LLT
>>> dec. Currently it is dynamically allocated in the compute function itself
>>> but it would be better to allow preallocation, but it is not good either to
>>> always preallocate it while we don't know is the user will want to solve a
>>> classic problem or a generalized one ?
>>
>> Regarding pre-allocation, the main issue that I left unsolved in the
>> Eigenvalues module is that HouseholderSequence::evalTo() dynamically
>> allocates a vector. I did not find an easy way to avoid this.
>>
>>
>> Jitse
>>
>>
>
>