Peligro de la aritmética compleja en informática científica.

El producto complejo interior tiene dos definiciones diferentes decididas por convenciones: ˉ u T v o u T ˉ v . En BLAS, encontré las rutinas cdotu, zdotu y cdotc, zdotc. Las dos primeras rutinas en realidad calculan u T v (¡un producto interno falso!) Y las dos últimas rutinas conjugan el primer vector en el producto interno. También, por cualquiera de las definiciones (conjugado u o 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}$con conjugación! Además, como se señaló en un comentario, la elección de los valores principales para funciones complejas de valores múltiples puede depender de la convención.

Mi pregunta es: ¿esta complicación causa verdadero peligro para el uso de aritmética compleja en computación científica? Este tema es enfatizado por los autores de deal.ii que sugieren dividir siempre números complejos en parte real y parte imaginaria y usar solo la aritmética real. Pero nunca encontré que el enfoque de división sea conveniente. Por ejemplo, piense en la PML para las ecuaciones de Maxwell armónicas en el tiempo.

Parece que la preocupación de usar números complejos prevalece en la mayoría de los softwares de código abierto de FEM, excepto FreeFem ++ y libmesh. Pero incluso para las dos excepciones, la aritmética compleja está menos probada que la real.

Mi última pregunta es: ¿debemos evitar siempre usar números complejos?

Usted dice que el problema con la aritmética compleja es que hay diferentes formas de definir el producto escalar para vectores complejos, en comparación con solo una forma en el caso real. Creo que el verdadero problema con el complejo producto escalar es otro, que, sin embargo, está estrechamente relacionado con su observación.

En la aritmética compleja, el orden de los argumentos del producto escalar es importante, mientras que en la aritmética real no lo es. Muchos algoritmos son esencialmente iguales en aritmética compleja y real, lo que significa que solo tiene que escribirlos una vez y luego usar el mismo código para aritmética compleja y real. (Por ejemplo, en C ++ puede usar plantillas para este propósito). Cuando termine de escribir su código, generalmente lo prueba. Para descubrir errores en el orden de los argumentos en algún producto escalar, debe probar su código con un caso de prueba de valor complejo.

A menudo obtiene el código de valor real para un algoritmo de forma gratuita cuando tiene un código de trabajo para problemas de valor complejo. Cuando ha probado su código con un caso de prueba de valor complejo, el código a menudo también es correcto para números reales. Sin embargo, convertir un código de valor real en uno complejo requiere trabajo adicional. Por lo tanto, hay más códigos que funcionan (y se prueban exhaustivamente) para problemas de valor real que para problemas de valor complejo.

Mi pregunta es: ¿esta complicación causa verdadero peligro para el uso de aritmética compleja en computación científica?

Yo diría "Sí", de la siguiente manera. Cuando el código no está bien probado para detectar problemas de valor complejo, existe una mayor probabilidad de errores en el código, pero esto depende del código concreto que esté viendo. Cuando el código está bien probado, no hay problema.

Mi última pregunta es: ¿debemos evitar siempre usar números complejos?

Como ya se señaló, hay problemas que no se pueden resolver con números reales. Por ejemplo, el cálculo de valores propios de matrices asimétricas. Por lo tanto, necesitamos aritmética compleja.

Este documento es relevante:

Cortes de rama para funciones complejas elementales o mucho ruido y pocas nueces.

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