[imp-hackers] Complex contagion
Raymond Toy
raymond.toy at stericsson.com
Mon Jul 6 14:32:11 UTC 2009
The CL spec clearly says that when mixing real and complex numbers,
the real number is converted to a complex by providing an imaginary
part of 0. (CLHS 12.1.5.2)
(Let's ignore the fact that the spec is somewhat inconsistent here.
The entry for COMPLEX says the imaginary part is a zero of the same
type as the real part. But the entry for IMAGPART says that it
returns 0*realpart. If you have signed zeroes, like cmucl and sbcl,
the two functions return different values.)
Applying complex contagion isn't normally a problem. But if you have
signed zeroes or support IEEE exceptional values like infinity and
NaN, it causes some issues. If your lisp doesn't support these, you
can ignore the rest of this message.
Consider
(+ 1d0 #c(1d0 -0d0)) -> (+ #c(1d0 +0d0) #c(1d0 -0d0)) -> #c(2d0 0d0)
But if we didn't apply complex contagion, the answer would be #c(2d0
-0d0). This will cause asin to produce results where the imaginary
part has the opposite sign.
Or consider (* 1d0 #c(1d0 <pos-inf>)), where <pos-inf> is IEEE
positive infinity. If we apply complex contagion, we'll get an answer
like #c(<NaN> <pos-inf>) or a signal an invalid operation because we
multiply 0 and pos-inf. Without contagion, we would get #c(1d0
<pos-inf>). This seems a somewhat more useful answer.
Kahan (in Much Ado About Nothing's Sign) argues that when mixing real
and complex, the imaginary part should not be changed unless
necessary.
What do people think about not doing complex contagion for mixed real
and complex arithmetic?
Some pros and cons of not doing contagion
Disadvantages:
- Inconsistent with the spec, but only if signed zeroes or
exceptional values are supported.
- More operations are needed (a real*complex is simpler than complex*complex)
Advantages:
- Possibly better behavior for signed zeroes.
- Few operations
- Possibly fewer execptions signaled.
- Simplifies calculations dealing with branch cuts of special
functions.
Ray
More information about the implementation-hackers
mailing list