REAL(8)

[herrman...@gmail.com]

Continuing from another thread, but I believe this one can have its own,

why would anyone use the non-portable REAL(8) when they could
use the nice and portable REAL(SELECTED_REAL_KIND(12)) instead?

Or maybe REAL(KIND(1.D0)) instead?

Is it really so hard to type four or two times as much?

I do remember in the Fortran 66 days, wondering why
EQUIVALENCE was so long, especially since you can't easily
correct keypunch mistakes. But I did get used to that one.

[Phillip Helbig (undress to reply)]

In article <060177e7-7864-41a7...@googlegroups.com>,

herrman...@gmail.com writes:

> Continuing from another thread, but I believe this one can have its own,
>
> why would anyone use the non-portable REAL(8) when they could
> use the nice and portable REAL(SELECTED_REAL_KIND(12)) instead?

I'm sure that there are several reasons.

> Or maybe REAL(KIND(1.D0)) instead?

Note that this is essentially always the same as REAL(8) or REAL*8 and
also the same as the standard DOUBLE PRECISION.

The KINDs make sense when you specify the precision once, when defining
a shorthand for the type, then use this shorthand in the definition.
Then you can change the precision by changing ONLY the definition of the
shorthand.

Doing stuff like

INTEGER, PARAMETER :: I4B = SELECTED_INT_KIND(9)
INTEGER, PARAMETER :: I2B = SELECTED_INT_KIND(4)
INTEGER, PARAMETER :: I1B = SELECTED_INT_KIND(2)
INTEGER, PARAMETER :: SP = KIND(1.0)
INTEGER, PARAMETER :: DP = KIND(1.0D0)
INTEGER, PARAMETER :: SPC = KIND((1.0,1.0))
INTEGER, PARAMETER :: DPC = KIND((1.0D0,1.0D0))

is confusing, though, if the definition is ever changed. If I am sure
that I will always use KIND(1.0D0) in a particular context, the standard
DOUBLE PRECISION is clearer.

> Is it really so hard to type four or two times as much?

I doubt that is the reason.

[Gary Scott]

I don't hard code the kind numbers, but I'm almost always intimately
concerned with the length of nearly all variables in terms of the size
they take up on disk when written in binary/stream form. I have to
define record structures in great low level detail so that they can be
communicated to other applications in the most efficient form I can
define. Few of my applications are exclusively algorithmicly oriented,
they are instead database applications with extensive GUIs and
communciation with other processes/threads, other servers. It would be
extremely rare for me to NOT care about that.

[Jos Bergervoet]

Indeed, because the two can be equally short:
real(d) :: x
real(8) :: y
where of course you need to have somewhere the definition
of the parameter:
integer, parameter :: d = kind(1d0)

Admittedly the use of real*8 is still one keystroke shorter,
but the question was about real(8).

I have never used real(8) in a program and I would never
trust it. When this syntax was introduced in the language (in
Fortran90) the clear warning was always added that there was
no guarantee about the meaning of the numbers. So I consider
it simply an error to use a specific number (8) and expect
it to have the meaning kind(1d0).

That would be as naive as not initializing a variable 'pi'
and *still* expecting it to have the value acos(-1d0), just
because of its name..

So, like OP, I can't understand why anyone would do it.

--
Jos

[Thomas Koenig]

Jos Bergervoet <jos.ber...@xs4all.nl> schrieb:

> That would be as naive as not initializing a variable 'pi'
> and *still* expecting it to have the value acos(-1d0), just
> because of its name..

There is a Richard Maine quote for that:

# The compiler does not change its operation to conform to the
# meanings implied by your variable names.

[herrman...@gmail.com]

(snip)

> > That would be as naive as not initializing a variable 'pi'
> > and *still* expecting it to have the value acos(-1d0), just
> > because of its name..

> There is a Richard Maine quote for that:

> # The compiler does not change its operation to conform to the
> # meanings implied by your variable names.

There are some languages that have predefined variables
with useful values. I believe one version of BASIC has P1
predefined with pi.

Python has math.pi

As far as I can tell, Matlab and Octave have pi as a
zero argument function, so you can:

x=pi

and not know that it is a function, not a variable.

I am not sure about i, j, and I, though.

[Clive Page]

Except that it does if you omit IMPLICIT NONE and your variable names start with letters I through N rather than the other letters. This was an unfortunate early feature that perhaps has influenced too many programmers?


--
Clive Page

[dpb]

i,j are builtin functions, I is not in MATLAB

>> which i
built-in (C:\ML_R2016b\toolbox\matlab\elmat\i)
>> which j
built-in (C:\ML_R2016b\toolbox\matlab\elmat\j)
>> which I
'I' not found.
>>

and, indeed, they are functions, NOT built-in constants

--

[Lynn McGuire]

On 12/17/2017 1:58 PM, herrman...@gmail.com wrote:

We use "double precision" in all of our Fortran code. Our calculation
engine has C and C++ interspersed throughout the Fortran code. We need
the Fortran double precision type to exactly match up with C/C++ double
type. Or else real bad things happen.

Lynn

[Ron Shepard]

On 12/25/17 12:20 AM, Lynn McGuire wrote:
> We use "double precision" in all of our Fortran code.  Our calculation
> engine has C and C++ interspersed throughout the Fortran code.  We need
> the Fortran double precision type to exactly match up with C/C++ double
> type.  Or else real bad things happen.

What was the C data type for REAL 64-bit floating point arithmetic on a
Cray? DOUBLE PRECISION on the Cray was 128-bit floating point. What was
the corresponding C data type for that?

$.02 -Ron Shepard

[FortranFan]

On Monday, December 25, 2017 at 1:20:56 AM UTC-5, Lynn McGuire wrote:

> ..

>
> We use "double precision" in all of our Fortran code. Our calculation
> engine has C and C++ interspersed throughout the Fortran code. We need
> the Fortran double precision type to exactly match up with C/C++ double

> type. Or else real bad things happen. ..

@Lynn McGuire,

Yours is not a portable approach, no wonder you keep having problems moving away from WATCOM-based compiler toolsets. You should know by now DOUBLE PRECISION in Fortran need not be the same as 'double' in C or C++. It is just a coincidence if the types match up with some implementations.

Anyways note the thread is about hard-wired values with the KIND approach introduced in Fortran since the 1990 revision, specifically REAL(8) that you don't use.

[herrman...@gmail.com]

On Monday, December 25, 2017 at 12:44:46 PM UTC-8, FortranFan wrote:

(snip)

> Yours is not a portable approach, no wonder you keep having
> problems moving away from WATCOM-based compiler toolsets.
> You should know by now DOUBLE PRECISION in Fortran need not
> be the same as 'double' in C or C++. It is just a coincidence
> if the types match up with some implementations.

It isn't quite that bad. I suppose in theory they could be
different, especially on systems with more than one 32 or 64
bit floating point type. (Consider VAX D_FLOAT and G_FLOAT.)

And yes, a system with 64 bit and 128 bit hardware could use
those for single and double, but so far that is rare. It might
be more common as hardware support for IEEE 754-2008 decimal
float increases.

[Lynn McGuire]

BTW, F77 double precision mapped to C double just fine on several Unix
boxes that we used to port to.

So, are you saying that REAL(8) is not just another way of saying REAL*8 ?

Lynn

[robin....@gmail.com]

REAL*8 is not standard, and REAL(8) is not portable,
and doesn't necessaryly mean double precision.

[spectrum]

On Monday, December 18, 2017 at 4:58:11 AM UTC+9, herrman...@gmail.com wrote:
> why would anyone use the non-portable REAL(8) when they could
> use the nice and portable REAL(SELECTED_REAL_KIND(12)) instead?
> Or maybe REAL(KIND(1.D0)) instead?

I think there are at least three possible reasons why many people keep on using
real(8) (excluding the amount of typing, which is not much different from
real(dp) etc).

[Reason 1] Some introductory textbooks can describe real(8) and complex(8)
explicitly to use double precision reals and complex numbers.

I learned Fortran90 using a locally (domestic) published introductory book
around 1999-2000, and assumed that real(8) is the Fortran-90 way for
writing real*8. The book also explained kind() etc also, but its merit was not
very clearly written in that book, and I didn't catch its significance (because
we can just write real(8)). Some time (1-2 years) after migrating
from Frotran77 to Fortran90, I got to know another style of writing
real(dp) etc and start considering "portability" a bit more.

Anyway, I think there are some (old or domestic) textbooks that explain
real(8) as "double precision" or 64-bit for learning Fortran90. Though
it is easy to blame that those books are "poorly written",
the point is that one's coding style could be affected pretty strongly
by the first textbook or any material used as "reference" (incl. other people's codes).

[Reason 2] Manual pages of major compilers are often written explicitly
using real(8) etc for explanation. For example, for cosine function,

https://gcc.gnu.org/onlinedocs/gfortran/COS.html
https://software.intel.com/en-us/node/679153

So, it seems very natural (to me) that one tends to follow this convention
because two major compilers use these numbers anyway.

[Reason 3] Though people here (on comp.lang.fortran or other forums) often
consider that portability is the highest issue, it is not of very high importance
in some cases. This is particularly so for students who use in-house PC or
workstations or clusters, and the choice of compilers is only from one or two
at most. I.e., the purpose of coding is not to distribute it on the net for
general use, or utilize it on many supercomputers with different compilers,
but just to make the work done using local machines. In such case, if we have
only gfortran (and sometimes Intel Fortran), why does one need to care portability?

[Reason 4] (This is a more minor possibility than 1-3 above.)
When people come to Fortran from other recent languages, the latter often
have types that specify the number of bits explicitly (e.g., Float64, real(64), f64, etc).
I think it is then possible for any "new comer" to Fortran to immediately
assume real(8) to be 8-byte reals (particularly when not consulting recent
textbooks, but just using Fortran empirically for other purposes, e.g., to
call it from Python.)

[Reason 5] (This is my most opinion-based one :-)
I believe we (= "human") prefer things that are more intuitive and their meaning
easy to imagine, while not prefer things that are not very intuitive and the meaning
immediately not clear. For example, I think real(1) and real(2) are also used
in some compilers, but I expect that people would prefer real(8) and real(16)
rather than real(1) and real(2), even the latter can have more advantages
(if all the KIND numbers are different). The latter is more similar to distinguishing
different types by numbers (e.g., Type1, Type2 rather than Applet_t and Orange_t),
in the sense that 1 or 2 does not remind anything concrete.

>
> Is it really so hard to type four or two times as much?
>

Typing real(dp) or real(wp) is not hard, but I want to avoid typing
REAL(SELECTED_REAL_KIND(12)) at least (it's simply long!)
I even want to avoid real(kind = dp) (<-- i.e., attaching "kind = ")...

[spectrum]

Hmm, sorry, this part

> in some compilers, but I expect that people would prefer real(8) and real(16)

> rather than real(1) and real(2), ...

is a typo of

> in some compilers, but I expect that people would prefer real(4) and real(8)
> rather than real(1) and real(2), ...

---
And I'm always wondering what compilers "enforce" real(1) and real(2)
systems in particular. I guess NAG provides compiler options to real(4) and
real(8). Probably these things become problematic when using some
supercomputers (e.g. Cray) or compilers for some platforms (e.g. WIndows)...?
(I have never used Cray supercomputers, so have no experience...)

# Up to now, I've utilized GCC, Intel, IBM(XL), Fujitsu, PGI, g77, f2c for my own
calculations (and also Sun/Oracle for comparison recently).

[robin....@gmail.com]

On Tuesday, December 26, 2017 at 2:31:34 PM UTC+11, spectrum wrote:
> Hmm, sorry, this part
>
> > in some compilers, but I expect that people would prefer real(8) and real(16)
> > rather than real(1) and real(2), ...
>
> is a typo of
>
> > in some compilers, but I expect that people would prefer real(4) and real(8)
> > rather than real(1) and real(2), ...
>
> ---
> And I'm always wondering what compilers "enforce" real(1) and real(2)
> systems in particular. I guess NAG provides compiler options to real(4) and
> real(8).

NAG also provides an option for unique kind numbers, which
helps guard against programming errors, when kind numbers
are the same for integers and reals.

Such an option is strongly preferred.

[dpb]

On 12/25/2017 5:42 PM, Lynn McGuire wrote:
...

> So, are you saying that REAL(8) is not just another way of saying REAL*8 ?

Possibly. *8 isn't a KIND number as in (8) and it isn't mandatory the
compiler vendor choose KIND numbers such that they are the same, no.
Also, since there's nothing that requires different compilers to use the
same numbering system for determining their implementation of KIND
values, (8) on one system isn't necessarily the same thing on another.

--

[herrman...@gmail.com]

Note that if REAL(8) is the same as REAL*8, then COMPLEX(8) can't be the same as COMPLEX*8, but instead COMPLEX*16. That is, the KIND equals bytes fails for COMPLEX, if it works for REAL. (At least for all systems using * notation that I know of.)

[dpb]

That, too! :)

Also note that in my original "Possibly" the actual answer to the
question posed is actually an unqualified "Yes!" -- the two syntaxes
aren't the same thing at all; one is a particular vendor extension while
the other is the Standard KIND value just with a specific choice for KIND.

As noted, that the two numeric values coincide for a specific case of
REALs is common implementation but "there be dragons!" hidden therein.

--

[Thomas Koenig]

On 2017-12-26, spectrum <septc...@gmail.com> wrote:

> [Reason 2] Manual pages of major compilers are often written explicitly
> using real(8) etc for explanation. For example, for cosine function,
>
> https://gcc.gnu.org/onlinedocs/gfortran/COS.html

Patches welcome :-)

