Standardize real*8 as real(kind=real64)?

[Beliavsky]

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?

[Beliavsky]

Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
real(kind=8), which is not guaranteed to work (failing with the NAG compiler for example). By standardizing real*8 appropriately this error is avoided.

[Robin Vowels]

On Sunday, April 10, 2022 at 12:37:41 AM UTC+10, Beliavsky wrote:
> On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, 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?
> Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
> real(kind=8),

.
An appropriate replacement is real (kind=dp)
which is one character more than the non-portable form you just suggested.
(where dp is defined as kind(1.0d0) or something equivalent specifying a number of digits )
.

> which is not guaranteed to work (failing with the NAG compiler for example).
> By standardizing real*8 appropriately this error is avoided.

.
real*8 has never been standard.

[FortranFan]

On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, Beliavsky wrote:

> ..

> would it make sense to standardize the former set of declarations, which is concise and clear, to mean the same as the latter?

No.

[gah4]

On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
(snip)

> would it make sense to standardize the former set of declarations,
> which is concise and clear, to mean the same as the latter?

One thing that I have long thought, is that it would be nice to include in the
standard some things that aren't required of implementations, but indicate
how to do something if it is included.

(And more generally than this question.)

In the past, this was complicated by machines with 60 or 64 bit words,
that had a type of that length as default REAL, and then (as required by
the standard) a longer type of DOUBLE PRECISION. Those machines are
now out of favor.

On the other hand, the IEEE 754-2008 decimal floating point has
the 64 bit and 128 bit forms as basic types. I suspect that a Fortran
compiler implementing those would use them as the single and
double precision types. (The 32 bit form has about the same status
as the 16 bit binary form.)

There are many deprecated features that it would be very easy to write
a program to convert to non-deprecated form. As far as I know, that hasn't
been done. (And in both free and fixed form.)

I do find it interesting that the Fortran II PRINT statement, after not making
it into Fortran 66, later was included in the standard. Including REAL*8 makes
about as much sense.

[gah4]

On Saturday, April 9, 2022 at 7:37:41 AM UTC-7, Beliavsky wrote:

(snip)

> Currently, if someone inherits a code with real*8 and decides to make it
> standard-conforming, they may replace it with real(kind=8), which is not
> guaranteed to work (failing with the NAG compiler for example).

> By standardizing real*8 appropriately this error is avoided.

As far as I know, REAL(8) is more popular, and equally standard and
non-portable.

I even knew of a MOOC, meant for introducing Fortran to physicists,
that taught REAL(8).

REAL(KIND(1D0))

would be standard, and reliably give a double precision type, though takes
more characters to type.

It is nice to have something that can be replaced, line by line, without the
need for any other lines to be included. (Well, assuming appropriate
continuation rules.)

[Beliavsky]

On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
> As far as I know, REAL(8) is more popular, and equally standard and
> non-portable.
>
> I even knew of a MOOC, meant for introducing Fortran to physicists,
> that taught REAL(8).
>
> REAL(KIND(1D0))
>
> would be standard, and reliably give a double precision type, though takes
> more characters to type.
>
> It is nice to have something that can be replaced, line by line, without the
> need for any other lines to be included. (Well, assuming appropriate
> continuation rules.)

If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
You could have a platform where singe precision is real(kind=real64) and double
precision is real(kind=real128). In that case the natural equivalent of real*8 would be
real(kind=real128) and not real(kind=kind(1.0d0)).

[Ron Shepard]

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.

Numerical analysts are now experimenting with 16-bit real arithmetic to
speed up critical parts of algorithms. If/when they get that working,
the fortran KIND system is already set up to handle that. IEEE decimal
arithmetic is another feature raising its head on the horizon. Again,
the fortran KIND system is already there and waiting. 10-byte arithmetic
is another example (although some compilers are currently doing this the
wrong way, I think). 128-bit arithmetic and beyond, both reals and
integers, are all handled perfectly well with the fortran KIND system.

If a compiler supports real types with those numbers of bits (real32,
real64, etc.), then the kind values are set appropriately. If there is
more than one kind with that many bits, then the processor chooses which
one to return. If the processor does not support a kind with exactly
those bits, then the processor sets the value to either -1 or -2. The -2
value means that some kind is available with higher precision. This
might not be the best way to write portable code, but if you want to
write code targeted to specific floating point formats, that is a
reasonable way to do it. The IEEE intrinsic module goes even further if
code is intended to target that floating point format, rounding modes,
NaN, subnormals, etc., all available within the fortran KIND system.
This is all in contrast to REAL*4, REAL*8, etc, which are mapped in a
very loose manner to the underlying supported floating point formats.

I think the fortran KIND system is well thought out and it works well in
practice. An improvement might be to eliminate shared KIND values
between different types -- that is a sometimes subtle source of code
errors. Another improvement might be the ability to write generic
subprograms that automatically accommodate all supported KINDs of arguments.

$.02 -Ron Shepard

[John Collins]

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.

[John Collins]

>
> There are many deprecated features that it would be very easy to write
> a program to convert to non-deprecated form. As far as I know, that hasn't
> been done. (And in both free and fixed form.)
>
> I do find it interesting that the Fortran II PRINT statement, after not making
> it into Fortran 66, later was included in the standard. Including REAL*8 makes
> about as much sense.

