• double precision for constants

    From Lynn McGuire@21:1/5 to All on Tue Oct 19 20:00:35 2021
    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Tue Oct 19 23:53:37 2021
    On Tuesday, October 19, 2021 at 6:00:40 PM UTC-7, Lynn McGuire wrote:

    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    OK, first, reading what -fdefault-double-8 does, it only affects variables
    and constants that are already double precision or KIND 8.

    Instead, -freal-4-real-8 applies to all KIND 4 variables and constants.

    I suspect the answer depends on the program, but I believe that in many
    cases double precision constants are overrated. It depends much on how
    well you know your program. Are all variables already KIND 8?

    Most often in physics problems, constants are expected to have the
    precision based on the number of digits specified. This goes into
    the idea of SIGFIGs, (that my TAs used to like to write on my papers).

    How many constants that have more than seven digits, but don't
    have a D exponent, does your program have? grep should be able
    to find them pretty fast.

    In a large fraction of physics problems, double precision is needed
    to make sure that precision isn't lost in intermediate calculations.
    That is especially true in matrix processing.

    The IBM 7030 Stretch has a feature designed to help understand
    precision loss in programs. One can specify the bits shifted in
    for post-normalization on floating point operations. Pretty much,
    that translates into either rounding down or up in hand calculation.

    You then run the program both ways, and look for different results.

    Adding D0 won't convert 3.14159 into a 16 digit approximation to pi.

    I suspect that the process could be automated, and for less time than
    hand editing 850,000 lines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to All on Wed Oct 20 08:09:30 2021
    On Wednesday, October 20, 2021 at 8:53:38 AM UTC+2, gah4 wrote:
    On Tuesday, October 19, 2021 at 6:00:40 PM UTC-7, Lynn McGuire wrote:

    If I want double precision for my real constants, is it better to use d0 on all values or use the compiler flag "-fdefault-double-8" from https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    OK, first, reading what -fdefault-double-8 does, it only affects variables and constants that are already double precision or KIND 8.

    Instead, -freal-4-real-8 applies to all KIND 4 variables and constants.

    I suspect the answer depends on the program, but I believe that in many cases double precision constants are overrated. It depends much on how
    well you know your program. Are all variables already KIND 8?

    Most often in physics problems, constants are expected to have the
    precision based on the number of digits specified. This goes into
    the idea of SIGFIGs, (that my TAs used to like to write on my papers).

    How many constants that have more than seven digits, but don't
    have a D exponent, does your program have? grep should be able
    to find them pretty fast.

    In a large fraction of physics problems, double precision is needed
    to make sure that precision isn't lost in intermediate calculations.
    That is especially true in matrix processing.

    The IBM 7030 Stretch has a feature designed to help understand
    precision loss in programs. One can specify the bits shifted in
    for post-normalization on floating point operations. Pretty much,
    that translates into either rounding down or up in hand calculation.

    You then run the program both ways, and look for different results.

    Adding D0 won't convert 3.14159 into a 16 digit approximation to pi.

    I suspect that the process could be automated, and for less time than
    hand editing 850,000 lines.
    At the very least it should be possible to identify the lines of code with literal numbers using grep and a convenient regular expression. That would be a first step.

    But I agree with gah4: double precision is not a sine qua non. In my line work the six decimals available with single precision help to identify a water level of a lake or a river relative to the reference down to 1 micron. Given that that reference
    level has not been measured with that precision it would be absurd to demand that you go down to the diameter of an atom ...
    On the other hand, if you need to work with dates, say via Julian dates, storing them in double precision is more than convenient so as not to lose seconds or even minutes over the span of centuries that such dates involve.

    Regards,

    Arjen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to arjen.m...@gmail.com on Wed Oct 20 08:20:48 2021
    On Wednesday, October 20, 2021 at 8:09:32 AM UTC-7, arjen.m...@gmail.com wrote:

    (snip)

    But I agree with gah4: double precision is not a sine qua non.
    In my line work the six decimals available with single precision
    help to identify a water level of a lake or a river relative to the
    reference down to 1 micron.

    By the way, if you have an Amazon Echo nearby, ask: "Alexa, what is the tangent of 90 degrees",
    and then be surprised at the answer. There might be a single precision constant in there.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Wed Oct 20 11:13:09 2021
    On Wednesday, October 20, 2021 at 12:00:40 PM UTC+11, Lynn McGuire wrote:
    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    .
    Presumably you don't have 850,000 constants.
    .
    Common constants such as 0, 1, 2, 3, etc may continue to be written as 1., 2., 3., etc.
    if your constants are are written already with the suffix E0, it should be straightforward
    to change that to "D0".
    Remaining constants may be converted by parsing the source.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Wed Oct 20 13:39:22 2021
    On 10/20/2021 1:13 PM, Robin Vowels wrote:
    On Wednesday, October 20, 2021 at 12:00:40 PM UTC+11, Lynn McGuire wrote:
    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    .
    Presumably you don't have 850,000 constants.
    .
    Common constants such as 0, 1, 2, 3, etc may continue to be written as 1., 2., 3., etc.
    if your constants are are written already with the suffix E0, it should be straightforward
    to change that to "D0".
    Remaining constants may be converted by parsing the source.

    In not all cases would a constant of value 2 be changed to a value of
    2.0d0. After all, we use many integers in our code. So, any upgrading
    of the constants must use some intelligence.

    We have been using d0 for around 20 years now for most real constants.
    But, our code dates back to 1965 or so and E-8 is fairly common in our code.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Wed Oct 20 11:23:46 2021
    On Wednesday, October 20, 2021 at 5:53:38 PM UTC+11, gah4 wrote:
    On Tuesday, October 19, 2021 at 6:00:40 PM UTC-7, Lynn McGuire wrote:

    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    OK, first, reading what -fdefault-double-8 does, it only affects variables and constants that are already double precision or KIND 8.
    .
    The program is FORTRAN 77.
    .
    Instead, -freal-4-real-8 applies to all KIND 4 variables and constants.

    I suspect the answer depends on the program, but I believe that in many
    cases double precision constants are overrated. It depends much on how
    well you know your program. Are all variables already KIND 8?
    .
    The program is FORTRAN 77.
    .
    Most often in physics problems, constants are expected to have the
    precision based on the number of digits specified. This goes into
    the idea of SIGFIGs, (that my TAs used to like to write on my papers).

    How many constants that have more than seven digits, but don't
    have a D exponent, does your program have? grep should be able
    to find them pretty fast.

    Even constants having as little as one digit can suffer loss of precision.

    . REAL :: X
    . DOUBLE PRECISION :: D
    .
    . X = 3.14159
    . D = 3.14159
    . PRINT *, X
    . PRINT *, D
    .
    . X = 0.1
    . D = 0.1
    . PRINT *, X
    . PRINT *, D
    .
    . END
    .
    . 3.14159
    . 3.14159011841
    . 0.100000
    . 0.100000001490
    .
    In a large fraction of physics problems, double precision is needed
    to make sure that precision isn't lost in intermediate calculations.
    That is especially true in matrix processing.

    The IBM 7030 Stretch has a feature
    .
    Are there any still in operation?
    .
    designed to help understand
    precision loss in programs. One can specify the bits shifted in
    for post-normalization on floating point operations. Pretty much,
    that translates into either rounding down or up in hand calculation.

    You then run the program both ways, and look for different results.

    Adding D0 won't convert 3.14159 into a 16 digit approximation to pi.
    .
    but at least the (decimal) digits beyond the "9" will be zero, not rubbish.
    .
    I suspect that the process could be automated, and for less time than
    hand editing 850,000 lines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Arjen Markus on Wed Oct 20 13:45:45 2021
    On 10/20/2021 10:09 AM, Arjen Markus wrote:
    On Wednesday, October 20, 2021 at 8:53:38 AM UTC+2, gah4 wrote:
    On Tuesday, October 19, 2021 at 6:00:40 PM UTC-7, Lynn McGuire wrote:

    If I want double precision for my real constants, is it better to use d0 >>> on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    OK, first, reading what -fdefault-double-8 does, it only affects variables >> and constants that are already double precision or KIND 8.

    Instead, -freal-4-real-8 applies to all KIND 4 variables and constants.

    I suspect the answer depends on the program, but I believe that in many
    cases double precision constants are overrated. It depends much on how
    well you know your program. Are all variables already KIND 8?

    Most often in physics problems, constants are expected to have the
    precision based on the number of digits specified. This goes into
    the idea of SIGFIGs, (that my TAs used to like to write on my papers).

    How many constants that have more than seven digits, but don't
    have a D exponent, does your program have? grep should be able
    to find them pretty fast.

    In a large fraction of physics problems, double precision is needed
    to make sure that precision isn't lost in intermediate calculations.
    That is especially true in matrix processing.

    The IBM 7030 Stretch has a feature designed to help understand
    precision loss in programs. One can specify the bits shifted in
    for post-normalization on floating point operations. Pretty much,
    that translates into either rounding down or up in hand calculation.

    You then run the program both ways, and look for different results.

    Adding D0 won't convert 3.14159 into a 16 digit approximation to pi.

    I suspect that the process could be automated, and for less time than
    hand editing 850,000 lines.
    At the very least it should be possible to identify the lines of code with literal numbers using grep and a convenient regular expression. That would be a first step.

    But I agree with gah4: double precision is not a sine qua non. In my line work the six decimals available with single precision help to identify a water level of a lake or a river relative to the reference down to 1 micron. Given that that reference
    level has not been measured with that precision it would be absurd to demand that you go down to the diameter of an atom ...
    On the other hand, if you need to work with dates, say via Julian dates, storing them in double precision is more than convenient so as not to lose seconds or even minutes over the span of centuries that such dates involve.

    Regards,

    Arjen

    We converted from single precision to double precision in 2001 or so.
    Very late to the game, we should have done the conversion in 1980. But
    we were always fighting memory issues, our main exe hit 1 MB in 1978 and
    6 MB in 1988 (some key mainframe limits there).

    My experience with single precision is that you are lucky if you can get
    5.5 digits of precision with 32 bit machines. The single precision
    worked great for us on the 36 bit Univac 1108 machines. And the 60 bit
    CDC 7600 machine was freaking awesome. But the ports to the 32 bit IBM mainframe in 1977 and the 32 bit Prime 450 in 1978 should have told us
    to precision up.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Wed Oct 20 21:58:06 2021
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    My experience with single precision is that you are lucky if you can get
    5.5 digits of precision with 32 bit machines. The single precision
    worked great for us on the 36 bit Univac 1108 machines. And the 60 bit
    CDC 7600 machine was freaking awesome. But the ports to the 32 bit IBM mainframe in 1977 and the 32 bit Prime 450 in 1978 should have told us
    to precision up.

    The IBM mainframe had radix 16, which was a bad idea (and which gets
    a deserved dishonorable mention in Hacker's Delight).

    What format did the Prime use?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Wed Oct 20 18:44:30 2021
    On Thursday, October 21, 2021 at 5:39:26 AM UTC+11, Lynn McGuire wrote:
    On 10/20/2021 1:13 PM, Robin Vowels wrote:
    On Wednesday, October 20, 2021 at 12:00:40 PM UTC+11, Lynn McGuire wrote:
    If I want double precision for my real constants, is it better to use d0 >> on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.
    .
    Presumably you don't have 850,000 constants.
    .
    Common constants such as 0, 1, 2, 3, etc may continue to be written as 1., 2., 3., etc.
    if your constants are are written already with the suffix E0, it should be straightforward
    to change that to "D0".
    Remaining constants may be converted by parsing the source.
    .
    In not all cases would a constant of value 2 be changed to a value of
    2.0d0.
    .
    Did you read what I wrote?
    I said that constants such as 0, 1, 2, 3, etc may continue to be written
    1., 2., 3., etc.
    Integer constants would not be changed.
    .
    After all, we use many integers in our code. So, any upgrading
    of the constants must use some intelligence.
    .
    Integer constants need no "upgrading", and most constants
    already written as 1., 2., etc can remain unchanged.
    The exception would be single-precision constants used as arguments.
    .
    We have been using d0 for around 20 years now for most real constants.
    But, our code dates back to 1965 or so and E-8 is fairly common in our code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Thomas Koenig on Wed Oct 20 19:01:02 2021
    On Thursday, October 21, 2021 at 8:58:09 AM UTC+11, Thomas Koenig wrote:
    Lynn McGuire <lynnmc...@gmail.com> schrieb:
    My experience with single precision is that you are lucky if you can get 5.5 digits of precision with 32 bit machines. The single precision
    worked great for us on the 36 bit Univac 1108 machines. And the 60 bit
    CDC 7600 machine was freaking awesome. But the ports to the 32 bit IBM mainframe in 1977 and the 32 bit Prime 450 in 1978 should have told us
    to precision up.
    .
    The IBM mainframe had radix 16, which was a bad idea (and which gets
    a deserved dishonorable mention in Hacker's Delight).
    .
    Only in the context of IBM's earlier 704, 709, 7090 machines (which used
    36-bit words).
    .
    32-bit words had already been use for floating-point operations
    on, for example, DEUCE for 8 years, and was used in an increasing
    number of translators on that machine from the late 1950s.
    (GEORGE used a 21-bit mantissa and a 10-bit exponent field.)
    .
    Single precision floating point on the S/360 was perfectly adequate,
    especially for small core machines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Duffy@21:1/5 to Lynn McGuire on Thu Oct 21 05:19:39 2021
    Lynn McGuire <lynnmcguire5@gmail.com> wrote:
    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    If it is pure-ish F77, then toolpack has the apt (Arithmetic Precision Transformer) utility, and NAG had their own version - NAGWare Fortran
    Tools nag_apt:

    "TRANSFORMATION DETAILS
    [...]
    3. Real constants are transformed to/from double precision, and if
    appropriate "D0" will be added to or deleted from the end of the constant."

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to David Duffy on Thu Oct 21 14:51:56 2021
    On 10/21/2021 12:19 AM, David Duffy wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> wrote:
    If I want double precision for my real constants, is it better to use d0
    on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    If it is pure-ish F77, then toolpack has the apt (Arithmetic Precision Transformer) utility, and NAG had their own version - NAGWare Fortran
    Tools nag_apt:

    "TRANSFORMATION DETAILS
    [...]
    3. Real constants are transformed to/from double precision, and if appropriate "D0" will be added to or deleted from the end of the constant."

    Toolpack ???

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Thu Oct 21 20:40:29 2021
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/21/2021 12:19 AM, David Duffy wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> wrote:
    If I want double precision for my real constants, is it better to use d0 >>> on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html >>>
    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    If it is pure-ish F77, then toolpack has the apt (Arithmetic Precision
    Transformer) utility, and NAG had their own version - NAGWare Fortran
    Tools nag_apt:

    "TRANSFORMATION DETAILS
    [...]
    3. Real constants are transformed to/from double precision, and if
    appropriate "D0" will be added to or deleted from the end of the constant."

    Toolpack ???

    Yes, toolpack.

    Googling finds this, for example, at https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

    It has some nice properties converting, for example, some GOTO stuff
    into IF/THEN/ELSE, reformatting, declaring variables and so on.

    I've used it on occasion to convert stuff from pre-77 days on
    Netlib to something more modern.

    It is _very_ picky about standard Fortran 77 syntax, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Thu Oct 21 16:01:12 2021
    On 10/21/2021 3:40 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/21/2021 12:19 AM, David Duffy wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> wrote:
    If I want double precision for my real constants, is it better to use d0 >>>> on all values or use the compiler flag "-fdefault-double-8" from
    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html >>>>
    I've got 850,000 lines of F77 code. Adding d0 to each real value might >>>> be completed before Sol burns out.

    If it is pure-ish F77, then toolpack has the apt (Arithmetic Precision
    Transformer) utility, and NAG had their own version - NAGWare Fortran
    Tools nag_apt:

    "TRANSFORMATION DETAILS
    [...]
    3. Real constants are transformed to/from double precision, and if
    appropriate "D0" will be added to or deleted from the end of the constant." >>
    Toolpack ???

    Yes, toolpack.

    Googling finds this, for example, at https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

    It has some nice properties converting, for example, some GOTO stuff
    into IF/THEN/ELSE, reformatting, declaring variables and so on.

    I've used it on occasion to convert stuff from pre-77 days on
    Netlib to something more modern.

    It is _very_ picky about standard Fortran 77 syntax, though.

    Thank you. My googling did not work for that.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Lynn McGuire on Fri Oct 22 13:13:52 2021
    On 10/21/2021 4:01 PM, Lynn McGuire wrote:
    On 10/21/2021 3:40 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/21/2021 12:19 AM, David Duffy wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> wrote:
    If I want double precision for my real constants, is it better to
    use d0
    on all values or use the compiler flag "-fdefault-double-8" from

    https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html >>>>>
    I've got 850,000 lines of F77 code.  Adding d0 to each real value
    might
    be completed before Sol burns out.

    If it is pure-ish F77, then toolpack has the apt (Arithmetic Precision >>>> Transformer) utility, and NAG had their own version - NAGWare Fortran
    Tools nag_apt:

    "TRANSFORMATION DETAILS
    [...]
    3. Real constants are transformed to/from double precision, and if
    appropriate "D0" will be added to or deleted from the end of the
    constant."

    Toolpack ???

    Yes, toolpack.

    Googling finds this, for example, at
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

    It has some nice properties converting, for example, some GOTO stuff
    into IF/THEN/ELSE, reformatting, declaring variables and so on.

    I've used it on occasion to convert stuff from pre-77 days on
    Netlib to something more modern.

    It is _very_ picky about standard Fortran 77 syntax, though.

    Thank you.  My googling did not work for that.

    Lynn

    BTW, you are listed on the expanded listing as the uploader of the
    toolbox in 1993.
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/toolpack-1.2.lsm

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Sat Oct 23 15:24:10 2021
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/21/2021 4:01 PM, Lynn McGuire wrote:
    On 10/21/2021 3:40 PM, Thomas Koenig wrote:

    Googling finds this, for example, at
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

    It has some nice properties converting, for example, some GOTO stuff
    into IF/THEN/ELSE, reformatting, declaring variables and so on.

    I've used it on occasion to convert stuff from pre-77 days on
    Netlib to something more modern.

    It is _very_ picky about standard Fortran 77 syntax, though.

    Thank you.  My googling did not work for that.

    Lynn

    BTW, you are listed on the expanded listing as the uploader of the
    toolbox in 1993.
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/toolpack-1.2.lsm

    Yes, I did that back in my University days.

    Toolpack was among the thing that the comptuter center offered on the
    IBM 3090, and I found it quite useful, so I ported it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Sat Oct 23 15:56:16 2021
    On 10/23/2021 10:24 AM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/21/2021 4:01 PM, Lynn McGuire wrote:
    On 10/21/2021 3:40 PM, Thomas Koenig wrote:

    Googling finds this, for example, at
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html >>>>
    It has some nice properties converting, for example, some GOTO stuff
    into IF/THEN/ELSE, reformatting, declaring variables and so on.

    I've used it on occasion to convert stuff from pre-77 days on
    Netlib to something more modern.

    It is _very_ picky about standard Fortran 77 syntax, though.

    Thank you.  My googling did not work for that.

    Lynn

    BTW, you are listed on the expanded listing as the uploader of the
    toolbox in 1993.
    https://www.ibiblio.org/pub/Linux/devel/lang/fortran/toolpack-1.2.lsm

    Yes, I did that back in my University days.

    Toolpack was among the thing that the comptuter center offered on the
    IBM 3090, and I found it quite useful, so I ported it.

    Thanks !

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to Lynn McGuire on Mon Oct 25 23:17:16 2021
    On Tuesday, October 19, 2021 at 7:00:40 PM UTC-6, Lynn McGuire wrote:

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    It's certainly true that ordinary text editors don't have the
    ability to recognize Fortran real constants.

    But perhaps a program written in C or awk or Basic could actually
    add D0 to every real constant automatically?

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Quadibloc on Tue Oct 26 10:52:08 2021
    Quadibloc <jsavard@ecn.ab.ca> schrieb:
    On Tuesday, October 19, 2021 at 7:00:40 PM UTC-6, Lynn McGuire wrote:

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    It's certainly true that ordinary text editors don't have the
    ability to recognize Fortran real constants.

    But perhaps a program written in C or awk or Basic could actually
    add D0 to every real constant automatically?

    As long as you do not exceed column 72, that should be fine.
    If you do...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Tue Oct 26 05:32:03 2021
    On Tuesday, October 26, 2021 at 3:52:10 AM UTC-7, Thomas Koenig wrote:
    Quadibloc <jsa...@ecn.ab.ca> schrieb:

    (snip)
    But perhaps a program written in C or awk or Basic could actually
    add D0 to every real constant automatically?

    As long as you do not exceed column 72, that should be fine.
    If you do...

    Yes, you want to read in each statement, including continuations, change the constants, then write out with new continuations.

    Should be pretty fast in awk.

    Slightly complicated if you allow constants with random spaces inside,
    though. Might want to fix those at the same time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Tue Oct 26 13:48:43 2021
    On 10/26/2021 5:52 AM, Thomas Koenig wrote:
    Quadibloc <jsavard@ecn.ab.ca> schrieb:
    On Tuesday, October 19, 2021 at 7:00:40 PM UTC-6, Lynn McGuire wrote:

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    It's certainly true that ordinary text editors don't have the
    ability to recognize Fortran real constants.

    But perhaps a program written in C or awk or Basic could actually
    add D0 to every real constant automatically?

    As long as you do not exceed column 72, that should be fine.
    If you do...

    I wrote a C program many years to convert our Fortran source code from
    REAL to DOUBLE PRECISION. I handled the past column 72 problem by
    backing up to the last comma and making the line into two lines.

    My C program also did some other cleanup also so it was not a generic
    solution.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Tue Oct 26 13:15:43 2021
    On Tuesday, October 26, 2021 at 11:48:47 AM UTC-7, Lynn McGuire wrote:
    On 10/26/2021 5:52 AM, Thomas Koenig wrote:

    (snip)

    As long as you do not exceed column 72, that should be fine.
    If you do...

    I wrote a C program many years to convert our Fortran source code from
    REAL to DOUBLE PRECISION. I handled the past column 72 problem by
    backing up to the last comma and making the line into two lines.

    My C program also did some other cleanup also so it was not a generic solution.

    Awk, and some other languages, have built-in regular expression matching.

    You have to be a little careful not to match ones inside quotes
    (or Hollerith constants!), but otherwise it isn't so hard to find them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Tue Oct 26 16:08:18 2021
    On 10/26/2021 3:15 PM, gah4 wrote:
    On Tuesday, October 26, 2021 at 11:48:47 AM UTC-7, Lynn McGuire wrote:
    On 10/26/2021 5:52 AM, Thomas Koenig wrote:

    (snip)

    As long as you do not exceed column 72, that should be fine.
    If you do...

    I wrote a C program many years to convert our Fortran source code from
    REAL to DOUBLE PRECISION. I handled the past column 72 problem by
    backing up to the last comma and making the line into two lines.

    My C program also did some other cleanup also so it was not a generic
    solution.

    Awk, and some other languages, have built-in regular expression matching.

    You have to be a little careful not to match ones inside quotes
    (or Hollerith constants!), but otherwise it isn't so hard to find them.

    No thank you for the Awk. My C program worked just fine for 5,000
    subroutines and functions to be updated.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Quadibloc@21:1/5 to Thomas Koenig on Thu Oct 28 00:40:04 2021
    On Tuesday, October 26, 2021 at 4:52:10 AM UTC-6, Thomas Koenig wrote:
    Quadibloc <jsa...@ecn.ab.ca> schrieb:
    On Tuesday, October 19, 2021 at 7:00:40 PM UTC-6, Lynn McGuire wrote:

    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    It's certainly true that ordinary text editors don't have the
    ability to recognize Fortran real constants.

    But perhaps a program written in C or awk or Basic could actually
    add D0 to every real constant automatically?

    As long as you do not exceed column 72, that should be fine.
    If you do...

    In any case, I see that writing a program was suggested long ago
    by others - and you had a better solution, the "toolpack" utilities,
    which were designed to handle all the issues around FORTRAN
    of the time - only looking between columns 7 and 72, ignoring
    quoted strings (and Hollerith constants of the form 5HHELLO
    as well, which is even harder).

    Better handle continuation cards properly as well!

    Of course replacing 3.141593 by 3.1415926535897932D0 would
    still have to be done by hand, but taking care of _that_ issue by
    hand is not unreasonable when the others are taken care of.

    John Savard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Quadibloc on Thu Oct 28 02:06:20 2021
    On Thursday, October 28, 2021 at 12:40:06 AM UTC-7, Quadibloc wrote:

    (snip)
    Of course replacing 3.141593 by 3.1415926535897932D0 would
    still have to be done by hand,

    "Alexa, what is the tangent of 90 degrees?"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to All on Sun Oct 31 06:03:46 2021
    I've got 850,000 lines of F77 code. Adding d0 to each real value might
    be completed before Sol burns out.

    Thanks,
    Lynn

    Try fpt (Download from http://simconglobal.com). Never mind the death of Sol - should do it before your coffee gets cold. The command is
    % change real size : 8
    There are also commands to change sizes to kinds (May not help if you are using an F77 compiler).
    Best wishes,

    John

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