[robin....@gmail.com]

On Wednesday, December 27, 2017 at 1:02:16 AM UTC+11, dpb wrote:

> On 12/26/2017 1:13 AM, h.....@gmail.com wrote:
> > On Monday, December 25, 2017 at 10:42:41 PM UTC-8, dpb wrote:
> >> On 12/25/2017 5:42 PM, Lynn McGuire wrote:
> >
> >>> So, are you saying that REAL(8) is not just another way of saying REAL*8 ?
> >
> >> Possibly. *8 isn't a KIND number as in (8) and it isn't mandatory the
> >> compiler vendor choose KIND numbers such that they are the same, no.
> >> Also, since there's nothing that requires different compilers to use the
> >> same numbering system for determining their implementation of KIND
> >> values, (8) on one system isn't necessarily the same thing on another.
> >
> > Note that if REAL(8) is the same as REAL*8, then COMPLEX(8) can't be the same as COMPLEX*8, but instead COMPLEX*16. That is, the KIND equals bytes fails for COMPLEX, if it works for REAL. (At least for all systems using * notation that I know of.)
>
>
> That, too! :)
>
> Also note that in my original "Possibly" the actual answer to the
> question posed is actually an unqualified "Yes!" -- the two syntaxes
> aren't the same thing at all; one is a particular vendor extension while
> the other is the Standard KIND value just with a specific choice for KIND.

There are no "Standard KIND values".
The number chosen (viz., 8) is not guaranteed to co-incide with any
of the kind numbers provided by the compiler,
hence it is not portable.

> As noted, that the two numeric values coincide for a specific case of
> REALs is common implementation but "there be dragons!" hidden therein.

Best to avoid them althgether.

[robin....@gmail.com]

On Wednesday, December 27, 2017 at 1:19:23 AM UTC+11, Thomas Koenig wrote:

> On 2017-12-26, spectrum <s.....7@gmail.com> wrote:
>
> > [Reason 2] Manual pages of major compilers are often written explicitly
> > using real(8) etc for explanation. For example, for cosine function,
> >
> > https://gcc.gnu.org/onlinedocs/gfortran/COS.html

The example given is:

program test_cos
real :: x = 0.0
x = cos(x)
end program test_cos

[Tim Prince]

In case kind=8 was chose for storage size, the more portable current
kind REAL64 is available in many compilers. The selected_real_kind
usage is of course widely used with reasonable convenience by the idiom
INTEGER,PARAMETER :: DP=SELECTED_REAL_KIND(12))

[dpb]

On 12/26/2017 9:21 AM, robin....@gmail.com wrote:
...

> There are no "Standard KIND values".

...

That's what I just said...to iterate what I said was that in the syntax
using (8) the 8 is a KIND number; KIND being a Standard construct. And
went on at length that the _VALUE_ used is implementation-specific as to
its particular meaning.

--

[kargl]

Patches aren't needed. The gfortran manual explains its convention
in the introduction of section 9.1. It states:

The enumeration of the KIND type parameter is processor defined in
the Fortran 95 standard. GNU Fortran defines the default integer
type and default real type by INTEGER(KIND=4) and REAL(KIND=4),
respectively. The standard mandates that both data types shall
have another kind, which have more precision. On typical target
architectures supported by gfortran, this kind type parameter is
KIND=8. Hence, REAL(KIND=8) and DOUBLE PRECISION are equivalent.
In the description of generic intrinsic procedures, the kind type
parameter will be specified by KIND=*, and in the description of
specific names for an intrinsic procedure the kind type parameter
will be explicitly given (e.g., REAL(KIND=4) or REAL(KIND=8)).
Finally, for brevity the optional KIND= syntax will be omitted.

I suspect other vendors have similar conventions explained in their
documentation.

--
steve

[kargl]

Spectrum is not referring to the exmaple code. She is referring to
the table (aligning might be messed up to display font)

Specific names:
Name Argument Return type Standard
COS(X) REAL(4) X REAL(4) Fortran 77 and later
DCOS(X) REAL(8) X REAL(8) Fortran 77 and later
CCOS(X) COMPLEX(4) X COMPLEX(4) Fortran 77 and later
ZCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension
CDCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension

Spectrum apparently did not read the introduction to the section
on intrinsic procedure where the kind type conventions are described.

--
steve

[Dick Hendrickson]

Exactly. One thing to remember is that REAL*8 was widely used before
the F90 KIND syntax. Many vendors adopted KIND=8 to mean double
precision for consistency with the old way.

All compiler writers know about this. If the compiler chooses something
like 1,2,3 as the kind values for single, double, and quad they'll give
an error for REAL(8) (or COMPLEX(16), etc.) No serious compiler will
attach any other meaning to REAL(8) and do something dumb. So, it's
safely non-portable; at the worst a pain in the butt to port to some
processors.

Dick Hendrickson

[herrman...@gmail.com]

On Tuesday, December 26, 2017 at 10:01:50 AM UTC-8, Dick Hendrickson wrote:

(snip)

> Exactly. One thing to remember is that REAL*8 was widely used before
> the F90 KIND syntax. Many vendors adopted KIND=8 to mean double
> precision for consistency with the old way.

> All compiler writers know about this. If the compiler chooses something
> like 1,2,3 as the kind values for single, double, and quad they'll give
> an error for REAL(8) (or COMPLEX(16), etc.) No serious compiler will
> attach any other meaning to REAL(8) and do something dumb. So, it's
> safely non-portable; at the worst a pain in the butt to port to some
> processors.

Yes, but the same ones that used REAL*8 also have COMPLEX*16,
but they don't use COMPLEX(16) to go with that one.

(Well, specifically, both IBM and DEC support REAL*8 and
COMPLEX*16. I believe both also support REAL*16 and COMPLEX*32.)

Both IBM and DEC have some hardware supporting 128 bit floating
point.

[Tim Prince]

but real*16 and complex*32 won't work with many compilers which do
support real(selected_real_kind(20)) and complex(selected_real_kind(20))
regardless of whether it's in firmware or software.
selected_real_kind(20) would be negative if there is no hardware or
software support.

[herrman...@gmail.com]

On Tuesday, December 26, 2017 at 10:42:03 AM UTC-8, Tim Prince wrote:

(snip, I wrote)

> > Yes, but the same ones that used REAL*8 also have COMPLEX*16,
> > but they don't use COMPLEX(16) to go with that one.

> > (Well, specifically, both IBM and DEC support REAL*8 and
> > COMPLEX*16. I believe both also support REAL*16 and COMPLEX*32.)

> > Both IBM and DEC have some hardware supporting 128 bit floating
> > point.

> but real*16 and complex*32 won't work with many compilers which do
> support real(selected_real_kind(20)) and complex(selected_real_kind(20))
> regardless of whether it's in firmware or software.
> selected_real_kind(20) would be negative if there is no hardware or
> software support.

Yes, but the point is that, according to the standard, you can't
have KINDs that equal the byte width for all data types. Specifically,
you can't have them for both REAL and COMPLEX.

The standard could have had a rule that the appropriate KIND for
COMPLEX is twice the KIND for the corresponding REAL, but didn't
do that.

(That would have some interesting cases like:

COMPLEX(2*DP) :: Z

assuming DP was the appropriate REAL kind.)

Also, others have noted the problem with using the same
KIND values for both INTEGER and REAL.

[robin....@gmail.com]

On Wednesday, December 27, 2017 at 4:19:57 AM UTC+11, kargl wrote:
> Thomas Koenig wrote:
>

> > On 2017-12-26, spectrum <s.....@gmail.com> wrote:
> >
> >> [Reason 2] Manual pages of major compilers are often written explicitly
> >> using real(8) etc for explanation. For example, for cosine function,
> >>
> >> https://gcc.gnu.org/onlinedocs/gfortran/COS.html
> >
> > Patches welcome :-)
>
> Patches aren't needed. The gfortran manual explains its convention
> in the introduction of section 9.1. It states:
>
> The enumeration of the KIND type parameter is processor defined in
> the Fortran 95 standard. GNU Fortran defines the default integer
> type and default real type by INTEGER(KIND=4) and REAL(KIND=4),

which is why those numbers can lead to inadvertent programmind errors.
The kinds are just numbers, and the "_4" can be wrongly applied to
an integer constant when the constant is intended to be real (for example).

[robin....@gmail.com]

On Wednesday, December 27, 2017 at 4:24:37 AM UTC+11, kargl wrote:

> r.....@gmail.com wrote:
>
> > On Wednesday, December 27, 2017 at 1:19:23 AM UTC+11, Thomas Koenig wrote:
> >> On 2017-12-26, spectrum <s.....7@gmail.com> wrote:
> >>
> >> > [Reason 2] Manual pages of major compilers are often written explicitly
> >> > using real(8) etc for explanation. For example, for cosine function,
> >> >
> >> > https://gcc.gnu.org/onlinedocs/gfortran/COS.html
> >
> > The example given is:
> >
> > program test_cos
> > real :: x = 0.0
> > x = cos(x)
> > end program test_cos
>
> Spectrum is not referring to the exmaple code. She is referring to
> the table (aligning might be messed up to display font)
>
> Specific names:
> Name Argument Return type Standard
> COS(X) REAL(4) X REAL(4) Fortran 77 and later
> DCOS(X) REAL(8) X REAL(8) Fortran 77 and later
> CCOS(X) COMPLEX(4) X COMPLEX(4) Fortran 77 and later
> ZCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension
> CDCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension

