On Sunday, April 10, 2022 at 4:19:23 AM UTC+10, john.c...@simconglobal.com wrote:
> On Saturday, April 9, 2022 at 3:05:29 PM UTC+1, Beliavsky wrote:
> > Since compilers treat the non-standard but very common
> >
> > real*4, real*8, integer*4, integer*8
> >
> > as
> >
> > use iso_fortran_env
> > real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)
> >
> > would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
> I am in favour of making this standard, but I think it is academic. I know of no compilers in common use which do not support declarations in this format, and I doubt if any compiler writers would remove them for the sake of annoying some of their users.
>
> The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.
..
In small test programs, REAL and DOUBLE PRECISION are clear,
and can be written quickly.

On Sunday, April 10, 2022 at 3:15:45 AM UTC+10, Ron Shepard wrote:
> On 4/9/22 9:05 AM, Beliavsky wrote:
> > Since compilers treat the non-standard but very common
> >
> > real*4, real*8, integer*4, integer*8
> >
> > as
> >
> > use iso_fortran_env
> > real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)
> >
> > would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
> In my opinion, this would be a step backward for the language.
>
> There are many reasons why this should not be done, but one of them is
> that REAL*4 etc. were always just defined by the local compiler to map
> to its supported floating point formats. For byte addressable machines,
> that meant that your suggested mapping would be correct. But there are
> also 36-bit, 60-bit, and 64-bit machines that cannot conform to those
> mappings, so they must do something different. In the f77 time in the
> 1980s, I used those declarations extensively for exactly that reason, it
> was a way, with some care, to write portable (but nonstandard) code. I
> used REAL*8 declarations to run on machines with all of those word
> lengths. It wasn't pretty, but it served its purpose at the time.
>
> But now we have the fortran KIND system, which handles all of that much
> better. Yes, when you incorporate old f66 and f77 code into your current
> project, you need to edit in those changes, but that is not a big deal.
> Your minimal efforts are rewarded with clarity and portability. I have
> programs with hundreds of thousands of lines where I can change the
> precision globally by modifying a single line of code in a module. From
> the programmer's perspective, that is hard to beat.
..
Indeed !!!

On Sunday, April 10, 2022 at 4:40:46 AM UTC+10, FortranFan wrote:
> On Saturday, April 9, 2022 at 2:19:23 PM UTC-4, john.c...@simconglobal.com wrote:
>
> > ..
> > I am in favour of making this standard ..
> > The KIND specifications are clear and unambiguous, but in small test programs they can take up a significant proportion of the entire text.
> Should the standard do anything now, a better option will be to simply provide built-in i.e., ALIASes toward type-and-kind equivalent to certain standard floating point formats, say IEEE binary (and perhaps decimal) formats.
>
> For the foreseeable future, the powers-that-be in the industry and research and engineering areas I know only expect to use IEEE binary 64-bit floating point in >99% of computing.
>
> So what will be really useful is to have, say, IEEE_FPB64 as an alias for real(KIND=xx) where xx is IEEE_SELECTED_REAL_KIND( p=, r=, radix=..) corresponding to 64-bit IEEE binary floating point format.
>
> One should then be able to do the following in any processor that provides support for IEEE_xxx features from Fortran 2003+ which is several of the modern Fortran compilers:
>
> ieee_fpb64 :: x
..
Can we not write in English? REAL (KIND=DP) :: x
..
> One can combine that with proposal for kinds for literal constants.

On Sunday, April 10, 2022 at 3:35:25 PM UTC+10, JCampbell wrote:
> On Sunday, April 10, 2022 at 12:05:29 AM UTC+10, Beliavsky wrote:
> > Since compilers treat the non-standard but very common
> >
> > real*4, real*8, integer*4, integer*8
> >
> > as
> >
> > use iso_fortran_env
> > real(kind=real32), real(kind=real64), integer(kind=int32), integer(kind=int64)
> >
> > would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?
> real*8 and real(kind=real64) both provide a clear documentation of precision.
> real(8) unfortunately, is not portable.
..
and real*8 is not standard.
>.
> real(dp) or real(kind=dp) is not clear,
..
in what way? "dp" is used often enough that it is immediately clear
that it signifies double precision.
..
>as you need to search for the definition of dp,
..
Really?
The purpose of using such "words" as 'dp' and 'wp' in your
programs makes it clear what the words mean.
..
> often in a "remote" module.
> sp, dp, qp, wp, r4 or r8 are not standard abbreviations. They are not uncommon real variables in legacy codes.
..
Can't say I have seen these in any old codes.
..
> I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use,
..
So does DOUBLE PRECISION, which is STANDARD.
..
> while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.
> One compiler has real_kinds of [ 1,2 ] and integer_kinds of [ 1,2,3,4 ]. Try using integers such as 123_4 and see what you get for the different compilers I use.
..
Don't use such silly suffixes.
..
> When using real*8, there is always the danger of using a compiler that does not support this non-standard syntax. I think there are greater dangers out there at the moment!
> I have used new Fortran compilers that did not support the real*byte syntax. It has happened a few times and I always successfully lobbied for the compiler to be enhanced.
..
"enhanced"? you mean, down-graded.
..
> Most new OS and compilers tend to want to help established users.
>
> IEEE documents also use REAL*8 syntax.
..
So what?

