Re: Fwd: [eigen] 3x3 symmetric eigenvalues Problem

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

I've just committed in the default branch a new version of the
*direct* eigenvector extraction code which is much more reliable and
as fast as the previous code.

gael


On Tue, Nov 1, 2011 at 12:24 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Hi,
>
> there is indeed an issue in the extraction of the eigenvectors in this
> very particular case: the input is a diagonal matrix with the biggest
> eigenvalue being the first entry of the diagonal. In this case, we
> should only consider the last two rows of A-lambda_2  to extract the
> eigenvector of the biggest eigen value while we currently always take
> into account the first row of A-lambda_2 which is zero. Without
> performance consideration, this would be an easy fix, but at least we
> now know the precise reason of this failing case.
>
> gael
>
> On Mon, Oct 31, 2011 at 10:52 PM, Benjamin Schindler
> <bschindler@xxxxxxxxxxx> wrote:
>> Hi
>>
>> Actually, I didn't think before replying, sorry. The matrix I found the
>> error with is not positive semi-definite, correct. However, the example I
>> posted, the matrix IS positive definitie actually (diag(2000, 1, 1)).
>> So, I have the impression that the code for solving the 3x3 equation system
>> is plain buggy...
>>
>> Cheers
>> Benjamin
>>
>>
>> If you take my example which clearly does not work
>> On 31.10.2011 22:10, Suat Gedikli wrote:
>>
>> Hi,
>>
>> thank you for the report.
>> This method (even if the name is misleading) is for symmetric positive
>> semi-definite matrices only => non-negative eigenvalues.
>> If in your case the largest eingenvalue is zero, then this would mean that
>> for a positive-semidefinite matrix the smallest one is also zero => the
>> first if would apply in line 195:
>> if((evals(2)-evals(0))<=Eigen::NumTraits<Scalar>::epsilon())
>>         {
>>             // all three equal
>>             evecs.setIdentity();
>>         }
>>
>> so, the matrix you're using can not produce correct results, since its
>> negative definite. If it should be a covariance matrix (as used for the
>> normal estimation) check the code where you're calculating the matrix. If
>> not, just use the SelfAdjoint Solver from Eigen which should give you
>> correct results, but is also much slower.
>>
>> Cheers,
>> Suat
>>
>>
>> On 10/31/2011 11:14 AM, Radu B. Rusu wrote:
>>
>> Could be interesting for you :)
>>
>> Cheers,
>> Radu.
>> Begin forwarded message:
>>
>> From: Benjamin Schindler <bschindler@xxxxxxxxxxx>
>> Date: October 31, 2011 9:52:44 PDT
>> To: "eigen@xxxxxxxxxxxxxxxxxxx" <eigen@xxxxxxxxxxxxxxxxxxx>
>> Cc: <gael.guennebaud@xxxxxxxxx>
>> Subject: [eigen] 3x3 symmetric eigenvalues Problem
>> Reply-To: eigen@xxxxxxxxxxxxxxxxxxx
>>
>> Hi
>>
>> I just stumbled over a problem in the analytic 3x3
>> eigenvalue/eigenvector for symmetric matrices.
>> I have a matrix, where all row vectors are parallel to each other and
>> there is a zero eigenvalue as the largest eigenvalue. What happens is that:
>>
>> Vector cross01 = tmp.row (0).cross (tmp.row (1));
>> Vector cross02 = tmp.row (0).cross (tmp.row (2));
>> Scalar n01 = cross01.squaredNorm();
>> Scalar n02 = cross02.squaredNorm();
>>
>> here, both n01 and n02 become zero and as a result, the entire
>> eigenvector matrix becomes nan's.
>>
>> Reproducing it is easy. Its a different case, but shows the same behavior:
>>
>>    Matrix3f m = Matrix3f::Zero();
>>    m.diagonal() = Vector3f(2000, 1, 0);
>>    Matrix3f evecs;
>>    Vector3f eivs;
>>    eigenSymm33(m, evecs, eivs);
>>    std::cout << evecs << std::endl << eivs.transpose() << std::endl;
>>
>> Output is:
>>
>> -nan -nan -nan
>> -nan -nan -nan
>> -nan -nan -nan
>> 0.0110269 0.98902    2000
>>
>> Now, one might think that 2000,1,0 is exploiting numerics. But in fact
>> its not. Test 2, 1, 1 as the diagonal. The routine will give out the
>> correct result, but if you look closely on what happens, both n01 and
>> n02 will be extremely small, like 1e-15, bot not zero. But analytically,
>> zero would be the correct value! So nan's are simply prevented because
>> of numerical errors.
>>
>> Cheers
>> Benjamin
>>
>>
>>
>>
>>
>