Those are carry-overs from FORTRAN 77 days.
It would be better if that notation were dropped.

[robin....@gmail.com]

It's a pain in the butt to have a constant that was intended to be
a REAL constant, only to find that it's been interpreted as an
INTEGER constant.

[kargl]

No. It is the convention adopted by gfortran for kind type
parameters. You saw my other post quoting the choice that
gfortran made, where it clearly states how the documentation
of the intrinsic procedure will be presented.

--
steve

[robin....@gmail.com]

But it is still a carry-over from FORTRAN 77 days.
Take a look at, for example, Ellis, Phillips & Lahey,s book
where arguments are expressed in terms of Real, and DP real,
for example.

There's no need to use the notation, real (4) etc.

[herrman...@gmail.com]

On Tuesday, December 26, 2017 at 9:24:37 AM UTC-8, kargl wrote:

(snip)

> Spectrum is not referring to the exmaple code. She is referring to
> the table (aligning might be messed up to display font)

> Specific names:
> Name Argument Return type Standard
> COS(X) REAL(4) X REAL(4) Fortran 77 and later
> DCOS(X) REAL(8) X REAL(8) Fortran 77 and later
> CCOS(X) COMPLEX(4) X COMPLEX(4) Fortran 77 and later
> ZCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension
> CDCOS(X) COMPLEX(8) X COMPLEX(8) GNU extension

> Spectrum apparently did not read the introduction to the section
> on intrinsic procedure where the kind type conventions are described.

If those we actual declarations, they would look like:

REAL(4) :: X

one can invent a notation for describing the byte width of
data types, that doesn't look like an actual declaration, or
that look similar, but not exactly.

If I saw the above documentation, I am not sure if I would
expect them to be actual KIND values, or byte widths.

[Ron Shepard]

You think COMPLEX(4) could be a variable four bytes long? Of course
COMPLEX(KIND=4) would remove any ambiguity, but it would make all of the
tables that much longer. I can see why they did it the way they did.

$.02 -Ron Shepard

[herrman...@gmail.com]

On Tuesday, December 26, 2017 at 11:37:38 PM UTC-8, Ron Shepard wrote:

(snip, I wrote)

> > one can invent a notation for describing the byte width of
> > data types, that doesn't look like an actual declaration, or
> > that look similar, but not exactly.

> > If I saw the above documentation, I am not sure if I would
> > expect them to be actual KIND values, or byte widths.

> You think COMPLEX(4) could be a variable four bytes long? Of course
> COMPLEX(KIND=4) would remove any ambiguity, but it would make all of the
> tables that much longer. I can see why they did it the way they did.

I was suggesting that the notation in the documentation,
COMPLEX(4), doesn't necessarily indicate that the KIND value is 4.

I was also noting that while many implementations use the byte
length for KIND values for INTEGER and REAL, they can't, at the
same time, use the byte length for COMPLEX.

If, when the standard was being written, there was thought
to using the byte length for KIND values, the standard could
have used COMPLEX KIND values that were twice as large as the
corresponding REAL value. They didn't do that.

[kargl]

herrman...@gmail.com wrote:

> On Tuesday, December 26, 2017 at 11:37:38 PM UTC-8, Ron Shepard wrote:
>
> (snip, I wrote)
>
>> > one can invent a notation for describing the byte width of
>> > data types, that doesn't look like an actual declaration, or
>> > that look similar, but not exactly.
>
>> > If I saw the above documentation, I am not sure if I would
>> > expect them to be actual KIND values, or byte widths.
>
>> You think COMPLEX(4) could be a variable four bytes long? Of course
>> COMPLEX(KIND=4) would remove any ambiguity, but it would make all of the
>> tables that much longer. I can see why they did it the way they did.
>
> I was suggesting that the notation in the documentation,
> COMPLEX(4), doesn't necessarily indicate that the KIND value is 4.

The convention is documented in the introduction to the section.
From Section 9.1, "Finally, for brevity the optional KIND= syntax
will be omitted."

I know. It is a rather novel idea to expect users to read the
documentation that comes with the software.

--
steve

[Ron Shepard]

On 12/27/17 2:01 PM, herrman...@gmail.com wrote:
> If, when the standard was being written, there was thought
> to using the byte length for KIND values, the standard could
> have used COMPLEX KIND values that were twice as large as the
> corresponding REAL value. They didn't do that.

Instead, the standard requires the identical SAME kind values for real
and complex. That makes much more sense, especially in cases where
floating point arithmetic is done with real and complex variables that
need to share exponent range and precision.

$.02 -Ron Shepard

[Dick Hendrickson]

It also makes COMMON and EQUIVALENCE work.

Dick Hendrickson

[Lynn McGuire]

Bummer. Another reason to move totally onto C++. Which, will probably
never happen due to the indexing issue.

I been having "fun" with dereferencing pointers in our fortran code.
Our builtin fortran compiler and interpreter uses pointers extensively
in its bytecode. Extensively. It is hell to debug. But, the users
love adding their own calculational features to our software so it is
very useful.

Lynn

[herrman...@gmail.com]

On Thursday, December 28, 2017 at 1:17:04 AM UTC-8, Ron Shepard wrote:

(snip, I wrote)

> > If, when the standard was being written, there was thought
> > to using the byte length for KIND values, the standard could
> > have used COMPLEX KIND values that were twice as large as the
> > corresponding REAL value. They didn't do that.

> Instead, the standard requires the identical SAME kind values for real
> and complex. That makes much more sense, especially in cases where
> floating point arithmetic is done with real and complex variables that
> need to share exponent range and precision.

It does make sense, but then there isn't a reason for KIND values
to equal byte sizes.

In the Fortran 66 days, you needed to know the byte width to
use with A format, and for storing character values. Now that we
don't need that, there is less reason to know the byte widths.

But again, why should the KIND equal bytes for INTEGER and REAL?

[dpb]

On 12/28/2017 1:31 PM, Lynn McGuire wrote:
> On 12/26/2017 12:42 AM, dpb wrote:
>> On 12/25/2017 5:42 PM, Lynn McGuire wrote:
>> ...
>>
>>> So, are you saying that REAL(8) is not just another way of saying
>>> REAL*8 ?
>>
>> Possibly.  *8 isn't a KIND number as in (8) and it isn't mandatory the
>> compiler vendor choose KIND numbers such that they are the same, no.
>> Also, since there's nothing that requires different compilers to use
>> the same numbering system for determining their implementation of KIND
>> values, (8) on one system isn't necessarily the same thing on another.
>
> Bummer.  Another reason to move totally onto C++.  Which, will probably
> never happen due to the indexing issue.

Well, it's one that is technically so since one is a vendor extension
while the other is the Standard form (at least using KIND number, albeit
as other have noted hardcoding them is non-portable).

BUT, AFAIK, any compiler that implements the *8 extension is highly
likely to keep the same convention for their KIND numbers so the chances
are good that it won't be a show-stopper for that reason.

--

[campbel...@gmail.com]

I use gFortran and Silverfrost FTN95 extensively and have used ifort and Lahey in the past. Silverfrost adopts Kind=1 for real*4, kind=2 for real*8 and kind=3 for real*10, while gF, ifort and Lahey uses 4, 8 and 16.
(For switching between compilers, I have found real*byte and constant_byte_size to be the most practical approach.)
Apparently NAG offers a feature where kind values for integer and real are different, which would be an interesting environment to code. I assume real and complex share the same kind value.
COMPLEX*byte_size can be confusing.
It would have been good if the F90 standard provided a commentary with recommendations for using kind values that are the same as the byte length. This would have been more convenient but may have encouraged more non-standard use of examples like 0.1_8.
While using a kind value, such as in 0.1_8 or 11_8 is discouraged, this can be a very easy non-standard coding approach.
The most annoying area for assuming kind values is when specifying 8-byte Integer constants, especially as inputs to system routines. Why should we provide a standard complying 8-byte integer to a non-standard system routine ?

I just find this a standard complying mess and wonder what non-Fortran coders think of this kind of storm ?

[Thomas Jahns]

On 01/02/18 05:27, campbel...@gmail.com wrote:
> It would have been good if the F90 standard provided a commentary with recommendations for using kind values that are the same as the byte length. This would have been more convenient but may have encouraged more non-standard use of examples like 0.1_8.

Actually the standard tries to hide the existence of bytes to make
implementations that don't have them possible. In my opinion that's a pointless
exercise for machines which never supported Fortran 90 and which don't exist
outside museums anymore.

I still hope that languages which simply recognize the total domination of
IEEE754 types and power-of-2 word sizes like Go will very slowly replace the
eventually unsustainable C/C++/Fortran ecosystem (but I'm quite sure that
language will not be Go).

> I just find this a standard complying mess and wonder what non-Fortran coders think of this kind of storm ?

It's a minor nuisance, but in practice really just a module with the usual type
kinds derived in a portable fashion. The nuisance part then comes from different
communities adopting different names for the kinds.

Thomas

[robin....@gmail.com]

Unfortunately, having 4 for the byte count of integer and reals
creates errors for the unwary, because
1_4 and 1.0_4 are INTEGER and REAL respectively.
It's easy to think that writing 1_4 is a real constant, when it is not.

The NAG compiler thankfully has had introduced an option
that allows kind numbers that are NOT 4 or 8 or 16,
and which helps guard against programming errors of that kind.

[Tim Prince]

gfortran and ifort implement the current standard, where if you want to
specify storage size (and specify data type), you have 0.1_real64,
11_int64. Presumably int64 and real64 are kind numbers different from 8.

[robin....@gmail.com]

On Wednesday, January 3, 2018 at 12:29:35 AM UTC+11, Tim Prince wrote:

> gfortran and ifort implement the current standard, where if you want to
> specify storage size (and specify data type), you have 0.1_real64,
> 11_int64. Presumably int64 and real64 are kind numbers different from 8.

Far better to specify something like

0.1_dp or 0.1_wp

where those suffixes are associated with the desired kind (whether real64
or simply kind(1D0) ) in some earlier statement.

[Thomas Koenig]

Tim Prince <tpr...@computer.org> schrieb:

> gfortran and ifort implement the current standard, where if you want to
> specify storage size (and specify data type), you have 0.1_real64,
> 11_int64. Presumably int64 and real64 are kind numbers different from 8.

It is possible to test such presumptions :-)

$ cat kinds.f90
program main
use, intrinsic :: iso_fortran_env
print *,real64
print *,int64
end
$ gfortran kinds.f90 && ./a.out
8
8
$ ifort kinds.f90 && ./a.out
8
8

[Dick Hendrickson]

On 1/2/18 3:11 AM, Thomas Jahns wrote:
> On 01/02/18 05:27, campbel...@gmail.com wrote:
>> It would have been good if the F90 standard provided a commentary with
>> recommendations for using kind values that are the same as the byte
>> length. This would have been more convenient but may have encouraged
>> more non-standard use of examples like 0.1_8.
>
> Actually the standard tries to hide the existence of bytes to make
> implementations that don't have them possible. In my opinion that's a
> pointless exercise for machines which never supported Fortran 90 and
> which don't exist outside museums anymore.

