Complex bakeoff - example 1
Harry H. Cheng
uunet!dragon.engr.ucdavis.edu!chengh
Fri Oct 6 03:15:35 PDT 1995
> > I feel I occassionally need to make the following points
> > about exceptional values (infinities, NaNs, signed zeroes,
> > etc.) that seems to get lost when we discuss details. These
> > exceptional values aren't really values, but placeholders
>
> This is THE key point. The exceptional values are placeholders to indicate
> that, in most cases, the true value can't be represented by the hardware.
> Now if the expression was 1/0, then the true value is infinity. But most
> of the infinities that occur in computations are overflows, that is, very
> large finite values but too big for the hardware to represent. So while
> MAX/MIN will
> give a predicable result - infinity - it is not the true result. If you
> start treating it like it was the true result, you can end up with a wrong
> result. See Frank's examples below.
I agree with both Frank and David.
But, I would like to offer the following counter
example to demonstrate that infinity can be useful.
exp(1/MIN) ==> Inf
exp(1/-MIN) ==> 0.0
Function exp(1/x) discontinues at 0.
> > As Harry Cheng pointed out, there are other ``infinity
> > paradigms'' that have a single infinity in contrast to
> > signed infinities. Each paradigm is useful for a certain
> > set of applications, but none are applicable 100% of the
> > time (another way of saying ``yes, there are several
> > branches of mathemetics'').
>
> Yes. And for complex in C, we could make things hopelessly complicated
> by trying to accomodate all (or even just several) of the possibilities.
> But choosing one paradigm, e.g. cartesian representation, covers most cases
> with the least difficulty. But it, as with any other paradigm, has it's
> limitations.
I agree that Cartesian representation is
the most convenient one.
And it is easy to implement.
>
> I am not in favor of the inclusion of an imaginary type because:
> 1) there really isn't a problem that needs to be solved by it,
> 2) it doesn't solve the problem any way,
> 3) the complexity added by it to the language is too great.
>
> - David Knaak
>
I agree with David here.
Besides, I think
(1) The distinction of signed zeros in real numbers
is useful because there are positive and
negative infinities. The distinction of signed zeros in complex numbers
is not necessary, because the origin of complex plane
can be approached from infinite directions as in r e^theta
when r approaches zero.
The distinction of signed zeros in complex numbers complicates
programming significantly.
(2) The signed infinities in complex number
not only significantly complicate programming,
they are mathematically questionable.
Under the Riemman sphere of complex analysis, there is
only one complex infinity.
I do not know any applications that actually
use signed complex infinities.
If signed complex infinities are needed in a particular application,
they maybe just two real numbers, not a complex number.
Under the programming paradigm of one complex infinity,
ComplexInf * 1.0I ==> ComplexInf
ComplexInf * (0+1.0I) ==> ComplexInf.
Let me quote a statement from "Theory of Functions of
Complex Variable" by A. I. Markushevich,
Chelsea Pulishing Company, New York, NY, page 79.
"If a is a proper complex, then a + complex_infinity = complex_infinity + a
= complex_infinity, but complex_infinity+complex_infinity is meaningless,
as shown by the two sequences ..."
Under the complex pragramming paradigm with a single complex
infinity and a single complex NaN,
ComplexInf+ComplexInf ==> ComplexNaN
This property will not be preserved in a programming paradigm with
signed complex infinities.
(3) I agree that there is a difference of computational speed
depending on implementation.
I still remain to see if there is any application
that can be solved under the complex programming paradigm
with signed complex infinities and imaginary types,
but cannot be solved under the complex programming paradigm
in an extended finite complex plane with
a *single* complex infinity and a *single* complex NaN.
Now that both programming paradigms have been implemented,
we can test some applications with complex metanumbers
to see the difference.
Harry Cheng
UC Davis
More information about the Numeric-interest
mailing list