We have tried to convert a large number of legacy constructs to standard form in fpt (http://simconglobal.com). This includes changing REAL*n to the appropriate kind (Or back again for migration projects where you need to retest on the original host :-) ).

Changing REAL*n, INTEGER*n etc. was easy but some of the conversions were NOT "very easy to write".

[FortranFan]

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

One can combine that with proposal for kinds for literal constants.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
> (snip)
>
>> would it make sense to standardize the former set of declarations,
>> which is concise and clear, to mean the same as the latter?
>
> One thing that I have long thought, is that it would be nice to include in the
> standard some things that aren't required of implementations, but indicate
> how to do something if it is included.
>
> (And more generally than this question.)
>
> In the past, this was complicated by machines with 60 or 64 bit words,
> that had a type of that length as default REAL, and then (as required by
> the standard) a longer type of DOUBLE PRECISION. Those machines are
> now out of favor.

POWER has rather recently acquired IEEE quad precision, and
gfortran will have aquired support for it in the upcoming
release.

Not as double precision, but as REAL(KIND=16).

[JCampbell]

real*8 and real(kind=real64) both provide a clear documentation of precision.
real(8) unfortunately, is not portable.

real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, 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.

I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, 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.

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.
Most new OS and compilers tend to want to help established users.

IEEE documents also use REAL*8 syntax.

[gah4]

On Saturday, April 9, 2022 at 2:29:37 PM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:
> > On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:

(snip)

> > In the past, this was complicated by machines with 60 or 64 bit words,
> > that had a type of that length as default REAL, and then (as required by
> > the standard) a longer type of DOUBLE PRECISION. Those machines are
> > now out of favor.

> POWER has rather recently acquired IEEE quad precision, and
> gfortran will have aquired support for it in the upcoming
> release.

It was the word addressed 60 and 64 bit machines that didn't have
a smaller floating point type. IBM had REAL*16 and COMPLEX*32
since the 360/85 and standard on all S/370 and later models.

I am surprised it took this long to get to POWER.

VAX Fortran also supports REAL*16 and COMPLEX*32, though
software emulated on many machines. That was from close
to the beginning of VAX. (A microcode option on most,
it was standard on the low end 11/730.)

> Not as double precision, but as REAL(KIND=16).

As long as it supports a 32 bit, more or less, type, that isn't
a problem. But the Fortran standard requires, or at least used to,
a double precision twice (more or less) single precision.

But as I noted, for the IEEE 754-2008 decimal float types,
the basic types are 64 and 128 bit.

A Fortran compiler implementing only those, would call them single
and double precision. I believe the later POWER machines support those,
in addition to the binary forms. I would be surprised if someone wrote
a Fortran compiler for POWER supporting only the decimal types.

Note, though, that the DEC compilers for the 36 bit PDP-10
recognize REAL*8 for the 72 bit double precision. I am not sure
about the CDC and Cray compilers. It isn't required that the *8
represent 8 bytes of any specific size. (The PDP-10 byte
instructions work on bytes from 1 to 36 bits. C compilers
tend to use 9 bits for char. C requires char to be an integer
fraction of the word (int) size.)

[Thomas Koenig]

JCampbell <campbel...@gmail.com> schrieb:

> real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, 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.

They are what I usually use. In most of my projects, I have a small
module

module prec
implicit none
integer, parameter :: sp = selected_real_kind(6)
integer, parameter :: dp = selected_real_kind(15)
integer, parameter :: qp = selected_real_kind(30)
end module prec

> I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.

Modules and object code are only valid for one compiler. If you
mix them, you're in for bigger trouble than that.

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

nagfor, I presume, although they have the -kind=byte option to
match what others are doing (market pressure, I presume).

I actually like the -kind=unique version best, no possiblity
of mixing up any of the kind numbers.

> 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. Most new OS and compilers tend to
> want to help established users.

That is correct. I still find the difference between REAL*8
and COMPLEX*8 a source of confusion, though.

[gah4]

On Saturday, April 9, 2022 at 9:46:13 AM UTC-7, Beliavsky wrote:
> On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
> > As far as I know, REAL(8) is more popular, and equally standard and
> > non-portable.

(snip)

> > REAL(KIND(1D0))

> > would be standard, and reliably give a double precision type, though takes
> > more characters to type.

> > It is nice to have something that can be replaced, line by line, without the
> > need for any other lines to be included. (Well, assuming appropriate
> > continuation rules.)

> If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
> You could have a platform where singe precision is real(kind=real64) and double
> precision is real(kind=real128). In that case the natural equivalent of real*8 would be
> real(kind=real128) and not real(kind=kind(1.0d0)).

The Cray-1 series are word addressed 64 bit machines, with a 64 bit
floating point type. I believe Fortran supports a software emulated 128
bit type, as required by the standard. But all the Cray machines are, as far
as I know, in museums. (There used to be a machine that would one on
one day a week, as that was how much power they could afford.)

I don't know about Cray support for REAL*8 syntax.

I do remember Fortran programs with a series of declarations and
DATA statements at the beginning, where you uncomment the ones
for the system you are using. That was for the different word size,
and also other constants that varied between machines.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:
> On Saturday, April 9, 2022 at 2:29:37 PM UTC-7, Thomas Koenig wrote:
>> gah4 <ga...@u.washington.edu> schrieb:
>> > On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
>
> (snip)
>
>> > In the past, this was complicated by machines with 60 or 64 bit words,
>> > that had a type of that length as default REAL, and then (as required by
>> > the standard) a longer type of DOUBLE PRECISION. Those machines are
>> > now out of favor.
>
>> POWER has rather recently acquired IEEE quad precision, and
>> gfortran will have aquired support for it in the upcoming
>> release.
>
> It was the word addressed 60 and 64 bit machines that didn't have
> a smaller floating point type. IBM had REAL*16 and COMPLEX*32
> since the 360/85 and standard on all S/370 and later models.
>
> I am surprised it took this long to get to POWER.

IIRC, the REAL*16 types were implemented as two doubles. POWER also
had that (but as a pair of IEEE doubles), and a true headache it
is proving to get rid of that in compiler support.

> VAX Fortran also supports REAL*16 and COMPLEX*32, though
> software emulated on many machines. That was from close
> to the beginning of VAX. (A microcode option on most,
> it was standard on the low end 11/730.)

You will also find it as KIND=16 on gfortran, implemented
in software as well (libquadmath).

[Dick Hendrickson]

On 4/10/22 2:46 AM, gah4 wrote:
> On Saturday, April 9, 2022 at 9:46:13 AM UTC-7, Beliavsky wrote:
>> On Saturday, April 9, 2022 at 12:16:46 PM UTC-4, gah4 wrote:
>>> As far as I know, REAL(8) is more popular, and equally standard and
>>> non-portable.
>
> (snip)
>
>>> REAL(KIND(1D0))
>
>>> would be standard, and reliably give a double precision type, though takes
>>> more characters to type.
>
>>> It is nice to have something that can be replaced, line by line, without the
>>> need for any other lines to be included. (Well, assuming appropriate
>>> continuation rules.)
>
>> If someone declares variables as real*8 they are saying that 8-byte reals are sufficient.
>> You could have a platform where singe precision is real(kind=real64) and double
>> precision is real(kind=real128). In that case the natural equivalent of real*8 would be
>> real(kind=real128) and not real(kind=kind(1.0d0)).
>
> The Cray-1 series are word addressed 64 bit machines, with a 64 bit
> floating point type. I believe Fortran supports a software emulated 128
> bit type, as required by the standard. But all the Cray machines are, as far
> as I know, in museums. (There used to be a machine that would one on
> one day a week, as that was how much power they could afford.)
>
> I don't know about Cray support for REAL*8 syntax.

Cray supported both real*4 and real*8 syntax. The syntax was easy, the
hard part was deciding what it meant. As you said, there was no
support for a 32 bit real; real*4 declared a 64 bit variable. The
hardware supported 64 bit real and software emulation did the 128 bit
real. The problem was most people used real*8 because 64 bits was
enough, not that they needed "double precision". Promoting real*8 to
twice the size of a real*4 wasn't what they wanted for performance.
Ultimately, we gave them a control card option to effectively treat
real*4 and real*8 as identical. Fortunately, the standard let us do that.

Dick Hendrickson

PS: there was one syntax issue. Things like REAL*4 HENRY initially
gave the parser fits.

[gah4]

On Sunday, April 10, 2022 at 12:59:28 AM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:

(snip)

> > It was the word addressed 60 and 64 bit machines that didn't have
> > a smaller floating point type. IBM had REAL*16 and COMPLEX*32
> > since the 360/85 and standard on all S/370 and later models.
> >
> > I am surprised it took this long to get to POWER.

> IIRC, the REAL*16 types were implemented as two doubles. POWER also
> had that (but as a pair of IEEE doubles), and a true headache it
> is proving to get rid of that in compiler support.

The IBM HFP 16 byte type has the form of two of the usual 8 byte type.
Base 16 like the others, with a 7 bit exponent. That is the form that the
360/85 implemented, and was carried on through S/370 and ESA/390.

When IBM did it, they implemented DXR, extended precision divide,
only in software emulation. Statistics said that it wasn't used all that
much, such that it wasn't worth doing in hardware. The "two doubles"
format makes the software emulation a little easier, and 112 bits
is enough.

They also wrote the emulation software for other S/360 models,
again the format makes it easier. My first hand disassembly of
a whole program was those emulators. (After I figured out
how to extract hex dumps from load module libraries.
Sometime in high school years, if you are counting.)

Also, the 16 byte values are stored in a pair of floating
point registers. S/360 only has four such registers, so
only two pairs. Later, ESA/390 added more registers.

Also, late in the ESA/390 years, so maybe 1995 or so, they finally
added DXR to hardware. Maybe about the time that IEEE binary
floating point was added, including a 16 byte form.

[Ron Shepard]

On 4/10/22 2:34 AM, gah4 wrote:
> Note, though, that the DEC compilers for the 36 bit PDP-10
> recognize REAL*8 for the 72 bit double precision. I am not sure
> about the CDC and Cray compilers. It isn't required that the *8
> represent 8 bytes of any specific size. (The PDP-10 byte
> instructions work on bytes from 1 to 36 bits. C compilers
> tend to use 9 bits for char. C requires char to be an integer
> fraction of the word (int) size.)

I remember using these machines in the late 1970s. My memory might be
off, but I remember being able to use REAL*4 (mapped to 36-bit single
precision) and REAL*8 (mapped to 72-bit double precision). This was
before the CHARACTER type was available, but Hollerith characters could
be stored in integer, real, double precision, or logical variables, or
even used in literal constants pretty freely. They were 7-bit ascii
characters, up to 5 per word (so one bit per word could be used by the
programmer for something else, if necessary). I never used an f77
compiler on those machines, but I think they did exist later on. I never
used C on those machines, so I do not know about its 9-bit characters,
but that would have been incompatible with both the fortran convention
and with all of the other uses of characters in the operating system
(file names, interactive shells, text editors, etc.).

I think gfortan even now has options that treat real*8 declarations as
single precision and real*16 as double precision. I don't use these, but
I think integer and logical kinds are all promoted too, so everything
works the way it should according to the standard storage sequence
requirements. There are, of course, incompatibilities with external
libraries such as BLAS and LAPACK that, in their naming convention,
continue to treat 4-byte integers and reals as single precision.

I also remember when CRAY started using byte-addressable CPUs (i.e. MIPS
and AMD chips). They tried to include options that would facilitate
porting from their earlier 64-bit word machines, but it was easy to make
mistakes with, for example, integer and real storage sequence
associations in common blocks.

$.02 -Ron Shepard

[Ron Shepard]

On 4/10/22 2:44 AM, Thomas Koenig wrote:
>> real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, 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.
> They are what I usually use. In most of my projects, I have a small
> module
>
> module prec
> implicit none
> integer, parameter :: sp = selected_real_kind(6)
> integer, parameter :: dp = selected_real_kind(15)
> integer, parameter :: qp = selected_real_kind(30)
> end module prec

Just to include this possibility into the mix, there is also

real*8, private :: temp
integer, parameter :: wp=kind(temp)

The rest of the code should use the "wp" parameter of course, in
declarations and in literal constants, but in that one module, it isn't
so bad to use real*8 in that one place. Once it is localized like this,
it isn't even so bad to hardwire the kind number.

integer, parameter :: wp=8

The big porting problems arise when the "8" is scattered throughout the
source code.

$.02 -Ron Shepard

[jfh]

On Sunday, April 10, 2022 at 7:44:59 PM UTC+12, Thomas Koenig wrote:
> JCampbell <campbel...@gmail.com> schrieb:
> > real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, 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.
> They are what I usually use. In most of my projects, I have a small
> module
>
> module prec
> implicit none
> integer, parameter :: sp = selected_real_kind(6)
> integer, parameter :: dp = selected_real_kind(15)
> integer, parameter :: qp = selected_real_kind(30)
> end module prec
> > I use multiple compilers, which have different kind values. Real*8 works easily for me on all compilers I use, while real(kind=dp) has the problem of which compiler last compiled the module where DP was defined.

In one of my projects where I test programs with lower precision to save run time but finish up using the highest I use a little module like this:

module myprec
integer, parameter :: prec(4) = [6,15,18,33]
integer, parameter :: wp = selected_real_kind(prec(2))
end module myprec

when I want what gfortran and ifort call double precision. Changing the desired precision requires changing only the 2 into 1, 3 or 4, and no change is needed in a program that uses that module.

That works well with gfortran but when compiling with ifort I must remember that asking for prec(3) is the same as asking for prec(4).

[JCampbell]

I am not sure I would agree that real*10 works well with gfortran, especially considering the memory storage approach.
I do miss the precision of 8087 real*10, especially for loop accumulators, but the improved performance of real*8 SIMD : MMX, SSE and AVX is a must.
I have felt cheated by the alignment issues with SSE and AVX, which should have always been solved by the hardware and not left for programmers to try and fix with messy memory address calculations.
Rather than 8, 16 or 32 byte compiler alignment options for arrays, why is there not a 4096 byte (memory page) alignment, which "might" be useful for multi-threading for heap ALLOCATE arrays ?

[Robin Vowels]

On Monday, April 11, 2022 at 3:48:14 AM UTC+10, Ron Shepard wrote:
> On 4/10/22 2:44 AM, Thomas Koenig wrote:
> >> real(dp) or real(kind=dp) is not clear, as you need to search for the definition of dp, 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.
> > They are what I usually use. In most of my projects, I have a small
> > module
> >
> > module prec
> > implicit none
> > integer, parameter :: sp = selected_real_kind(6)
> > integer, parameter :: dp = selected_real_kind(15)
> > integer, parameter :: qp = selected_real_kind(30)
> > end module prec
> Just to include this possibility into the mix, there is also
>
> real*8, private :: temp

.
It REALly isn't standard, is it !!
.

[Robin Vowels]

.
In small test programs, REAL and DOUBLE PRECISION are clear,
and can be written quickly.

[Robin Vowels]

.
Indeed !!!

[Robin Vowels]

.
Can we not write in English? REAL (KIND=DP) :: x
.

[Robin Vowels]

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?

[steve kargl]

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

[Ron Shepard]

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

[steve kargl]

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

[John Collins]

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.

[gah4]

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.

[steve kargl]

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

[Phillip Helbig (undress to reply)]

In article <t34lac$utb$1...@dont-email.me>, steve kargl

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

[gah4]

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.

[Ron Shepard]

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

[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

[Robin Vowels]

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

[Robin Vowels]

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

[Robin Vowels]

.
How long would it take to write a program to read in a Fortran
program and change REAL(8) to REAL(dp) ?

[Robin Vowels]

On Wednesday, April 13, 2022 at 5:52:47 AM UTC+10, steve kargl wrote:

.
How many machines are you using that offer 64 bit words for single precision?

[gah4]

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?

[Robin Vowels]

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.

[Ron Shepard]

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

[steve kargl]

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

[John Collins]

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.

[gah4]

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

[gah4]

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.

[FortranFan]

On Wednesday, April 13, 2022 at 2:41:22 PM UTC-4, john.c...@simconglobal.com wrote:

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

REAL*8 comes with considerable confusion given the current state of nonstandard compiler implementations and it is not going to make it into the ISO IEC standard for Fortran.

A "simple, unambiguous declaration" can be as suggested upthread i.e., IEEE_FPB64 where

IEEE_FPB64 is an intrinsic (built-in) alias for REAL(KIND=K) where K = IEEE_SELECTED_REAL_KIND( P=15, R=307, RADIX=2 )

Here IEEE_FPB64 is something a Fortran processor supporting IEEE_ARITHMETIC introduced Fortran 2003 must support intrinsically, meaning there will be no need for any USE statements.

The introduction of IEEE_FPB64 can meet almost all the needs given the >9X.Y% (X, Y likely >8) of computing that is now done using IEEE floating-point arithmetic toward the binary64 format in the IEEE 60559:2011 standard.

Note: the Fortran standard can also introduce IEEE_FPB32, IEEE_FPB128, IEEE_FPB256 for completeness to introduce intrinsic support for binart32, binary128, and binary256 formats from the IEEE 60559:2011 i.e., those that are colloquially understood to be single, quadruple, and octuple precision formats respectively. Additionally the standard can also introduce IEEE_FPD32, IEEE_FPD64, IEEE_FPD128 for the decimal formats since the IEEE_SELECTED_REAL_KIND also permits RADIX argument. The latter may not be supported by any real processor for a long, long time but it will be there for comprehensiveness.

Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".

[gah4]

On Wednesday, April 13, 2022 at 6:16:51 PM UTC-7, FortranFan wrote:

(snip)

> A "simple, unambiguous declaration" can be as suggested upthread i.e., IEEE_FPB64 where

> IEEE_FPB64 is an intrinsic (built-in) alias for REAL(KIND=K) where
> K = IEEE_SELECTED_REAL_KIND( P=15, R=307, RADIX=2 )

I didn't know about that one.

> Here IEEE_FPB64 is something a Fortran processor supporting
> IEEE_ARITHMETIC introduced Fortran 2003 must support intrinsically,
> meaning there will be no need for any USE statements.

It is still longer than REAL*8, so string substitution is a little complicated.

> The introduction of IEEE_FPB64 can meet almost all the needs given
> the >9X.Y% (X, Y likely >8) of computing that is now done using IEEE
> floating-point arithmetic toward the binary64 format in the
> IEEE 60559:2011 standard.

> Note: the Fortran standard can also introduce IEEE_FPB32, IEEE_FPB128,
> IEEE_FPB256 for completeness to introduce intrinsic support for binart32,
> binary128, and binary256 formats from the IEEE 60559:2011 i.e.,
> those that are colloquially understood to be single, quadruple, and octuple
> precision formats respectively. Additionally the standard can also introduce
> IEEE_FPD32, IEEE_FPD64, IEEE_FPD128 for the decimal formats since the
> IEEE_SELECTED_REAL_KIND also permits RADIX argument.
> The latter may not be supported by any real processor for a long,
> long time but it will be there for comprehensiveness.

IBM is selling hardware that supports it, but I don't know which compilers do.

> Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".

OK, but you really should have one that allows for either IEEE binary64 or decimal64.

Given the above, it should be IEEE_FP64.

As I noted earlier, in the case if IEEE decimal, 64 is single precision and 128
is double precision. And all that without Cray!

[Robin Vowels]

On Thursday, April 14, 2022 at 4:41:22 AM UTC+10, 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.

.
That can be added trivially on the same statement as the first REAL X (DP) :: ....
in a procedure, or all of them after the first statement of the procedure.
e.g., INTEGER, PARAMETER :: dp = KIND(1.0d0) ; REAL (dp) :: ...

.
> Inserting an INCLUDE file or USE statement into every Fortran sub-program is
> much more work than a 1-line sed script.

.
Try doing it in Fortran. Even inserting a line is trivial. Let it be USE

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

.
What a mess.

[Robin Vowels]

.
That's gobbledegook.
English words are better, such as REAL, etc.

[FortranFan]

On Wednesday, April 13, 2022 at 11:04:02 PM UTC-4, Robin Vowels wrote:

> On Thursday, April 14, 2022 at 11:16:51 AM UTC+10, FortranFan wrote:
> On Wednesday, April 13, 2022 at 2:41:22 PM UTC-4, john.c...@simconglobal.com wrote:
>
> > .. I think a simple, unambiguous declaration

>..

> > Refactoring, when needed, of "REAL*8" codes would be a simple string replacement to "IEEE_FPB64".
> .
> That's gobbledegook.
> English words are better, such as REAL, etc.

@Robin Vowels, re: your comments "That's gobbledegook," and "English words are better" no, you're absolutely wrong on both fronts.

"English words" in far too many situations absolutely fail to convey a "simple, unambiguous" declaration. The topic of this thread with REAL*8 is one such.

About the only thing that can work to achieve a "simple, unambiguous" to address the REAL*8 is an acronym that is also a mnemonic which is exactly what is IEEE_FPB64.

[pehache]

Le 09/04/2022 à 16:05, Beliavsky a écrit :
> 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?

It could make sense, except that xxxx*n notations have never been
standardized

As noted by other contributors :
- both REAL*4 and REAL*8 were mapped to the 64 bits floating point type
on old CRAY computers
- REAL*4 was mapped to the 36 bits floating point on CDC, and REAL*8 to
72 bits.

So mapping REAL*4 to kind=real32 could break some legacy codes, as it
seems to me that kind=real32 is *required* to be stored on exactly 32 bits.

I have to admit that 36 bits machines are unlikely to show up again (but
how knows...), but compilers that would completely drop 32 flating point
support are not that unlikely in the future.

--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine
ST passe le mur du çon : <j3nn2h...@mid.individual.net>

[pehache]

Le 09/04/2022 à 16:55, Robin Vowels a écrit :
> On Sunday, April 10, 2022 at 12:37:41 AM UTC+10, Beliavsky wrote:

>> On Saturday, April 9, 2022 at 10:05:29 AM UTC-4, 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?

>> Currently, if someone inherits a code with real*8 and decides to make it standard-conforming, they may replace it with
>> real(kind=8),
> .
> An appropriate replacement is real (kind=dp)
> (where dp is defined as kind(1.0d0)...)

If it was, the developers would have used DOUBLE PRECISION from the
begining, and not REAL*8

[pehache]

Yep. And REAL*8 was by far the simplest way to have code running
efficiently on both these supercomputers and the unix workstations, when
~64bits precision was needed

[gah4]

On Friday, June 17, 2022 at 3:02:31 PM UTC-7, pehache wrote:

(snip)

> Yep. And REAL*8 was by far the simplest way to have code running
> efficiently on both these supercomputers and the unix workstations, when
> ~64bits precision was needed

It seems, though, that REAL(8) is now very popular, and even taught in
some scientific computing courses. However, KIND values are not
standardized at all, and so that is less reasonable than REAL*8.

In the days of punched cards, less typing was important, though
the shift needed for the * made it slightly harder.

[pehache]

Le 09/04/2022 à 19:15, Ron Shepard a écrit :

> 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.
>
> Numerical analysts are now experimenting with 16-bit real arithmetic to
> speed up critical parts of algorithms. If/when they get that working,
> the fortran KIND system is already set up to handle that. IEEE decimal
> arithmetic is another feature raising its head on the horizon. Again,
> the fortran KIND system is already there and waiting. 10-byte arithmetic
> is another example (although some compilers are currently doing this the
> wrong way, I think). 128-bit arithmetic and beyond, both reals and
> integers, are all handled perfectly well with the fortran KIND system.
>
> If a compiler supports real types with those numbers of bits (real32,
> real64, etc.), then the kind values are set appropriately. If there is
> more than one kind with that many bits, then the processor chooses which
> one to return. If the processor does not support a kind with exactly
> those bits, then the processor sets the value to either -1 or -2. The -2
> value means that some kind is available with higher precision. This
> might not be the best way to write portable code, but if you want to
> write code targeted to specific floating point formats, that is a
> reasonable way to do it. The IEEE intrinsic module goes even further if
> code is intended to target that floating point format, rounding modes,
> NaN, subnormals, etc., all available within the fortran KIND system.
> This is all in contrast to REAL*4, REAL*8, etc, which are mapped in a
> very loose manner to the underlying supported floating point formats.
>
> I think the fortran KIND system is well thought out and it works well in
> practice.

And yet, it still lacks something as simple as REAL*8, which would
select either the default REAL or the DOUBLE PRECISION, and nothing else.

kind=real64 is almost that, except that:
- it may not exist
- nothing garantees that real64 is kind(1.0) or kind(1.0d0)

OK, as of today there's probably no compiler where real64 does not exist
(or does exist but is inefficient). Nevertheless it can happen one day
or another...

I used to write:

integer, parameter :: sp = kind(1.0)
integer, parameter :: dp = kind(1.0d0)
integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)

so REAL(kind=double) is similar to the C "double", which is only
required to have at least 10 digits precision, and which can be
identical to "float". And most importantly it is always, and will always
be, defined.

kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.

[Lynn McGuire]

On 6/17/2022 4:27 PM, pehache wrote:
> Le 09/04/2022 à 16:05, Beliavsky a écrit :
>> 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?
>
> It could make sense, except that xxxx*n notations have never been
> standardized
>
> As noted by other contributors :
> - both REAL*4 and REAL*8 were mapped to the 64 bits floating point type
> on old CRAY computers
> - REAL*4 was mapped to the 36 bits floating point on CDC, and REAL*8 to
> 72 bits.
>
> So mapping REAL*4 to kind=real32 could break some legacy codes, as it
> seems to me that kind=real32 is *required* to be stored on exactly 32 bits.
>
> I have to admit that 36 bits machines are unlikely to show up again (but
> how knows...), but compilers that would completely drop 32 flating point
> support are not that unlikely in the future.

The CDC 7600 that I programmed on back in the 1970s was 60 bit words.
REAL*4 was mapped to the 60 bit word.

The UNIVAC 1108 was 36 bit words back in the 1970s. REAL*4 was mapped
to the 36 bit word.

Lynn

[gah4]

On Friday, June 17, 2022 at 4:58:32 PM UTC-7, Lynn McGuire wrote:

(snip)

> The CDC 7600 that I programmed on back in the 1970s was 60 bit words.
> REAL*4 was mapped to the 60 bit word.

> The UNIVAC 1108 was 36 bit words back in the 1970s. REAL*4 was mapped
> to the 36 bit word.

I am not sure about REAL*4 and the PDP-10's 36 bit word, but I do
remember that REAL*8 got the double precision 72 bit word.
(Actually, there are two PDP-10 double precisions, one for the machines
without double precision hardware that do it in software, the other
for ones with the hardware.

[Robin Vowels]

.
DOUBLE PRECISION was clear and unequivocal (and STANDARD).

[Robin Vowels]

.
Are you not overlooking the fact that you can have a single statement
in an entire program of hundreds of functions and subroutines
that sets the precision required? And which can be changed to set the
precision required? -- and it saves considerably more typing than what you propose.

> kind=real64 is almost that, except that:
> - it may not exist
> - nothing garantees that real64 is kind(1.0) or kind(1.0d0)
>
> OK, as of today there's probably no compiler where real64 does not exist
> (or does exist but is inefficient). Nevertheless it can happen one day
> or another...
>
> I used to write:
>
> integer, parameter :: sp = kind(1.0)
> integer, parameter :: dp = kind(1.0d0)
> integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
> integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)

.
This last line won't work in some compilers.
.

[pehache]

Le 18/06/2022 à 04:10, Robin Vowels a écrit :

>>>
>>> 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.
>>
>> Yep. And REAL*8 was by far the simplest way to have code running
>> efficiently on both these supercomputers and the unix workstations, when
>> ~64bits precision was needed
> .
> DOUBLE PRECISION was clear and unequivocal (and STANDARD).

And a full waste of resources (both CPU time and memory) on a Cray, as
it was 128 bits software emulated.

When you were lucky enough to have access to such machines back then, it
was a crime to use DOUBLE PRECISION where REAL was enough.

[pehache]

Le 18/06/2022 à 04:21, Robin Vowels a écrit :
>>
>> I used to write:
>>
>> integer, parameter :: sp = kind(1.0)
>> integer, parameter :: dp = kind(1.0d0)
>> integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
>> integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
> .
> This last line won't work in some compilers.
> .

Isn't it a constant expression ?

[Robin Vowels]

On Saturday, June 18, 2022 at 3:30:07 PM UTC+10, pehache wrote:
> Le 18/06/2022 à 04:10, Robin Vowels a écrit :
>
> >>>
> >>> 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.
> >>
> >> Yep. And REAL*8 was by far the simplest way to have code running
> >> efficiently on both these supercomputers and the unix workstations, when
> >> ~64bits precision was needed
> > .
> > DOUBLE PRECISION was clear and unequivocal (and STANDARD).
> And a full waste of resources (both CPU time and memory) on a Cray, as
> it was 128 bits software emulated.
>
> When you were lucky enough to have access to such machines back then, it
> was a crime to use DOUBLE PRECISION where REAL was enough.

.
In that case, you used REAL.

[pehache]

Le 18/06/2022 à 14:34, Robin Vowels a écrit :

>>> .
>>> DOUBLE PRECISION was clear and unequivocal (and STANDARD).
>> And a full waste of resources (both CPU time and memory) on a Cray, as
>> it was 128 bits software emulated.
>>
>> When you were lucky enough to have access to such machines back then, it
>> was a crime to use DOUBLE PRECISION where REAL was enough.
> .
> In that case, you used REAL.

You forgot what I wrote in a previous message: "...code running
efficiently on both these supercomputers and the unix workstations..."

People who had access to a Cray at the times also had classical unix
workstations, with compilers defaulting REAL to 32 bits as usual. Many
codes had to run on both machines.

[pehache]

Le 18/06/2022 à 00:55, pehache a écrit :
>
> And yet, it still lacks something as simple as REAL*8, which would
> select either the default REAL or the DOUBLE PRECISION, and nothing else.
>
> kind=real64 is almost that, except that:
> - it may not exist
> - nothing garantees that real64 is kind(1.0) or kind(1.0d0)
>
> OK, as of today there's probably no compiler where real64 does not exist
> (or does exist but is inefficient). Nevertheless it can happen one day
> or another...
>
> I used to write:
>
> integer, parameter :: sp = kind(1.0)
> integer, parameter :: dp = kind(1.0d0)
> integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
> integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
>
> so REAL(kind=double) is similar to the C "double", which is only
> required to have at least 10 digits precision, and which can be
> identical to "float". And most importantly it is always, and will always
> be, defined.
>
> kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.
>
>

I am just discovering the stdlib kinds module... REAL(kind=dp) might be
the quasi-standard substitute for REAL*8. If I understand correctly "dp"
is just an alias to "c_double" in ISO_BIND_C. Good point : it is always
defined.

[pehache]

Le 18/06/2022 à 21:38, pehache a écrit :
> Le 18/06/2022 à 00:55, pehache a écrit :
>>
>> And yet, it still lacks something as simple as REAL*8, which would
>> select either the default REAL or the DOUBLE PRECISION, and nothing else.
>>
>> kind=real64 is almost that, except that:
>> - it may not exist
>> - nothing garantees that real64 is kind(1.0) or kind(1.0d0)
>>
>> OK, as of today there's probably no compiler where real64 does not
>> exist (or does exist but is inefficient). Nevertheless it can happen
>> one day or another...
>>
>> I used to write:
>>
>> integer, parameter :: sp = kind(1.0)
>> integer, parameter :: dp = kind(1.0d0)
>> integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
>> integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
>>
>> so REAL(kind=double) is similar to the C "double", which is only
>> required to have at least 10 digits precision, and which can be
>> identical to "float". And most importantly it is always, and will
>> always be, defined.
>>
>> kind=sp, kind=dp, and kind=double, cover 99.99% of the needs.
>>
>>
>
> I am just discovering the stdlib kinds module... REAL(kind=dp) might be
> the quasi-standard substitute for REAL*8. If I understand correctly "dp"
> is just an alias to "c_double" in ISO_BIND_C. Good point : it is always
> defined.
>

https://stdlib.fortran-lang.org/page/specs/stdlib_kinds.html

[Phillip Helbig (undress to reply)]

> >> integer, parameter :: sp = kind(1.0)
> >> integer, parameter :: dp = kind(1.0d0)

In such cases, why not just write REAL and DOUBLE PRECISION? The
results will be exactly the same.

If you are going to use KIND, then don't call it something like sp or dp
which is confusing if you change the definition (sort of the point of
KIND); if you won't ever change it, just use REAL and DOUBLE PRECISION:
completely clear, completely standard.

[gah4]

Well, some then define wp, working precision, which is either sp or dp.
So you only have to change one place.

But in the days before KIND, it was also somewhat common to have
different sets of constants for different machines. There might at
least be an EPSILON, but sometimes whole polynomial approximations
that were different for different machines.

They would then have comments for the ones you weren't using.

One trick from the card days was a C in column 80. You then reverse
the card, and to end, so the C is in column 1. Just for the ones

you don't want to use.

With computer editors, the complications are different, but usually
it isn't so hard to select the ones you want.

[jfh]

On Sunday, June 19, 2022 at 8:02:51 AM UTC+12, gah4 wrote:
>
> Well, some then define wp, working precision, which is either sp or dp.
> So you only have to change one place.

I use wp a lot but with the gfortran compiler I sometimes use selected_real(kind(prec)) where prec is any of 6,15,18,33 because the smaller ones are useful for checking the program and they run faster, but 33 is needed for high accuracy in one of my programs.

[FortranFan]

On Saturday, June 18, 2022 at 5:05:54 PM UTC-4, jfh wrote:

> .. I sometimes use selected_real(kind(prec)) where prec is any of 6,15,18,33 ..

You meant selected_real_kind(prec)?

[Lynn McGuire]

I never wrote anything on a PDP. Just the later 32 bit VMS machines.

Lynn

[jfh]

Yes. Sorry. I usually check anything I say in Fortran by compiling it but I was in a hurry this morning.

[Phillip Helbig (undress to reply)]

In article <88433631-0744-4418...@googlegroups.com>,

gah4 <ga...@u.washington.edu> writes:

> On Saturday, June 18, 2022 at 12:45:40 PM UTC-7, Phillip Helbig (undress to reply) wrote:
> > > >> integer, parameter :: sp = kind(1.0)
> > > >> integer, parameter :: dp = kind(1.0d0)
>
> > In such cases, why not just write REAL and DOUBLE PRECISION? The
> > results will be exactly the same.
>
> > If you are going to use KIND, then don't call it something like sp or dp
> > which is confusing if you change the definition (sort of the point of
> > KIND); if you won't ever change it, just use REAL and DOUBLE PRECISION:
> > completely clear, completely standard.
>
> Well, some then define wp, working precision, which is either sp or dp.
> So you only have to change one place.

That is different, and makes sense.

> One trick from the card days was a C in column 80. You then reverse
> the card, and to end, so the C is in column 1. Just for the ones
> you don't want to use.

Hadn't heard of that one. (But I started after punched cards. I know
someone only 7 years older, though, he used them extensively.)