Floating point formats were chaotic in the 80s. Almost all the major
computers had their own proprietary formats and a couple had unusual
word lengths (36 or 60) and several did not have byte addressable
memory. DEC supported 3 or so floating point formats. And the IEEE
format was loudly opposed by several numerical analysts. The KIND
system seemed a reasonable compromise. People could spend some time and
get a code to do the right thing (not just execute) on machines with
either a 32 or 64 bit basic word size.

Recent standards have defined constants, (INT64, REAL128, etc.) that let
people specify low level hardware details.

Dick Hendrickson

[Steve Lionel]

On 1/2/2018 11:39 AM, Dick Hendrickson wrote:
> Recent standards have defined constants, (INT64, REAL128, etc.) that let
> people specify low level hardware details.

Actually, they don't - they just specify total number of bits. We had a
long and drawn-out argu..er..discussion of that topic here a few months
ago. It is true that, with IEEE FP being pretty much universal nowadays,
these constants are reasonably reliable but in the broader context they
are not. Consider for example the DEC Alpha that supported three
different 64-bit real formats!

--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[campbel...@gmail.com]

Steve,

I am not familiar with DEC Alpha. Could you elaborate:
Is it still in use ?
Can you use all 3 64-bit real formats in the one program or only one ?
Are the 3 formats selectable using Fortran 90+ via the KIND syntax ?
After all, this is a justification for KIND.

I remember that DEC VAX supported 2 64-bit real formats, one with higher precision, but an exponent range that was too restrictive. Practically (for me) there was only one suitable format.

[herrman...@gmail.com]

On Tuesday, January 2, 2018 at 2:55:18 PM UTC-8, campbel...@gmail.com wrote:
> On Wednesday, January 3, 2018 at 6:09:53 AM UTC+11, Steve Lionel wrote:

(snip)

> Consider for example the DEC Alpha that supported three
> > different 64-bit real formats!

>

> I am not familiar with DEC Alpha. Could you elaborate:
> Is it still in use ?
> Can you use all 3 64-bit real formats in the one program or only one ?
> Are the 3 formats selectable using Fortran 90+ via the KIND syntax ?
> After all, this is a justification for KIND.

Alpha is the successor to VAX in the DEC line.

It is a 64 bit RISC architecture. It lost support when
DEC got bought, and VMS was ported to Itanium (IA64).

So, there are three hardware platforms for VMS, VAX,
Alpha, and Itanium.

As well as I know it, Alpha supports the IEEE formats,
along with instructions to convert to/from the VAX
(F_float, D_float, G_float, and H_float) formats.

In some cases, significant bits are lost in the conversion.

> I remember that DEC VAX supported 2 64-bit real formats,
> one with higher precision, but an exponent range that was
> too restrictive. Practically (for me) there was only one
> suitable format.

VAX also has H_float, a 128 bit format with a larger exponent
field than the others. Hardware support on some models,
software emulation on others.

[robin....@gmail.com]

On Wednesday, January 3, 2018 at 3:39:49 AM UTC+11, Dick Hendrickson wrote:

> Floating point formats were chaotic in the 80s.

and 70's and 60's.

> Almost all the major
> computers had their own proprietary formats and a couple had unusual
> word lengths (36 or 60)

amd 40 bits and 48 bits amd so on.

> and several did not have byte addressable
> memory.

CDC machines, at least.

[Phillip Helbig (undress to reply)]

In article <be2915fa-f519-4b3c...@googlegroups.com>,

herrman...@gmail.com writes:

> > I am not familiar with DEC Alpha. Could you elaborate:
> > Is it still in use ?

I am typing this on an Alpha running VMS. :-)

> > Can you use all 3 64-bit real formats in the one program or only one ?

You can use them all in one program.

> > Are the 3 formats selectable using Fortran 90+ via the KIND syntax ?

That I don't know. I've written much Fortran on Alpha, but only ever
needed REAL and DOUBLE PRECISION.

> Alpha is the successor to VAX in the DEC line.
>
> It is a 64 bit RISC architecture. It lost support when
> DEC got bought, and VMS was ported to Itanium (IA64).
>
> So, there are three hardware platforms for VMS, VAX,
> Alpha, and Itanium.

There is a company, VSI, founded three years ago, which has taken over
VMS and have as their main goal porting it to x86. They have also said
that they would bring the compilers up to date.

VMS Fortran was, back in the day, the gold standard for Fortran
compilers.

> > I remember that DEC VAX supported 2 64-bit real formats,
> > one with higher precision, but an exponent range that was
> > too restrictive. Practically (for me) there was only one
> > suitable format.

Do you need more range? Or more precision? You had the choice.

> VAX also has H_float, a 128 bit format with a larger exponent
> field than the others. Hardware support on some models,
> software emulation on others.

Yes.

[Thomas Koenig]

Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> schrieb:

> There is a company, VSI, founded three years ago, which has taken over
> VMS and have as their main goal porting it to x86. They have also said
> that they would bring the compilers up to date.

Interesting. Didn't see a lot of information on Fortran, though.

> VMS Fortran was, back in the day, the gold standard for Fortran
> compilers.

Also the source of numerous extensions which plague the Fortran
world to this day :-)

[Ian D Chivers]

Following on from what Dick Hendrikson said
here are some of the numeric formats in use
at the time of the Fortran 77 standard.

I worked in Computing Services at Imperial
College at the time and these were some of
the systems we were involved in supporting.

#####
Queen Mary College, University of London was an ICL site.
#####

ICL 1900
========
Data formats

The instruction set supported the following data formats:

Single-length integer A 24-bit two's complement signed number.
Multi-length integer The first word held a 24-bit two's complement
signed number,
subsequent words held 23-bit extensions with the high bit used for
internal carry.
Single-length floating point number
Two words holding a 24-bit signed argument (mantissa) and a nine-bit
exponent.
Double-length floating-point number
Two words holding a 38-bit signed argument and a nine-bit exponent.
Quadruple-length floating-point number Four words holding a
75-bit signed argument and a nine-bit exponent.
Handled in software on all but 1906/7 processors with the extended
floating-point feature.

#####
Imperial College was a CDC site
at the time I started work and added
a combined DEC Vax and FPS vector box later.
#####

CDC 6500 and various 170 series
===============================

60 bit words

48 bit integers

60 and 120 bit reals
48 bit mantissa
11 bit exponent
1 sign bit

DEC Vax
=======

F_floating point numbers have the range of approximately plus or
minus 2.9E-39 to plus or minus 1.7E+38, with a precision of
approximately seven decimal digits.

D_floating point numbers have the range of approximately plus or
minus 2.9E-39 to plus or minus 1.7E+38, with a precision of
approximately 16 decimal digits

G_floating point numbers have the range of approximately plus or minus
5.6E-309 to plus or minus 0.9E+308, with a precision of approximately 15
decimal digits.
The exponent has a bias of 1024 (not 128).

H_floating point numbers have the range of approximately plus or minus
8.4E-4933 to plus or minus 5.9E+4931, with a precision of approximately
33 decimal digits.
The exponent has a bias of 16384 (not 1024).

#####
University of London Computer Center
was initially a Cray and CDC (7600) site.
It added Amdahl later.
#####

Cray
====

64 and 128 bit reals

So as Dick says the Fortran 90 standard kind type system
helped overcome many portability issues
users had with Fortran.

[Steve Lionel]

On 1/2/2018 5:55 PM, campbel...@gmail.com wrote:
> I am not familiar with DEC Alpha. Could you elaborate:
> Is it still in use ?
> Can you use all 3 64-bit real formats in the one program or only one ?
> Are the 3 formats selectable using Fortran 90+ via the KIND syntax ?
> After all, this is a justification for KIND.
>
> I remember that DEC VAX supported 2 64-bit real formats, one with higher precision, but an exponent range that was too restrictive. Practically (for me) there was only one suitable format.

Alpha supported three different 64-bit REAL formats (and two 32 or
128-bit). In addition to IEEE double (called "T float" by DEC), Alpha
supported the VAX D and G formats (G is close to IEEE double, but with
different normalization rules and no denorms/infinities.)

In practice, you'd use only one of these at a time, but it was certainly
possible to use more than one if you worked at it.

Whether or not Alphas are still in use (and yes, they are) is
immaterial, though I did say that IEEE float is pretty much universal
now.) My point here, as before, was that the constants in
ISO_FORTRAN_ENV tell you *nothing* about the hardware format other than
number of bits. If you care about such things, the language provides
SELECTED_REAL_KIND (and SELECTED_INT_KIND) as well as an
IEEE_SELECTED_REAL_KIND if you absolutely want IEEE behavior.

I consider REAL64, etc. to be no better than the nonstandard *8 syntax.
Feel free to use them if you want, but don't delude yourself into
thinking that they're anything more than standard-conforming syntax for
expressing a non-portable concept. But I also recognize that there are
people, whose opinions I generally respect, that disagree with me here.

[Steve Lionel]

On 1/3/2018 6:24 AM, Thomas Koenig wrote:
>> VMS Fortran was, back in the day, the gold standard for Fortran
>> compilers.
> Also the source of numerous extensions which plague the Fortran
> world to this day :-)

Really the only extension added to VMS Fortran that is in widespread use
today is STRUCTURE/RECORD/UNION/MAP (and the "dot" syntax for record
components.) Most other extensions you may attribute to VMS Fortran
predate it (Variable Format Expressions from the PDP-11, for example).
When I was working on VAX Fortran in the 1970s and 1980s, it
incorporated many extensions from IBM, CDC and Univac as they were in
widespread use at the time.

[Lynn McGuire]

The 36 bit (Univac 1108) and 60 bit (CDC 6600/7600) machines were six
bits to a byte machines also. No lower case characters. But I loved
those 36 bits for floating point calcs in the 1970s.

Lynn

[robin....@gmail.com]

I think that you will find that integers were 60 bits, same as the word size.
The multiplier, however, required that all significant bits be
confined to 48 bits.

The reason for that is that the same instruction was used for integer multiply
and floating-point multiply. If significant bits of an integer were
found in the upper 12 bits, a floating-point multiplication was carried out
(with the outcome that the "integer" product was garbage).

Characters were 6 bits, with a character set comprised of 65 characters.
Some characters could be 6/12 bits, using an escape code.

[robin....@gmail.com]

On Thursday, January 4, 2018 at 3:01:32 PM UTC+11, Lynn McGuire wrote:

> The 36 bit (Univac 1108) and 60 bit (CDC 6600/7600) machines were six
> bits to a byte machines also.

There were no bytes, as they were 60-bit words.
Characters were of 6 bits and 12 bits.

> No lower case characters.

Upper and lower case were provided with 6/12 bit characters (using an escape character).

[edmondo.g...@gmail.com]

I remember a problem when we moved our programs from Alpha to Linux (or from an IBM mainframe to alpha, I cannot remember better) several years ago.

I am working on plasma physics and the typical density of the plasma in our tokamak is about 10^20 m^-3 (as in almost all other tokamaks).

Some of the programs that were analysing the experimental data were squaring the plasma density. As you can expect the squared plasma density couldn't get anymore in a single precision variable.

So we had to fix all the programs that had this problem (basically normalising it 10^20).

[Ron Shepard]

On 1/3/18 5:24 AM, Thomas Koenig wrote:
>> VMS Fortran was, back in the day, the gold standard for Fortran
>> compilers.
> Also the source of numerous extensions which plague the Fortran
> world to this day :-)

