SymmetricEigen produces wrong sign of eigenvector values on Matrix6 about nalgebra

[Andlon]

Normalized eigenvectors are not generally unique. As you've observed, you can arbitrarily change their signs while still retaining a valid eigendecomposition for the matrix. For example, we can check that we still get the original matrix back if we recompose the matrix from its eigendecomposition, as I've done here (note that due to limited precision of f32, the zero blocks don't "look" very close to zero to a human eye).

As far as I can tell, nalgebra appears to be doing the right thing, and the discrepancy between Eigen and nalgebra is just due to implementation details. I don't quite understand how you can have an algorithm that fails because the sign is "wrong" - perhaps you can elaborate on this if you think there might still be more to the story.

I'll close this issue for now but feel free to re-open or follow up if you think there is more to address here. Hope this helps!

[yesint]

@Andlon thanks a lot for a quick response! Yes, indeed there is an algorithm, which is sensitive to this - the alignment of two molecular structures in terms of minimal RMSD.

In this algorithm one computes the eigenvectors of the 6x6 matrix and takes two eigenvectors with the largest eigenvalues (vectors 4 and 5 since they are sorted ascending). After that parts of these vectors are used to construct the transformation matrix that aligns one point cloud to the other.

The algorithm is here, look for rot_transform_matrix.

I'm not an expert in this algorithm, I've copy-pasted it initially from old C-code and adapted for Eigen in C++. Now I translated it literally to nalgebra and have found an issue with the sign on 4-th eigenvector.

Currently I've just put "-" to invert the offending vector, but this looks like an unreliable hack because I can't guarantee that it will work for all matrices consistently (somehow, for Eigen and older C code it always just works).

I really don't like this kind of "black magic", so I'd be very grateful for any suggestions how to adapt the things to nalgebra way of computing eigenvectors.

[yesint]

I don't see a way to re-open an issue, btw.

[yesint]

And there is yet another bug candidate :)
If I compute the eigenvalues of this matrix with nalgebra::SymmetricEigen I get this:

val =
 
  ┌            ┐
  │ -39261.336 │
  │ -58575.883 │
  │  -17988.87 │
  │  17988.875 │
  │   39261.33 │
  │  58575.883 │
  └            ┘

Two first values are not in correct ascending order.

If I do this with with nalgebra_lapack::SymmetricEigen I get this:

val =
 
  ┌            ┐
  │   -58575.8 │
  │ -39261.313 │
  │ -17988.877 │
  │  17988.863 │
  │  39261.305 │
  │   58575.83 │
  └            ┘

Now everything is sorted correctly.
This is weird to say the least.