[pehache]

Le 18/06/2022 à 21:45, Phillip Helbig (undress to reply) a écrit :
>>>> integer, parameter :: sp = kind(1.0)
>>>> integer, parameter :: dp = kind(1.0d0)
>
> In such cases, why not just write REAL and DOUBLE PRECISION?

Just to simplify the two lines that come ater and that you have cut ;)

[Ron Shepard]

On 6/17/22 5:35 PM, gah4 wrote:
[...]

> It seems, though, that REAL(8) is now very popular, and even taught in
> some scientific computing courses. However, KIND values are not
> standardized at all, and so that is less reasonable than REAL*8.

I think the real problem now with REAL(8) usage is how compiler
documentation is written. Take gfortran, as one of many examples. If you
look up any intrinsic function involving real kinds, it will use literal
(4) and (8). This is both more concise than the longer (kind(1.0))) and
(kind(1.0D0)), or (real32) and (real64), but it also documents the kind
mapping that gfortran uses. Also, if (real32) etc. were used in the
documentation, than the accompanying line with USE ISO_FORTRAN_ENV would
need to be added throughout. Otherwise, the example code would not work
when a beginner types in the code.

So when a beginner looks up the details of some feature in the
documentation, and that documentation uses hardwired KIND literals, he
is going to follow that example exactly as written. Then once he has
invested effort in writing a few thousand lines of code with literal
kind values, he isn't going to want to go back and fix them, he is
instead going to ask the standard committee to change the language to
agree with his code.