This is true, but using fortran extensions was a practical necessity in
the 70s and 80s because the language itself was so limited, even after
f77 was available. If you wanted command line arguments, that required
an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
an extension. If you wanted to write portable code that ran on a wide
range of hardware, you needed to use REAL*8 and that was an extension.
If you wanted dynamic memory allocation at runtime, that was an
extension. If you wanted to do any kind of bit manipulation,
and/or/shift/not, that required an extension. If you wanted to spawn
processes, that was an extension. If you wanted time, date, or cpu time
information, that was an extension. And on and on and on. F90 addressed
many of these limitations, but it was not available until the mid 90s
and it was at least a decade late to have had its maximal impact on
programmers. And DEC was one of the companies that caused that delay.

$.02 Ron Shepard

[Lynn McGuire]

The 36 bit machines supported 6 upper case characters in an integer.
And the 60 bit machines supported 10 upper case characters in an integer.

Didn't the 12 bit characters on those machines come about in the 1980s ?

Lynn

[robin....@gmail.com]

On Friday, January 5, 2018 at 4:12:59 AM UTC+11, Ron Shepard wrote:
> On 1/3/18 5:24 AM, Thomas Koenig wrote:
> >> VMS Fortran was, back in the day, the gold standard for Fortran
> >> compilers.
> > Also the source of numerous extensions which plague the Fortran
> > world to this day :-)
>
> This is true, but using fortran extensions was a practical necessity in
> the 70s and 80s because the language itself was so limited, even after
> f77 was available. If you wanted command line arguments, that required
> an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
> an extension. If you wanted to write portable code that ran on a wide
> range of hardware, you needed to use REAL*8 and that was an extension.

You didn't need REAL*8.
There was DOUBLE PRECISION.

I wrote portable code even pre-FORTRAN 77.
That included translators (which needed character handling).

In FORTRAN 77 I wrote a preprocessor that gave many Fortran 90
facilities including recursion.

> If you wanted dynamic memory allocation at runtime, that was an
> extension.

No it wasn't; facilities for that were written in standard FORTRAN.
Look in CACM.

> If you wanted to do any kind of bit manipulation,
> and/or/shift/not, that required an extension.

Are you sure?

> If you wanted to spawn
> processes, that was an extension. If you wanted time, date, or cpu time
> information, that was an extension. And on and on and on.

PL/I provided all of these "extensions" as standard language features,
and had done so since 1966.

> F90 addressed
> many of these limitations, but it was not available until the mid 90s

early 1990s.

[robin....@gmail.com]

On Friday, January 5, 2018 at 5:48:46 AM UTC+11, Lynn McGuire wrote:

We got our CDC machine in 1975 (a Cyber 72). That was later "upgraded" to
a 7600.

[Ron Shepard]

On 1/4/18 12:48 PM, Lynn McGuire wrote:
> On 1/3/2018 10:31 PM, robin....@gmail.com wrote:
>> On Thursday, January 4, 2018 at 3:01:32 PM UTC+11, Lynn McGuire wrote:

[...]

>>>   But I loved
>>> those 36 bits for floating point calcs in the 1970s.
>
> The 36 bit machines supported 6 upper case characters in an integer. And
> the 60 bit machines supported 10 upper case characters in an integer.

The DEC TOPS-10 and TOPS-20 machines were also 36-bit words, and they
supported 7-bit ascii characters with five characters per word. My
experience was before f77 compilers were available, so the character
manipulation was done with hollerith and I/O using A formats on the
integer or real variables.

$.02 -Ron Shepard

[Ron Shepard]

On 1/4/18 6:01 PM, robin....@gmail.com wrote:
> On Friday, January 5, 2018 at 4:12:59 AM UTC+11, Ron Shepard wrote:
>> On 1/3/18 5:24 AM, Thomas Koenig wrote:
>>>> VMS Fortran was, back in the day, the gold standard for Fortran
>>>> compilers.
>>> Also the source of numerous extensions which plague the Fortran
>>> world to this day :-)
>>
>> This is true, but using fortran extensions was a practical necessity in
>> the 70s and 80s because the language itself was so limited, even after
>> f77 was available. If you wanted command line arguments, that required
>> an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
>> an extension. If you wanted to write portable code that ran on a wide
>> range of hardware, you needed to use REAL*8 and that was an extension.
>
> You didn't need REAL*8.
> There was DOUBLE PRECISION.

Unless you were on a Cray, in which case REAL*8 was REAL, not DOUBLE
PRECISION. Hence, REAL*8 was the portable, but nonstandard, way to write
portable code.

> I wrote portable code even pre-FORTRAN 77.
> That included translators (which needed character handling).

I did the same thing, but I did not call that writing portable code, I
called it translation from one nonportable dialect to another.

>> If you wanted dynamic memory allocation at runtime, that was an
>> extension.
>
> No it wasn't; facilities for that were written in standard FORTRAN.
> Look in CACM.

Every vendor did this differently, hence my characterization of these as
being nonportable extensions. There were "cray pointers", interfaces to
C malloc(), and several other approaches.

>> If you wanted to do any kind of bit manipulation,
>> and/or/shift/not, that required an extension.
>
> Are you sure?

Yes, of course I'm sure. F77 had no standard bit operators, and among
the extensions, there were two conventions, one based on IBM extensions
and the other based on f2c extensions. I believe the MIL-STD standard
followed the IBM conventions.

>> If you wanted to spawn
>> processes, that was an extension. If you wanted time, date, or cpu time
>> information, that was an extension. And on and on and on.
>
> PL/I provided all of these "extensions" as standard language features,
> and had done so since 1966.

I would not call PL/I a fortran compiler, so that is irrelevant.

>> F90 addressed
>> many of these limitations, but it was not available until the mid 90s
>
> early 1990s.

The first compilers were available in about 1992, but it took two or
three more years before enough vendors supported it to be confident of
writing portable code. This was a decade before gfortran was available,
so for the most part, vendors were still supporting compilers on just
their own hardware in the 90s. One of the first available, the
commercial NAG compiler, which compiled to C intermediate code, was an
exception, it ran on multiple hardware.

$.02 -Ron Shepard

[campbel...@gmail.com]

On Friday, January 5, 2018 at 11:01:29 AM UTC+11, robin....@gmail.com wrote:
>
> You didn't need REAL*8.
> There was DOUBLE PRECISION.
>

I have used a range of machines since 70's and always used REAL*8 as it documented both the real precision and the hardware that was being used for the software development. Moving between CDC, Pr1me, Vax and very occasionally Cray, IBM or ICL, you never knew what REAL or DOUBLE PRECISION meant, but to this day REAL*8 has always meant a 64-bit real. This is much easier to understand that "r=308". Real*8 was the default standard in 70's to 90's
REAL or DOUBLE PRECISION was never very informative.

Why do so many people specify 308 ? I certainly don't know why that is required ! I have rarely seen a discussion of what precision or range is required for the computation and certainly never seen a justification of 308. In my experience r=38 (real*4) was not sufficient, and there weren't many alternatives. Nearly always only 1 practical option; an 8-byte real ! I have always objected to the illusion of choice that SELECTED_REAL_KIND has implied.

Robin, we got our CDC 6600 machine in 1974 then Pr1me in 75. Our Vax didn't arrive till about 80, so most code swapped from CDC to Pr1me then had to do ports to others hardware. There was lots of public domain CDC or Vax (nonF77) Fortran, so the non-standard features were always a challenge. IBM, ICL etc were never easy. IOSTAT= on an IBM was a nightmare.

[Lynn McGuire]

On 1/4/2018 11:12 AM, Ron Shepard wrote:
> On 1/3/18 5:24 AM, Thomas Koenig wrote:

...

> If you wanted dynamic memory allocation at runtime, that was an
> extension.

...

Nope, we implemented dynamic memory allocation in 1978 using DYNOSOR.
https://dl.acm.org/citation.cfm?doid=954654.954661

> $.02 Ron Shepard

Lynn

[Lynn McGuire]

Cool. I did not use any DEC machines until 1989 when I jumped back to
ChemShare where we were using Vax stations. All I know is that it was a
32 bit platform.

Lynn

[robin....@gmail.com]

On Friday, January 5, 2018 at 2:01:19 PM UTC+11, Ron Shepard wrote:

> On 1/4/18 6:01 PM, r.....@gmail.com wrote:
> > On Friday, January 5, 2018 at 4:12:59 AM UTC+11, Ron Shepard wrote:
> >> On 1/3/18 5:24 AM, Thomas Koenig wrote:
> >>>> VMS Fortran was, back in the day, the gold standard for Fortran
> >>>> compilers.
> >>> Also the source of numerous extensions which plague the Fortran
> >>> world to this day :-)
> >>
> >> This is true, but using fortran extensions was a practical necessity in
> >> the 70s and 80s because the language itself was so limited, even after
> >> f77 was available. If you wanted command line arguments, that required
> >> an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
> >> an extension. If you wanted to write portable code that ran on a wide
> >> range of hardware, you needed to use REAL*8 and that was an extension.
> >
> > You didn't need REAL*8.
> > There was DOUBLE PRECISION.
>
> Unless you were on a Cray, in which case REAL*8 was REAL,

As I said, you didn't need REAL*8. DOUBLE PRECISION
was the standard way to get the extra precision.
And anythihg standard was portable.

> not DOUBLE
> PRECISION. Hence, REAL*8 was the portable, but nonstandard, way to write
> portable code.

I do not agree.

> > I wrote portable code even pre-FORTRAN 77.
> > That included translators (which needed character handling).
>
> I did the same thing, but I did not call that writing portable code, I
> called it translation from one nonportable dialect to another.

Mine was standard and portable.

> >> If you wanted dynamic memory allocation at runtime, that was an
> >> extension.
> >
> > No it wasn't; facilities for that were written in standard FORTRAN.
> > Look in CACM.
>
> Every vendor did this differently,

I wasn't referring to vendors.
I was referring to how it was done using FORTRAN. Look at
Collected Algorithms for examples.

> hence my characterization of these as
> being nonportable extensions. There were "cray pointers", interfaces to
> C malloc(), and several other approaches.

I wasn't referring to any of those non-standard things.

> >> If you wanted to do any kind of bit manipulation,
> >> and/or/shift/not, that required an extension.
> >
> > Are you sure?
>
> Yes, of course I'm sure. F77 had no standard bit operators, and among
> the extensions, there were two conventions, one based on IBM extensions
> and the other based on f2c extensions. I believe the MIL-STD standard
> followed the IBM conventions.
>
> >> If you wanted to spawn
> >> processes, that was an extension. If you wanted time, date, or cpu time
> >> information, that was an extension. And on and on and on.
> >
> > PL/I provided all of these "extensions" as standard language features,
> > and had done so since 1966.
>
> I would not call PL/I a fortran compiler, so that is irrelevant.

I have compiled FORTRAN code with a PL/I compiler.

In any case, it's relevant because the facilities you lacked
were available in PL/I.

> >> F90 addressed
> >> many of these limitations, but it was not available until the mid 90s
> >
> > early 1990s.
>
> The first compilers were available in about 1992,

In 1991.
That's why I said, "early 1990s".

> but it took two or
> three more years before enough vendors supported

There were a number of compilers available well before mid-1990s.

[Gary Scott]

I remember them being the "Purdue" extensions.