JCampbell wrote:

> I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.

Can you elaborate?

gfortran's real(10) on x86_64 class hardware is Intel 80-bit
extended double precision.

--
steve

On 4/11/22 11:05 AM, steve kargl wrote:
> JCampbell wrote:
>
>> I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.
>
> Can you elaborate?
>
> gfortran's real(10) on x86_64 class hardware is Intel 80-bit
> extended double precision.

I think the problem people have is that it is stored in 16 bytes, so
there is a lot of wasted memory and/or file space.

I'm glad the option is there, for example for accumulating sums with
extended precision, but its overall usefulness is limited because of
those wasted 48-bits per value. Programmers instead are likely just to
use the 128-bit floating point kind which takes up the same memory/file
space. And it is nice to have the 128-bit kind supported too.

$.02 -Ron Shepard

Ron Shepard wrote:

> On 4/11/22 11:05 AM, steve kargl wrote:
>> JCampbell wrote:
>>
>>> I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.
>>
>> Can you elaborate?
>>
>> gfortran's real(10) on x86_64 class hardware is Intel 80-bit
>> extended double precision.
>
> I think the problem people have is that it is stored in 16 bytes, so
> there is a lot of wasted memory and/or file space.
>
> I'm glad the option is there, for example for accumulating sums with
> extended precision, but its overall usefulness is limited because of
> those wasted 48-bits per value. Programmers instead are likely just to
> use the 128-bit floating point kind which takes up the same memory/file
> space. And it is nice to have the 128-bit kind supported too.

Then those people are blaming the wrong thing. Intel choose 4, 8, and 16-byte
alignment in their ABIs. gfortran (and gcc) are just a tool sitting above the cpu.

--
steve

On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
<snip>> .
> So does DOUBLE PRECISION, which is STANDARD.
> .

I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.

I agree that standardising REAL*8 would inject a fossil into the language. Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.

PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)

Then REAL_8 could only be used in a kind specification and would always mean the same thing. This would avoid an error which we found recently in an important code where the user had written an expression of the form:

REAL(dp),PARAMETER :: kappa = 68431_dp

dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer was defined as 64-bits and no error occurred on the original ifort compiler. What NAG or FTN95 would have done with it I don't want to know. We don't (yet) know how many more of these are likely to turn up. The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.

On Tuesday, April 12, 2022 at 11:04:21 AM UTC-7, john.c...@simconglobal.com wrote:

(snip)

> I agree that standardising REAL*8 would inject a fossil into the language.
> Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.
> PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)
> Then REAL_8 could only be used in a kind specification and would always mean the same thing.
> This would avoid an error which we found recently in an important code where
> the user had written an expression of the form:
> REAL(dp),PARAMETER :: kappa = 68431_dp

The KIND values could have been required to be different for different
types, though they are required to be the same for a REAL type and the
twice as big COMPLEX type.

(IBM and DEC call the double precision complex type REAL*16.)

> dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer
> was defined as 64-bits and no error occurred on the original ifort compiler.

> What NAG or FTN95 would have done with it I don't want to know.
> We don't (yet) know how many more of these are likely to turn up.
> The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.

As well as I know the standard, the KIND values are just integers.

The standard doesn't care much where you get your KIND values,
as long as the one you come up with is supported.

REAL(dp),PARAMETER :: kappa = 68431_dp

is legal, standard, but not portable.

I suspect one could claim that reusing KIND values between INTEGER and
REAL kinds is a quality of implementation issue, and that a high quality
implementation would not do that. Start sending in bug reports!

The original subject here is the non-standard REAL*8, but there is the
standard, non-portable, and way too common REAL(8).

There is no suggestion in the standard that REAL(8) exists,
and even less that it is an 8 byte or 64 bit type.

John Collins wrote:

> On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
> <snip>> .
>> So does DOUBLE PRECISION, which is STANDARD.
>> .
>
> I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
>

