Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
DSYEVR returns non-orthogonal vectors #151
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.
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.
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.)