I don't know the answer to this dilemma. I don't think the fortran
documentation needs to be changed, but beginners somehow need to know
not to write code that way. It is at least an awkward situation when
learning or teaching the language.

$.02 -Ron Shepard

[Ron Shepard]

No, it was just standard. It was neither clear nor unequivocal, as
explained above, or portable in a practical sense. Ironically, REAL*8
was more portable, yet nonstandard, which is why it was so popular at
the time and why so much legacy code was written that way.

Now modern fortran has a much superior mechanism for specifying
precision that is portable, standard conforming, and open ended for
future precisions. Yet some people want to continue using the old
approaches.

$.02 -Ron Shepard

[Ron Shepard]

On 6/18/22 11:26 AM, pehache wrote:
[...]

> People who had access to a Cray at the times also had classical unix
> workstations, with compilers defaulting REAL to 32 bits as usual. Many
> codes had to run on both machines.

I think this is why CRAY computers weren't more popular than they were.
Seymore Cray focused on high-end supercomputing, and he was not
interested in the full programming infrastructure to support that
supercomputing. There were several things that would have saved the
company and that computing environment, none of which happened:

1) PC-level, workstation-level, or department-level minicomputers that
supported the CRAY instruction set.

2) Development of interactive debuggers to facilitate code development.

3) Support for cross compilers that would allow code development on
PC-level computers. It would have been great if code could have run in
simulation mode on these computers, but even having the ability to
compile the code on a local PC or workstation to see compile-time
diagnostics would have been a huge step forward.

