Lapack: DSYEVR renvoie des vecteurs non orthogonaux

Bonjour Miro, Merci d'avoir ajouté le BUG 126 en tant que problème GitHub. C'est bien. Osni ( @oamarques ) travaille sur #100. Merci d'avoir partagé votre code de test avec nous. Oui, il est prévu de travailler sur une nouvelle suite de tests pour LAPACK et toute mauvaise matrice est la bienvenue. Osni possède de nombreuses matrices de ce type et l'objectif serait d'en développer une collection, ainsi qu'une infrastructure de test. Dans tous les cas, merci d'avoir ajouté le BUG 126 en tant que problème GitHub. C'est bien. Bravo Julien.

Ce bogue est lié au critère de découpage utilisé dans DSTEMR, commençant à la ligne 606 dans le fichier source correspondant (comme dans LAPACK 3.7.0). A partir de la variable d'entrée TRYRAC, le sous-programme DLARRR renvoie INFO=1 (cela semble contredire le comportement attendu de DLARRR), ce qui déclenche par la suite un découpage néfaste de la matrice tridiagonale (particulière) passée en entrée. _Si nous ignorons ce que fait DLARRR et définissons IINFO=0 juste avant "Définir le critère de fractionnement", les vecteurs renvoyés sont orthogonaux, lors de l'utilisation d'une nouvelle version de DLARRF, voir le problème 100. Cependant, ce n'est pas une solution appropriée à ce bogue : nous besoin de comprendre quel devrait être le comportement correct de DLARRR._)

Salut, des news concernant la résolution de ce bug ?

@oamarques L'utilisation de DSTEGR au lieu du DSTEMR sous-jacent atténue-t-elle ce problème ?

@uihsnv : bonne question. STEGR n'est plus maintenu. Il y a des problèmes avec ça. Nous travaillons et maintenons uniquement STEMR. Mais, oui, ce serait une bonne idée de voir ce que STEGR fait sur ce problème.

@langou Ah ! Je n'en avais aucune idée!! J'utilise quelques instances de STEGR dans mon code. Dois-je passer à STEMR ?

De plus, j'ai apporté quelques modifications au test que @miroi a partagé, et s'il accepte, vous pouvez voir les différences.

J'utilise quelques instances de STEGR dans mon code. Dois-je passer à STEMR ?

Je pense que oui. J'espère que @oamarques fera bientôt le suivi avec nous.

De plus, j'ai apporté quelques modifications au test que @miroi a partagé, et s'il accepte, vous pouvez voir les différences.

Ce serait formidable de partager le test modifié avec @oamarques

Bonjour, des nouvelles concernant ce bug ? Et pourquoi était-il étiqueté "Documentation" ?

Pourtant, lapack frais donne cette erreur (testé avec gfortran 4.9.2 , https://github.com/miroi/lapack-dsyevr-test ):

~~~
Bienvenue dans le programme de test des routines de diagonalisation de DIRAC !
lire N= 9 NZ= 1
la matrice de diagonalisation a été lue
tableaux pour le sous-programme RS alloué
Valeurs propres RS d'Eispack :
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> norme/diag :0.1912D-15 norme/horsdiag :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
Valeurs propres LAPACK DSYEVR :
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> norme/diag :0.1807D-14 norme/offdiag :0.9012D-07
U^{+} U - I ?= 0> norme/diag :0.2591D-15 norme/horsdiag :0.1802D-06U U^{+} - I ?= 0> norme/diag:0.7543D-06 norme/offdiag:0.4951D-06
Valeurs propres LAPACK DSTEGR :
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> norme/diag :0.1617D+01 norme/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

~~~

En relisant ceci, il semble que sa résolution dépende de la résolution # 100 qui a été causée par une tentative de résolution d'une boucle infinie (le sentiment que je me spécialise dans la proposition de solutions boiteuses de basse technologie pour ceux-ci ces derniers temps) et le tout est entré dans une boucle infinie de des doutes sur ce que pourrait être une solution idéale. Quelqu'un est-il revenu à la version 3.5.0 et a-t-il vérifié comment ce cas se comportait avant le changement de la variable flag mentionnée dans #100 ?