| 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 23:51:18 +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=PKd6D+NwZKOhd/uhEHykKRInmEQD1R/59WsNSnWxzSs=; b=hl+bVFT7GcnL1UZPI3GEviKVD2hO5oVQgHguLcG3vrCAPevAvKw64cw6ZJ5EtuK0mL AXq7YqLEQqjiKJmZqNyo3/FQ8u9iecn/ABN5dmvOKTbmxlVqXIJt9l0zzggiQAD6JCdI zq6AXxdP6QWwui++L3ix0Qs+SAQBSlrs8UspQ=
- 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=JeCcmzpjzs3bOsLEsCVjHfesbWAIM8wFj/KsnwN+P6nat2PlEYlzbOes7aWG1Qx4Gh foHb4QHhdna9fQQvdFvTfCMiBIG2Kr4qAgRtloGJB1OX6S/nK3qr5mYH70FbxHE2/cVq Qysb8f/JjsXgmGUIP/tAvKCpHlDbfdUhFMuRk=
committed, but I'm wondering whether the option to control the
computation of the eigenvectors and the one controlling the problem
kind (Ax_lBx, etc.) should not be decoupled ? Currently they are
specified together using bit flags, e.g.: AX_lBx | EigenvaluesOnly.
gael
On Wed, Jun 16, 2010 at 10:02 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> 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
>>>
>>>
>>
>>
>