과학 컴퓨팅에서 복잡한 산술의 위험

복소 내적 : 규칙에 의해 결정된 두 가지 정의 보유 ˉ U T V 또는 U T ˉ 브이 . BLAS에서 cdotu, zdotu 및 cdotc, zdotc 루틴을 찾았습니다. 전자의 두 루틴은 실제로 u T v (가짜 내부 제품!)를 계산하고 마지막 두 루틴은 내부 제품의 첫 번째 벡터를 결합합니다. 또한, 어느 정의상 (공액 U 또는 V ) ⟨ U , V ⟩ = ¯ ⟨ V , U $\langle u,v\rangle$$\bar{u}^Tv$$u^T\bar{v}$$u^Tv$$u$$v$$\langle u,v\rangle=\overline{\langle v,u\rangle}$활용 또한 주석에서 지적했듯이 다중 값 복합 함수의 주요 값을 선택하는 것은 규칙에 따라 다를 수 있습니다.

내 질문은 :이 합병증이 과학 컴퓨팅에서 복잡한 산술을 사용하는 데 진정한 위험을 초래합니까? 이 문제는 deal.ii 저자가 강조합니다. 그는 복잡한 숫자를 항상 실수 부분과 허수 부분으로 나누고 실제 산술 만 사용하도록 제안합니다. 그러나 분할 방법이 편리하다는 것을 결코 알지 못했습니다. 예를 들어 시간-고조파 맥스웰 방정식 에 대한 PML 을 생각해보십시오 .

FreeFem ++ 및 libmesh를 제외한 대부분의 오픈 소스 FEM 소프트웨어에서 복잡한 숫자를 사용하는 것에 대한 우려가 널리 퍼져있는 것 같습니다. 그러나 두 예외를 제외하고 복잡한 산술은 실제보다 덜 테스트됩니다.

내 마지막 질문은 : 우리는 항상 복잡한 숫자를 사용하지 않아야합니까?

복소수 산술의 문제점은 실제 경우의 한 가지 방법과 비교하여 복소수 벡터에 대한 스칼라 곱을 정의하는 방법이 다르다는 것입니다. 복잡한 스칼라 곱의 실제 문제는 또 다른 문제이지만 관찰과 밀접한 관련이 있다고 생각합니다.

복잡한 산술에서는 스칼라 곱의 인수 순서가 중요하지만 실제 산술에서는 그렇지 않습니다. 많은 알고리즘은 복소수와 실제 산술에서 본질적으로 동일합니다. 즉, 한 번만 작성한 다음 복소수와 실제 산술에 동일한 코드를 사용해야합니다. (예를 들어, C ++에서는 이러한 목적으로 템플릿을 사용할 수 있습니다.) 코드 작성이 끝나면 일반적으로 테스트합니다. 일부 스칼라 제품에서 인수 순서의 실수를 발견하려면 복잡한 값의 테스트 케이스로 코드를 테스트해야합니다.

복잡한 가치 문제에 대한 작업 코드가있는 경우 종종 알고리즘의 실제 코드를 무료로 얻을 수 있습니다. 복소수 테스트 사례를 사용하여 코드를 테스트 한 경우 코드는 실수로도 정확합니다. 그러나 실제 가치 코드를 복잡한 코드로 바꾸려면 추가 작업이 필요합니다. 따라서 복잡한 가치 문제보다 실제 가치에 대해 작동하고 철저히 테스트되는 코드가 더 많습니다.

내 질문은 :이 합병증이 과학 컴퓨팅에서 복잡한 산술을 사용하는 데 진정한 위험을 초래합니까?

나는 다음과 같이 "예"라고 말할 것입니다. 복잡한 값의 문제에 대해 코드를 제대로 테스트하지 않으면 코드에 버그가있을 가능성이 높지만보고있는 구체적인 코드에 따라 다릅니다. 코드가 제대로 테스트되면 아무런 문제가 없습니다.

내 마지막 질문은 : 우리는 항상 복잡한 숫자를 사용하지 않아야합니까?

이미 지적했듯이 실수를 사용하여 해결할 수없는 문제가 있습니다. 예를 들어, 비대칭 행렬의 고유 값 계산. 따라서 복잡한 산술이 필요합니다.

이 논문은 관련이있다 :

초등 복잡한 함수 또는 아무것도없는 부호 비트에 대한 분기 컷.

http://people.freebsd.org/~das/kahan86branch.pdf