(SC22WG14.1757) Complex bakeoff - example 2

[Doug Gwyn (ACISD/MCSB)]

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.
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.)

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.