Complex and imaginary

[Jim Thomas]

Mail*Link(r) SMTP               RE>Complex and imaginary
This is a stab at explaining why it's important that C and C++ adopt a complex
spec along the lines of "Complex C Extensions" (X3J11.1/93-048), CCE here for
short, which includes imaginary types.  Although a C spec, it was written with
C++ compatibility in mind and has been prototyped in C++.  

Imaginary types enable a clean solution to the problem of extending the
treatment of special cases from the real to the complex domain.  For IEEE
implementations this means infinities, NaNs, and signed zeros in complex
arithmetic can behave as one reasonably would expect based on their behavior
in real arithmetic.  A simple example illustrates the problem:

The mathematical product 2.0i * (#176# + 3.0i) should be computed with two
multiplications and yield -6.0 + #176#i.  But without an imaginary type, 2.0i
would have to be represented as 0.0 + 2.0i, so that

2.0i * (#176# + 3.0i) 	=>	(0.0 + 2.0i) * (#176# + 3.0i)	
				=>	(0.0*#176# - 2.0*3.0) + (0.0*3.0 + 2.0*#176#)i					=>	NaN + #176#i

requiring four multiplications and two additions to obtain an undesirable
result.

CCE specifies imaginary types to solve these sorts of semantic/efficiency
problems and provide consistent treatment of special cases across the real and
complex domains.

On the other hand, there is no claim that a specification without imaginary
types, or some roughly equivalent mechanism, can  provide consistent treatment
of special cases.  A major achievement of the IEEE floating-point standards
was to establish a level of consistency in treatment of special cases for real
arithmetic.  A complex spec without imaginary types would anchor complex
arithmetic a decade back in the past.

The arguments put forth in favor of such an approach are (1) it would be
simpler, (2) special cases in the complex domain are so complicated that
consistency is not useful, and (3) IEEE style treatment of special cases,
though not supported, would not be precluded.  There is some truth in all of
these, though not enough to support the conclusion.

The imaginary types do complicate the spec to some degree.  However, CCE is
still straightforward.  There has been no claim that imaginary types will be
difficult to implement.  And, most importantly, a system with consistent
treatment of special cases will be less complicated for the user (programmer).

An explanation aside:  CCE makes the imaginary types available for program
declarations, though largely to follow the open spirit of C.  In the
anticipated common programming model, imaginary and complex values will be
introduced in the natural mathematical style, y*I or x + y*I, where x and y
are real and I is the predefined imaginary unit constant;  variables generally
will be declared real or complex. 

Special cases for complex arithmetic are more complicated than for real
arithmetic.  For example, two topologies are commonly used in complex
mathematics:  the complex plane with its continuum of infinities and the
Riemann sphere with its single infinity.  The complex plane is better suited
for transcendental functions, the Riemann sphere for algebraic functions.  CCE
uses the natural augmentation of the real and imaginary axes with signed
infinities, which provides a useful (though admittedly not perfect) model for
the complex plane, and prescribes a projection function mapping all infinities
to one, which helps model the Riemann sphere.  This approach is directly
useful in some applications;  more generally, it provides the predictability
necessary to program without costly preflighting.       
 
It has been pointed out that a spec without imaginary types need not preclude
consistent treatment of special cases.  Rather, infinities, NaNs, and signed
zeros could be regarded as outside the specification's model, which would
admit any treatment, including what CCE requires.  But this would beg the
question, leaving the work of determining consistency to yet another spec, which
would have to be jerrybuilt around the "simple" one. 

The C and C++ complex specs should be as simple as possible -- but not more
so.

-Jim


--------------------------------------
Date: 11/17/93 4:31 PM
To: Jim Thomas
From: Al Vermeulen

FT>      WG9 N177 Proposed Standard for Packages of Real and Complex Type
FT>      Declarations and Basic Operations for Ada (including Vector and
FT>      Matrix Types) ISO-IEC/JTC1/SC22/WG9 (Ada) Numerics Rapporteur Group
FT>      Draft 1.0 22 April 1993
FT>  
FT>      WG9 N178 Proposed Standard for a Generic Package of Complex
FT>      Elementary Functions for Ada ISO-IEC/JTC1/SC22/WG9 (Ada) Numerics
FT>      Rapporteur Group Draft 1.3 19 April 1993

I recently proposed complex classes for C++ to the ANSI C++ committee
X3J16.  I did not include imaginary classes; instead I stuck fairly
close to David Knaak's NCEG proposal.  I'm interested in reading the
rational behind the decision to include imaginary in the set of Ada
types.  Do you have info on how I can get copies of the documents you
cite above?

thanks,

- Al

-------------------------------------------------------------------------------
Al Vermeulen,  alvaroguewave.com  | "Emancipate yourselves from mental
slavery"
Rogue Wave Software               |      - Bob Marley, mon

------------------ RFC822 Header Follows ------------------
Received: by qm.taligent.com with SMTP;17 Nov 1993 16:31:08 -0800
Received: from relay2.UU.NET by taligent.com with SMTP (5.67/23-Oct-1991-eef)
	id AA14018; Wed, 17 Nov 93 16:29:02 -0800
	for 
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA23292; Wed, 17 Nov 93 19:11:37 -0500
Received: from validgh.UUCP by uucp4.uu.net with UUCP/RMAIL
	(queueing-rmail) id 190949.873; Wed, 17 Nov 1993 19:09:49 EST
Received: from uunet.UUCP by validgh.com (4.1/SMI-4.1)
	id AA13656; Wed, 17 Nov 93 15:11:10 PST
Received: from cray.com (via timbuk.cray.com) by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA18883; Wed, 17 Nov 93 17:06:47 -0500
Received: from hemlock.cray.com by cray.com (Bob mailer 1.1)
	id AA09753; Wed, 17 Nov 93 16:06:39 CST
Received: from sequoia.cray.com by hemlock.cray.com
	id AA23616; 4.1/CRI-5.6; Wed, 17 Nov 93 16:02:55 CST
Received: from cray.com (timbuk.cray.com) by sequoia.cray.com
	id AA05694; 4.1/CRI-5.5; Wed, 17 Nov 93 16:02:53 CST
Received: from garnet.msen.com by cray.com (Bob mailer 1.1)
	id AA09384; Wed, 17 Nov 93 16:02:50 CST
Received: from heifetz.msen.com by garnet.msen.com with smtp
	(Smail3.1.28.1 #11) id m0ozuxX-000EisC; Wed, 17 Nov 93 17:02 EST
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
	id <m0ozupx-000Hd7Caheifetz.msen.com>; Wed, 17 Nov 93 16:54 EST
Received: from rwave by fix.fenris.com with uucp
	(Smail3.1.28.1 #7) id m0ozuSl-0009zVC; Wed, 17 Nov 93 13:30 PST
Received: by roguewave.com (Smail3.1.28.1 #10)
	id m0ozuK3-000AWyC; Wed, 17 Nov 93 13:21 PST
Message-Id: <m0ozuK3-000AWyCaroguewave.com>
Date: Wed, 17 Nov 93 13:21 PST
From: uunet!roguewave.com!alvauunet.UU.NET (Al Vermeulen)
To: tydemanaibmpa.awdpa.ibm.com
Cc: ncegacray.com
In-Reply-To: Fred Tydeman's message of Fri, 27 Aug 1993 13:01:12 -0400
<9308271701.AA23568aibmpa.awdpa.ibm.com>
Subject: Complex and imaginary