Lapack: DSYEVR gibt nicht-orthogonale Vektoren zurück

Hallo Miro, danke, dass du BUG 126 als GitHub-Problem hinzugefügt hast. Das ist toll. Osni ( @oamarques ) arbeitet an #100. Vielen Dank, dass Sie Ihren Testcode mit uns geteilt haben. Ja, es gibt einen Plan, an einer neuen Testsuite für LAPACK zu arbeiten, und jede fiese Matrix ist willkommen. Osni hat viele solcher Matrizen und das Ziel wäre es, eine Sammlung davon zusammen mit einer Infrastruktur zum Testen aufzubauen. Auf jeden Fall vielen Dank, dass Sie den BUG 126 als GitHub-Problem hinzugefügt haben. Das ist toll. Gruß, Julien.

Dieser Fehler hängt mit dem in DSTEMR verwendeten Aufteilungskriterium ab Zeile 606 in der entsprechenden Quelldatei (wie in LAPACK 3.7.0) zusammen. Basierend auf der Eingabevariablen TRYRAC gibt die Subroutine DLARRR INFO=1 zurück (dies scheint dem erwarteten Verhalten von DLARRR zu widersprechen), was anschließend eine schädliche Aufspaltung der als Eingabe übergebenen (bestimmten) tridiagonalen Matrix auslöst. _Wenn wir ignorieren, was DLARRR tut, und IINFO=0 kurz vor "Aufteilungskriterium festlegen" setzen, sind die zurückgegebenen Vektoren orthogonal, wenn eine neue Version von DLARRF verwendet wird, siehe Problem 100. Dies ist jedoch keine richtige Lösung für diesen Fehler: wir müssen herausfinden, was das richtige Verhalten von DLARRR sein sollte._)

Hallo, gibt es Neuigkeiten zur Lösung dieses Fehlers?

@oamarques Wird dieses Problem durch die Verwendung von DSTEGR anstelle des zugrunde liegenden DSTEMR gemindert?

@uihsnv : gute Frage. STEGR wird nicht mehr gepflegt. Es gibt Probleme damit. Wir arbeiten nur an und pflegen STEMR. Aber ja, es wäre eine gute Idee zu sehen, was STEGR bei diesem Problem tut.

@langou Oh! Ich hatte keine Ahnung!! Ich verwende ein paar Instanzen von STEGR in meinem Code. Soll ich auf STEMR umsteigen?

Außerdem habe ich einige Änderungen an dem Test vorgenommen, den @miroi geteilt hat. Wenn er akzeptiert, können Sie die Unterschiede sehen.

Ich verwende ein paar Instanzen von STEGR in meinem Code. Soll ich auf STEMR umsteigen?

Ich glaube schon. Ich hoffe, @oamarques wird uns bald darauf ansprechen.

Außerdem habe ich einige Änderungen an dem Test vorgenommen, den @miroi geteilt hat. Wenn er akzeptiert, können Sie die Unterschiede sehen.

Es wäre großartig, den modifizierten Test mit @oamarques zu teilen

Hallo, gibt es Neuigkeiten zu diesem Fehler? Und warum wurde es als "Dokumentation" bezeichnet?

Dennoch gibt frisches Lapack diesen Fehler (getestet mit gfortran 4.9.2 , https://github.com/miroi/lapack-dsyevr-test ):

~~~
Willkommen beim Testprogramm für die Diagonalisierungsroutinen von DIRAC!
gelesen N = 9 NZ = 1
Matrix für die Diagonalisierung wurde gelesen
Arrays für RS-Subroutine zugewiesen
RS-Eigenwerte von Eispack:
1 -1,5000000000000062
2 -1,500000000000002
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-16U U^{+} - I ?= 0> norm/diag:0.9869D-16 norm/offdiag:0.9320D-16
LAPACK DSYEVR Eigenwerte:
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-06U U^{+} - I ?= 0> norm/diag:0.7543D-06 norm/offdiag:0.4951D-06
LAPACK DSTEGR Eigenwerte:
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-06U U^{+} - I ?= 0> norm/ diag:0.5411D-06 norm/ offdiag:0.2301D-06

~~~

Beim erneuten Lesen scheint es, dass die Behebung von der Behebung von Nr. 100 abhängt, die durch einen Versuch verursacht wurde, eine Endlosschleife zu reparieren (ich habe das Gefühl, dass ich mich in letzter Zeit darauf spezialisiert habe, lahme Low-Tech-Lösungen für diese vorzuschlagen), und das Ganze geriet in eine Endlosschleife von Zweifel, was eine ideale Lösung sein könnte. Ist jemand zu 3.5.0 zurückgegangen und hat überprüft, wie sich dieser Fall vor der Änderung der Flag-Variablen verhielt, auf die in #100 angespielt wurde?