Lapack: DSYEVR devuelve vectores no ortogonales

Hola Miro, gracias por agregar el BUG 126 como un problema de GitHub. Esto es genial. Osni ( @oamarques ) está trabajando en el #100. Gracias por compartir su código de prueba con nosotros. Sí, hay un plan para trabajar en un nuevo conjunto de pruebas para LAPACK y cualquier matriz desagradable es bienvenida. Osni tiene muchas matrices de este tipo y el objetivo sería hacer crecer una colección de estas, junto con una infraestructura para realizar pruebas. En cualquier caso, gracias por agregar el BUG 126 como problema de GitHub. Esto es genial. Saludos, Julián.

Este error está relacionado con el criterio de división utilizado en DSTEMR, comenzando en la línea 606 en el archivo fuente correspondiente (como en LAPACK 3.7.0). Basándose en la variable de entrada TRYRAC, la subrutina DLARRR devuelve INFO=1 (esto parece contradecir el comportamiento esperado de DLARRR), que posteriormente desencadena una división dañina de la matriz tridiagonal (particular) pasada como entrada. _Si ignoramos lo que hace DLARRR y establecemos IINFO=0 justo antes de "Establecer el criterio de división", los vectores devueltos son ortogonales, al usar una nueva versión de DLARRF, consulte el problema 100. Sin embargo, esta no es una solución adecuada para este error: necesito averiguar cuál debería ser el comportamiento correcto de DLARRR._)

Hola, ¿alguna noticia sobre la solución de este error?

@oamarques ¿El uso de DSTEGR en lugar del DSTEMR subyacente mitiga este problema?

@uihsnv : buena pregunta. STEGR ya no se mantiene. Hay problemas con eso. Solo estamos trabajando y manteniendo STEMR. Pero, sí, sería una buena idea ver qué hace STEGR en este problema.

@langou ¡Ah! ¡¡No tenía ni idea!! Estoy usando un par de instancias de STEGR en mi código. ¿Debo cambiar a STEMR?

Además, le he hecho algunas modificaciones a la prueba que compartió @miroi , que si acepta, pueden ver las diferencias.

Estoy usando un par de instancias de STEGR en mi código. ¿Debo cambiar a STEMR?

Creo que sí. Espero que @oamarques haga un seguimiento pronto de esto con nosotros.

Además, le he hecho algunas modificaciones a la prueba que compartió @miroi , que si acepta, pueden ver las diferencias.

Sería genial compartir la prueba modificada con @oamarques

Hola, ¿alguna noticia sobre este error? ¿Y por qué estaba etiquetado como "Documentación"?

Aún así, lapack nuevo da este error (probado con gfortran 4.9.2, https://github.com/miroi/lapack-dsyevr-test):

~~~
¡Bienvenido al programa de prueba de las rutinas de diagonalización de DIRAC!
leer N= 9 NZ= 1
se leyó la matriz para la diagonalización
matrices para la subrutina RS asignada
Valores propios 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
Valores propios de 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> norma/diag:0.1807D-14 norma/offdiag:0.9012D-07
U^{+} U - I ?= 0> norma/diagnóstico:0.2591D-15 norma/diagnóstico:0.1802D-06U U^{+} - I ?= 0> norma/diag:0.7543D-06 norma/offdiag:0.4951D-06
Valores propios de 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

~~~

Al releer esto, parece que arreglarlo depende de arreglar el #100 que fue causado por un intento de arreglar un bucle infinito (sintiendo que me estoy especializando en proponer soluciones poco tecnificadas para esos últimamente) y todo entró en un bucle infinito de dudas sobre cuál podría ser una solución ideal. ¿Alguien volvió a la versión 3.5.0 y comprobó cómo se comportaba este caso antes del cambio de la variable indicadora a la que se alude en el n.º 100?