Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

371 views

Skip to first unread message

Nov 23, 2023, 5:29:41 AM11/23/23

to

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.

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.

Nov 23, 2023, 10:28:46 AM11/23/23

to

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

Nov 26, 2023, 6:14:51 PM11/26/23

to

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

>

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.

Nov 27, 2023, 6:17:43 AM11/27/23

to

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

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.

0 new messages

Search

Clear search

Close search

Google apps

Main menu