|Re: Fwd: [eigen] 3x3 symmetric eigenvalues Problem|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: Benjamin Schindler <bschindler@xxxxxxxxxxx>
- Subject: Re: Fwd: [eigen] 3x3 symmetric eigenvalues Problem
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Tue, 1 Nov 2011 00:24:41 +0100
- Cc: Suat Gedikli <gedikli@xxxxxxxxxxxxxxxx>, "Radu B. Rusu" <rusu@xxxxxxxxxxxxxxxx>, eigen@xxxxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=fL1Ma67OMCbYhSvVHYVo+RFL22xtLddpkhsGd44K3Ug=; b=Qvj+20SyBDUnBP0OEPiM3PR3CUhuuqioABeHzwsTnIlyvfHaZGu5kXG8ve3qkJ2gfJ cYy/cNzLrfXRS8T87dqLlElKu45biZx6gIYtXL7CBOKIxO8ge13p/C+KIp+oHjiRwooJ irAsOA4QdktCG0Q7aryKzJ1xxugkNU3diKIws=
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.
On Mon, Oct 31, 2011 at 10:52 PM, Benjamin Schindler
> 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...
> If you take my example which clearly does not work
> On 31.10.2011 22:10, Suat Gedikli wrote:
> 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:
> // all three equal
> 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.
> On 10/31/2011 11:14 AM, Radu B. Rusu wrote:
> Could be interesting for you :)
> 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
> 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.