DOUBLE PRECISION is defined by the standard. An entity with
default REAL kind type occupies one numeric storage unit.
An entity with DOUBLE PRECISION type occupies two numeric
storage units. If one numeric storage unit is 64 bits, then
two would use 128 bits.

--
steve

In article <t34lac$utb$1@dont-email.me>, steve kargl
<sgk@REMOVEtroutmask.apl.washington.edu> writes:

> John Collins wrote:
>
> > On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
> > <snip>> .
> >> So does DOUBLE PRECISION, which is STANDARD.
> >> .
> >
> > I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
> >
>
> DOUBLE PRECISION is defined by the standard. An entity with
> default REAL kind type occupies one numeric storage unit.
> An entity with DOUBLE PRECISION type occupies two numeric
> storage units. If one numeric storage unit is 64 bits, then
> two would use 128 bits.

Right. DOUBLE is really double the size, since the actual precision,
however it is measured, can vary, and is usually not double.

On Tuesday, April 12, 2022 at 12:52:47 PM UTC-7, steve kargl wrote:

(snip)

> DOUBLE PRECISION is defined by the standard. An entity with
> default REAL kind type occupies one numeric storage unit.
> An entity with DOUBLE PRECISION type occupies two numeric
> storage units. If one numeric storage unit is 64 bits, then
> two would use 128 bits.

Yes, the word addressed Cray machines with 64 bit words, and CDC machines with 60 bit
words, did not have a smaller type. So the Fortran required double precision had to
be 128 bits, or 120 bits, respectively, and as well as I know, was done in software.

As far as I know, all those are in museums, so we don't have to plan for them.
Is there any thought that more such processor might be built?

Otherwise, for the IEEE 754 decimal forms, the basic (IEEE 754 term) forms
are the 64 bit and 128 bit forms. If there was interest in a Fortran compiler
supporting them as its default types, such that default REAL would be 64 bits,
then it would be useful, as above, to have a way to ask for this, without
asking for a double precision type.

On 4/12/22 1:23 PM, gah4 wrote:
> The original subject here is the non-standard REAL*8, but there is the
> standard, non-portable, and way too common REAL(8).

There are thousands of lines of compiler documentation that use REAL(8)
because that is a concise way to describe how the compiler does things.
When new programmers see that documentation, they will mimic it in their
codes. This problem is not going away any time soon.

$.02 -Ron Shepard

On 4/12/22 3:06 PM, Phillip Helbig (undress to reply) wrote:
[...]
> Right. DOUBLE is really double the size, since the actual precision,
> however it is measured, can vary, and is usually not double.

And sometimes the precision is more than double. Compare the 24-bit
mantissas in single precision to the 53-bit mantissas in double
precision. Those counts include the implicit hidden bit.

$.02 -Ron Shepard

On Wednesday, April 13, 2022 at 4:04:21 AM UTC+10, john.c...@simconglobal.com wrote:
> On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
> <snip>> .
> > So does DOUBLE PRECISION, which is STANDARD.
> > .
> I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
..
How many of those do you use?
..
> I agree that standardising REAL*8 would inject a fossil into the language. Perhaps a way forward is to define a new class of PARAMETER for types and kinds, e.g.
>
> PARAMETER,KIND :: REAL_8 = REAL,KIND=KIND(1.0D0)
>
> Then REAL_8 could only be used in a kind specification and would always mean the same thing. This would avoid an error which we found recently in an important code where the user had written an expression of the form:
>
> REAL(dp),PARAMETER :: kappa = 68431_dp
>
> dp was (as a result of SELECTED_REAL_KIND) equal to 8 so the integer was defined as 64-bits and no error occurred on the original ifort compiler. What NAG or FTN95 would have done with it I don't want to know.
..
The design of the kind system in FORTRAN is flawed, and allows errors of this type to pass unnoticed.
The way around it is to have a kind number that is unique for every available kind.
Most manufacturers have circumvented this simple check and invented kind numbers
according to the number of bytes typically employed for the relevant real or integer.
Thus, compilers have the same kind number for both single-precision real [32-bit] and for
a default [32-bit] integer, and so on.
..
In PL/I we can write DECLARE X FLOAT DECIMAL(15);
and DECLARE Y FLOAT DECIMAL (6);
and get the precision that we desire, so that even if a machine
were available that offered only 64-bit reals, we would have
it using hardware floats of 64-bits for variables X and Y.
(Of course, the number of desired digits can be parameterised,
just as in Fortran, so that it would be easy to change.)
As well as the above, one can write DECLARE Z FLOAT BINARY (53);
if it is desired to express the requirement in binary digits.
...
>We don't (yet) know how many more of these are likely to turn up.
> The compiler could issue an error if a parameterised KIND were used as a tag for an integer literal.
..
It could do it now had the compiler writer used unique integers for every kind.
It doesn't need any language changes,.

