lapack routine dsbev

[kmdunseath]

I am having some trouble reproducing my earlier results using the latest MKL version 10.3.1. The problem arises in the lapack routine dsbev for diagonalising a real symmetric band matrix. While the eigenvalues are the same as before, the eigenvectors can be slightly different. The original matrix is fairly empty, and has bunches of degenerate eigenvalues. With MKL 10.0 (and with other compilers and libraries), the eigenvectors contained mostly zeros, with only a few non-zero components. With MKL 10.3 however, few eigenvector components are identically zero, and some have become relatively large.

The attached code illustrates the problem. Also included are results obtained by compiling with different compilers and libraries. The versions using gfortran and ifort 10.1 give the same results. I can also get these results using ifort 12 by compiling lapack from source.

The versions compiled using ifort version 12 and MKL 10.3.1 however do not give the same results, neither under Mac OSX 10.6 nor under Linux. This is particularly evident when the eigenvectors are printed using the e edit descriptor. In all cases the eigenvectors are numerically orthonormal and satisfy the matrix eigenvalue problem. The eigenvectors in one set of results are not however linear combinations of the eigenvectors in the other set.

I do not know if this can be called a bug, since numerically the results are still eigenvectors, but the change is disconcerting and is making debugging a bit more more painful!

Thanks for any comments or suggestions!

Edit: my mistake, the eigenvectors in one set of results corresponding to a particular degenerate eigenvalue ARE linear combinations of the eigenvectors associated with the same degenerate eigenvalue in the other set.

[mecej4]

This is particularly evident when the eigenvectors are printed using the e edit descriptor

That is equivalent to amplifying and comparing noise from two different sources. Even a single compiler, run with different options, can yield slightly different results when real arithmetic is involved.

Here is a link to a version of diff that shows far fewer false positives than the standard Unix utility:

http://www.math.utah.edu/~beebe/software/ndiff/

It lets you set tolerances for relative and absolute difference, so you can tweak it for your needs.