Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted
##

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.

kmdunseath

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-12-2011
09:36 AM

6 Views

lapack routine dsbev

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.

1 Reply

Highlighted
##

*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.

mecej4

Black Belt

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-13-2011
05:41 AM

6 Views

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

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.

For more complete information about compiler optimizations, see our Optimization Notice.