Lapack: 暗黙的および明示的なすべての単精度ワークスペースクエリでの精度の低下

当時は（作業配列ポインターを介してサイズを返すために）理にかなっていると思いますが、サイズ指定子を入力/出力変数に変換して正確な値を返すのを妨げるものは何でしょうか？ 次に、「最新の」呼び出し元は最初にそれを確認し、lworkがまだ​​-1の場合にのみ、作業配列メンバーに頼ります。「古い」呼び出し元は変更に気づきません。

また、おそらく当時必要だったLWORKは物理的に大きすぎてこの問題を解決できず、ilp64がそれを明らかにしました。 2呼び出し方式ではなく、実行時にNB値が導出される日を夢見ています。

これに関連する2つのディスカッションスレッドは次のとおりです。
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があります。 LWORKをINPUT / OUTPUTに変更すると、大きな変更があります。 この問題を解決するためのアイデアはありますか？ 見る：
https://github.com/Reference-LAPACK/lapack/blob/aa631b4b4bd13f6ae2dbab9ae9da209e1e05b0fc/LAPACKE/src/lapacke_dgeqrf_work.c#L35

LAPACK_dgeqrf__workspace_query（）などのワークスペース割り当てサブルーチンを作成することもでき、これにより必要なワークスペースが返されると考えていました。

ウェルプ、私の狡猾な計画は、地味なときは実際には機能しません...
しかし、これらは実際には2つの問題だと思います。1つはlapack_intでオーバーフローする作業サイズであり、もう1つは精度が限られているために不実表示のみです。計算されたサイズを切り上げて後者を予測することは可能でしょうか。 「いくつかの」未使用のメモリ？

はい、これは設計上の欠陥です。

私はここで2つの異なる欠陥を見ることができます：

1. LAPACKの場合：ルーチンは実変数を使用して作業サイズを返します。
2. LAPACKEの場合：ルーチンはLAPACKからの欠陥を伝播します。

@ martin-frbgのアイデアは、（1）の良い解決策です。 新しいFortranコードでは、WORK（1）の代わりにLWORKの戻り値を使用できます。 置換のためのいくつかの（半）自動手順でコードを変更してみることができます。 たとえば、 ssyevd.fでは、置き換えることができます

  ELSE IF( LQUERY ) THEN
     RETURN
  END IF

に

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

@langouが示唆するように、 LAPACKE_dgeqrf__work_query()追加すると、（2）が解決されますが、この変更に関連する作業はたくさんあります。

lworkをIN / OUTに変更することは、元々は優れたソリューションですが、下位互換性はありません。 その場合、アプリケーションは、LAPACKのバージョンが<= 3.10（たとえば）であるか> 3.10であるかを認識して、lworkの入手先を知る必要があります。 さらに悪いことに、アプリケーションがconst値を渡す場合があります（constのままであると期待します）。そのため、LAPACKがその動作を変更してその値を上書きすると、非常に有害になります（UB）。 たとえば、MAGMAでは次のようになります。

    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に実装したソリューションは、work [1]で返されたlworkを少し切り上げるために、単にsgesddなどで行われるため、戻り値は常に意図した値以上になります。 https://bitbucket.org/icl/magma/src/master/control/magma_zauxiliary.cppを参照し、 ください。 （生成された単精度バージョンのリリースを参照してください。）基本的に置換

    WORK( 1 ) = MAXWRK

と

    WORK( 1 ) = lapack_roundup_lwork( MAXWRK )

ここで、関数lapack_roundup_lworkは、 magma_*make_lworkと同様に、わずかに切り上げます。 MAGMAでは、単精度epsを使用し、計算を2倍にして、（1 + eps）を掛けて切り上げました。 そうすれば、既存のアプリケーションは、ワークスペースクエリを変更することなく正しく動作します。

さらにテストした結果、lwork> 2 ^ 54の場合、LAPACK定義slamch（ "eps"）= 5.96e-ではなく、イプシロン= 1.19e-07（別名ulp）のC / C ++ / Fortran定義を使用する必要があることがわかりました。 08（別名ユニット丸め、u）。 ulpを使用している場合、計算は1回で実行できるように見えます。