Re: Complex numbers & Oakwood suggestions

[acken@informatik.uni-kl.de]

>  Date: Mon, 5 Feb 96 06:57:32 EST
>  From: Mike Griebling <grieblm@trt.allied.com>
>  
>  > CMPLX(x,y)	REAL, REAL		COMPLEX		complex number z=x+yi
>  > LONGCMPLX(x,y)LONGREAL, LONGREAL	LONGCOMPLEX	complex number z=x+yi
>  
>   I was thinking about the CMPLX/LONGCMPLX functions.  I'm not
>  convinced that we really need them since the compiler would
>  automatically create complex numbers from expressions like "1+3i".
>  The only question might be how to automatically get these kinds of
>  expressions to create LONGCOMPLEX vs. COMPLEX numbers.  We might
>  just side-step the issue and force people to say LONG(1+3i) to
>  create a LONGCOMPLEX number.

The "1+3.0i" notation only works for constants.  You need the
constructors if you want to build a COMPLEX from variables.

>  BTW, the only reason I suggested supporting structured return
>  values was that they would be required at any rate in the complex
>  number implementation.  Since they are essentially free (with
>  COMPLEX type support) why not extend the support to cover other
>  structured return values.  These types could make it easy to create
>  other libraries which support more friendly mathematical
>  expressions (e.g., vectors, matrices, etc.)  With structured
>  returns, you could say something like a := b.add(c) where a, b, c
>  are structured types (possibly multiple-dimensioned arrays).

Yes, it's only a small step towards structured returns.  But the
mathematical expressions you mention can efficiently be implemented
using pointers (which you'll need to use for multi-dim arrays anyway).
There is quite a difference between putting a matrix of, say, 4x4
elements on the heap and putting 16 complex records there.  And the
pointer semantics (changing the value that is referred to changes all
other references) are more easily accepted for large, structured
objects than for scalar values (like COMPLEX).  
  The infix notation a := b.add(c) can be implemented by type-bound
procedures.  But in this case you have to define all tb procs in the
same module that defined the record type.

-- mva