Perigo de aritmética complexa na computação científica

O produto complexo interior tem duas definições diferentes decididas pelo convenções: ˉ u T v ou u T ˉ v . No BLAS, encontrei as rotinas cdotu, zdotu e cdotc, zdotc. Os dois primeiros rotinas realmente computação u T V (um produto interno falso!) E os dois últimos rotinas conjugar o primeiro vector no produto interno. Além disso, por definição, quer (conjugado de u ou 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}$com conjugação! Além disso, como apontado em um comentário, a escolha dos valores principais para funções complexas com vários valores pode depender da convenção.

Minha pergunta é: essa complicação causa verdadeiro perigo para o uso de aritmética complexa na computação científica? Essa questão é enfatizada pelos autores do acordo. Que sugerem sempre dividir números complexos em parte real e parte imaginária e usar apenas a aritmética real. Mas nunca achei a abordagem de divisão conveniente. Por exemplo, pense na PML para as equações de Maxwell harmônicas no tempo.

Parece que a preocupação de usar números complexos é predominante na maioria dos softwares de código-fonte aberto do FEM, exceto FreeFem ++ e libmesh. Mas mesmo para as duas exceções, a aritmética complexa é menos testada que a real.

Minha pergunta final é: devemos sempre evitar o uso de números complexos?

Você diz que o problema da aritmética complexa é que existem diferentes maneiras de definir o produto escalar para vetores complexos, em comparação com apenas uma maneira no caso real. Penso que o verdadeiro problema com o complexo produto escalar é outro, que está, no entanto, intimamente relacionado à sua observação.

Na aritmética complexa, a ordem dos argumentos do produto escalar é importante, enquanto na aritmética real, não. Muitos algoritmos são essencialmente os mesmos em aritmética complexa e real, o que significa que você apenas precisa escrevê-los uma vez e depois usar o mesmo código para aritmética real e complexa. (Por exemplo, em C ++, você pode usar modelos para esse fim.) Quando você termina de escrever seu código, geralmente o testa. Para descobrir erros na ordem dos argumentos em algum produto escalar, você deve testar seu código com um caso de teste de valor complexo.

Você geralmente obtém o código com valor real de um algoritmo gratuitamente quando possui um código de trabalho para problemas com valor complexo. Quando você testou seu código com um caso de teste de valor complexo, geralmente o código também está correto para números reais. Transformar, um código com valor real em um código complexo, no entanto, requer trabalho adicional. Portanto, há apenas mais códigos que funcionam (e são exaustivamente testados) para valores reais do que para problemas complexos.

Minha pergunta é: essa complicação causa verdadeiro perigo para o uso de aritmética complexa na computação científica?

Eu diria "Sim", da seguinte maneira. Quando o código não é bem testado para problemas de valor complexo, há uma maior probabilidade de erros no código, mas isso depende do código concreto que você está visualizando. Quando o código é bem testado, não há problema.

Minha pergunta final é: devemos sempre evitar o uso de números complexos?

Como já apontado, existem problemas que não podem ser resolvidos usando números reais. Por exemplo, o cálculo de autovalores de matrizes assimétricas. Portanto, precisamos de aritmética complexa.

Este artigo é relevante:

Cortes de ramo para funções complexas elementares ou muito barulho por nada.

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