From Newsgroup: comp.lang.fortran

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

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))
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.fortran

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

Yeah, I have been doing that recently. Compiled a package with -Wall,
and there were shit-tons of implicit conversions. Rather disturbing, as default behaviour for real to integer is INT(), when in a few cases it
seemed NINT() would the correct behaviour.
--- Synchronet 3.20a-Linux NewsLink 1.114

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