[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Complex numbers & Oakwood suggestions



>  From: Sander van der Wal <svdwal@xs4all.nl>
>  Date: Sat, 03 Feb 1996 23:55:54 +0100
>  
>  > 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. 

First of all the SHORT/LONG functions have nothing to do with the type
graph, which is only used to describe the language type conversion
rules.  They operate only on a section of the type hierachy and are
defined for the subsets of integer and real types.  In fact you're
describing the SHORT/LONG functions I proposed in an earlier mail. 

>  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.

I don't think it's helpful to introduce the term `projection' here.
Extracting the parts of a complex number is handled by RE/IM.  The
other way round, i.e. transforming a real number into a complex number
with zero IM part, is handled by the language's type conversion rules
(just like conversion from integer to real types).

>  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. 

This is exactly what I'm trying to do ;-).


-- mva