double precision for constants

[Lynn McGuire]

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

[gah4]

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.

[Arjen Markus]

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

[gah4]

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.

[Robin Vowels]

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

[Robin Vowels]

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.

[Lynn McGuire]

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

[Lynn McGuire]

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

[Thomas Koenig]

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

What format did the Prime use?

[Robin Vowels]

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.

[Robin Vowels]

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

[David Duffy]

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."

[Lynn McGuire]

Toolpack ???

Thanks,
Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

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.

[Lynn McGuire]

Thank you. My googling did not work for that.

Lynn

[Lynn McGuire]

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

[Thomas Koenig]

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.

[Lynn McGuire]

Thanks !

Lynn

[Quadibloc]

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

[Thomas Koenig]

Quadibloc <jsa...@ecn.ab.ca> schrieb:

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

[gah4]

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.

[Lynn McGuire]

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

[gah4]

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.

[Lynn McGuire]

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

Lynn

[Quadibloc]

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

[gah4]

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?"

[John Collins]

> 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