On Wednesday, April 13, 2022 at 12:41:22 PM UTC-6, john.c...@simconglobal.com wrote:
> To that end REAL*8 is the best we have got, it works everywhere (at least that I know of)
> and doesn't need to be in the standard if everyone understands it.

On the FORTRAN compiler for the IBM System/360, IBM added length specifications as
an extension to the standard. It allowed them to define COMPLEX*16, since DOUBLE
COMPLEX was not yet part of the standard at the time. And it allowed them to define
LOGICAL*1 in addition to LOGICAL*4 (the default), and INTEGER*2 in addition to
INTEGER*4.

This extension served a purpose in its day. But it was not intended to be _portable_.

So on a machine with addressable 6-bit characters, REAL might be REAL*6 or REAL*8,
and DOUBLE PRECISION might be REAL*12 or REAL*16. Or even REAL*10.

Of course, these days, byte addressing and power-of-two word sizes are nigh universal.

John Savard

On Sunday, June 19, 2022 at 3:15:52 PM UTC-6, pehache wrote:

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

And that is history repeating itself. IBM's FORTRAN II compiler for the 7090
had the same excellent optimization as the original FORTRAN for the 704,
but when IBM brought in a FORTRAN IV compiler, it wasn't optimized. So
people had to use FORTRAN II for serious work.

John Savard

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

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

Generally speaking, though, that isn't a problem one encounters in
real life. FORTRAN compilers would allow use of those hardware floating-point
types that are relevant to the kinds of computation FORTRAN is for.

The kind system deals with another problem: since some machines
might have 32-bit single precision, and 64-bit double precision, and others
might have 64-bit single precision and 128-bit double precision, a way is
provided to use the 64-bit reals on both kinds of machine by specifying that
one wants at least 15 (or even 12) decimal digits of precision.

John Savard

On Thursday, June 23, 2022 at 11:57:22 AM UTC-7, Quadibloc wrote:

(snip)

> The kind system deals with another problem: since some machines
> might have 32-bit single precision, and 64-bit double precision, and others
> might have 64-bit single precision and 128-bit double precision, a way is
> provided to use the 64-bit reals on both kinds of machine by specifying that
> one wants at least 15 (or even 12) decimal digits of precision.

Most of those are now in museums, running or not.

It looks to me, though, that IEEE 754 decimal floating point considers
the 64 bit form single precision, and the 128 bit as double precision.

There are 16 bit binary, 256 bit binary, and 32 bit decimal forms that
are called "not-basic".

It looks to me that Fortran compilers implementing it would use
the 64 bit and 128 bit formats for REAL and DOUBLE PRECISION.

We will have to see when those compilers come out.

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> 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.

Not with all compilers (nagfor being one example).

On Friday, June 24, 2022 at 6:15:44 AM UTC+12, Quadibloc wrote:
> On Wednesday, April 13, 2022 at 12:41:22 PM UTC-6, john.c...@simconglobal..com wrote:
> > To that end REAL*8 is the best we have got, it works everywhere (at least that I know of)
> > and doesn't need to be in the standard if everyone understands it.
>
> On the FORTRAN compiler for the IBM System/360, IBM added length specifications as
> an extension to the standard. It allowed them to define COMPLEX*16, since DOUBLE
> COMPLEX was not yet part of the standard at the time. And it allowed them to define
> LOGICAL*1 in addition to LOGICAL*4 (the default), and INTEGER*2 in addition to
> INTEGER*4.
>
> This extension served a purpose in its day. But it was not intended to be _portable_.
>
> So on a machine with addressable 6-bit characters, REAL might be REAL*6 or REAL*8,
> and DOUBLE PRECISION might be REAL*12 or REAL*16. Or even REAL*10.
>
> Of course, these days, byte addressing and power-of-two word sizes are nigh universal.
>
> John Savard

DOUBLE COMPLEX was not standard f77 and is not standard f18. Last time I looked at NAG Fortran it did not use 4 and 8 for single and double precision unless one asked for a particular compiling option. When I don't know in advance what precision a given calculation will need I try all four of wp=selected_real_kind(n) where n is 6,15,18 or 33. That works well with gfortran but ifort treats 18 as if it were 33 because that compiler offers only three real kinds. I no longer have access to NAG because my university's systems people thought not enough people were using it to justify the cost.

Le 23/06/2022 à 14:21, Robin Vowels a écrit :

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

I get that, and that's not my point.

--
"...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 : <j3nn2hFmqj7U1@mid.individual.net>