Re: Complex numbers & Oakwood suggestions

[Sander van der Wal <svdwal@xs4all.nl>]

(A bit late but my emailer screwed up )

On Fri, 2 Feb 96 6:54:33 EST acken@informatik.uni-kl.de (you) wrote:

> 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 ]
> 
>[Knip]
> 
> 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.
> 
> ------------------------------------------------------------------------
> 
> 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 propose not to use type inclusion, because SHORT(LONGCOMPLEX)
has two possible outcomes, both of which seems reasonable.
I think their should be two type hierarchies, that are
not connectedby type inclusion. This means SHORT(LONGCOMPLEX) 
becomes COMPLEX and SHORT(COMPLEX) is illegal. LONG(LONGREAL) 
is illegal too, and LONG(REAL) stays LONGREAL. 
Oberon(2) also has the concept of 'projection' and I think this
should be the mechanism to convert between (LONG)COMPLEX and
(LONG)REAL. Projection from (LONG)COMPLEX to (LONG)REAL is
easy, the (LONG)REAL becomes the real part of the (LONG)COMPLEX.
To extract the imaginary part the predefined function IM is used.
Projecting a (LONG)REAL to a (LONG)COMPLEX is also possible 
(unlike the normal rules for projecting a supertype to a 
subtype), the imaginary part becomes zero.

> Is there any reason at all to provide MIN/MAX for complex types?

No, because one cannot define a MAX(COMPLEX) etc.
 
> Maybe toss in an operator for conjugation?  `~' is free and has the
> right priority.  `~z' would calculate the conjugate complex value of
> `z'.  

Mmmmmm....

>      While I'm at it, what about adding a predefined complex ABS
> function?  
 
There is a definition possible for ABS(COMPLEX).

>           Is anyone in favor of these additions?

It's a can of worms :-) I think that we should first think this over
(a lot) and discuss the implications, before committing ourselves
to implementing complex numbers. 

-- 
Sander