DSYEVR returns non-orthogonal vectors

[miroi]

Greetings,

thanks for moving lapack resources to github.

i) I wish to remind the old reported bug, http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=2&t=1820#p11388 , showing up with the newest lapack-3.7.0, as I am reporting here, https://github.com/miroi/lapack-dsyevr-test .

Based on the lapack bug tracker ( http://www.netlib.org/lapack/bug_list.html - bug 126), you are taking care of this nasty bug, right ?

ii) Freel free to take this specific vectors orthogonality test ( https://github.com/miroi/lapack-dsyevr-test ) and add it to lapack tests.

Best, Miro

[langou]

Hi Miro, Thanks for adding the BUG 126 as a GitHub issue. This is great. Osni ( @oamarques ) is working on #100. Thanks for sharing your test code with us. Yes there is a plan to work on a new test suite for LAPACK and any nasty matrix is welcome. Osni has many such matrices and the goal would be to grow a collection of these, along with an infrastructure for testing. In any case, thanks for adding the BUG 126 as a GitHub issue. This is great. Cheers, Julien.

[oamarques]

This bug is related to the splitting criterion used in DSTEMR, starting at line 606 in the corresponding source file (as in LAPACK 3.7.0). Based on the input variable TRYRAC, the subroutine DLARRR returns INFO=1 (this seems to contradict the expected behavior of DLARRR), which subsequently triggers a harmful splitting of the (particular) tridiagonal matrix passed as input. If we ignore what DLARRR does and set IINFO=0 just before "Set the splitting criterion" the returned vectors are orthogonal, when using a new version of DLARRF, see issue 100. However, this is not a proper fix to this bug: we need to figure out what the correct behavior of DLARRR should be.)

[miroi]

Hi, any news concerning solving this bug?

[uihsnv]

@oamarques Does using DSTEGR instead of the underlying DSTEMR mitigate this issue?

[langou]

@uihsnv: good question. STEGR is not maintained any longer. There are issues with it. We are only working on and maintaining STEMR. But, yes, it would be a good idea to see what STEGR does on this problem.

[uihsnv]

@langou Oh! I had no idea!! I'm using a couple of instances of STEGR in my code. Should I switch to using STEMR?

Also, I've made some modifications to the test that @miroi shared, which if he accepts, you can see the differences.

[langou]

I'm using a couple of instances of STEGR in my code. Should I switch to using STEMR?

I think so. I hope @oamarques will follow up soon on this with us.

[langou]

Also, I've made some modifications to the test that @miroi shared, which if he accepts, you can see the differences.

It would be great to share the modified test with @oamarques

[miroi]

Hello, any news concerning this bug ? And why was it labeled "Documentation" ?

Still, fresh lapack give sthis error (tested with gfortran 4.9.2 , https://github.com/miroi/lapack-dsyevr-test ):

  Welcome to the testing program for DIRAC's diagonalization routines !
 read N=           9  NZ=           1
 matrix for diagonalization was read
 arrays for RS subroutine allocated
 Eispack's RS eigenvalues:
           1  -1.5000000000000062
           2  -1.5000000000000002
           3  -1.4999999999999982
           4  0.49999999999999772
           5  0.49999999999999856
           6  0.49999999999999994
           7  0.50000000000000033
           8  0.50000000000000122
           9   2.4999999999999969
  **** EISPACK RS ****
 U^{+}*A*U - eps ?= 0> norm/diag:0.1912D-15  norm/offdiag:0.1008D-15
     U^{+}*U - I ?= 0> norm/diag:0.2344D-15  norm/offdiag:0.7239D-16
     U*U^{+} - I ?= 0> norm/diag:0.9869D-16  norm/offdiag:0.9320D-16
 LAPACK DSYEVR eigenvalues:
           1  -1.5000000000000056
           2  -1.5000000000000009
           3  -1.4999999999999973
           4  0.49999999999999523
           5  0.49999999999999867
           6  0.49999999999999939
           7  0.49999999999999950
           8  0.50000000000000100
           9   2.4999999999999862
  **** LAPACK DSYEVR ****
 U^{+}*A*U - eps ?= 0> norm/diag:0.1807D-14  norm/offdiag:0.9012D-07
     U^{+}*U - I ?= 0> norm/diag:0.2591D-15  norm/offdiag:0.1802D-06
     U*U^{+} - I ?= 0> norm/diag:0.7543D-06  norm/offdiag:0.4951D-06
 LAPACK DSTEGR eigenvalues:
           1  -1.5000000000000056
           2  -1.5000000000000009
           3  -1.4999999999999973
           4  0.49999999999999523
           5  0.49999999999999867
           6  0.49999999999999939
           7  0.49999999999999950
           8  0.50000000000000100
           9   2.4999999999999862
  **** LAPACK DSYTRD+DSTEGR ****
 U^{+}*A*U - eps ?= 0> norm/diag:0.1617D+01  norm/offdiag:0.1644D+00
     U^{+}*U - I ?= 0> norm/diag:0.1234D-15  norm/offdiag:0.1802D-06
     U*U^{+} - I ?= 0> norm/diag:0.5411D-06  norm/offdiag:0.2301D-06

[martin-frbg]

On rereading this, it seems fixing it hinges on fixing #100 which was caused by an attempt to fix an infinite loop (feeling I am specializing in proposing lame low-tech solutions for those lately) and the whole thing went into an infinite loop of doubts about what an ideal solution could be. Did anybody go back to 3.5.0 and check how this case behaved prior to the changing of the flag variable alluded to in #100 ?