On Sunday, June 19, 2022 at 11:27:51 AM UTC+12, FortranFan wrote:
> 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)?
Yes. Sorry. I usually check anything I say in Fortran by compiling it but I was in a hurry this morning.

In article <88433631-0744-4418-b371-90bd0a4b463bn@googlegroups.com>,
gah4 <gah4@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.)

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

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

On 6/17/22 9:10 PM, Robin Vowels wrote:
> 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).

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

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

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

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.

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

In article <jh8mctFn6e2U1@mid.individual.net>, pehache
<pehache.7@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.

Ron Shepard <nospam@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.

Le 19/06/2022 à 18:00, Ron Shepard a écrit :
> 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.

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.

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

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?

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

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

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)

Le 21/06/2022 à 15:07, Robin Vowels a écrit :
> 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)

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

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

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

On 6/20/2022 8:57 PM, gah4 wrote:
> 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?

And logical*4 and logical*8.

Lynn

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"

:)

On Thursday, June 23, 2022 at 8:55:32 PM UTC+10, pehache wrote:
> 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()

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.

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

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

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