Programming with complex numbers

[fanf]

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

On pages 11-15 this rant goes off on a tangent about branch cuts in complex arithmetic. It distinguishes between C99-style complex numbers, which have a separate type for bare imaginary numbers, and Fortran-style complex numbers, which do not. The authors assert that it isn't possible for Fortran-style complex numbers to handle signed zeroes correctly and therefore that programs written to use this style of arithmetic necessarily get branch cuts wrong.

This seems unlikely to me, if the programmer has suitable facilities for constructing or decomposing complex numbers from or into two reals. I guess they must be over-simplifying.

Comments

pure imaginaries

[(Anonymous)]

I think that there is a problem in Fortran-style (and Common Lisp-style, which is where I come from) imaginaries and zeros, in that typically the complex numbers which can be decomposed into two reals must have the two reals of the same type: for instance, at least in CL, if you have \sqrt{i} it must be represented as #C(0.70710677 0.70710677); 1+2i must be #C(1 2) and cannot be #C(1 2.0) or any other mixed representation.

Why does this matter? It matters because there are three values for the real part to consider along the imaginary axis: +0, -0 and really truly 0. But it's impossible to express the third concept with a floating point imaginary part in those languages with no mixed representation. I'd have to go back to my notes to dig out cases where it matters, but the basic point is that multiplying a floating point real by i twice is not the same as multiplying by -1, and that causes pain.

Christophe

Re: pure imaginaries

[fanf]

Hmm, yes I think i² is a good pointer to where the problem may lie... I wonder what the C99 standard and rationale have to say.

Re: pure imaginaries

[mad-tigger.livejournal.com]

How does having a 'truly zero' help, unless you define your function to have a value at zero that is inequal to either of its +/-0 limits. If you do that you've lef the realms of complex numbers well behind. If you have a branch cut, then it's meaningless to say you're on the branch cut rather than either side of it, e.g. for sqrt(z) the principal branch has a cut along the negative reals and restrict the argument of z to be -pi < arg(z) <= pi, thus giving you a function that has a definite answer that is not path dependant.

Fundamentally, if you deal with a function with a branch cut and do not stay well enough away from the cut the value of the function either becomes discontinuous or path dependant, given that we don't expect complex libraries to require a path along which to evaluate a function, the only posisble way to resolve this is to only return the principal branch. The fortran happens to pick the ''wrong'' branch of log(z^2 + zsqrt(z^2+1)) in the example given, but it picks a perfectly legitimate interpretation of log(-r).

What the guy wants it to do is take g(-ri + 0) get -X - 0i out, and then take the log. However, how does having an imaginary class help that, you need the +0 in the argument to g to make it even vaguely sensible. That just requires a library that takes care over the +/- 0, and really, if you're using functions that have that many branch points you ought to do that yourself.