Lapack: DSYEVR возвращает неортогональные векторы

Привет Миро, спасибо за добавление BUG 126 в качестве проблемы GitHub. Это здорово. Осни ( @oamarques ) работает над #100. Спасибо, что поделились с нами своим тестовым кодом. Да, есть план по работе над новым набором тестов для LAPACK, и любая неприятная матрица приветствуется. У Osni есть много таких матриц, и цель состоит в том, чтобы вырастить их коллекцию вместе с инфраструктурой для тестирования. В любом случае, спасибо за добавление BUG 126 в качестве проблемы GitHub. Это здорово. Здоровья, Жюльен.

Эта ошибка связана с критерием разделения, используемым в DSTEMR, начиная со строки 606 в соответствующем исходном файле (как в LAPACK 3.7.0). Основываясь на входной переменной TRYRAC, подпрограмма DLARRR возвращает INFO=1 (это, кажется, противоречит ожидаемому поведению DLARRR), что впоследствии запускает вредоносное разбиение (конкретной) трехдиагональной матрицы, переданной в качестве входных данных. _Если мы проигнорируем то, что делает DLARRR, и установим IINFO=0 непосредственно перед «Установить критерий разделения», возвращаемые векторы будут ортогональны при использовании новой версии DLARRF, см. проблему 100. Однако это не является правильным исправлением этой ошибки: мы нужно выяснить, каким должно быть правильное поведение DLARRR._)

Привет, есть новости по решению этой ошибки?

@oamarques Устраняет ли эту проблему использование DSTEGR вместо базового DSTEMR?

@uihsnv : хороший вопрос. STEGR больше не поддерживается. Есть проблемы с этим. Мы работаем только над STEMR и поддерживаем его. Но, да, было бы неплохо посмотреть, что STEGR делает с этой проблемой.

@langou О! Не имел представления!! Я использую пару экземпляров STEGR в своем коде. Должен ли я перейти на использование STEMR?

Кроме того, я внес некоторые изменения в тест, которым поделился @miroi , и если он примет их, вы сможете увидеть различия.

Я использую пару экземпляров STEGR в своем коде. Должен ли я перейти на использование STEMR?

Я так думаю. Я надеюсь, что @oamarques скоро продолжит это вместе с нами.

Кроме того, я внес некоторые изменения в тест, которым поделился @miroi , и если он примет их, вы сможете увидеть различия.

Было бы здорово поделиться модифицированным тестом с @oamarques.

Привет, есть новости по поводу этой ошибки? И почему он был помечен как «Документация»?

Тем не менее, свежий lapack выдает эту ошибку (проверено с помощью gfortran 4.9.2, https://github.com/miroi/lapack-dsyevr-test):

~~~
Добро пожаловать в программу тестирования процедур диагонализации DIRAC!
читать N = 9 NZ = 1
матрица для диагонализации была прочитана
массивы для подпрограммы RS выделены
Собственные значения RS Айспака:
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
* ЭЙСПАК РС *
U^{+} A U - eps ?= 0> норма/диаг:0.1912D-15 норма/выклдиаг:0.1008D-15
U^{+} U - I ?= 0> норма/диаг:0.2344D-15 норма/откл диаг:0.7239D-16U U^{+} - I ?= 0> норма/диаг:0.9869D-16 норма/выклдиаг:0.9320D-16
Собственные значения 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
*ЛАПАК ДСЬЕВР*
U^{+} A U - eps ?= 0> норма/диаг:0.1807D-14 норма/выклдиаг:0.9012D-07
U^{+} U - I ?= 0> норма/диаг:0.2591D-15 норма/откл диаг:0.1802D-06U U^{+} - I ?= 0> норма/диаг:0.7543D-06 норма/откл диаг:0.4951D-06
Собственные значения 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> норма/диаг:0.1617D+01 норма/выклдиаг:0.1644D+00
U^{+} U - I ?= 0> норма/диаг:0.1234D-15 норма/откл диаг:0.1802D-06U U^{+} - I ?= 0> норма/ диаг:0.5411D-06 норма/ выклдиаг:0.2301D-06

~~~

При перечитывании этого кажется, что исправление зависит от исправления #100, которое было вызвано попыткой исправить бесконечный цикл (чувство, что я специализируюсь на предложении хромых низкотехнологичных решений для тех, кто в последнее время), и все это превратилось в бесконечный цикл сомнения в том, каким может быть идеальное решение. Кто-нибудь возвращался к версии 3.5.0 и проверял, как вел себя этот случай до изменения переменной флага, упомянутой в #100?