Re: Unexpected 15 digits precision from "REAL"



On 25 mrt, 10:31, Terence <tbwri...@xxxxxxxxx> wrote:
I am working on many old Fortran IV programs written for the IBM
mainframes of 1961-66.

My question is "What was (in the old days) the default precision of
real variables NOT defined as "double precision" nor as REAL*8, but
simple as
        DIMENSION A(50),B(5),C(1)?

The data type declarations are almost all defined with dimension
statements. All references to a variable are considered to be of REAL
type unless the variable name commenced with one of the letters I to N
in wgich case ther were of integer type.  There are no character and
almost no logical variables in the old programs. And the IMPLICIT
statement didn't exist at that time.

Compilations of the programs today, produce executables which run the
test data sets and ALMOST produce the exact published results on
comparison.

The only differences between expected and observed results exist only
for real variables printed or output with more than 7 digits of
precision.
(E.g. a format of F15.7 will produce trailing decimal zeroes in such a
way that the digits to the left of the string of trailing zeroes are
no more than 7 in number.

Obviously, in the PC compilation, the real variables are automatically
REAL*4 (and the integers are INTEGER*4). As a check, I dumped
unformatted work files from PC runs and determined that, on an Intel-
cored  PC, the default data types were of width 4 bytes for both real
and integer variables as expected . (Compilers CVF 6.6.c and MS 3.31)

But the original compilations produced data with at least 15 digits of
precsion. Which IMPLIES that the default precision was REAL*8.

Which if true, because of COMMON alignments, means the integers
variables had to be INTEGER*8 too, Otherwise the programs wouldn't run
(unless you got lucky).

And I noted that "double precision" was ONLY used to save 6-byte
character strings as constants.

So I know why the data output from compile-running on a PC has only 7
digits of precision (Reals are REAL*4 unless specified otherwise). But
what was the situation on the Mainframes of that time?.

Am I missing something about what REAL and INTEGER meant and produced
'back then'?

One thing that can be confusing is that a single-precision IEEE real
may
have only 6 or 7 decimal digits of precision, but you need at least
12 digits to reconstruct it exactly in binary form. (For double-
precision
that is 12 digits of precision and 17 required for reconstruction.)

I am not sure what the characteristics are for reals other than those
formatted according to the IEEE standard, but it is likely to be
similar.

Regards,

Arjen
.



Relevant Pages

  • Re: Unexpected 15 digits precision from "REAL"
    ... precision to get along but the 32 bit one was struggling badly. ... Compilations of the programs today, ... way that the digits to the left of the string of trailing zeroes are ... digits of precision (Reals are REAL*4 unless specified otherwise). ...
    (comp.lang.fortran)
  • Re: Rounding off double precision
    ... -|support quad precision, there is no statement that will work. ... Public domain 2004 by James Van Buskirk ... print *, "dp reals are of kind number", number ...
    (comp.lang.fortran)
  • Re: Unexpected 15 digits precision from "REAL"
    ... My question is "What was the default precision of ... Compilations of the programs today, ... way that the digits to the left of the string of trailing zeroes are ... digits of precision (Reals are REAL*4 unless specified otherwise). ...
    (comp.lang.fortran)
  • Unexpected 15 digits precision from "REAL"
    ... My question is "What was the default precision of ... Compilations of the programs today, ... way that the digits to the left of the string of trailing zeroes are ... digits of precision (Reals are REAL*4 unless specified otherwise). ...
    (comp.lang.fortran)
  • Re: Rounding off double precision
    ... -|support quad precision, there is no statement that will work. ... Public domain 2004 by James Van Buskirk ... print *, "dp reals are of kind number", number ... understanding them is that existing machines only support a couple ...
    (comp.lang.fortran)