Re: [eigen] Generalized selfadjoint eigenvalues

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

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