Niebezpieczeństwo złożonej arytmetyki w obliczeniach naukowych

Kompleks iloczyn skalarny dwa różne definicje ustalone przez konwencje: ˂ u, T, V lub u T ˂ v . W BLAS znalazłem procedury cdotu, zdotu i cdotc, zdotc. Dwie poprzednie procedury faktycznie obliczają u T v (fałszywy produkt wewnętrzny!), A dwie ostatnie procedury koniugują pierwszy wektor w produkcie wewnętrznym. Ponadto, według jednej z definicji (koniugat U lub 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}$z koniugacją! Ponadto, jak wskazano w komentarzu, wybór głównych wartości dla złożonych funkcji wielowartościowych może być zależny od konwencji.

Moje pytanie brzmi: czy ta komplikacja powoduje prawdziwe zagrożenie dla stosowania złożonej arytmetyki w obliczeniach naukowych? Kwestię tę podkreślają autorzy rozdania.ii, którzy sugerują zawsze dzielenie liczb zespolonych na część rzeczywistą i część urojoną i stosowanie wyłącznie prawdziwej arytmetyki. Ale nigdy nie uważałem, że podejście dzielenia jest wygodne. Pomyśl na przykład o PML dla harmonicznych czasowych równań Maxwella.

Wydaje się, że zmartwienie związane ze stosowaniem liczb zespolonych jest powszechne w większości programów FEM typu open source, z wyjątkiem FreeFem ++ i libmesh. Ale nawet w przypadku dwóch wyjątków złożona arytmetyka jest mniej testowana niż rzeczywista.

Moje ostatnie pytanie brzmi: czy zawsze powinniśmy unikać używania liczb zespolonych?

Mówisz, że problem ze złożoną arytmetyką polega na tym, że istnieją różne sposoby definiowania iloczynu skalarnego dla złożonych wektorów, w porównaniu z tylko jednym sposobem w prawdziwym przypadku. Myślę, że prawdziwym problemem ze złożonym iloczynem skalarnym jest inny, który jest jednak ściśle związany z twoją obserwacją.

W złożonej arytmetyki kolejność argumentów iloczynu skalarnego ma znaczenie, podczas gdy w prawdziwej arytmetyki nie. Wiele algorytmów jest zasadniczo takich samych w złożonej i rzeczywistej arytmetyce, co oznacza, że ​​musisz je tylko raz napisać, a następnie użyć tego samego kodu do złożonej i rzeczywistej arytmetyki. (Na przykład w C ++ możesz użyć do tego celu szablonów). Po zakończeniu pisania kodu zwykle go testujesz. Aby odkryć błędy w porządkowaniu argumentów w niektórych produktach skalarnych, musisz przetestować swój kod w przypadku testowym o złożonej wartości.

Często dostajesz kod o wartości rzeczywistej dla algorytmu za darmo, gdy masz działający kod na złożone problemy. Po przetestowaniu kodu w przypadku testu o złożonej wartości kod często jest również poprawny dla liczb rzeczywistych. Przekształcenie kodu o wartościach rzeczywistych w złożony wymaga jednak dodatkowej pracy. Dlatego jest tylko więcej kodów, które po prostu działają (i są dokładnie testowane) w przypadku problemów o wartości rzeczywistej niż w przypadku problemów o złożonej wartości.

Moje pytanie brzmi: czy ta komplikacja powoduje prawdziwe zagrożenie dla stosowania złożonej arytmetyki w obliczeniach naukowych?

Powiedziałbym „Tak” w następujący sposób. Kiedy kod nie jest dobrze przetestowany pod kątem problemów o złożonej wartości, istnieje większe prawdopodobieństwo błędów w kodzie, ale zależy to od konkretnego kodu, na który patrzysz. Kiedy kod jest dobrze przetestowany, nie ma problemu.

Moje ostatnie pytanie brzmi: czy zawsze powinniśmy unikać używania liczb zespolonych?

Jak już wspomniano, istnieją problemy, których nie można rozwiązać za pomocą liczb rzeczywistych. Na przykład obliczanie wartości własnych macierzy niesymetrycznych. Dlatego potrzebujemy złożonej arytmetyki.

Ten artykuł jest odpowiedni:

Odcięcia gałęzi dla elementarnych złożonych funkcji lub dużo hałasu o bit znaku nic.

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