Pericolo di aritmetica complessa nell'informatica scientifica

Il complesso prodotto interno ha due diverse definizioni decise dalle convenzioni: o . In BLAS, ho trovato le routine cdotu, zdotu e cdotc, zdotc. Le prime due routine in realtà calcolano (un prodotto interno falso!) E le ultime due routine coniugano il primo vettore nel prodotto interno. Inoltre, da una definizione (coniugato o ), con coniugazione! Inoltre, come sottolineato in un commento, la scelta dei valori principali per le funzioni complesse multivalore può essere dipendente dalla convenzione. $\langle u,v\rangle$ $\bar{u}^Tv$ $u^T\bar{v}$ $u^Tv$ $u$ $v$ $\langle u,v\rangle=\overline{\langle v,u\rangle}$

La mia domanda è: questa complicazione causa un vero pericolo per l'uso dell'aritmetica complessa nell'informatica scientifica? Questo problema è sottolineato dagli autori di deal.ii che suggeriscono di dividere sempre numeri complessi in parte reale e parte immaginaria e usare solo l'aritmetica reale. Ma non ho mai trovato conveniente l'approccio alla scissione. Ad esempio, pensa al PML per le equazioni di Maxwell armoniche nel tempo.

Sembra che la preoccupazione di usare numeri complessi sia prevalente nella maggior parte dei software FEM open source tranne FreeFem ++ e libmesh. Ma anche per le due eccezioni, l'aritmetica complessa è meno testata di quella reale.

La mia ultima domanda è: dovremmo sempre evitare di usare numeri complessi?

— Hui Zhang
fonte

Qualcuno sa davvero quale radice di

e quale è

? Sembrerebbe che uno sviluppatore di software dovrebbe includere una piccola serie di esempi di test nella loro suite di regressione per evitare di incorporare coniugazioni incoerenti in qualsiasi lunga catena di calcoli aritmetici complessi.

- 1

$-1$

i

$i$

- i

$-i$

— Hardmath,

@hardmath Grazie! L'ho aggiunto alla domanda.

— Hui Zhang,

@hardmath: "piccola serie di esempi di test" - nella maggior parte delle biblioteche che implementano in modo completo operazioni di algebra lineare, ci sarebbero probabilmente dozzine o centinaia di luoghi in cui vengono presi i prodotti interni. Ci vorrebbero centinaia di test per verificarne la correttezza, probabilmente impiegheranno mesi per implementare correttamente. Naturalmente non è impossibile e alcune biblioteche lo hanno fatto. È solo un sacco di lavoro e non tutti gli autori di biblioteche sono sicuri di aver capito bene :-(

— Wolfgang Bangerth,

@ WolfgangBangerth, forse potresti spiegare la decisione di progettazione di deal.ii?

— Bill Barth,

Eviteremo sempre di usare numeri complessi? Per favore no. Credo che ogni scienziato computazionale abbia bisogno di decomposizioni di autovalori asimmetriche, per esempio.

— Federico Poloni,

Risposte:

Dici che il problema con l'aritmetica complessa è che ci sono diversi modi per definire il prodotto scalare per vettori complessi, rispetto a un solo modo nel caso reale. Penso che il vero problema con il complesso prodotto scalare sia un altro, che è tuttavia strettamente correlato alla tua osservazione.

Nell'aritmetica complessa l'ordine degli argomenti del prodotto scalare è importante, mentre nell'aritmetica reale non contano. Molti algoritmi sono essenzialmente gli stessi nell'aritmetica complessa e reale, il che significa che devi solo scriverli una volta e quindi utilizzare lo stesso codice per l'aritmetica complessa e reale. (Ad esempio, in C ++ puoi usare i template per questo scopo.) Quando hai finito di scrivere il tuo codice, di solito lo collaudi. Per scoprire errori nell'ordinamento degli argomenti in alcuni prodotti scalari, è necessario testare il codice con un caso di test di valore complesso.

Spesso si ottiene gratuitamente il codice a valore reale per un algoritmo quando si dispone di un codice funzionante per problemi a valore complesso. Dopo aver testato il codice con un caso di valutazione a valore complesso, il codice è spesso corretto anche per i numeri reali. La trasformazione di un codice a valore reale in un codice complesso, tuttavia, richiede un lavoro aggiuntivo. Pertanto, ci sono solo più codici che funzionano (e sono stati testati a fondo) per problemi con valori reali che per problemi con valori complessi.

La mia domanda è: questa complicazione causa un vero pericolo per l'uso dell'aritmetica complessa nell'informatica scientifica?

Direi "Sì", nel modo seguente. Quando il codice non è ben testato per problemi di valore complesso, c'è una maggiore probabilità di bug nel codice, ma questo dipende dal codice concreto che stai osservando. Quando il codice è ben testato, non ci sono problemi.

La mia ultima domanda è: dovremmo sempre evitare di usare numeri complessi?

Come già sottolineato, ci sono problemi che non possono essere risolti utilizzando numeri reali. Ad esempio, il calcolo di autovalori di matrici asimmetriche. Quindi, abbiamo bisogno di aritmetica complessa.

— H. Rittich
fonte

-1

Questo documento è rilevante:

Il ramo taglia per funzioni complesse elementari o molto rumore per il bit di segno di niente.

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

— Julian Cienfuegos
fonte

Benvenuto in SciComp! Forse potresti spiegare di più sul perché il documento che colleghi è rilevante? Un riepilogo renderebbe la tua risposta più preziosa e più probabile che venga votata. Tendiamo a scoraggiare le risposte che aggiungono collegamenti senza un contesto sufficiente.

— Geoff Oxberry,