From Newsgroup: comp.lang.fortran
On 11/23/23 7:28 AM, Steve Lionel wrote:
On 11/23/2023 5:29 AM, Woozy Song wrote:
Where X and Y are both real, and W is double precision. I presume they
wanted extra precision for the arithmetic, but then it gets quantised
back to 32-bit float.
By the way, this code came from a large oil company with a team of
programmers.
The multiplication by 1.0D0 of each term has no effect whatsoever. If
those were removed, the multiplication of Y*W would convert Y to double,
due to "mixed-mode arithmetic" rules, before doing the operation. Then
when X is added, it too would be converted to double before the
addition. Then the whole result would be rounded back to single
precision for the assignment.
If I were writing this, I'd use the standard conversion intrinsic
functions to make it clear what is happening, as I hate seeing implicit conversion. For example:
X = REAL(DBLE(X)+(DBLE(Y)*W))
In the Fortran 66 days, there was worry that constants would
be converted at run-time, if needed.
We were told to use 1.0 instead of 1 in REAL expressions.
As well as I know, compilers did compile time conversions long
before this recommendation went away. Though often enough, I still
write 1.0, as it makes it more obvious that the expression is REAL.
As for conversions, Java requires a cast for narrowing conversions.
Widening conversions in the order:
byte --> {short, char} --> int --> long --> float --> double
don't require a cast, but the other way, narrowing, do.
Note that this is true, even though significant bits might be lost
in the int --> float and long --> double cases.
The unsigned 16 bit char, and signed 16 bit short, require a
cast in both directions.
As to the original question, often double precision is needed
in intermediate values, even when the final result is single precision.
But also, it is possible that the type declarations changed over the
years, but not the line in question.
--- Synchronet 3.20a-Linux NewsLink 1.114