4) Support for fortran 8x, with array operations and more or less direct
support for vector hardware. Instead, it was not until the late 1980s
and 1990s that CRAY computers even supported f77.

$.02 -Ron Shepard

[Ron Shepard]

On 6/17/22 5:55 PM, pehache wrote:
>>
>> I think the fortran KIND system is well thought out and it works well
>> in practice.
>
> And yet, it still lacks something as simple as REAL*8, which would
> select either the default REAL or the DOUBLE PRECISION, and nothing else.

The common real(wp) convention is only one character more, and it avoids
all of the problems with the literal kind value. You can write millions
of lines of code with that declaration, and the wp parameter can be
defined in a single line of code. To change precision throughout, only
that single line of code needs to be changed.

You can't make things easier than that.

Further, if for some reason there is a conflict of kinds between some
legacy code and the modern code, then you find out these problems at
compile time where they can be easily addressed. It does not require
some extensive testing and debugging at run time to find the kind
mismatches.

I do think it would be better if it were easier to incorporate legacy
code into modules. But it is hard to think of an improvement over the
fortran KIND system, for either mixed- or nonmixed precision arithmetic.

$.02 -Ron Shepard

[pehache]

Le 19/06/2022 à 17:44, Ron Shepard a écrit :
> On 6/18/22 11:26 AM, pehache wrote:
> [...]
>> People who had access to a Cray at the times also had classical unix
>> workstations, with compilers defaulting REAL to 32 bits as usual. Many
>> codes had to run on both machines.
>
> I think this is why CRAY computers weren't more popular than they were.

I think the main reason was the price :)

> Seymore Cray focused on high-end supercomputing, and he was not
> interested in the full programming infrastructure to support that
> supercomputing. There were several things that would have saved the
> company and that computing environment, none of which happened:
>
> 1) PC-level, workstation-level, or department-level minicomputers that
> supported the CRAY instruction set.
>
> 2) Development of interactive debuggers to facilitate code development.
>
> 3) Support for cross compilers that would allow code development on
> PC-level computers. It would have been great if code could have run in
> simulation mode on these computers, but even having the ability to
> compile the code on a local PC or workstation to see compile-time
> diagnostics would have been a huge step forward.
>
> 4) Support for fortran 8x, with array operations and more or less direct
> support for vector hardware. Instead, it was not until the late 1980s
> and 1990s that CRAY computers even supported f77.

I have worked a bit on Cray computers near the end of this era, in the
1990's, and I don't share this analysis.

For development, tests, small to medium volumes of calculations, we had
Sun and HP workstations. The codes were tested, debugged, etc, first on
these workstations, and didn't need a lot of additional work on the Cray
itself. Sure, an interactive debugger or a cross-compiler may have
helped a bit, but I don't remember that we had big troubles.

Early support for f90, maybe... But even in the 1990s f90 was not that
popular in high performance computing (for sometimes good, sometimes bad
reasons). The recommandation where I was working (as a PhD student) was
to stick to f77. So the lack of f90 features on the Cray was not a big
problem I guess.

Regarding workstation-level computers, I have some doubts... The
architecture was so special that it would have been quite difficult to
tranpose it to lower end machines.

[Phillip Helbig (undress to reply)]

In article <jh8mct...@mid.individual.net>, pehache
<peha...@gmail.com> writes:

> Le 18/06/2022 à 21:45, Phillip Helbig (undress to reply) a écrit :

> >>>> integer, parameter :: sp = kind(1.0)
> >>>> integer, parameter :: dp = kind(1.0d0)
> >
> > In such cases, why not just write REAL and DOUBLE PRECISION?
>
> Just to simplify the two lines that come ater and that you have cut ;)

Yes, you have a point. However, I have seen the above used standalone.

[Thomas Koenig]

Ron Shepard <nos...@nowhere.org> schrieb:

> On 6/18/22 11:26 AM, pehache wrote:
> [...]
>> People who had access to a Cray at the times also had classical unix
>> workstations, with compilers defaulting REAL to 32 bits as usual. Many
>> codes had to run on both machines.
>
> I think this is why CRAY computers weren't more popular than they were.

Crays and other mainframes were very expensive mainframes, and they
were not suitable for every task. Partial differential equations
were great, but for solving ODEs, for example, they were not
particularly fast.

> Seymore Cray focused on high-end supercomputing, and he was not
> interested in the full programming infrastructure to support that
> supercomputing. There were several things that would have saved the
> company and that computing environment, none of which happened:

Vector computers were only effective for a particular time, when
memory latency was relatively low compared to the cycle time and
you could use the vector pipes to do several operations per cycle.
They had no cache, for example.

Nowadays, you get several operations by cycle using superscalar
OoO - microarchitectures. DRAM speed has not increased as much
as cycle times, which led to the introduction of multi-level
cache hierarchies.

If your algorithms have a good cache footprint, you can also do
several operations per cycle, with very good flexibility, and this
does not count the "vectorization" (which is really a bit painful)
using SIMD registers, which can lead to a large speedup for the
right problems and right algorithms (and the right compiler magic,
which is still lacking for many cases). SIMD is an area where a
good assembler programmer can still get a factor 2,4 or 8 against
normal code.

And, of course, there's graphics cards - very hard to program,
extremely fast, often memory bound.

> 1) PC-level, workstation-level, or department-level minicomputers that
> supported the CRAY instruction set.

Once the ISA was no longer beneficial, that would have died out.

> 2) Development of interactive debuggers to facilitate code development.
>
> 3) Support for cross compilers that would allow code development on
> PC-level computers. It would have been great if code could have run in
> simulation mode on these computers, but even having the ability to
> compile the code on a local PC or workstation to see compile-time
> diagnostics would have been a huge step forward.

I did both of the above with a Fujitsu VP and a HP workstation,
later with Linux. I even wrote a short wrapper to convert END DO
to the standarf F77 form.

> 4) Support for fortran 8x, with array operations and more or less direct
> support for vector hardware. Instead, it was not until the late 1980s
> and 1990s that CRAY computers even supported f77.

Late introduction for never Fortran version, and late adoption by
vendors, has led to Fortran's lost decase (or so). Once people
had discovered the ubiquitous C language, with all its faults
(but with structs and recursion and dynamic memory management)
that particular train left its station.

[pehache]

In practice I mostly agree with you.

Still, there is something missing: how do you know the degree of hardware
support of a given kind?

Requesting and obtaining a true quadruple precision real (128 bits) is
nice, but if it is emulated maybe you would prefer (or not) an extended
precision real (80 bits) that is much faster (at the price of more
algorithmic work on your side).

