Lapack: Потеря точности во всех неявных и явных запросах рабочей области одинарной точности

Я предполагаю, что в то время это должно было иметь смысл (возвращать размер через указатель рабочего массива), но мне интересно, что мешает нам превратить спецификатор размера в переменную ввода / вывода и передать туда точное значение? «Современный» вызывающий объект сначала проверит это и обратится к члену рабочего массива, только если lwork все еще будет -1, «старый» вызывающий не заметит изменений.

Также, вероятно, требуемый LWORK тогда был физически слишком велик, чтобы решить эту проблему, и ilp64 сделал это очевидным. Я мечтаю о днях, когда значение NB выводится во время выполнения, а не по схеме с двумя вызовами.

Вот две темы обсуждения, связанные с этим:
https://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=1418
http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00827.html

Это особенно проблема для алгоритмов, которым требуется рабочее пространство O (n ^ 2). Для алгоритма, для которого требуется рабочее пространство O (n * nb), это не проблема.

Да, это недоработка конструкции.

@ martin-frbg: как бы вы предложили изменение интерфейса C _work? Только там у нас есть LWORK как INPUT. При изменении LWORK на INPUT / OUTPUT происходит серьезное изменение. У вас есть идея решить эту проблему? Видеть:
https://github.com/Reference-LAPACK/lapack/blob/aa631b4b4bd13f6ae2dbab9ae9da209e1e05b0fc/LAPACKE/src/lapacke_dgeqrf_work.c#L35

Я думал, что мы могли бы также создать некоторые подпрограммы распределения рабочего пространства, такие как LAPACK_dgeqrf__workspace_query (), и это вернет необходимое рабочее пространство.

Хорошо, мой хитрый план не работает, когда я трезв ...
Но на самом деле, я думаю, это две проблемы: одна - размер работы, превышающий lapack_int, а другая - "всего лишь" искажение из-за ограниченной точности - мне интересно, можно ли округлить рассчитанный размер, чтобы предвидеть последнее, за счет "какая-то" неиспользуемая память?

Да, это недоработка конструкции.

Здесь я вижу 2 разных недостатка:

1. В LAPACK: процедуры возвращают размер работы с использованием реальной переменной.
2. В LAPACKE: подпрограммы распространяют брешь из LAPACK.

Идея @martin-frbg - хорошее решение (1). Новый код Fortran может использовать возвращаемое значение LWORK вместо WORK (1). Мы можем попробовать изменить код с помощью некоторой (полу) автоматической процедуры замены. Например, в ssyevd.f мы могли бы заменить

  ELSE IF( LQUERY ) THEN
     RETURN
  END IF

по

  ELSE IF( LQUERY ) THEN
     LWORK = LOPT
     RETURN
  END IF

Добавление LAPACKE_dgeqrf__work_query() , как предлагает @langou , решает (2), хотя с этой модификацией связано много работы.

Изначально изменение lwork на IN / OUT было бы хорошим решением, но оно не имеет обратной совместимости. Затем приложению необходимо знать, была ли версия LAPACK <= 3.10 (скажем) или> 3.10, чтобы узнать, где взять работу. Хуже того, бывают случаи, когда приложения передают константное значение - ожидая, что оно останется константным, - поэтому LAPACK, изменяя свое поведение, чтобы перезаписать это значение, будет очень вредным (UB). Например, в МАГМА:

    const magma_int_t ineg_one = -1;
    ...
            magma_int_t query_magma, query_lapack;
            magma_zgesdd( *jobz, M, N,
                          unused, lda, runused,
                          unused, ldu,
                          unused, ldv,
                          dummy, ineg_one,  // overwriting ineg_one would break MAGMA
                          #ifdef COMPLEX
                          runused,
                          #endif
                          iunused, &info );
            assert( info == 0 );
            query_magma = (magma_int_t) MAGMA_Z_REAL( dummy[0] );

Решение, которое я предложил несколько лет назад и реализовано в MAGMA, состоит просто в sgesdd и т. Д., Чтобы немного округлить lwork, возвращаемое в work [1], поэтому возвращаемое значение всегда> = предполагаемое значение. См. Https://bitbucket.org/icl/magma/src/master/control/magma_zauxiler.cpp и используйте в https://bitbucket.org/icl/magma/src/master/src/zgesdd.cpp. (См. Выпуск для сгенерированной версии с одинарной точностью.) В основном заменить

    WORK( 1 ) = MAXWRK

с

    WORK( 1 ) = lapack_roundup_lwork( MAXWRK )

где функция lapack_roundup_lwork немного округляет его, как это делает magma_*make_lwork . В MAGMA я округлял, умножая на (1 + eps), используя eps с одинарной точностью, но выполняя вычисления в двойном размере. Тогда существующие приложения будут вести себя правильно, без необходимости изменять запросы своей рабочей области.

После дополнительного тестирования я обнаружил, что для lwork> 2 ^ 54 необходимо использовать определение epsilon = 1.19e-07 (также известное как ulp) в C / C ++ / Fortran, а не определение LAPACK slamch ("eps") = 5.96e- 08 (он же округление единиц, u). Если вы используете ulp, похоже, что расчет может быть выполнен за один раз.