(SC22WG14.1732) Complex bakeoff - example 1

Doug Gwyn (ACISD/MCSB) uunet!ARL.MIL!gwyn
Wed Oct 4 18:20:11 PDT 1995


Continued fractions are certainly an important family of application
examples, and clearly they directly benefit from the IEEE extensions
1/inf = 0 and 1/0 = inf.  I admit to not having kept track of the
evolution of the competing complex C extension proposals, but am
puzzled to hear that Cray's proposal does not currently preserve a
property like 1/inf = 0.  I thought the real issues were twofold:
	(a) separate representation and conversion rules for pure-
	imaginary types (which has nothing to do with the current
	example), and
	(b) "directional" zeros and infinities, e.g.
	(+1,+0)/(-0,-inf) -> (-0,-0) (I guess) -- why that choice
		instead of -> (+0,-0) or (+0,+0) etc.?  Similarly,
	(+1,+0)/(-0,-0) -> (-inf,-0) (I guess) -- why not (-0,-inf)
		or (-inf,+inf) or some other flavor of infinity?
Directional issues are very important in complex math; the functions
whose derivatives do not depend on the direction from which the limits
are approached form an important subclass of all functions, for example.
(Their partial derivatives w.r.t. real and imaginary components obey
the Cauchy conditions, which is not true of complex functions in
general.)  It is a mystery to me what the "right" specification should
be for these 0-reciprocal-of-inf cases, when forced to choose a
real-IEEE representation for each component, real and imaginary.
As discussed previously, there are numerous important situations in
complex analysis where the most useful approach is to have a single
(non-coordinate, non-signed) "infinity" element added to the complex
field.  Of course, mathematically the idea of distinct -0 and +0
values is pretty silly, since by any of the usual axiom systems one
can quickly show that -0 = +0 and so there is no difference in value;
why there should be a difference in representation when there is no
difference in value may be a matter of convenience for some classes of
computation, but it muddies the C standard which tries to dictate
numeric properties only in terms of the resulting *values*.

My 2-cents worth for the day.



More information about the Numeric-interest mailing list