Lapack: DSYEVR retorna vetores não ortogonais

Oi Miro, Obrigado por adicionar o BUG 126 como um problema do GitHub. Isso é ótimo. Osni ( @oamarques ) está trabalhando no #100. Obrigado por compartilhar seu código de teste conosco. Sim, há um plano para trabalhar em um novo conjunto de testes para o LAPACK e qualquer matriz desagradável é bem-vinda. A Osni tem muitas dessas matrizes e o objetivo seria aumentar uma coleção delas, juntamente com uma infraestrutura para testes. De qualquer forma, obrigado por adicionar o BUG 126 como um problema do GitHub. Isso é ótimo. Abraço, Juliano.

Este bug está relacionado ao critério de divisão usado no DSTEMR, começando na linha 606 no arquivo de origem correspondente (como no LAPACK 3.7.0). Com base na variável de entrada TRYRAC, a sub-rotina DLARRR retorna INFO=1 (isso parece contradizer o comportamento esperado de DLARRR), que posteriormente desencadeia uma divisão prejudicial da matriz tridiagonal (particular) passada como entrada. _Se ignorarmos o que o DLARRR faz e definir IINFO=0 logo antes de "Definir o critério de divisão", os vetores retornados são ortogonais, ao usar uma nova versão do DLARRF, consulte o problema 100. No entanto, esta não é uma correção adequada para este bug: nós precisa descobrir qual deve ser o comportamento correto do DLARRR._)

Oi, alguma notícia sobre a resolução deste bug?

@oamarques O uso de DSTEGR em vez do DSTEMR subjacente atenua esse problema?

@uihsnv : boa pergunta. STEGR não é mais mantido. Há problemas com isso. Estamos apenas trabalhando e mantendo STEMR. Mas, sim, seria uma boa ideia ver o que o STEGR faz nesse problema.

@langou Ah! Eu não fazia ideia!! Estou usando algumas instâncias de STEGR no meu código. Devo mudar para o uso de STEMR?

Além disso, fiz algumas modificações no teste que @miroi compartilhou, que se ele aceitar, você pode ver as diferenças.

Estou usando algumas instâncias de STEGR no meu código. Devo mudar para o uso de STEMR?

Eu penso que sim. Espero que @oamarques acompanhe isso em breve conosco.

Além disso, fiz algumas modificações no teste que @miroi compartilhou, que se ele aceitar, você pode ver as diferenças.

Seria ótimo compartilhar o teste modificado com @oamarques

Olá, alguma notícia sobre este bug? E por que foi rotulado como "Documentação"?

Ainda assim, o novo lapack dá este erro (testado com gfortran 4.9.2 , https://github.com/miroi/lapack-dsyevr-test ):

~~~
Bem-vindo ao programa de testes das rotinas de diagonalização do DIRAC!
leia N= 9 NZ= 1
matriz para diagonalização foi lida
arrays para sub-rotina RS alocados
Autovalores RS de 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> norma/diag:0.1912D-15 norma/offdiag:0.1008D-15
U^{+} U - I ?= 0> norma/diag:0,2344D-15 norma/offdiag:0,7239D-16U U^{+} - I ?= 0> norma/diag:0,9869D-16 norma/offdiag:0,9320D-16
Autovalores 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 DSIEVR*
U^{+} A U - eps ?= 0> norma/diag:0.1807D-14 norma/offdiag:0.9012D-07
U^{+} U - I ?= 0> norma/diag:0.2591D-15 norma/offdiag:0.1802D-06U U^{+} - I ?= 0> norma/diag:0.7543D-06 norma/offdiag:0.4951D-06
Autovalores 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> norma/diag:0,1617D+01 norma/offdiag:0,1644D+00
U^{+} U - I ?= 0> norma/diag:0.1234D-15 norma/offdiag:0.1802D-06U U^{+} - I ?= 0> norma/ diag:0.5411D-06 norma/ offdiag:0.2301D-06

~~~

Ao reler isso, parece que consertá-lo depende da correção # 100, que foi causada por uma tentativa de consertar um loop infinito (sentindo que estou me especializando em propor soluções de baixa tecnologia para eles ultimamente) e a coisa toda entrou em um loop infinito de dúvidas sobre qual poderia ser uma solução ideal. Alguém voltou para 3.5.0 e verificou como este caso se comportou antes da mudança da variável flag mencionada em #100 ?