• Re: Fortran 202X

    From john.alexiou@jtekt.com@21:1/5 to All on Wed Mar 23 07:22:23 2022
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
    more variants.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to john.a...@jtekt.com on Wed Mar 23 09:59:56 2022
    On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
    [...]
    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
    more variants.

    Yes, the accuracy of these function references can sometimes be a
    problem. For example, there is no guarantee that the two expressions you
    give above are the same to the last bit, so if a programmer uses one in
    one place and the other in another place, and later checks for equality,
    chaos may ensue. There is also the issue of rounding modes. If the
    programmer sets one rounding mode in one place, and another rounding
    mode in another, does he expect different values of PI to be returned
    with those expressions?

    However for the intrinsic constants approach, there would need to be
    different versions of those constants for each real type, not just a
    single version. How should those different kinds be denoted, given that different compilers might associate different kind integer values to the available candidates? For example, if they were given an integer label associated with the REAL_TYPES(:) array, then it might be complicated
    for the programmer to write portable code. Another possibility might be
    to introduce intrinsic functions, similar to HUGE() and EPSILON(), that
    return values of the kind of its argument. If these were resolved at run
    time, then it would be the same efficiency as a parameter reference, but
    if they had to be done at run time, then it would cost machine cycles to
    access those constants.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to john.a...@jtekt.com on Wed Mar 23 09:31:03 2022
    On Thursday, March 24, 2022 at 1:22:25 AM UTC+11, john.a...@jtekt.com wrote:
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
    more variants.

    4*ATAN(1D0) will give adequate accuracy, double precision;
    4*ATAN(1.0) will do the same for single precision.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Wed Mar 23 18:10:16 2022
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
    [...]
    I wish a standard constant for PI, E would be included,
    instead of everyone having to create their own every time it is
    needed. I have seen numeric definitions with not enough digits,
    with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
    many more variants.


    Yes, the accuracy of these function references can sometimes be a
    problem. For example, there is no guarantee that the two expressions you
    give above are the same to the last bit,

    From a numerical standpoint, arctan makes a lot more sense because
    the derivative of acos(x) has a pole at x=-1.

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.

    so if a programmer uses one in
    one place and the other in another place, and later checks for equality, chaos may ensue.

    As is usual for equality comparisons if it is indeed unknown that
    the values _are_ exact.

    You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
    but otherwise floating point expressions should be treated with
    care (and +/- epsilon).

    There is also the issue of rounding modes. If the
    programmer sets one rounding mode in one place, and another rounding
    mode in another, does he expect different values of PI to be returned
    with those expressions?

    4*atan(1.d0) is a constant expression, so I do not think that the
    IEEE rounding modes apply.

    However for the intrinsic constants approach, there would need to be different versions of those constants for each real type, not just a
    single version.

    Not necessarily. A constant of the longest available real mode
    could serve in principle, but could cause intermediate calculations
    in higher precision than anticipated, which might be problematic.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Wed Mar 23 23:08:27 2022
    On 3/23/22 1:10 PM, Thomas Koenig wrote:
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
    [...]
    I wish a standard constant for PI, E would be included,
    instead of everyone having to create their own every time it is
    needed. I have seen numeric definitions with not enough digits,
    with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
    many more variants.


    Yes, the accuracy of these function references can sometimes be a
    problem. For example, there is no guarantee that the two expressions you
    give above are the same to the last bit,

    From a numerical standpoint, arctan makes a lot more sense because
    the derivative of acos(x) has a pole at x=-1.

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.

    Where in the standard is that required, either within an expression or
    as part of a parameter definition? Isn't a compiler always allowed to
    defer that evaluation until run time?

    so if a programmer uses one in
    one place and the other in another place, and later checks for equality,
    chaos may ensue.

    As is usual for equality comparisons if it is indeed unknown that
    the values _are_ exact.

    That was the point of the original post. Namely if there is a single
    defined constant, then it should always be equal to itself, no matter
    the optimization level, rounding mode, etc.


    You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
    but otherwise floating point expressions should be treated with
    care (and +/- epsilon).

    Normally yes, but in the case of PI and E and other such constants, the simplest way to guarantee their value would be with an intrinsic
    constant, not a run time or even a compile time expression. Even if you
    specify the constant manually with a literal, you really need about
    three more digits than the epsilon in order to guarantee correct
    rounding to the last bit.


    There is also the issue of rounding modes. If the
    programmer sets one rounding mode in one place, and another rounding
    mode in another, does he expect different values of PI to be returned
    with those expressions?

    4*atan(1.d0) is a constant expression, so I do not think that the
    IEEE rounding modes apply.

    Why not? Is that part of the standard specification, or it it just the
    way one compiler choose to do it?


    However for the intrinsic constants approach, there would need to be
    different versions of those constants for each real type, not just a
    single version.

    Not necessarily. A constant of the longest available real mode
    could serve in principle, but could cause intermediate calculations
    in higher precision than anticipated, which might be problematic.

    That would be one approach. However, as you say, the programmer would
    always need to assign the long value to a parameter or variable of the
    correct kind first, and then use that local entity rather than the long intrinsic value in the expression. Otherwise, as you point out, the
    programmer would lose control of the precision of the intermediate
    results in the expression.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Thu Mar 24 00:05:29 2022
    On Wednesday, March 23, 2022 at 9:08:31 PM UTC-7, Ron Shepard wrote:
    On 3/23/22 1:10 PM, Thomas Koenig wrote:

    (snip)

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.

    Where in the standard is that required, either within an expression or
    as part of a parameter definition? Isn't a compiler always allowed to
    defer that evaluation until run time?

    integer, save :: x(int(4000*atan(1.)))
    x=3.1
    print *,size(x)
    end

    Dimensions of saved arrays need to be known at compile time.
    To be even more sure, put it in COMMON.

    Note also, regarding comparisons for equality, at least some compilers
    I know evaluate compile time expressions to different accuracy than
    for run-time expressions. compile time atan(1.0) might differ from
    run-time atan(1.0)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Thu Mar 24 07:42:07 2022
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 3/23/22 1:10 PM, Thomas Koenig wrote:
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
    [...]
    I wish a standard constant for PI, E would be included,
    instead of everyone having to create their own every time it is
    needed. I have seen numeric definitions with not enough digits,
    with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
    many more variants.


    Yes, the accuracy of these function references can sometimes be a
    problem. For example, there is no guarantee that the two expressions you >>> give above are the same to the last bit,

    From a numerical standpoint, arctan makes a lot more sense because
    the derivative of acos(x) has a pole at x=-1.

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.

    Where in the standard is that required, either within an expression or
    as part of a parameter definition?

    F2018:

    10.1.12 Constant expression

    1 A constant expression is an expression with limitations that
    make it suitable for use as a kind type parameter, initializer,
    or named constant. It is an expression in which each operation is
    intrinsic, and each primary is

    (1) a constant or subobject of a constant,

    [...]

    and where each subscript, section subscript, substring starting
    point, substring ending point, and type parameter value is a
    constant expression

    and

    3.38.2
    named constant
    named data object with the PARAMETER attribute (8.5.13)

    and finally

    8.5.13 PARAMETER attribute

    1 The PARAMETER attribute specifies that an entity is a named
    constant. The entity has the value specified by its constant-expr,
    converted, if necessary, to the type, type parameters and shape
    of the entity.

    So, while evaluation at compile-time is not strictly mandated by
    the standard (because the standard has no concept of compilation,
    for example) the effect is the same.

    Isn't a compiler always allowed to
    defer that evaluation until run time?

    As long as the change is invisible to the user, yes (which
    is another way of saying "no").

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ron Shepard on Thu Mar 24 02:54:00 2022
    On Thursday, March 24, 2022 at 3:08:31 PM UTC+11, Ron Shepard wrote:
    On 3/23/22 1:10 PM, Thomas Koenig wrote:
    Ron Shepard <nos...@nowhere.org> schrieb:
    On 3/23/22 9:22 AM, john.a...@jtekt.com wrote:
    [...]
    I wish a standard constant for PI, E would be included,
    instead of everyone having to create their own every time it is
    needed. I have seen numeric definitions with not enough digits,
    with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
    many more variants.


    Yes, the accuracy of these function references can sometimes be a
    problem. For example, there is no guarantee that the two expressions you >> give above are the same to the last bit,

    From a numerical standpoint, arctan makes a lot more sense because
    the derivative of acos(x) has a pole at x=-1.

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.
    Where in the standard is that required, either within an expression or
    as part of a parameter definition? Isn't a compiler always allowed to
    defer that evaluation until run time?
    .
    Certain expressions are required to be evaluated at compile time.
    Those that aren't could be evaluated at compile time or evaluated at
    run time.
    For example, those that have the PARAMETER attribute are
    required to be evaluated at compile time, e.g.
    integer, parameter, wp = kind (1.0d)

    Those expressions that can be evaluated at compile time usually
    are. It saves having to evaluate them at run time.

    so if a programmer uses one in
    one place and the other in another place, and later checks for equality, >> chaos may ensue.

    As is usual for equality comparisons if it is indeed unknown that
    the values _are_ exact.
    That was the point of the original post. Namely if there is a single
    defined constant, then it should always be equal to itself, no matter
    the optimization level, rounding mode, etc.

    You can reasonably compare 1 + 0.5 against 1.5 and expect equality,
    but otherwise floating point expressions should be treated with
    care (and +/- epsilon).
    Normally yes, but in the case of PI and E and other such constants, the simplest way to guarantee their value would be with an intrinsic
    constant, not a run time or even a compile time expression. Even if you specify the constant manually with a literal, you really need about
    three more digits than the epsilon in order to guarantee correct
    rounding to the last bit.

    There is also the issue of rounding modes. If the
    programmer sets one rounding mode in one place, and another rounding
    mode in another, does he expect different values of PI to be returned
    with those expressions?

    4*atan(1.d0) is a constant expression, so I do not think that the
    IEEE rounding modes apply.
    Why not? Is that part of the standard specification, or it it just the
    way one compiler choose to do it?

    However for the intrinsic constants approach, there would need to be
    different versions of those constants for each real type, not just a
    single version.

    Not necessarily. A constant of the longest available real mode
    could serve in principle, but could cause intermediate calculations
    in higher precision than anticipated, which might be problematic.
    That would be one approach. However, as you say, the programmer would
    always need to assign the long value to a parameter or variable of the correct kind first, and then use that local entity rather than the long intrinsic value in the expression. Otherwise, as you point out, the programmer would lose control of the precision of the intermediate
    results in the expression.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Thu Mar 24 10:37:56 2022
    On 3/24/22 2:05 AM, gah4 wrote:
    On Wednesday, March 23, 2022 at 9:08:31 PM UTC-7, Ron Shepard wrote:
    On 3/23/22 1:10 PM, Thomas Koenig wrote:

    (snip)

    4*atan(1.d0) is much better. This is also guaranteed to be evaluated
    at compile-time and suitable for a parameter.

    Where in the standard is that required, either within an expression or
    as part of a parameter definition? Isn't a compiler always allowed to
    defer that evaluation until run time?

    integer, save :: x(int(4000*atan(1.)))
    x=3.1
    print *,size(x)
    end

    Instead of 4000*atan(1.), how about 10**7*atan(1.)? Now we are in the
    realm where the last bit of the function evaluation makes a difference
    in the result. Now there can be problems associated with differences in
    the evaluation of that expression at run time, compile time, different
    floating point rounding modes, different optimization levels, compiler
    options, and so on.

    It still looks like intrinsic run time constants would solve many of
    those issues.

    Dimensions of saved arrays need to be known at compile time.
    To be even more sure, put it in COMMON.

    You are right about common being fixed size, but not about the first
    statement. It is allowed to save an allocatable array whose size is
    known only at run time.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Thu Mar 24 10:23:18 2022
    On 3/24/22 2:05 AM, gah4 wrote:
    Note also, regarding comparisons for equality, at least some compilers
    I know evaluate compile time expressions to different accuracy than
    for run-time expressions. compile time atan(1.0) might differ from
    run-time atan(1.0)

    Good point. This is yet another good argument for having some intrinsic constants defined. I have used cross-compilers where the compile time expressions were evaluated with the numerical library of the host
    machine, while the run time version of the same expression was evaluated
    with the numerical library of the target machine. Those results
    sometimes differed in the last few bits. My experience with this was in
    the 1980s, but as far as I know, that is still allowed with modern
    compilers.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Thu Mar 24 10:41:36 2022
    On 3/24/22 2:42 AM, Thomas Koenig wrote:
    As long as the change is invisible to the user, yes (which
    is another way of saying "no").

    Haha. Sometimes you just have to take "yes" as an answer.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Thu Mar 24 12:38:12 2022
    On Thursday, March 24, 2022 at 8:38:00 AM UTC-7, Ron Shepard wrote:


    (snip, I wrote)

    integer, save :: x(int(4000*atan(1.)))

    (snip)

    You are right about common being fixed size, but not about the first statement. It is allowed to save an allocatable array whose size is
    known only at run time.

    I was going to disagree, as mine doesn't have the ALLOCATABLE
    attribute, but then again, I am not sure that the compiler can't do the allocation at run time, anyway. I presume it can't look like it has
    the allocatable attribute, though.

    (It better not pass one to a subroutine with an ALLOCATABLE
    argument, for example.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Thu Mar 24 12:34:41 2022
    On Thursday, March 24, 2022 at 12:42:11 AM UTC-7, Thomas Koenig wrote:

    (snip)

    10.1.12 Constant expression

    1 A constant expression is an expression with limitations that
    make it suitable for use as a kind type parameter, initializer,
    or named constant. It is an expression in which each operation is
    intrinsic, and each primary is

    (1) a constant or subobject of a constant,

    and where each subscript, section subscript, substring starting
    point, substring ending point, and type parameter value is a
    constant expression


    (snip)

    So, while evaluation at compile-time is not strictly mandated by
    the standard (because the standard has no concept of compilation,

    I have sometimes wondered why no Fortran interpreter.

    Depending on how it is done, an interpreter could change the order
    that things are done, but still give the effect that the standard requires.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Thu Mar 24 21:48:33 2022
    On Thursday, March 24, 2022 at 6:05:30 PM UTC+11, gah4 wrote:

    Note also, regarding comparisons for equality, at least some compilers
    I know evaluate compile time expressions to different accuracy than
    for run-time expressions. compile time atan(1.0) might differ from
    run-time atan(1.0)

    That is a poor-quality implementation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to john.a...@jtekt.com on Fri Mar 25 17:08:25 2022
    On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
    more variants.

    I still have pi memorized to ten places from college. Wow, I graduated
    from TAMU 40 years ago with a degree in Mechanical Engineering.

    3.141592654d0

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Fri Mar 25 21:36:39 2022
    On Saturday, March 26, 2022 at 9:08:29 AM UTC+11, Lynn McGuire wrote:
    On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and
    many more variants.
    I still have pi memorized to ten places from college. Wow, I graduated
    from TAMU 40 years ago with a degree in Mechanical Engineering.

    3.141592654d0
    .
    Not enough for double precision.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Sat Mar 26 09:04:15 2022
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many
    more variants.

    I still have pi memorized to ten places from college. Wow, I graduated
    from TAMU 40 years ago with a degree in Mechanical Engineering.

    3.141592654d0

    Not quite enough for double precision. I have (from school
    days) just enough numbers for double precision memorized:
    3.1415926535897932

    Curiously appropriate, I had occasion to look at some
    Fortran code at work yesterday, which set a double
    precision variable named pi to 3.1415927 . Hmm...

    The code also had two other characteristics: It had ^Z as the
    last character in each file (which a modern compiler choked on,
    but easy enough to remove), so it probably originated on MS-DOS
    and some files had

    $define test 0

    and

    $if test

    (I'd have to boot may work laptop to make sure I have the
    syntax remembered correctly). Out of interest: Any idea
    what the compiler might have been? Maybe Microsoft Fortran
    for MS-DOS?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Sat Mar 26 02:18:08 2022
    On Saturday, March 26, 2022 at 2:04:18 AM UTC-7, Thomas Koenig wrote:
    Lynn McGuire <lynnmc...@gmail.com> schrieb:

    (snip)

    3.141592654d0
    Not quite enough for double precision. I have (from school
    days) just enough numbers for double precision memorized:
    3.1415926535897932

    Curiously appropriate, I had occasion to look at some
    Fortran code at work yesterday, which set a double
    precision variable named pi to 3.1415927 . Hmm...

    A large number of programs need double precision to get
    single precision results. If, for example, you do a numerical
    derivative. Or even more, a second or third derivative,
    you lose precision fast.

    You might be especially unlucky, especially with some case of
    trigonometric functions, but often enough it is close enough.


    The code also had two other characteristics: It had ^Z as the
    last character in each file (which a modern compiler choked on,
    but easy enough to remove), so it probably originated on MS-DOS
    and some files had

    The ^Z convention came from text files on CP/M, where the file
    system only keeps track of whole disk blocks. For some reason
    that I never knew, it stayed around way too long on MS-DOS
    systems, where the file system keeps byte file lengths.

    It mostly depends on the editor, as some would add them,
    and many programs would accept them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Sat Mar 26 10:55:00 2022
    On 3/26/22 4:04 AM, Thomas Koenig wrote:
    Curiously appropriate, I had occasion to look at some
    Fortran code at work yesterday, which set a double
    precision variable named pi to 3.1415927 . Hmm...

    I hate it when that happens. You don't know without looking through the
    code if correcting that value for pi will make things better or
    introduce internal consistency errors. And you seem to find these
    mistakes at the worse time possible, when you are tracking down other
    bugs with deadlines approaching.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to lynnmcguire5@gmail.com on Sat Mar 26 18:40:12 2022
    In article <t1legp$m39$1@dont-email.me>, Lynn McGuire
    <lynnmcguire5@gmail.com> writes:

    On 3/23/2022 9:22 AM, john.a...@jtekt.com wrote:
    I am more interested in some minor changes:
    Format descriptor AT will remove many uses of TRIM in I/O lists, which I use frequently.
    COSD, SIND, and TAND will standardize what is a common extension.

    I wish a standard constant for PI, E would be included, instead of everyone having to create their own every time it is needed. I have seen numeric definitions with not enough digits, with way too many digits, use of ACOS(-1D0) or 4*ATAN(1D0) and many

    I still have pi memorized to ten places from college. Wow, I graduated
    from TAMU 40 years ago with a degree in Mechanical Engineering.

    3.141592654d0

    I knew 150 at one time, but still know 50.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Sat Mar 26 20:01:01 2022
    Ron Shepard <nospam@nowhere.org> schrieb:
    On 3/26/22 4:04 AM, Thomas Koenig wrote:
    Curiously appropriate, I had occasion to look at some
    Fortran code at work yesterday, which set a double
    precision variable named pi to 3.1415927 . Hmm...

    I hate it when that happens. You don't know without looking through the
    code if correcting that value for pi will make things better or
    introduce internal consistency errors. And you seem to find these
    mistakes at the worse time possible, when you are tracking down other
    bugs with deadlines approaching.

    In that particular case, it wasn't critical - it was an old
    code where the question if it needs to be resurrected or not.
    The algorithm is well documented, there is an executable that still
    works, and the program isn't very big. The only problem I found
    was that the source was incomplete. Finally, there is no hurry.

    So, the decision will probably be to re-implement and test against
    the old executable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)