Mark Biggar wrote:
> Let's worry about getting principal values, branch cuts and handling signed 
> zeros correct before dealing with the interaction of junctions and 
> multi-valued complex functions.


> BTW, two good references on this that we might want to plagiarizer.....I mean 
> borrow from are the Ada Refernece Manual and the Common LISP Reference 
> Manual.  Both go into great detail on this subject.

I've just reviewed the Ada Reference Manual's take on this topic, and
it did indeed address a few wrinkles that I overlooked.

Basic rule: Complex.modulus >= 0; Complex.arg ~~ -pi .. pi.

I'm not fully up on the lingo; so I'm going to invent some:  Number $x
is 'indefinite' if it is defined but has a value of Inf, NaN, or the
like.  It is 'definite' if it is defined and not indefinite.

If either .re or .im is indefinite, the complex number is indefinite.

If signed zeroes are used, then a definite complex number can always
be assigned to one of the four quadrants.  (In particular, if .im ==
-0, the number falls in one of the lower quadrants, and .arg == -pi or
-0, depending on whether .re is negative or positive, respectively; if
.im == +0, the number falls in one of the upper quadrants, and .arg ==
pi or +0.  It is impossible for .arg to be indefinite if both .re and
.im are definite: complex zeroes are "signed" by a definite .arg.)
Conjecture: signed zeroes should be accompanied by signed infinities:
as with zeroes, the "sign" of a complex infinity is a definite

Without signed zeroes, a definite complex number can be assigned to
one of the four quadrants, to the positive or negative real number
axes, to the positive or negative imaginary number axes, or to the
origin.  Under this scheme, some modifications and caveats need to be
stated: .arg ~~ -pi ^.. pi.  (So if the number falls on the negative
real number line, .arg == pi.) If the number is zero, .arg is
indefinite.  If the number is indefinite, .arg is indefinite.  If .re
is indefinite, then .im is indefinite, and vice versa.

The first paradigm has fewer special cases than the second one, but
has several "redundancies" of the same nature as signed zeroes; the
second paradigm more closely reflects what a mathematician would
expect when seeing a complex number, but has several incongruities
that might give a programmer headaches.

Jonathan "Dataweaver" Lang

Reply via email to