[Ron Shepard]

On 1/4/18 9:35 PM, campbel...@gmail.com wrote:
> I have used a range of machines since 70's and always used REAL*8 as it documented both the real precision and the hardware that was being used for the software development. Moving between CDC, Pr1me, Vax and very occasionally Cray, IBM or ICL, you never knew what REAL or DOUBLE PRECISION meant, but to this day REAL*8 has always meant a 64-bit real.

REAL*8 did not mean a 64-bit real on 60-bit CDC machines, or 36-bit
univac or DEC machines, or 24-bit Harris machines. But the REAL*8
declarations worked pretty much as expected in fortran code on these
computers nonetheless. It was mapped to the nearest available precision,
or there were compiler options that allowed the mapping that you wanted.
On the CDC machines you could get REAL 60-bit precision, on the univac
and DEC machines you could get 72-bit DOUBLE PRECISION, and on Harris
machines you could get 48-bit DOUBLE PRECISION. None of those were
64-bit reals, but they allowed one to write portable code that worked on
these along with dozens of other vendor hardware combinations.

By portable code, I mean that you can move to another machine and
compile the source with no change at all. Using a convertor or a
translator to process code prior to compilation is not portable in this
sense, that rather converts from one nonportable dialect to another.

I disagree with your comments about SELECTED_REAL_KIND(). I think it is
almost the ideal solution to the problem of writing portable code, and
in those cases where one cannot write strictly portable code, you can
isolate the nonportable code that needs to be changed to a single line
within a shared module. Especially now that RADIX can be selected and
IEEE support is standardized (f2008 I think), very detailed
specifications of the required floating point format can be given.

$.02 -Ron Shepard

[Dick Hendrickson]

On 1/5/18 8:08 AM, robin....@gmail.com wrote:
> On Friday, January 5, 2018 at 2:01:19 PM UTC+11, Ron Shepard wrote:
>> On 1/4/18 6:01 PM, r.....@gmail.com wrote:
>>> On Friday, January 5, 2018 at 4:12:59 AM UTC+11, Ron Shepard wrote:
>>>> On 1/3/18 5:24 AM, Thomas Koenig wrote:
>>>>>> VMS Fortran was, back in the day, the gold standard for Fortran
>>>>>> compilers.
>>>>> Also the source of numerous extensions which plague the Fortran
>>>>> world to this day :-)
>>>>
>>>> This is true, but using fortran extensions was a practical necessity in
>>>> the 70s and 80s because the language itself was so limited, even after
>>>> f77 was available. If you wanted command line arguments, that required
>>>> an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
>>>> an extension. If you wanted to write portable code that ran on a wide
>>>> range of hardware, you needed to use REAL*8 and that was an extension.
>>>
>>> You didn't need REAL*8.
>>> There was DOUBLE PRECISION.
>>
>> Unless you were on a Cray, in which case REAL*8 was REAL,
>
> As I said, you didn't need REAL*8. DOUBLE PRECISION
> was the standard way to get the extra precision.
> And anythihg standard was portable.
>

I think you're underestimating the practical problems in moving codes
from a 32/64 bit real/double to a 64/128 bit real/double system.

There were two classes of DOUBLE PRECISION users. A few actually needed
2 different precisions in their algorithms. Most needed about 64 bits
to get the right answer. They didn't want "extra precision", they
wanted a 48 (or so) bit mantissa.

Moving the second case to a CRAY was the problem. The hardware provided
essentially no help for double precision. DP multiply was simulated by
breaking the 96 bit mantissas into four 24 bit integer values, doing
enough cross multiplies, doing enough shifting and adding of the 48 bit
results to get a 96 bit result, adding the exponents (checking for a 97
bit sum), packing into floating point format. Worked perfectly, just a
bit slow ;). People bought CRAYs because they were fast. Simulating DP
to get the same answer much slower wasn't a solution.

Ron probably was a careful programmer, so he didn't have to worry about
mixing REAL*4 and REAL*8 variables in argument lists, COMMON, or
EQUIVALENCE. But, it wasn't obvious what the compiler should do to give
the user what he wanted. Command line parameters helped. But for
people who cared about speed, it was a joint effort between the
programmer and the compiler. It wasn't trivial.

Dick Hendrickson

[herrman...@gmail.com]

On Thursday, January 4, 2018 at 6:35:56 PM UTC-8, Ron Shepard wrote:

(snip)

> The DEC TOPS-10 and TOPS-20 machines were also 36-bit words, and they
> supported 7-bit ascii characters with five characters per word. My
> experience was before f77 compilers were available, so the character
> manipulation was done with hollerith and I/O using A formats on the
> integer or real variables.

The usual text file has five characters per word, and yes I believe
that is what Fortran does with A format.

For file names and such, TOPS-10 stores six SIXBIT characters
per word. There is a way to read/write from nine track tapes
that stores four 8 bit characters per word.

C requires that CHAR be at least 8 bits, and that copying an array
of unsigned char copies whole words. C compiles usual store four
9 bit characters per word.

And if you want to actually try this out, with an account on an
actual PDP-10:

http://www.livingcomputers.org/Discover/Online-Systems/Request-a-Login.aspx

[herrman...@gmail.com]

On Thursday, January 4, 2018 at 7:35:17 PM UTC-8, campbel...@gmail.com wrote:

(snip)

> I have used a range of machines since 70's and always used
> REAL*8 as it documented both the real precision and the
> hardware that was being used for the software development.
> Moving between CDC, Pr1me, Vax and very occasionally Cray,
> IBM or ICL, you never knew what REAL or DOUBLE PRECISION
> meant, but to this day REAL*8 has always meant a 64-bit real.

On DEC PDP-10 systems, REAL*8 is a 72 bit format.

The KA-10 doesn't have double precision hardware, and uses a
different format for software emulation, but 72 bits in
either case. Later models have it in hardware.

[herrman...@gmail.com]

On Friday, January 5, 2018 at 9:22:58 AM UTC-8, Ron Shepard wrote:

(snip)

> REAL*8 did not mean a 64-bit real on 60-bit CDC machines, or 36-bit
> univac or DEC machines, or 24-bit Harris machines. But the REAL*8
> declarations worked pretty much as expected in fortran code on these
> computers nonetheless. It was mapped to the nearest available precision,
> or there were compiler options that allowed the mapping that you wanted.
> On the CDC machines you could get REAL 60-bit precision, on the univac
> and DEC machines you could get 72-bit DOUBLE PRECISION, and on Harris
> machines you could get 48-bit DOUBLE PRECISION. None of those were
> 64-bit reals, but they allowed one to write portable code that worked on
> these along with dozens of other vendor hardware combinations.

I do remember Fortran source that had sets of (usually) DATA statemens
at the beginning, giving the values of constants for different systems.
For some algorithms, you fine tune for the different formats, rounding,
and such. You uncomment the ones appropriate for the hardware you have.

[robin....@gmail.com]

On Saturday, January 6, 2018 at 4:22:58 AM UTC+11, Ron Shepard wrote:

> On 1/4/18 9:35 PM, c.....@gmail.com wrote:
> > I have used a range of machines since 70's and always used REAL*8 as it documented both the real precision and the hardware that was being used for the software development. Moving between CDC, Pr1me, Vax and very occasionally Cray, IBM or ICL, you never knew what REAL or DOUBLE PRECISION meant, but to this day REAL*8 has always meant a 64-bit real.
>
> REAL*8 did not mean a 64-bit real on 60-bit CDC machines, or 36-bit
> univac or DEC machines, or 24-bit Harris machines. But the REAL*8
> declarations worked pretty much as expected in fortran code on these
> computers nonetheless. It was mapped to the nearest available precision,
> or there were compiler options that allowed the mapping that you wanted.
> On the CDC machines you could get REAL 60-bit precision, on the univac
> and DEC machines you could get 72-bit DOUBLE PRECISION, and on Harris
> machines you could get 48-bit DOUBLE PRECISION. None of those were
> 64-bit reals, but they allowed one to write portable code that worked on
> these along with dozens of other vendor hardware combinations.

REAL and DOUBLE PRECISION were standard and fully portable,
and allowed portable code to run on every system.

> By portable code, I mean that you can move to another machine and
> compile the source with no change at all.

That's what programs written in standand FORTRAN did.

[robin....@gmail.com]

On Saturday, January 6, 2018 at 5:37:51 AM UTC+11, Dick Hendrickson wrote:

> On 1/5/18 8:08 AM, r.....@gmail.com wrote:
> > On Friday, January 5, 2018 at 2:01:19 PM UTC+11, Ron Shepard wrote:
> >> On 1/4/18 6:01 PM, r.....@gmail.com wrote:
> >>> On Friday, January 5, 2018 at 4:12:59 AM UTC+11, Ron Shepard wrote:
> >>>> On 1/3/18 5:24 AM, Thomas Koenig wrote:
> >>>>>> VMS Fortran was, back in the day, the gold standard for Fortran
> >>>>>> compilers.
> >>>>> Also the source of numerous extensions which plague the Fortran
> >>>>> world to this day :-)
> >>>>
> >>>> This is true, but using fortran extensions was a practical necessity in
> >>>> the 70s and 80s because the language itself was so limited, even after
> >>>> f77 was available. If you wanted command line arguments, that required
> >>>> an extension. If you wanted IMPLICIT NONE to help locate bugs, that was
> >>>> an extension. If you wanted to write portable code that ran on a wide
> >>>> range of hardware, you needed to use REAL*8 and that was an extension.
> >>>
> >>> You didn't need REAL*8.
> >>> There was DOUBLE PRECISION.
> >>
> >> Unless you were on a Cray, in which case REAL*8 was REAL,
> >
> > As I said, you didn't need REAL*8. DOUBLE PRECISION
> > was the standard way to get the extra precision.
> > And anythihg standard was portable.

> I think you're underestimating the practical problems in moving codes
> from a 32/64 bit real/double to a 64/128 bit real/double system.

Not so, because our installation did exactly that, moved from
32-bit machine (4 byte) to 60-bit word machine.

> There were two classes of DOUBLE PRECISION users. A few actually needed
> 2 different precisions in their algorithms. Most needed about 64 bits
> to get the right answer.

Nonsense. 32 bit reals was adequate for most work.

[campbel...@gmail.com]

Robin,

"32 bit reals was adequate for most work"

We clearly have different experiences of past use of Fortran. 32 bit reals were
never adequate for the work I do in Structural FE analysis (r=38 fails and p=8
fails badly) or in 3D coordinate geometry and GIS (p=8 fails).

I hated getting code that used REAL or worse DOUBLE PRECISION, as I did not
know what precision was required. The development machine was often not
described and system include files usually went missing.
Using real*8 provided more certainty and before generic intrinsics, I used my
own interface library of ZSIN, ZCOS, ZABS etc to overcome most intrinsic
interfaces.
The advantage of REAL*8 was that when you used a machine that did not support
REAL*8 you got lots of messages, while using REAL or DOUBLE PRECISION gave no
indication of problems.

I suspect we would disagree on many more non-standard Fortran uses, that were
typically used in my field in 70's, especially mixed mode for memory allocation.

While F90 compilers may have been available by 1991, my experience was that it
was at least to 95+ before they were sufficiently stable/bug reduced to replace
the F77 compilers that were trusted with commercial use.
(I must admit that I am impressed with the stability of gFortran, especially
for F90/95 syntax and it's ability to support so many different vector
instructions)

