Re: [eigen] Generalized selfadjoint eigenvalues

[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
>>>>
>>>>
>>>
>>>
>>
>