## Programming with complex numbers

#### « previous entry | next entry »

** 31st May 2006 | 10:14**

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.

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.

## pure imaginaries

from:anonymousdate:31st May 2006 10:29 (UTC)Permalink

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

itwice is not the same as multiplying by -1, and that causes pain.Christophe

## Reply | Thread

## Re: pure imaginaries

from:fanfdate:31st May 2006 13:12 (UTC)Permalink

i^{2}is a good pointer to where the problem may lie... I wonder what the C99 standard and rationale have to say.## Reply | Parent | Thread

## Re: pure imaginaries

from:mad_tiggerdate:31st May 2006 16:27 (UTC)Permalink

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.

## Reply | Parent | Thread

from:ewxdate:31st May 2006 12:07 (UTC)Permalink

Branch cuts for complex elementary functions; or, Much ado about nothing's sign bithas the answer. Perhaps an instance can be found in the UL (I can't find any indication of an online version). But while looking I found tthis somewhat diverting - I kind of like the idea of anonymous mathematicians taking pot shots through journals.## Reply | Thread

(Deleted comment)## Re: You look like the silent type

from:fanfdate:31st May 2006 14:53 (UTC)Permalink

## Reply | Parent | Thread

(Deleted comment)