I'm seeing a drastic reduction in the accuracy of computation of eigenvectors when I switch from the previous version to the current version. That is, from 3.0.6 (c76e08cca8eb) to 3.1.1 (43d9075b23ef).

I'm working with the matrix:

Code: Select all

       0 0.577350269189626        0        0        0        0        0        0        0        0(
0.577350269189626        0 0.516397779494322        0        0        0        0        0        0        0
       0 0.516397779494322        0 0.50709255283711        0        0        0        0        0        0
       0        0 0.50709255283711        0 0.50395263067897        0        0        0        0        0
       0        0        0 0.50395263067897        0 0.502518907629606        0        0        0        0
       0        0        0        0 0.502518907629606        0 0.501745206004254        0        0        0
       0        0        0        0        0 0.501745206004254        0 0.501280411827603        0        0
       0        0        0        0        0        0 0.501280411827603        0 0.50097943286812        0
       0        0        0        0        0        0        0 0.50097943286812        0 0.500773395667191
       0        0        0        0        0        0        0        0 0.500773395667191        0

It's small and symmetric, so seems easy enough. Taking an eigenvalue decomposition is the core step of computing a 10 point Gauss-Legendre quadrature rule, so I can check part of the answer very precisely by comparing to Abramowitz and Stegun, p916.

I take an eigen decomp using

Code: Select all

   SelfAdjointEigenSolver<MatrixXd> eigenSolver;
   eigenSolver.compute(z);

The part I can easily check is the first row of the matrix of eigenvectors. 3.0.6, I get the correct answer,

Code: Select all

0.182580590847834 0.273359972518456 -0.330973082376786 -0.366924187884906 -0.384398377152371 -0.384398377152371 -0.366924187884907 0.330973082376786 -0.273359972518455 0.182580590847833
 

This matches matlab's result from the printed matrix to better than 14 digits, excepting some sign flips I don't care about. It also generates the correct quadrature points to within 1e-15. However, on 3.1.1, although the input code prints precisely the same input matrix, I get this for the first row.

Code: Select all

-0.182580590847739 -0.273359972520136 0.330973082375465 0.366924187884892 0.384398377152371 0.384398377152371 -0.366924187884906 0.330973082376786 -0.273359972518464 0.182580590847819

This solution is only accurate to about 11 digits, which is a significant change in accuracy. Both versions agree with matlab and the book to +/- 1e-15 on the eigenvalues. I'm using gcc 4.7.0 on ubuntu, and I believe I see the same thing on mac, with the same compiler.

I saw in the change notes that the iteration limit system was changed: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=479 However, the info() shows success and I also tried changing that hard-coded value to 1000, with no effect, so I don't think that's it.

I would appreciate thought on what caused the change and how I can restore accuracy. Thanks!

This might be this changeset:

https://bitbucket.org/eigen/eigen/chang ... 6601e7be2b

which actually fixed some numerical issues in some cases, but maybe it also introduced some issues in other cases. You can easy check it by commenting/uncommenting the respective lines at the beginning of the tridiagonal_qr_step function.

That's precisely it - thanks for the fast reply. Switching the comments restores the more accurate solution. What's the route forward from here? And is there any way I should help? My linear algebra isn't sharp enough to easily come up with a new patch, but I can probably help make bug reports or regression tests as desired.

There's actually a family of similar eigenproblems that have well known solutions. There are tables of the solutions for various n from 1 to 96.

Fixed:

https://bitbucket.org/eigen/eigen/chang ... 28daa3ff7/
changeset: 39a28daa3ff7
user: ggael
date: 2012-08-05 09:57:31
summary: Fix precision regression when attempting to fix underflow issues.

Verified. Thanks for the fast response. I'll look forward to seeing it in the next release.