Complex bakeoff - example 2

[Harry H. Cheng]

> exp() has a singularity at infinity under the Riemann-sphere model;
> it's not significantly worse than sqrt() having a branch point at 0
> so that computationally whether one ought to use the "principal root" or
> the negative of the principal root is something that has to be figured
> out carefully.  An error in a similar matter once caused a fly-by-wire
> fighter aircraft prototype to flip over when it crossed the equator.
> I don't think we should encourage programmers to believe that the right
> answers have been prearranged for them just because their compiler
> supports the IEEE model and CCE.
> 
> As to what the exp(z) function ought to do when (the real part of) z
> overflows, well, that's exp(point_at_infinity) and being singular
> there, there is no right answer.  Personally I would want an exception
> raised.  In IEEE terms, one has to require that exp(-inf) (the real
> argument) be 0 and exp(+inf) (the real argument) be some sort of inf
> (+inf probably), but for complex-inf argument, exp() is simply undefined.

Under the complex programming paradigm with a *single* complex infinity
and a *single* complex NaN, exp(ComplexInf) is defined as ComplexNaN.
In addition,  both +Inf and -Inf are casted as ComplexInf when
they are converted to a complex number. Of course,
exp(Inf) ==> Inf and exp(-Inf) ==> 0.0 under the IEEE model.

> If you want to devise a standard definition as the "same as the function
> with identical real part, ignoring the imaginary part", that would be *a*
> way to resolve the ambiguity, but I honestly don't see that it is any
> better than any other random choice.  Another way of putting it is that
> the complex and real functions should agree *on the real axis*, but +- inf
> is not on the real axis and therefore the functions can disagree there.
> It's all really a problem with trying to assign too much specific meaning
> to +- inf as values rather than treating them as limits.  The consistent
> treatment of infinity values among complex analysts is the Riemann-sphere
> model of one point at infinity.  All sorts of nice things happen, such as
> the ability to properly define meromorphic (global analytic) functions,
> the residue theorem applies universally, inversion in the unit circle
> (1/z function) maps infinity to the origin where it can be dealt with
> in a reasonable manner, etc.  Without that single point at infinity, a
> substantial portion of complex analysis would be spoiled.
> 
> Frankly, I don't object to specifying IEEE complex behavior to depend
> on which of the two mandated representational components (real, imag
> parts) contains what sort of signed-zero or signed-infinity; it's
> conceptually compatible with the already misguided (in my opinion)
> extension that IEEE f.p. has made to representation for real numbers.
> All I object to is the *argument* that somehow the IEEE artificial
> distinctions between mathematically identical values are more logical or
> have uniformly better properties than treating the same values the same
> way independently of the specific representational bit pattern (which is
> how we came down on the multiple-representations-of-0 issue: there can
> be multiple representations for 0, but they all have the same value with
> regard to the computational requirements specified in C89).
> 
> The reason this issue crops up for complex numbers but didn't surface
> for real numbers is that it isn't until one extends analysis into the
> complex domain that one gets a handle on infinity; the number-line model
> deceptively implies that -inf and +inf must be, intuitively, "very far
> apart", but that intuition turns out to be no different than the notion
> that -0 and +0 are significantly different.  Perhaps it would be more
> instructive to analyze what functional behavior we're expecting for
> complex functions that have a singularity or branch point at the origin,
> with 1/z, log(z), and sqrt(z) being canonical examples.  So a question
> might be, what is sqrt(-0,-0)?  Traditionally a "cut line" is introduced
> which would answer the question to some extent if -0 and +0 are taken to
> represent *approaches* to 0.  (The answer is (+0,-0) -- I don't recall
> what the CCE specified in the TR.)

This is precisely the problem with signed zeros in complex number.
One almost cannot program without carrying a manual because of
its complexity. The problem is even worse if a function involves
more than one complex zeros.
Under the complex programming paradigm with a *single* complex infinity
and a *single* complex NaN, exp(ComplexInf) is defined as ComplexNaN,
complex zero is not signed. One can expect the result
sqrt(complex(-0,-0)) ==> ComplexZero without looking at the specification.

> 
> I would suggest that, *if* it is logically possible, exp(log(z))==z &&
> log(exp(z))==z is a necessary property for all z in the IEEE-extended
> complex plane.  Given the nature of essential singularities I have my
> doubts about its feasibility.  I don't have the CCE proposal at hand
> or I would check whether it satisfies that property.
> 

As you have pointed out, exp() is singular at complex infinity.
There is no way to preserve this identity 
under a single complex infinity model.
For example,  log(exp(ComplexInf)) is ComplexNaN.
I suspect that this identity can be preserved under the CCE proposal.
Even if it is preserved purely from the IEEE-model point of view,
its applicability is questionable. 



Harry Cheng
UC Davis