On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
> John Collins wrote:
>
> > On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
> > <snip>> .
> >> So does DOUBLE PRECISION, which is STANDARD.
> >> .
> >
> > I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
> >
> DOUBLE PRECISION is defined by the standard. An entity with
> default REAL kind type occupies one numeric storage unit.
> An entity with DOUBLE PRECISION type occupies two numeric
> storage units. If one numeric storage unit is 64 bits, then
> two would use 128 bits.
..
How many machines are using that offer only 64 bit reals?

On Wednesday, April 13, 2022 at 3:04:34 PM UTC+10, Ron Shepard wrote:
> On 4/12/22 1:23 PM, gah4 wrote:
> > The original subject here is the non-standard REAL*8, but there is the
> > standard, non-portable, and way too common REAL(8).
> There are thousands of lines of compiler documentation that use REAL(8)
> because that is a concise way to describe how the compiler does things.
> When new programmers see that documentation, they will mimic it in their
> codes. This problem is not going away any time soon.
..
How long would it take to write a program to read in a Fortran
program and change REAL(8) to REAL(dp) ?

On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
> John Collins wrote:
>
> > On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
> > <snip>> .
> >> So does DOUBLE PRECISION, which is STANDARD.
> >> .
> >
> > I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
> >
> DOUBLE PRECISION is defined by the standard. An entity with
> default REAL kind type occupies one numeric storage unit.
> An entity with DOUBLE PRECISION type occupies two numeric
> storage units. If one numeric storage unit is 64 bits, then
> two would use 128 bits.
..
How many machines are you using that offer 64 bit words for single precision?

On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:

(snip)

> How many machines are using that offer only 64 bit reals?

Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
Cray-C90 Cray-EL90.

How many of each did they make, so we can add them all up?

On Wednesday, April 13, 2022 at 5:44:14 PM UTC+10, gah4 wrote:
> On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:
>
> (snip)
> > How many machines are using that offer only 64 bit reals?
..
The word "you" was inadvertently omitted from the sentence.
..
> Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
> Cray-C90 Cray-EL90.
>
> How many of each did they make, so we can add them all up?
..
There is none in use. Any that still exist are museum pieces.

On 4/13/22 2:44 AM, gah4 wrote:
> On Tuesday, April 12, 2022 at 11:06:52 PM UTC-7, Robin Vowels wrote:
>
> (snip)
>
>> How many machines are using that offer only 64 bit reals?
>
> Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
> Cray-C90 Cray-EL90.

I'm not sure exactly what this discussion is about, but fortran
compilers on those computers also supported 128-bit reals. Double
precision on those machines was slow, but it was there if you absolutely
needed it.

However, the FPS series of machines, which were also popular in the
1980s, did not support 128-bit arithmetic at all. They only supported
64-bit single precision floating point.

> How many of each did they make, so we can add them all up?

These were not personal computers, so the measure is not how many of the
computers were made, but rather how many programmers and users had
access to them. In my field of computational chemistry, that would be
essentially every active programmer. In the 1980s, one could gain access
in a variety of ways, through government agencies like NSF, NIH, DoD, or
DOE, through state computer access programs, through universities, or
through private employers. Those machines cast a huge shadow in their time.

$.02 -Ron Shepard

Robin Vowels wrote:

> On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:
>> John Collins wrote:
>>
>> > On Monday, April 11, 2022 at 10:21:33 AM UTC+1, Robin Vowels wrote:
>> > <snip>> .
>> >> So does DOUBLE PRECISION, which is STANDARD.
>> >> .
>> >
>> > I'm not sure that it is, or at least, not in a helpful way. A system with a default 64-bit real number might interpret DOUBLE PRECISION as 128-bit.
>> >
>> DOUBLE PRECISION is defined by the standard. An entity with
>> default REAL kind type occupies one numeric storage unit.
>> An entity with DOUBLE PRECISION type occupies two numeric
>> storage units. If one numeric storage unit is 64 bits, then
>> two would use 128 bits.
> .
> How many machines are you using that offer 64 bit words for single precision?

I can run any code that I have with a 64-bit default real on x86_64 hardware.
The requirements in the Fortran standard do not place restrictions on the
underlying hardware.