John

[Lynn McGuire]

On 1/5/2018 7:10 PM, robin....@gmail.com wrote:
...

> Nonsense. 32 bit reals was adequate for most work.

...

Not in my 42 years of programming experience. 36 bit reals, yes. 32
bit reals, no.

You and I have way different software development experiences.

Lynn

[Lynn McGuire]

Not today. I am too busy trying to force our antiquated inline fortran
bytecode interpreter into handling pointer dereferencing automatically.

Lynn

[robin....@gmail.com]

In the days of limited memories, double precision was a luxury.
Single precision was used extensively for structural analysis.

> I hated getting code that used REAL or worse DOUBLE PRECISION, as I did not
> know what precision was required. The development machine was often not
> described and system include files usually went missing.
> Using real*8 provided more certainty and before generic intrinsics, I used my
> own interface library of ZSIN, ZCOS, ZABS etc to overcome most intrinsic
> interfaces.
> The advantage of REAL*8 was that when you used a machine that did not support
> REAL*8 you got lots of messages, while using REAL or DOUBLE PRECISION gave no
> indication of problems.

Why should it!?

> I suspect we would disagree on many more non-standard Fortran uses, that were
> typically used in my field in 70's, especially mixed mode for memory allocation.

> While F90 compilers may have been available by 1991, my experience was that it
> was at least to 95+ before they were sufficiently stable/bug reduced to replace
> the F77 compilers that were trusted with commercial use.

You could never trust a FORTRAN 77 or earlier compiler.

I would say that the problems you had related to the non-standard
"features" used in your FORTRAN programs.

More than likely, the F90 compilers found bugs in the FORTRAN 77
and earlier programs.

[campbel...@gmail.com]

> > On Saturday, January 6, 2018 at 12:10:31 PM UTC+11, robin....@gmail.com wrote:
> > > Nonsense. 32 bit reals was adequate for most work.

On Saturday, January 6, 2018 at 3:49:13 PM UTC+11, robin....@gmail.com wrote:
> In the days of limited memories, double precision was a luxury.
> Single precision was used extensively for structural analysis.
>

> You could never trust a FORTRAN 77 or earlier compiler.
>
> I would say that the problems you had related to the non-standard
> "features" used in your FORTRAN programs.
>
> More than likely, the F90 compilers found bugs in the FORTRAN 77
> and earlier programs.
>

I'm sorry but I don't know your background in structural analysis,
but these comments you have provided are not consistent with my 40
years experience (1975+) in developing and using structural analysis
software.

32 bit reals were never adequate for shell or beam bending elements.
Any set of equations that included both displacement and rotation freedoms
required more precision.

"You could never trust a FORTRAN 77 or earlier compiler" is blatantly
unsupportable, given the achievements in FE Analysis using Fortran prior
to 1990.

Prior to F90, all FEA programs required non-standard "features" to function effectively. You always complied with the F66 or F77 standards ?

Early versions of F90 and F95 compilers had many more bugs that their FTN or
F77 predecessors. F77 verification found many bugs in early F90 compilers.
How can you claim the opposite ?

Efficient 8 byte reals have been a necessity for FE analysis to achieve what
it has.

In the future, will there be a generally available hardware implementation for
something longer? Perhaps REAL*16 or even 64-bit OS real*10 or real*12 ?

[Stefano Zaghi]

Dear Campbell,

"
In the future, will there be a generally available hardware implementation for
something longer? Perhaps REAL*16 or even 64-bit OS real*10 or real*12 ? "

Today and in the future I hope to not see again non standard, non portable "real*x" definition... It is a very long time that Fortraners have standard and portable built-in functions like "selected_real_kind".

It is surprising that in 2018 there are still Fortraners supporting such a bad practice like "real*x" definition.

Concerning the hardware support for 16 bytes real representation I think that it is "secondary" aspect: fortran should remain an high level language by witch Fortraners could focus on math/physics selecting the precision/range they need (in a standard and portable way). The need to know how many bytes are used for data representation can be done "after" by means of other built-in facilities, e.g. for IO goals the bytes Number could be important.

My best regards.

[Phillip Helbig (undress to reply)]

In article <7ac9a8bc-272e-45de...@googlegroups.com>,

robin....@gmail.com writes:

> > > You didn't need REAL*8.
> > > There was DOUBLE PRECISION.
> >
> > Unless you were on a Cray, in which case REAL*8 was REAL,
>

> As I said, you didn't need REAL*8. DOUBLE PRECISION
> was the standard way to get the extra precision.
> And anythihg standard was portable.

DOUBLE PRECISION was standard. What it means is twice the storage of
REAL. The point is that the amount of storage for REAL was not
specified. In particular, REAL on the Cray was 8 bytes, but 4 on most
other compilers. So code which needed 8 bytes worked fine with REAL on
the Cray, but was not portable in that it wouldn't work with REAL
elsewhere. REAL*8, though not standard, meant the same thing
everywhere, i.e. 8 bytes. (However, as the recent discussion of VMS
Fortran shows, specifying just the number of bytes isn't enough, since
there can be (and, on VMS, were) different types with the same number of
bytes but different sizes of mantissa and exponent.)

The SELECTED_REAL_KIND allows one to PORTABLY (i.e., no changes needed
to the code) specify the amount of precision and range needed. This
assumes, of course, that the programmer actually knows how much range
and precision are needed.

[Tim Prince]

We used to hear the story frequently that the C5A military transport was
designed using single precision finite element structural analysis, and
this was blamed for a 50% shortfall from design goal wing fatigue life.
Single precision was considered adequate up to 40 elements, which of
course is far short of the requirement for aircraft design.
More recently, nonlinear analysis for automotive crash safety has been
carried out in single precision. Compiler "optimization" which performs
algebraic simplification (perhaps not entirely consistently) can break
carefully implemented element analysis. Even when everything is done
right, experience showed that single precision could perform adequately
only when the smallest elements were of 0.006 inch size (for a typical
automobile). Effective compromises could be found, such as using double
precision for displacements and rotations, but it requires an expert to
avoid (among other things) having a combination of single and double
precision run slower than full double. Careful use of the Fortran
standards for accurate expression evaluation, and preventing the
compiler from breaking them, is still a requirement.
Present implementations of "real*10" and software "real*16" don't
support vectorization, so there is no hope for competitive performance.
The closest current analogy for more than 64-bit precision is in the
decimal arithmetic libraries, where Intel (favoring a software
implementation) negotiated successfully with the decimal "hardware
implementation" (which I suppose is firmware) to make the standard
support either software or hardware implementation. Intel claims there
would be no significant advantage in hardware over the decimal
arithmetic library which we must rebuild every time we make a gfortran
compiler. Arbitrary precision libraries such as gmp and mpfr used by
gfortran for evaluation of constants have been improved to where they
are quite satisfactory in comparison for example with H-float which we
had on some VAX machines.

[herrman...@gmail.com]

On Saturday, January 6, 2018 at 4:52:59 AM UTC-8, Tim Prince wrote:
> On 1/6/2018 2:36 AM, campbel...@gmail.com wrote:

(snip)

> > I'm sorry but I don't know your background in structural analysis,
> > but these comments you have provided are not consistent with my 40
> > years experience (1975+) in developing and using structural analysis
> > software.

> > 32 bit reals were never adequate for shell or beam bending elements.
> > Any set of equations that included both displacement and rotation freedoms
> > required more precision.

(snip)

> We used to hear the story frequently that the C5A military transport was
> designed using single precision finite element structural analysis, and
> this was blamed for a 50% shortfall from design goal wing fatigue life.
> Single precision was considered adequate up to 40 elements, which of
> course is far short of the requirement for aircraft design.
> More recently, nonlinear analysis for automotive crash safety has been
> carried out in single precision. Compiler "optimization" which performs
> algebraic simplification (perhaps not entirely consistently) can break
> carefully implemented element analysis. Even when everything is done
> right, experience showed that single precision could perform adequately
> only when the smallest elements were of 0.006 inch size (for a typical
> automobile). Effective compromises could be found, such as using double
> precision for displacements and rotations, but it requires an expert to
> avoid (among other things) having a combination of single and double
> precision run slower than full double. Careful use of the Fortran
> standards for accurate expression evaluation, and preventing the
> compiler from breaking them, is still a requirement.

Single precision results are fine for most applications. Often
enough, that requires double precision arithmetic.

Specifically, numerical derivatives are great for losing precision,
and higher derivatives lose it faster.

Finite elements are an especially good example. Note that the
smaller you make the elements, such as to better approximate the
continuous limit, the worse the results from precision loss.

Smaller elements means that the values on each one are closer
together, and so lose more precision when subtracted in computing
a derivative. Often enough, you need second derivatives.

[spectrum]

On Wednesday, December 27, 2017 at 2:19:57 AM UTC+9, kargl wrote:
> Patches aren't needed. The gfortran manual explains its convention
> in the introduction of section 9.1. It states:
>
> The enumeration of the KIND type parameter is processor defined in
> the Fortran 95 standard. GNU Fortran defines the default integer
> type and default real type by INTEGER(KIND=4) and REAL(KIND=4),
> respectively. The standard mandates that both data types shall
> have another kind, which have more precision. On typical target
> architectures supported by gfortran, this kind type parameter is
> KIND=8. Hence, REAL(KIND=8) and DOUBLE PRECISION are equivalent.
> In the description of generic intrinsic procedures, the kind type
> parameter will be specified by KIND=*, and in the description of
> specific names for an intrinsic procedure the kind type parameter
> will be explicitly given (e.g., REAL(KIND=4) or REAL(KIND=8)).
> Finally, for brevity the optional KIND= syntax will be omitted.
>
> I suspect other vendors have similar conventions explained in their
> documentation.
>
> --
> steve

Thanks very much for clarification on the gfortran manual and the part
describing the convention used for KIND. I have not read all the manual pages
throughout (I only consult the online manual for particular things via search),
but I know that kind=4 and 8 etc are conventions used in gfortran and ifort.

https://gcc.gnu.org/onlinedocs/gfortran/index.html#SEC_Contents
https://gcc.gnu.org/onlinedocs/gfortran/Introduction-to-Intrinsics.html#Introduction-to-Intrinsics

# I'm not complaining about this choice, but rather trying to write that they are
"de fact standard" now used in major compilers. So I guess people would feel
feel it safe to follow this convention, which is (what I thought) one of the possible
reasons why people often use real(8) directly (in my above post).
Very personally, I feel this choice is nice and intuitive and probably
made the migration from F77 -> 90 smooth for many users (incl. me), though
I guess other people may have different ideas (e.g., as written elsewhere).

[spectrum]

> > There were two classes of DOUBLE PRECISION users. A few actually needed
> > 2 different precisions in their algorithms. Most needed about 64 bits
> > to get the right answer.
>
> Nonsense. 32 bit reals was adequate for most work.

Though I haven't followed the contexts (of the above talk) very well,
there seem to be various recent studies on the effective use of 32 and 64-bit
precisions, many of which seem to be motivated by efficient use of GPU.
For example...

Routine Microsecond Molecular Dynamics Simulations with AMBER on GPUs (2012)
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3348677/

