Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bloom-beacon!gatech!ufcsv!codas!novavax!hcx1!hcx2!bill
From: bill@hcx2.SSD.HARRIS.COM
Newsgroups: comp.lang.fortran
Subject: Re: Strict parens not sufficient
Message-ID: <44400016@hcx2>
Date: 20 Jan 88 13:52:00 GMT
References: <546@cresswell.quintus.UUCP>
Lines: 53
Nf-ID: #R:cresswell.quintus.UUCP:546:hcx2:44400016:000:2635
Nf-From: hcx2.SSD.HARRIS.COM!bill    Jan 20 08:52:00 1988


> This means that
> 	DOUBLE PRECISION TEMP, X, Y	| double temp, x, y;
> 	TEMP = X+Y			| temp = x+y;
> 	IF (TEMP .LT. 0.0D0) CALL HOME	| if (temp < 0.0) home();
> and
> 	IF (X+Y .LT. 0.0D0) CALL HOME	| if (x+y < 0.0) home();
> may behave differently.
> ...
> whereas the version which stores into TEMP would have rounded or
> truncated.

First of all, note that the assignment to TEMP does NOT force a
store to memory (assuming TEMP is a local variable and not
EQUIVALENCEd to anything else).  There is nothing in either standard
that says local variables have to be stored in memory.  A smart
compiler would try its darnedest to keep TEMP in a register.  Still,
your point is valid in at least some cases.

> It seems to me that FLOAT()/(float) and DBLE()/(double) should mean
> "convert the operand to exactly the precision that would be given
> to a REAL {DOUBLE PRECISION} variable in storage."
> Note that only converting an expression which already appears to
> have the desired type is changed, and then only if intermediate
> results are calculated in a higher precision.  Most programs should
> notice no change.

I disagree.  Type-casts/conversions are often written to convey
information to the reader, not so much to the compiler.  Furthermore,
a C macro may contain a type-cast so it could work for both float
or double.  In either case, the "no conversion" case would not only
see a different result; it would also take a performance hit.
Remember that many of the machines you refer to impose a significant
cost for moving data into/out of the floating-point unit.

> Without this definition in the standard, you have to explicitly
> introduce temporary variables, as shown above.  As things stand, all
> FLOAT(float) or DBLE(double) are good for is providing strict
> parentheses...

Not so; they provide assurance that the data type is exactly what
is specified (here I refer to *language* data type, not machine
representations of them).

Anyway, I am surprised that anyone would complain about getting more
precision than they asked for.  FORTRAN, C, and even Ada have always
allowed compilers to give *more* precise answers than requested;
Ada makes this very explicit in the standard, even to the point of
allowing compilers to avoid raising exceptions.  If this is really a
problem, then I think the languages should provide some intrinsics
for converting a value to a specified precision, which would be different
from a type conversion.  This would allow a programmer to specify
any kind of rounding desired, whether the machine supported that
precision or not (of course, it might have to be done in software).