Re: Complex numbers & Oakwood suggestions

[Mike Griebling <grieblm@trt.allied.com>]

Hi all, on Feb 3, Michael Van Acken wrote (in part):

> 10.3 Predeclared procedures
> Function procedures
> Name		Argument type		Result type	Function
> RE(z)		COMPLEX			REAL		real part of z
> RE(z)		LONGCOMPLEX		LONGREAL	real part of z
> IM(z)		COMPLEX			REAL		imagenary part of z
> IM(z)		LONGCOMPLEX		LONGREAL	imagenary part of z
> LONG(z)	COMPLEX			LONGCOMPLEX	identity
> SHORT(z)	LONGCOMPLEX		COMPLEX		identity
> 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.

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

Michael G.