(j3.2006) Asymmetry of REAL, CMPLX

Van Snyder Van.Snyder
Tue Jan 8 18:43:00 EST 2008

On Tue, 2008-01-08 at 15:50 -0500, Dan Nagle wrote:
> Hello,
> On Jan 8, 2008, at 3:36 PM, Robert Corbett wrote:
> > Van Snyder wrote:
> >> On Mon, 2008-01-07 at 20:27 -0800, Robert Corbett wrote:
> >>
> >>> I am one of those who proposed providing a new intrinsic spelled
> >>> COMPLEX that would be symmetric.  In what sense does it not solve
> >>> the problem?
> >>
> >>
> >> The problem is the surprise caused by the asymmetry of REAL and  
> >> CMPLX.
> >> This negatively affects reliability and economics.
> >
> > Yes, but if the standard, over time, replaces CMPLX with a symmetric
> > routine named COMPLEX, the problem goes away as far as the standard
> > is concerned. Implementations would be forced to support the then
> > nonstandard intrinsic CMPLX, but the standard would be clean.

This does nothing for existing codes.  Of those that have double
precision arguments for CMPLX, and no kind argument, I'd bet at least a
dollar that 98% of them are expecting a double precision result.  So
introducing an incompatibility, to correct a blunder in the design of
Fortran 90, does them a favor.

> I favor Bob's approach.  We cannot introduce an incompatibility,
> and call it a fix, for so small a reason as perceptions of symmetry.

It's not just a perception.  The unexpected asymmetry has real
consequences for accuracy and labor cost.

> Besides, as Bill remarked, one may also view cmplx() as a component
> extractor, a la %re and %im...

I don't quite understand how a constructor is the same as a component
extractor....  Isn't it the inverse?  REAL is the component extractor,
and it's (not quite exact) inverse is CMPLX.

>   It is these *two* views that mean
> that someone will be "surprised" no matter what.  So let's do nothing
> for f08.

Now is not the time.

More information about the J3 mailing list