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*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 17 Jun 2010 08:20:46 -0400*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=meB/pyA2Iyp6IggLBSoPbWoXv9mETXjMXq0/1E57I/o=; b=j02DBDOIHNpcZEdswJtn8tI+yXaK7ZsI9WdTYmEiU4yjZ08Z8GPG7f7KlEoGtg0vAp 1h9WaRapVXRZWS1n49+U4n+KwA13QUgFaHgbQmJlgAVn2fdF+STE5ogR8RARQKfguKM5 lso3aiQ4StwQRUSrEFhzDiNmHN2Isb3DkTJ9A=*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=yBJCH0oIZRWcD6MGMu9NkXT8MD6f9wmLpOg89Sslbv7eVQQ/f5eOuvwdIfd1EbWmDX L3AGloyribbirxTxeZMP1+c/yF4hv37kwB1oOky5izsR3i0he2I43l8FEh0s516MVvBB b5QIAj8WYxvDmi095MrRCSjNn7ZA69+6MgIaY=

Very good points! 2010/6/17 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>: > finally having a single option parameter is not too bad because: > - we can support new options in the future without changing the interface > - the user do not have to remember the option order > - the user can only modify a single option while keeping the default > for the rest > > gael > > On Wed, Jun 16, 2010 at 11:51 PM, Gael Guennebaud > <gael.guennebaud@xxxxxxxxx> wrote: >> 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 >>>>> >>>>> >>>> >>>> >>> >> > > >

**References**:**[eigen] Generalized selfadjoint eigenvalues***From:*Gael Guennebaud

**Re: [eigen] Generalized selfadjoint eigenvalues***From:*Jitse Niesen

**Re: [eigen] Generalized selfadjoint eigenvalues***From:*Gael Guennebaud

**Re: [eigen] Generalized selfadjoint eigenvalues***From:*Gael Guennebaud

**Re: [eigen] Generalized selfadjoint eigenvalues***From:*Gael Guennebaud

**Re: [eigen] Generalized selfadjoint eigenvalues***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] Eigen Blocked QR algorithm** - Next by Date:
**Re: [eigen] A modest start with the documentation** - Previous by thread:
**Re: [eigen] Generalized selfadjoint eigenvalues** - Next by thread:
**[eigen] 2.0.13 released**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |