• what is point of X=1.0D0*X+1.0D0*Y*W ?

    From Woozy Song@suzyw0ng@outlook.com to comp.lang.fortran on Thu Nov 23 18:29:30 2023
    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 Steve Lionel@steve@seesignature.invalid to comp.lang.fortran on Thu Nov 23 10:28:40 2023
    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 Robinn@32s116e@gmail.invalid to comp.lang.fortran on Mon Nov 27 07:14:33 2023
    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 gah4@gah@ugcs.caltech.edu to comp.lang.fortran on Mon Nov 27 03:17:34 2023
    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