(SC22WG14.1747) Complex bakeoff - example 1

[Doug Gwyn (ACISD/MCSB)]

Re. pure-imaginary type:  Yes, it has advantages (as mentioned in
previous discussions), e.g., half the storage when it is known that
the algorithm is supposed to produce precisely purely imaginary
results, and improved bookkeeping characteristics as Frank mentioned.

There are also drawbacks.  When a complex quantity is assigned to a
pure imaginary datum, as one expects to be quite common (e.g. in
Fourier transform code), the expected usage is that the r.h.s. has
exactly zero real part, which is of course not stored.  But if it
has nonzero real part, what should happen?  The two obvious
possibilities are (a) the nonzero real part is silently discarded,
or (b) the nonzero real part causes an exception to be raised.  No
matter which one chooses, it won't be universally appropriate in
all contexts.  The C language lacks in general a way to distinguish
upon a conversion (as with a cast) between two cases like that, also
for example when casting an integer into a shorter one when the r.h.s.
has a value that cannot be completely represented in the l.h.s.  I
suppose an IEEE f.p. implementation will have definite, consistent
rules to cover all such cases and not just some of the floating/
complex/imaginary cases.

Independently of complex arithmetic, it is worth remembering that
any attempt to define arithmetic for infinities/signed zeros will
run into situations such as Frank's examples, where the obviously
desired answer may not be what the arithmetic produces.  Cantor's
notion of infinities showed, as I recall, that 2^inf > inf but
inf^2 = inf.  In normal algebra on field elements, given x^2 = x,
solve for x, there are precisely two "roots":
	x = 0 and x = 1,
which is an instance of an extremely important property of roots
of polynomials over the complex field (which is the essentially
unique maximal extension field for the real numbers).  If we have
to allow inf on an equal footing with the other numbers in the
field, so that it obeys normal algebraic operations, there have to
be (at least) three roots of x^2 = x, inf being another root.
With mathematical properties like this, which run counter to
standard properties of the numbers used by engineers who devise
formulas in the first place, how is one to trust the utility of
the computed results?  Essentially, each IEEE-extended computation
has to be carefully designed anr/or evaluated to confirm that its
output has appropriate semantic interpretation for each possible
"benign exception", or else as in Frank's example the computation
is allowed to go forward but afterward if *any* exception arose
during the computation (and one would not at that point know which
exception it was), special handling would be invoked.  The
continued-fraction function was an example of the former situation,
which seems to follow the computational paradigm that is usually in
the minds of IEEE f.p. proponents, but there are numerous instances
where the latter approach would be logically necessary.

What I am saying above is, don't try to make too much sense out of
the arithmetic properties of IEEE pseudo-numbers like infinities
and signed zeros, because when pressed too far one finds that the
logic has to break down.  Users of these facilities need to be
aware of what makes sense and limit their use to that domain.