Re: [eigen] inconsistency in fast eigen decomposition

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Oh! I thought that we were talking about a bug in Eigen here. Sorry.

Benoit

2011/2/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> he is not using something which is officially in eigen, but a function
> which is in bench/eig33.cpp that I added for benchmarking purpose and
> possible inclusion in Eigen in the future. The main question is how to
> integrate it (option of SelfAdjointEigenSolver, a new class, both...)
> That can be discussed for 3.1 since there already is a template
> Options parameter in SelfAdjointEigenSolver.
>
> gael
>
> On Thu, Feb 3, 2011 at 2:24 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Could a unit test be added? Maybe just take his matrix, decompose,
>> reconstruct original matrix, compare. My understanding is that before
>> your fix, eigen would have given a completely wrong reconstructed
>> matrix, so just a fuzzy compare at default test precision would be
>> good enough.
>>
>> Benoit
>>
>> 2011/2/3 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>> yes but was is strange in Radu's example is that the direct method
>>> find a negative eigenvalue while they should all be positive (or equal
>>> to zero). I guess that's because of the multiple trigonometric
>>> functions. Anyway, now I start to compute the eigenvectors from the
>>> biggest eigenvalue and compute the last eigenvectors from the first
>>> two while taking care of some degenerated cases.
>>>
>>> gael
>>>
>>> On Thu, Feb 3, 2011 at 1:52 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> Yeah, it's hard to be accurate when there are degenerate eigenvalues.
>>>> Radu's example had well separated eigenvalues.
>>>
>>>
>>>
>>
>>
>>
>
>
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/