> Date: Tue, 29 Oct 2002 18:44:20 -0700
> From: James Giles <[log in to unmask]>
> "robin" <[log in to unmask]> wrote:
> ...
> > > We don't have to do this for any different kind of integers, so apart
> > > from history why do we need it for reals? What benefit did this dubious
> > > history give us that it has never been changed ( -- is it there just to
> > > keep Richard Maine's typing skills updated :-))? IIRC, there was (is)
> > > some oddity about complex numbers in this respect.
> >
> > The CMPLX function returns a single-precision result for a double-precision
> > or extended-precision argument. This one that should not have happened.
> > It does not follow the custom of generic functions.
>
> I support rationalizing COMPLEX data type using derived types as
> a model. Hence, the constructor for a complex value would be:
>
> COMPLEX(a_real, another_real)
>
> instead of
>
> CMPLX(a_real, another_real)
>
> For the COMPLEX function, the KIND of the result would be the
> same as KIND(a_real+another_real). This is a much simpler and
> more regular than the present intrinsic.
>
> Similarly, if Z is a complex variable (or names constant), the real
> part of Z would be written Z%R, and the imaginary part of Z would
> be written Z%I.
Interesting, but I prefer the existing function to be made properly generic.
A compiler switch could be provided (or a compiler directive
in the source) could handle the current case for backwards compatibility.
> --
> J. Giles
>
|