Also imagine a future machine where the hardware floating point model
would not be IEEE (because the vendor has found another representation
that is simpler to implement, or that allows higher performances, or
whatever), but with a compiler that also provides emulated IEEE kinds for
compatibility purposes. Then selected_real_kind() may return an emulated
kind even for usual precisions...

Also in theory the result of selected_real_kind() could be a kind that is
neither REAL nor DOUBLE PRECISION. But if your code is calling libraries
such as BLAS/LAPACK, you really want only one of these two...

What I mean here is that in practice, the usage of all the kind system
rely on some assumptions about the hardware. It's OK because we have
nowadays quite standardized machines, but we tend to forget that we are
making assumptions.

[Ron Shepard]

On 6/20/22 11:06 AM, pehache wrote:
> Also in theory the result of selected_real_kind() could be a kind that
> is neither REAL nor DOUBLE PRECISION. But if your code is calling
> libraries such as BLAS/LAPACK, you really want only one of these two...

This is a shortcoming of the implementation of the BLAS and LAPACK
libraries. They were designed to support the real and double precision
provided by fortran in the 1970s and 1980s, and nothing else.

>
> What I mean here is that in practice, the usage of all the kind system
> rely on some assumptions about the hardware. It's OK because we have
> nowadays quite standardized machines, but we tend to forget that we are
> making assumptions.

I think the fortran kind system is quite open ended and well designed.
When combined with explicit interfaces, which prevent mistakes
associated with mismatched arguments, it seems hard to beat the design.
Take for example, the two 8-byte floating point representations
supported by the VAX computers in the 1980s. It was very difficult
within a program to either switch back and forth between those data
types or to have a program that allowed mixtures. Instead, you basically
compiled your code either one way or the other, and took whatever that
produced. The modern fortran kind system would have solved both of those
problems. Of course, Ken Olsen, who was CEO of DEC in the 1980s, opposed
modern fortran, so that support never happened during the VAX lifetime.

The problem I see with fortran isn't the kind system, which allows the
programmer to mix kinds within expressions with complete control, rather
it is the complications that come from the library support of those
kinds. If a compiler has, say 10 different real kinds, then it is
required to support all of the intrinsics for each of those kinds, all
the exp and log functions, all the trig functions, all the Bessel
functions, and so on, for both real and complex types. That seems like a
high hurdle. I don't know what the answer is for this. Maybe the
language should have two types of support, one just a subset for simple
operations, and the other level being the full support as it is now.

$.02 -Ron Shepard

[gah4]

On Saturday, April 9, 2022 at 7:05:29 AM UTC-7, Beliavsky wrote:
> Since compilers treat the non-standard but very common
>
> real*4, real*8, integer*4, integer*8

I just notice that there is no mention of COMPLEX*8, COMPLEX*16, and even COMPLEX*32.

Should we have those, too?

[pehache]

Le 20/06/2022 à 19:39, Ron Shepard a écrit :
> On 6/20/22 11:06 AM, pehache wrote:
>> Also in theory the result of selected_real_kind() could be a kind that
>> is neither REAL nor DOUBLE PRECISION. But if your code is calling
>> libraries such as BLAS/LAPACK, you really want only one of these two...
>
> This is a shortcoming of the implementation of the BLAS and LAPACK
> libraries. They were designed to support the real and double precision
> provided by fortran in the 1970s and 1980s, and nothing else.

Whatever, this is something that should be addressed, as legacy has
always been something to care about in Fortran.

For instance :

selected_real_kind(p,r,list) where list would be an optional array of
kinds we want to chose from

or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
the moment), which would have at leasts 10 digits precison and that
would be either kind(1.0) or kind(1.0d0)

By the way, as long as there's no full generic programming in Fortran,
writing libraries for all possible kinds that can be encountered is not
easy.

> I don't know what the answer is for this. Maybe the
> language should have two types of support, one just a subset for simple
> operations, and the other level being the full support as it is now.

Let's say that REAL and DOUBLE PRECISION must have full support, and the
rest don't have to... :)

[gah4]

On Monday, June 20, 2022 at 10:39:10 AM UTC-7, Ron Shepard wrote:

(snip)

> I think the fortran kind system is quite open ended and well designed.
> When combined with explicit interfaces, which prevent mistakes
> associated with mismatched arguments, it seems hard to beat the design.

I suppose, but it leaves out that you often don't know the kind needed.

Maybe it is more obvious for integers. They need to be big enough
for whatever you might want to count. And you might know now how
big is enough, but maybe not forever, when your program might be
used by someone else. 32 bit integers are big enough for the
size (one dimension) of a square matrix, but maybe not for the
number of elements. 16 bit integers are not big enough for
storing a US (five digit) zip code.

For floating point, very little is built to better than single
precision. (About 1mm per km, or 1s per day, or one gram
per ton.) But very often double precision intermediates
are needed to get single precision results. That is true
for many matrix algorithms, and often for numerical
derivatives.

Sometimes we know that four or five digits is good
enough, but that isn't enough reason to rewrite the
program to use that precision. (Assuming that there
is hardware to supply it.)

Most often, algorithms are written to "good enough"
precision.

You could write REAL(SELECTED_REAL_KIND(8)) when you knew
that 8 digits was enough, and that you didn't need 12 or 14.

But since 8 digit hardware is rare, might as well just use the
usual hardware precision of about 52 significant bits.

[Robin Vowels]

On Saturday, June 18, 2022 at 3:36:34 PM UTC+10, pehache wrote:
> Le 18/06/2022 à 04:21, Robin Vowels a écrit :
> >>
> >> I used to write:
> >>
> >> integer, parameter :: sp = kind(1.0)
> >> integer, parameter :: dp = kind(1.0d0)
> >> integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
> >> integer, parameter :: double = sp*sp_is_enough + dp*(1-sp_is_enough)
> > .
> > This last line won't work in some compilers.
> > .
> Isn't it a constant expression ?

.
0004) integer, parameter :: sp_is_enough = min(max(precision(sp)-9,1),0)
*** The first argument (X) to the intrinsic PRECISION must be of REAL or
COMPLEX type, not INTEGER(KIND=3)

[pehache]

Ah, yes, on the *third* line it should be "precision(1.0)" and not
"precision(sp)"

[Ron Shepard]

On 6/21/22 6:04 AM, pehache wrote:
> Le 20/06/2022 à 19:39, Ron Shepard a écrit :
>> On 6/20/22 11:06 AM, pehache wrote:
>>> Also in theory the result of selected_real_kind() could be a kind
>>> that is neither REAL nor DOUBLE PRECISION. But if your code is
>>> calling libraries such as BLAS/LAPACK, you really want only one of
>>> these two...
>>
>> This is a shortcoming of the implementation of the BLAS and LAPACK
>> libraries. They were designed to support the real and double precision
>> provided by fortran in the 1970s and 1980s, and nothing else.
>
> Whatever, this is something that should be addressed, as legacy has
> always been something to care about in Fortran.

Note that some vendors supported 128-bit floating point arithmetic even
in the 1970s and early 1980s when these libraries were first developed.
They did extend the use to double precision complex, a common extension
that was not part of standard fortran, but they did not account for any
other real or complex kinds. Now that the kind facility is available,
this could be done in a straightforward way, but that hasn't occurred in
the 30+ years since f90 has been available. I'm just guessing about
this, but I think the reason is that the source code is available, so if
some individual wanted a 128-bit floating point version of some linear
algebra code, he could do the work himself.

>
> For instance :
>
> selected_real_kind(p,r,list) where list would be an optional array of
> kinds we want to chose from
>
> or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
> the moment), which would have at leasts 10 digits precison and that
> would be either kind(1.0) or kind(1.0d0)

This is already what selected_real_kind(10) does. If there are more than
one choice, then maybe it doesn't return the one the programmer might
want, but then the other exponent and base arguments can be added to
refine the selection. In any case, this only needs to be done once in a
program, and it propagates throughout the code from that one place.

> By the way, as long as there's no full generic programming in Fortran,
> writing libraries for all possible kinds that can be encountered is not
> easy.

If a programmer wants to manually specify the kinds, then it is not too
difficult. If he wants to automate the process, and produce different
numbers of kind versions on different machines, then it is more
difficult. And then if the programmer wants to allow mixed-kind
arguments, including various combinations of integer, real, and complex
kinds, it becomes truly a difficult process.

