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