Lapack: 암시적 및 명시적 모든 단정밀도 작업 공간 쿼리의 정밀도 손실

(작업 배열 포인터를 통해 크기를 반환하기 위해) 그 당시에는 의미가 있었을 것 같지만 크기 지정자를 in/out 변수로 바꾸고 정확한 값을 거기에 다시 전달하지 못하도록 하는 이유가 무엇인지 궁금합니다. 그런 다음 "현대" 호출자는 먼저 확인하고 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. LAPACK에서: 루틴은 LAPACK에서 결함을 전파합니다.

@martin-frbg의 아이디어는 (1)에 대한 좋은 솔루션입니다. 새 포트란 코드는 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 값을 전달하는 경우가 있습니다. 따라서 해당 값을 덮어쓰도록 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에서 구현한 솔루션은 단순히 sgesdd 등으로, work[1]에서 반환된 lwork를 약간 반올림하므로 반환된 값은 항상 >= 의도된 값입니다. 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를 사용하지만 두 배의 계산을 수행하여 (1 + eps)를 곱하여 반올림했습니다. 그러면 기존 응용 프로그램은 작업 공간 쿼리를 변경할 필요 없이 올바르게 작동합니다.

더 많은 테스트를 거친 후 lwork > 2^54에 대해 LAPACK 정의 slamch("eps") = 5.96e- 대신 엡실론 = 1.19e-07(일명 ulp)의 C/C++/Fortran 정의를 사용해야 한다는 것을 발견했습니다. 08(일명 단위 반올림, u). ulp를 사용하면 한 번에 계산이 가능할 것 같습니다.