[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Complex numbers [replies]
Here are the replies from Mike Griebling and Michael Smith:
------------------------------------------------------------------------
Date: Fri, 2 Feb 96 07:53:55 EST
From: Mike Griebling <grieblm@trt.allied.com>
Subject: Re: Complex numbers & Oakwood suggestions
> Brian Hawley <bhawley@luc.edu> wrote:
> > I have a couple questions that relate to the efficiency of the
> > implementation of complex numbers in the library.
> > [ lots of good arguments deleted ]
>
> This is a very convincing text about the problems of handling complex
> values efficiently. At least it convinced _me_ that complex math is a
> pain if you have to implement it with real numbers and without any way
> to pass them as function results. This is strange because I never had
> to use complex numbers in my live and it doesn't make any difference
> to me. It probably means that I'm easily influenced by long mails
> exhaustively listing solutions that are all proven to be inadeqaute
> ;-).
>
> Well, there is always the option to extend the language to include
> COMPLEX and LONGCOMPLEX as basic types. The Oakwood Guidelines deal
> with most of the details, and it is fairly simple to integrate into
> the front-end. So, if there are no strong objections on this mailing
> list against adding those types, I propose to extend the language as
> sketched out in the Oakwood text.
I wasn't going to suggest adding COMPLEX numbers... ;-)
> ------------------------------------------------------------------------
>
> There are some points to add, though:
>
> Oakwood has no constructors for complex values. Adding two predefined
> functions
> CMPLX(REAL,REAL) --> COMPLEX
> and
> LONGCMPLX(LONGREAL, LONGREAL) --> LONGCOMPLEX
> would do the trick.
>
> It is a bit vague on the type hierachy to be used. Proposal:
> LONGCOMPLEX--LONGREAL--REAL--LONGINT--INTEGER--SHORTINT
> \ /
> COMPLEX
I assume these constructors would be useable in constant expressions?
> Is there any reason at all to provide MIN/MAX for complex types?
Not sure...
> Maybe toss in an operator for conjugation? `~' is free and has the
> right priority. `~z' would calculate the conjugate complex value of
> `z'. While I'm at it, what about adding a predefined complex ABS
> function? Is anyone in favor of these additions?
We also have to consider the implications of the comparison operators.
Can we really compare REALs and COMPLEX numbers? I'm not exactly sure
what a comparison of two complex numbers means.
Maybe we could look at the compiler that has implemented COMPLEX numbers
and see how they handle this sort of thing.
Now, that you've broken down and allowed the addition of a whole new
data type, what about also allowing structured returns from functions?
This last request would make interfacing with C++ routines a lot easier
and is necessary anyway to give us the COMPLEX types.
I guess I might also ask for overloaded function names. I've noticed
the BeBox OS used overloaded functions quite extensively and it would
be a real pain to have to create numbered functions or something to
map to their overloaded functions.
While I'm at it, how about also allowing the use of infix notation
operator definitions like:
PROCEDURE (a : INTEGER) "+" (b : INTEGER) : INTEGER;
Which would be used as: z := a + b and would be kind of a procedure-type
of the INTEGER type. In this case replacing the default INTEGER addition
operation.
Michael G.
------------------------------------------------------------------------
From: Michael Smith <msmith5@orion.it.luc.edu>
Subject: Re: Complex numbers & Oakwood suggestions
Date: Fri, 2 Feb 1996 11:00:14 -0600 ()
> This is a very convincing text about the problems of handling complex
> values efficiently. At least it convinced _me_ that complex math is a
> pain if you have to implement it with real numbers and without any way
> to pass them as function results. This is strange because I never had
> to use complex numbers in my live and it doesn't make any difference
> to me. It probably means that I'm easily influenced by long mails
> exhaustively listing solutions that are all proven to be inadeqaute
> ;-).
If I could interject:
I'm a math major and a friend of Mr. Hawley's who first proposed the
possibility of math libraries in the Oberon language, including
complex libraries. The implementation of complex numbers in the Oberon
language would open up a user base amoung Physicists, Engineers
(virtially all disciplines of Engineering), Mathematicians,
Economists, Ecologists, &c. &c. &c. Because complex numbers have some
special properties real numbers don't, use of real number libraries is
insufficient and in some cases produces wrong answers.
> Well, there is always the option to extend the language to include
> COMPLEX and LONGCOMPLEX as basic types.
It would be best to implement those both as Cartesian, since Cartesian
is optimal for most applications. We should have polar notation
complex as a separate library (not a base class) included as a standard
feature of the compiler, since polar notation is more efficient for
certain kinds of tasks (multiplication, division, powers of complex
numbers) and very inefficient in others (addition, subtraction,
numbers to complex powers).
> Is there any reason at all to provide MIN/MAX for complex types?
No. Complex numbers have two dimentions and so any concept of maximum,
minimum, less than or greater than is senseless.
> Maybe toss in an operator for conjugation? `~' is free and has the
> right priority. `~z' would calculate the conjugate complex value of
> `z'. While I'm at it, what about adding a predefined complex ABS
> function? Is anyone in favor of these additions?
Conjugation is essential to the use of complex numbers and such a
function would hopefully save a lot of overhead. ABS I'm less sure
about; you could probably implement ABS as a library function.
(NB: If anyone is interested in C++ pseudocode for complex functions I
will be more than happy to provide. If we include those in a separate
library the techheads will adore us. If all else fails, any college
text on Complex Analysis will give you the information you want.)
Of course, I know a lot more about mathematics and physics and EE than
I know about compiler design. :)
> Structured function returns
> A common misbelief is that introducing structured function returns
> would eliminate the discussion about COMPLEX, because then one could
> define complex operations as functions. It should be noted that this
> is only half the way since the mathematicians still want to have infix
> notation which would require the introduction of a more general
> overloading concept including infix operators. This in turn would
> break the idea of always qualifying imported objects by the module
> name.
Why not use a pointer-based implementation? That way you don't have to
mess with the overhead of infix notation in the compiler, nor do coders
have the complication of a structure-valued implementation.
SOrry to butt in.
Blessed Be,
Mike Smith
DISCLAIMER: My opinions do not necesarily, or even remotely, reflect those
of Loyola University, Chicago.
------------------------------------------------------------------------