# Danger of complex arithmetics in scientific computing

The complex inner product $\langle u,v\rangle$ has two different definitions decided by conventions: $\bar{u}^Tv$ or $u^T\bar{v}$. In BLAS, I found the routines cdotu, zdotu, and cdotc, zdotc. The former two routines actually compute $u^Tv$ (a fake inner product!) and the last two routines conjugate the first vector in the inner product. Also, by either definition (conjugate $u$ or $v$), $\langle u,v\rangle=\overline{\langle v,u\rangle}$ with conjugation! Moreover, as pointed out in a comment, choosing the principal values for multi-valued complex functions can be convention dependent.

My question is: does this complication cause true danger for use of complex arithmetic in scientific computing? This issue is emphasised by the authors of deal.ii who suggest to always split complex numbers into real part and imaginary part and use the real arithmetic only. But I never found the splitting approach is convenient. For example, think about the PML for time-harmonic Maxwell's equations.

It seems the worry of using complex numbers is prevalent in most open source FEM softwares except FreeFem++ and libmesh. But even for the two exceptions, the complex arithmetic is less tested than the real.

My final question is: shall we just always avoid using complex numbers?

• Does anybody really know which root of $-1$ is $i$ and which is $-i$? It would seem that a software developer should include a small set of test examples in their regression suite to guard against incorporating inconsistent conjugations in any lengthy chain of complex arithmetic computations. – hardmath Mar 21 '15 at 21:36
• @hardmath Thank you! I added it in the question. – Hui Zhang Mar 21 '15 at 22:00
• @hardmath: "small set of test examples" -- in most libraries that comprehensively implement linear algebra operations, there would likely be dozens or hundreds of places where inner products are taken. It would take hundreds of tests to verify their correctness, likely taking months to implement correctly. It's not impossible, of course, and some libraries have done that. It's just a lot of work and not all library authors are confident that they got it right :-( – Wolfgang Bangerth Mar 22 '15 at 10:56
• @WolfgangBangerth, maybe you could explain the deal.ii design decision? – Bill Barth Mar 22 '15 at 14:38
• Shall we just always avoid using complex numbers? Please, no. I believe every computational scientist needs unsymmetric eigenvalue decompositions, for instance. – Federico Poloni Mar 23 '15 at 11:57

You say that the problem with complex arithmetic is that there are different ways to define the scalar product for complex vectors, compared to just one way in the real case. I think the real problem with the complex scalar product is another one, which is, however, closely related to your observation.

In complex arithmetic the order of the arguments of the scalar product do matter, while in real arithmetic they do not. Many algorithms are essentially the same in complex and real arithmetic, meaning you just have to write them once and then use the same code for complex and real arithmetic. (For example, in C++ you can use templates for this purpose.) When you are done writing your code, you usually test it. To uncover mistakes in the ordering of the arguments in some scalar product, you have to test your code with a complex-valued test case.

You often get the real-valued code for an algorithm for free when you have a working code for complex valued problems. When you have tested your code with a complex-valued test case, the code is often also correct for real numbers. Turning, a real-valued code into a complex one, however, requires additional work. Therefore, there are just more codes that just work (and are thoroughly tested) for real-valued than for complex valued problems.

My question is: does this complication cause true danger for use of complex arithmetic in scientific computing?

I would say "Yes", in the following way. When the code is not well tested for complex-valued problems, there is a higher probability of bugs in the code, but this depends on the concrete code you are looking at. When the code is well tested, there is no problem.

My final question is: shall we just always avoid using complex numbers?

As already pointed out, there are problems that cannot be solved using real numbers. For example, the computation of eigenvalues of unsymmetric matrices. Hence, we need complex arithmetic.

This paper is relevant:

Branch Cuts for Elementary Complex Functions or Much Ado About Nothing's Sign Bit.

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

• Welcome to SciComp! Perhaps you could explain more about why the paper you link is relevant? A summary would make your answer more valuable, and more likely to be upvoted. We tend to discourage answers that add links without sufficient context. – Geoff Oxberry Mar 23 '15 at 18:59