| Re: [eigen] Generalized selfadjoint eigenvalues |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
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