>> I don't know what the answer is for this. Maybe the language should
>> have two types of support, one just a subset for simple operations,
>> and the other level being the full support as it is now.
>
> Let's say that REAL and DOUBLE PRECISION must have full support, and the
> rest don't have to... :)

What I meant was some simple operations (+-*/><) along with some subset
of conversions and query functions (int(), real(), cmplx(), precision(),
max_val(), min_val(), nearest(), and so on). If the compiler supported
that minimal subset of operations on a kind value, then the programmer
could go from there and do whatever else was necessary, complex log
functions or whatever, entirely within that supported subset of
operations. There would be no need to write assembler language or use
interfaces to other languages, it could all be done within fortran. An
interface to the function could extend the intrinsic functions, and from
there the programmer could access it the same way as if that kind were
supported in the language.

BTW, that kind of formalized minimal support for some KIND might also be
a way to allow unsigned integers and bit strings into the language. They
would be second class passengers in the language compared to the other
integers, but that subset would allow them to be used where they are
needed, without blowing up the rest of the language.

$.02 -Ron Shepard

[Ron Shepard]

On 6/21/22 7:35 AM, gah4 wrote:
> On Monday, June 20, 2022 at 10:39:10 AM UTC-7, Ron Shepard wrote:
>
> (snip)
>
>> I think the fortran kind system is quite open ended and well designed.
>> When combined with explicit interfaces, which prevent mistakes
>> associated with mismatched arguments, it seems hard to beat the design.
>
> I suppose, but it leaves out that you often don't know the kind needed.
>
> Maybe it is more obvious for integers. They need to be big enough
> for whatever you might want to count. And you might know now how
> big is enough, but maybe not forever, when your program might be
> used by someone else. 32 bit integers are big enough for the
> size (one dimension) of a square matrix, but maybe not for the
> number of elements. 16 bit integers are not big enough for
> storing a US (five digit) zip code.

Selected_int_kind(5) is enough to hold current zip codes, and if the
post office were to add another digit, then selected_int_kind(6) would
be sufficient. In this case, one does know the number of digits in
advance. I've used machines in the past that supported 3-byte integers,
although that was before f90 was available. That kind value can be
specified in a single place, and then propagated throughout your code,
so if the usps does add that digit, you only need to change a single
character in your source code, recompile, and you are good to go.

> For floating point, very little is built to better than single
> precision. (About 1mm per km, or 1s per day, or one gram
> per ton.) But very often double precision intermediates
> are needed to get single precision results. That is true
> for many matrix algorithms, and often for numerical
> derivatives.

Yes, but these are comments about floating point arithmetic. Sometimes
you need more mantissa bits, sometimes you need more exponent bits,
sometimes you need both.

> Sometimes we know that four or five digits is good
> enough, but that isn't enough reason to rewrite the
> program to use that precision. (Assuming that there
> is hardware to supply it.)
>
> Most often, algorithms are written to "good enough"
> precision.
>
> You could write REAL(SELECTED_REAL_KIND(8)) when you knew
> that 8 digits was enough, and that you didn't need 12 or 14.

Those machines that supported 3-byte integers also supported 6-byte
reals. That was sufficient for a lot of numerical work, but I think it
failed in a few places such as the ones you mention where extra
precision is necessary.

> But since 8 digit hardware is rare, might as well just use the
> usual hardware precision of about 52 significant bits.

Yes, this is the way floating point arithmetic is done typically. It
doesn't hurt much to use more precision than necessary, but it is
catastrophic to try to use too little precision. The exception is when
the additional precision is localized within the algorithm, such as an
extended precision accumulator, then you might see code that is written
in a more targeted and specific way. The other exception was back in the
1970s when memory was scarce. Then you might see minicomputer codes
where every integer and real declaration had a (2), (4), or (8), because
if they used integer(4) and real(8) everywhere, the program would not fit.

$.02 -Ron Shepard

[Lynn McGuire]

And logical*4 and logical*8.

Lynn

[pehache]

Le 21/06/2022 à 17:24, Ron Shepard a écrit :
> On 6/21/22 6:04 AM, pehache wrote:
>> Le 20/06/2022 à 19:39, Ron Shepard a écrit :
>>> On 6/20/22 11:06 AM, pehache wrote:
>>>> Also in theory the result of selected_real_kind() could be a kind
>>>> that is neither REAL nor DOUBLE PRECISION. But if your code is
>>>> calling libraries such as BLAS/LAPACK, you really want only one of
>>>> these two...
>>>
>>> This is a shortcoming of the implementation of the BLAS and LAPACK
>>> libraries. They were designed to support the real and double precision
>>> provided by fortran in the 1970s and 1980s, and nothing else.
>>
>> Whatever, this is something that should be addressed, as legacy has
>> always been something to care about in Fortran.
>
> Note that some vendors supported 128-bit floating point arithmetic even
> in the 1970s and early 1980s when these libraries were first developed.
> They did extend the use to double precision complex, a common extension
> that was not part of standard fortran, but they did not account for any
> other real or complex kinds. Now that the kind facility is available,
> this could be done in a straightforward way, but that hasn't occurred in
> the 30+ years since f90 has been available. I'm just guessing about
> this, but I think the reason is that the source code is available, so if
> some individual wanted a 128-bit floating point version of some linear
> algebra code, he could do the work himself.

The main reason is that there is not something like a unified hardware
support for quadruple precision. If one writes a library and wants to
provide binaries for a platform that has no hardware support for quadruple
precision, what should one do? One can compile the library with a compiler
that has a real128 kind, but without any guarantee that it will work if
the compiled library is called from a code compiled with another compiler,
as different compilers may use different interpretation of real128
(ieee-754 compliant, or as "double double", or as the x86 10 bytes
floating point padded to 16 bytes, ...).

>> For instance :
>>
>> selected_real_kind(p,r,list) where list would be an optional array of
>> kinds we want to chose from
>>
>> or a "double" kind value provided by ISO_FORTRAN_ENV (or stdlib_kind at
>> the moment), which would have at leasts 10 digits precison and that
>> would be either kind(1.0) or kind(1.0d0)
>
> This is already what selected_real_kind(10) does.

No, it does not ensure that the result is necessarily kind(1.0) or
kind(1.0d0)

> If there are more than
> one choice, then maybe it doesn't return the one the programmer might
> want, but then the other exponent and base arguments can be added to
> refine the selection.

If the programmer knows what specific kind he wants beforehand, there's
simply no reason at all to use selected_real_kind()

It's like:
- "From now I want you to recruit from anonymous CVs"
- "OK, but really I'd like to hire this guy at the end"
- "No problem, just write job requirements that exactly correspond to his
skills"

:)

[Robin Vowels]

The point of using the kind system is that you don't need to know in advance
what kinds are available. SELECTED_REAL_KIND helps to do that.

[gah4]

On Thursday, June 23, 2022 at 3:55:32 AM UTC-7, pehache wrote:

(snip)

> No, it does not ensure that the result is necessarily kind(1.0) or
> kind(1.0d0)

Yes. But the big assumption with SELECTED_REAL_KIND is
that you know how many digits you need. In numerical
algorithms, that is fairly rare. With most matrix routines,
there is precision loss with subtraction, but you never
known when, where, or how much.

If you are lucky enough to know how many digits you
need in the end, you still don't know how much for
intermediate calculations.

The result is that, most of the time, you have to
assume kind(1.0) and kind(1.d0).

IBM has consistently supplied REAL*16 with the 360/85
and all 370 and successors. VAX has H_FLOAT, but
it might be in software emulation.

(Actually, for a long time IBM did DXR, that is,
extended precision divide, in software emulation,
even when the hardware had the rest. They did
a study to show that was good enough, enough
of the time. But then later, late ESA/390 days,
added it.)

[Quadibloc]

On Monday, April 11, 2022 at 3:21:33 AM UTC-6, Robin Vowels wrote:
> On Sunday, April 10, 2022 at 3:35:25 PM UTC+10, JCampbell wrote:

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

My quarrel with it is that it is redundant. DOUBLE PRECISION is already
in existence in the language; the syntax real(...) is for when you want to
specify by length instead.

John Savard

[Quadibloc]

On Tuesday, April 12, 2022 at 10:17:23 AM UTC-6, steve kargl wrote:
> Ron Shepard wrote:

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

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

If people avoid using Intel's temporary real format because it wastes space,
they would do so regardless of whether it's the compiler or the hardware that
is to blame, so I don't see how the fact that they're avoiding it means that they're
blaming the compiler.

John Savard