% cat o.f90
program o
real a ! default real kind
real*4 b ! nonstanard, but portable, declaration
a = 0.1_4 ! initialization with kind type suffix
b = 3. ! default real kind literal real constant
print '(2I3,1X,G0)', storage_size(a), storage_size(b), a / b
a = exp(1.)
b = 4 * atan(1.)
print '(2I3,1X,G0)', storage_size(a), storage_size(b), a / b
end program

% gfortran11 -o z o.f90 && ./z
32 32 0.333333351E-1
32 32 0.865255952
% gfortran11 -o z o.f90 && ./z
% gfortran11 -o z -fdefault-real-8 o.f90 && ./z
64 32 0.33333333830038704E-1
64 32 0.86525595535432454
% gfortran11 -o z -freal-4-real-8 o.f90 && ./z
64 64 0.33333333333333333E-1
64 64 0.86525597943226507

I'll let you ponder what's going on.

--
steve

On Wednesday, April 13, 2022 at 7:09:17 AM UTC+1, Robin Vowels wrote:
> .
> How long would it take to write a program to read in a Fortran
> program and change REAL(8) to REAL(dp) ?

If the original code didn't have odd space characters, continuation lines and comments in silly places very little time at all. But I think that an issue here is that dp must be defined somewhere, and the definition added to every routine. Inserting an INCLUDE file or USE statement into every Fortran sub-program is much more work than a 1-line sed script.

We have done all this. But I think a simple, unambiguous declaration which didn't have any associated complexities would be useful. To that end REAL*8 is the best we have got, it works everywhere (at least that I know of) and doesn't need to be in the standard if everyone understands it.

On Wednesday, April 13, 2022 at 8:10:29 AM UTC-7, Ron Shepard wrote:

(snip, I wrote)

> > Cray-1, Cray-1A, Cray-1S, Cray-1M, Cray-X-MP, Cray-Y-MP, Cray-2
> > Cray-C90 Cray-EL90.

> I'm not sure exactly what this discussion is about, but fortran
> compilers on those computers also supported 128-bit reals. Double
> precision on those machines was slow, but it was there if you absolutely
> needed it.
In the 1970's (mostly CDC) and 1980's (CDC and Cray), porting
programs was complicated if you wanted a 64 bit (more or less)
data type. That is, single precision on some machines, double
on others. (In addition, some other constants, sometimes many
other constants, would change between machines.)

One that I think I remember, from the card days, was cards for all
the different possibilities, each with a C in column 80. You then
reverse the card in the deck, so the C is in column 1, for those you
don't want to use.

In any case, REAL*8 suggests that you want about 64 bits,
and maybe about 53 bits of significand, on any machine.

It does not suggest that you want double precision on hardware
with a 60 or 64 bit single precision.

There are ways to do this within the standard, which take a lot
of typing, and also ways that are non-standard.

If you manage to USE the appropriate module, at the right time,
there is REAL64 and C_DOUBLE.

REAL(SELECTED_REAL_KIND(12))

might be about right, but is a lot to write. It is difficult to do a simple
string substitution without problems with continuations and such.

REAL(8) is shorter, but the standard does not give specific
KIND values, so one can't reliably expect any specific type,
or even that such type exists.

REAL*8 is easy to type, and does not suggest double precision on hardware
with a longer single precision type.

> However, the FPS series of machines, which were also popular in the
> 1980s, did not support 128-bit arithmetic at all. They only supported
> 64-bit single precision floating point.

Interesting. Since Fortran compilers were, as well as I know, not hosted
on the FPS machine, they might avoid the standard requirement for
a double precision type.

As well as I know it, C does not require or suggest that (double)
is twice the size, or otherwise more precision, than (float).
Systems with a 64 bit (float) can also have a 64 bit (double).

On Wednesday, April 13, 2022 at 11:41:22 AM UTC-7, john.c...@simconglobal.com wrote:
> On Wednesday, April 13, 2022 at 7:09:17 AM UTC+1, Robin Vowels wrote:
> > How long would it take to write a program to read in a Fortran
> > program and change REAL(8) to REAL(dp) ?

> If the original code didn't have odd space characters, continuation lines
> and comments in silly places very little time at all.
> But I think that an issue here is that dp must be defined somewhere,
> and the definition added to every routine. Inserting an INCLUDE file or
> USE statement into every Fortran sub-program is much more work
> than a 1-line sed script.

I would probably use AWK, and it is likely more than one line.

I am not sure at all how easy it is to find the right place to put
in the USE statement (for a constant that is in a module)
or PARAMETER statement for one that isn't.

And then you need to be sure that there isn't already one,
or that (ugh) the name could already have another use.