In this paper, the authors study the effect of using single-precision entirely (SPSP),
or used both single- and double-precision (SPDP), and full double-precision entirely
(DPDP). For SPSP, the total energy of the system drifts more and more in time, while
SPDP and DPDP are able to conserve total energy pretty well. (In the case of
SPDP, the accumulation of precision-sensitive quantities are done in double
precision, while most other calculations are done in single precision.

# But it should be noted that the above "molecular dynamics (MD)" simulation is
not too sensitive to the precision (and indeed, many old MD calculations were done
in single precision). But one difference from the "old days" is that we run
a very long trajectory recently (on the microsecond scale, which amounts to
10^9 time steps). So the error accumulation is probably of more concern than
before. But fortunately, MD is usually inherently "chaotic" (and only statistical
average matters), so some "noise" is pretty acceptable (in contrast to other
fields such as electronic structure theory or structural mechanics?)

[FortranFan]

On Wednesday, January 3, 2018 at 11:53:39 AM UTC-5, Steve Lionel wrote:

> .. I did say that IEEE float is pretty much universal
> now .

Can Fortran move on please?

Considering there are industries and organizations who now consciously do *all* their computing using IEEE floating-point arithmetic and by including in the
language a proposal led by Van Snyder that has been presented previously to the Fortran standards committee where it is possible to define new types from existing ones and by building on it to include a few more *new intrinsic types*, can the language finally become simpler for many practitioners, especially the industry-based practical types as well as casual coders, by allowing them to move on from the confusion with KINDs of REALs?!

So the proposal by Van Snyder is to introduce a NEW keyword and be able to do things such as:

--- pseudo code 1 ---
..
! create a new type 'fpp6' as in a floating-point type with a
! precision of at least 6 digits
type, new :: fpp6 => real(kind=selected_real_kind(p=6))

..
! define a variable of type fpp6
fpp6 :: foo
! where foo is the same type as real(kind=selected_real_kind(p=6))
..

--- end pseudo code 1 ---

or with IEEE arithmetic

--- pseudo code 2 ---
use, intrinsic :: ieee_arithmetic, only : ieee_selected_real_kind
..
! create a new type 'fpb32' as in a floating-point type with the
! same attributes as given in the IEEE standard
! (https://www.iso.org/standard/57469.html) on binary formats
type, new :: fpb32 => real(kind=ieee_selected_real_kind(p=6))
type, new :: fpb64 => real(kind=ieee_selected_real_kind(p=15))
type, new :: fpb128 => real(kind=ieee_selected_real_kind(p=33))

..
! define a variable of type fpb64
fpb64 :: foo
! where foo is the same type as real(kind=selected_real_kind(p=15))
..

--- end pseudo code 2 ---

But it will be even better for many coders

1) if fpb32, fpb64, fpb128 are types prefined in the *intrinsic* module ieee_arithmetic,

AND

2) if *intrinsic* modules such IEEE_* are USE-associated by default, that coders need to include some instruction such as "IMPORT NONE" to not do so.

Then many industrial users as well as most casual coders can simply do

fpb64 :: foo

to declare an object 'foo' that is of IEEE floating-point type with the binary64 format defined in the IEEE 754:2008 standard. And that's 2 keystrokes less typing than REAL(8) and yet infinitely more informative.

But of course additional aspects, especially with literal and named constants, will need to be addressed. But such improvements are called for anyway and there have been prior proposals on such matters as well that the committee should revisit for Fortran 2020 revision.

Assuming suitable enhancements for constants are also introduced, a middle-schooler coding in year 2022 can write:

! solve ax^2 + bx + c = 0 using floating-point arithmetic
fpb64 :: a, b, c
..
fpb64 :: discriminant
fpb64 :: root1, root2

read( .. ) a, b, c
..
discriminant = b**2 - 4*b*c
if ( discriminant > 0) then
root1 = ..
root2 = ..
..
else
..
end if

No more mucking around with REALs (is God real if declared an integer!) and their KINDs then, both are terms that are not part of any computer education/instruction anywhere for floating-point data.

[robin....@gmail.com]

On Saturday, January 6, 2018 at 10:12:04 PM UTC+11, Phillip Helbig (undress to reply) wrote:
> In article <7.....@googlegroups.com>,

> r.....@gmail.com writes:
>
> > > > You didn't need REAL*8.
> > > > There was DOUBLE PRECISION.
> > >
> > > Unless you were on a Cray, in which case REAL*8 was REAL,
> >
> > As I said, you didn't need REAL*8. DOUBLE PRECISION
> > was the standard way to get the extra precision.

> > And anything standard was portable.

>
> DOUBLE PRECISION was standard. What it means is twice the storage of
> REAL. The point is that the amount of storage for REAL was not
> specified.

It was not specified because machines came in two flavors:
word addressed and byte addressed.
A word machine could have any nynmber of bits. It was not
the business of language standards to dictate a word size
to computer manufacturers.

Machine word sizes (in bits) included 16, 24, 32, 36, 40,
48, 60, and 64.
Byte machines included character sizes of 6, 8, and 12 bits.

So REAL typically meant anything from 32 bits to 64 bits.

> In particular, REAL on the Cray was 8 bytes, but 4 on most
> other compilers.

CDC computers had 60 bit words, with a 48-bit exponent
for floating-point.

> So code which needed 8 bytes worked fine with REAL on
> the Cray, but was not portable in that it wouldn't work with REAL
> elsewhere.

Change it to DOUBLE PRECISION.

> REAL*8, though not standard, meant the same thing
> everywhere, i.e. 8 bytes.

No it didn't. And you are forgetting the CDC machines
with their 60-bit words.

> (However, as the recent discussion of VMS
> Fortran shows, specifying just the number of bytes isn't enough, since
> there can be (and, on VMS, were) different types with the same number of
> bytes but different sizes of mantissa and exponent.)
>
> The SELECTED_REAL_KIND allows one to PORTABLY (i.e., no changes needed
> to the code) specify the amount of precision and range needed.

Most of the time, this is OK, except for cases where the chosen (single)
precision turns out to be double precision, and then you're in trouble
when you request double precision.

> This
> assumes, of course, that the programmer actually knows how much range
> and precision are needed.

And hence not entirely portable.

[robin....@gmail.com]

On Saturday, January 6, 2018 at 6:36:54 PM UTC+11, c....@gmail.com wrote:

> > > On Saturday, January 6, 2018 at 12:10:31 PM UTC+11, r......@gmail.com wrote:
> > > > Nonsense. 32 bit reals was adequate for most work.
>
> On Saturday, January 6, 2018 at 3:49:13 PM UTC+11, robin....@gmail.com wrote:
> > In the days of limited memories, double precision was a luxury.
> > Single precision was used extensively for structural analysis.
> >
> > You could never trust a FORTRAN 77 or earlier compiler.
> >
> > I would say that the problems you had related to the non-standard
> > "features" used in your FORTRAN programs.
> >
> > More than likely, the F90 compilers found bugs in the FORTRAN 77
> > and earlier programs.

> I'm sorry but I don't know your background in structural analysis,
> but these comments you have provided are not consistent with my 40
> years experience (1975+) in developing and using structural analysis
> software.
>
> 32 bit reals were never adequate for shell or beam bending elements.
> Any set of equations that included both displacement and rotation freedoms
> required more precision.

As I said, 32-bits were extensively used for structural work,
including, I believe, for aircraft design, in the 1950s and 60s.

> "You could never trust a FORTRAN 77 or earlier compiler" is blatantly
> unsupportable,

Which FORTRAN compilers (FORTRAN 77 and earlier)
checked for uninitialized variables?

Which FORTRAN compilers checked that the types of actual arguments
and dummy arguments agreed?

Which FORTRAN compilers checked that the number of actual arguments
agreed with the number of dummy arguments?

Which FORTRAN compilers checked that the lengths of COMMON blocks
in the main program and in various subroutines and functions agreed?

Which FORTRAN compilers checked for subscript bounds errors?

Then there are the typical programming/coding errors of the time
including mis-typed variables (including the popular O for 0, I for 1)
inadvertently going beyond column 72, mis-counting the lengths of
Hollerith constants, missing fullstop in .EQ., .NE., G.T., etc ;
DO 10 I = 1. 20 (and probably many other similar errors)

> given the achievements in FE Analysis using Fortran prior
> to 1990.
>
> Prior to F90, all FEA programs required non-standard "features"
> to function effectively.

Most of the "extensions" could be avoided with ordinary FORTRAN programming.
The "extensions" were designed to attract companies to buy the vendor's
computer, and once the "extensions" became widely used at the site,
the site was "locked on" to using that product (and subsequent ones).

> You always complied with the F66 or F77 standards ?

> Early versions of F90 and F95 compilers had many more bugs that their FTN or
> F77 predecessors. F77 verification found many bugs in early F90 compilers.
> How can you claim the opposite ?

We did not find that. On the contrary, I'll wager that the
F90 and F95 compilers found bugs in the FORTRAN verification suites.

> Efficient 8 byte reals have been a necessity for FE analysis to achieve what
> it has.
>
> In the future, will there be a generally available hardware implementation for
> something longer? Perhaps REAL*16 or even 64-bit OS real*10 or real*12 ?

You can always try rolling your own extended precision.

[dpb]

On 1/5/2018 7:05 PM, robin....@gmail.com wrote:
> On Saturday, January 6, 2018 at 4:22:58 AM UTC+11, Ron Shepard wrote:

...

>> By portable code, I mean that you can move to another machine and
>> compile the source with no change at all.
>
> That's what programs written in standand FORTRAN did.

...

Just not necessarily the same or desired _result_

--

[Sjouke Burry]

You forgot the 18bit pdp7. :)

[campbel...@gmail.com]

Robin,

In FE calculations, I usually loose 10^7 precision when mixing axial and bending
stiffness. Aircraft design, in the 1950s and 60s would have needed much care in
mesh sizing to mitigate this effect. Not many equations available then so it
would be interesting to see the models that were practically used.

I don't recall all the pre-F95 compilers I used, as I did not use a PC till
late 80's. Before then I mainly used Pr1me and Apollo. No CDC use after 76.
I found Vax to require too much non-standard code which limited portability,
perhaps "provided" rather than "required".
All hardware supplied compilers I used included extensions to F77 standard.
My recollection is the "extensions" were requested and a necessity.
Apparently IMPLICIT NONE was not in F77 standard.
How did you avoid using INCLUDE ?

Very early PC F77 compilers were Microsoft and HP.
Lack of extensions were a disappointment.
"Huge" and overlay linkers are gladly left behind.

By far the best compiler I used on PC was Salford F77, which had most of the
diagnostics you describe. I found it the best diagnostic compiler at the time.
You ask a number of questions "Which FORTRAN compilers" and the answer to all
these is Salford F77 (now Silverfrost).
It had an extensive library of utility routines and graphics support.

Lahey also provided a F77 compiler that had good diagnostics.
Lahey provided an early F90, but I did not adopt F90/95 till about 1996, mainly
because of the lack of F90 compiler reliability and inferior performance of .exe.
I did not trust F90/95 compilers till about 97/98.

Silverfrost F95 provided different KIND values as to most other compilers.
On Silverfrost, INTEGER_KINDS = (/ 1,2,3,4 /) and REAL_KINDS = (/ 1,2,3 /)
Use of REAL(8) is not supported by default and requires /ALT_KINDS compiler option.
All compilers I have used supported REAL*8 by default.

The AVX registers support 4-byte and 8-byte vector calculations.
I wonder why they can't adapt to support 12 or 16 byte formats.
I find library support of 10-byte or 16-byte outside the AVX registers is not
an option.