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

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!

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.

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 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".
..
That's gobbledegook.
English words are better, such as REAL, etc.

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.

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

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

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

Le 13/04/2022 à 17:10, Ron Shepard a écrit :
> 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.

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

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

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.

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.

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

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

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.

On Saturday, June 18, 2022 at 8:02:31 AM UTC+10, pehache wrote:
> Le 13/04/2022 à 17:10, Ron Shepard a écrit :
> > 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.
> 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).

On Saturday, June 18, 2022 at 8:55:30 AM UTC+10, pehache wrote:
> 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.
..
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.
..
> 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.

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.

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

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 ?

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

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.

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.

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

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.

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

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

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

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

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.

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.

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.

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

On 6/17/2022 7:31 PM, gah4 wrote:
> 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.

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

Lynn