|Re: [eigen] Generalized selfadjoint eigenvalues|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Generalized selfadjoint eigenvalues
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 11 Jun 2010 19:24:25 +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=ixxA/tsQ+f+2JIRNlVYCAD6h0yp9hzHbAfplvxmjniw=; b=h3Rue9ZRDdFfTBzOAK26hpOP76GyweQKvsQn73xODCmrp2inV6y40+buJnCxMZ988c q94ssermSuG1+O+Sr3WYI6KXs42l7WgyzoNigL/ZXzpPeO8IHSjWJQ2y3p2BwMJqtVwY LXs3QBwurAcyt+baU+re1e1zFSUzo5srYenkE=
- 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=ELM05Um7FC5pQaoVlhvMdb9fwwwW2VCYXKsOwgYNkkBKItbWa8VErb79X9/Lmj9o/Q YO4y1v3K0ZUsvClExShQkj7QyROz0FjMUPZ7G+4MrX5i91Wv3QonnKdqZvOpOY60041e POlPy6xLPuo+x47jcWxxCXqbt1hKamSbA+eOg=
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.
On Thu, Jun 10, 2010 at 11:53 AM, Jitse Niesen <jitse@xxxxxxxxxxxxxxxxx>
Oops, I postponed that part of the Eigenvalues module because I don't know much about generalized eigenvalue problems and promptly forgot about it..
On Thu, 10 Jun 2010, Gael Guennebaud wrote:
I have some API concerns about the generalized selfadjoint eigenvalues.
[...] 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?
ComputeOnlyEigenvalues? Perhaps we can leave out the "Compute"?
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 !
eigensolver.compute(A, OnlyEigenvalues) seems pretty clear. The constructor is more of a problem though.
So perhaps that's best.
So perhaps we could have an options parameter of or-ed flags shared by all decompositions:
Yes, I agree with that.
3 - Last concern: maybe it would be better to introduce a new GenSelfAdjointEigenSolver class built on top of SelfAdjointEigenSolver.
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.
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 ?