Possible implicit declaration of double precision in old compilers

[ewan.b...@aurecongroup.com]

I'm looking for advice about whether or not early 1970s Fortran compilers could implicitly declare double-precision variables.

I have some very old engineering software, written in Fortran in the early 1970s and updated only superficially since then.

Background: the program is Subway Environmental Simulation (SES), engineering software developed for the US Department of Transportation to model air and heat movement in underground railway systems. There is some information about what computer systems the software was originally developed on. The programmer's manual (dated 1974) states that the program was developed on a Univac 1108 running University Computing Company's EXEC 2 operating system. Also that the developers stuck to ANSI Standard Fortran (as it was in 1974) in order to allow it to run on an IBM 360, 370 or CDC 6600; and that the developers "excluded from use many of the machine-dependent tricks that are available on a particular computer, since they might not exist on another computer." I guess this means that the code is either Fortran 66 or one of the development versions that eventually turned into Fortran 77. It certainly looks more like Fortran 66 than 77; I keep coming across arithmetic IF statements.

I have been compiling my modifed versions with gfortran 4.6.0. I understand that gfortran is particularly strict in its interpretation of the Fortran standards. My background is Algol 68 (which is strongly typed) so old Fortran's implicit type system induces enough paranoia to make me to turn on all the warnings (gfortran -Wall). As a result, a number of statements make gfortran raise a warning about narrowing variables for double- to single precision. A typical example is:

DUMY1=DBLE((1.0+(MU*(MU+14.0)-399.0)/(768.0*X*X))/SQR2)
1
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)

DUMY1 was not explicitly declared before this line of code; and there are no "IMPLICIT DOUBLE PRECISION" statements in the routine's header. The variables used in the expression (the constants, MU, X & SQR2) are a mix of double- and single-precision. If I understand the compiler warnings correctly, DUMY1 is initialised as a single-precision real; a double-precision expression is then evaluated; the double-precision value is then narrowed to single precision and is stored in DUMY1.

Further on in the same routine the single-precision DUMY1 is used in the calculation of an explicitly-declared double-precision variable.

My take on the warning message that it is pointless to include the DBLE statement around the expression. Or at least, it's pointless when compiling with modern, strict gfortran.

My question: is the implicit declaration for DUMY1 just sloppy work on the part of the original programmer working in 1974, or were there early 1970s Fortran compilers - running on the UNIVAC 1108, IBM 360/370 or CDC6600 - that would have had the ability to pick up on the presence of the DBLE statement and implicitly declare the DUMY1 as double precision? Was such implicit declaration of double precision data types possible/common practice back then?

I appreciate this is a question that can probably only be answered by a compiler author with a long memory, but it would be interesting to learn the facts.

Regards,

Ewan

[Louis Krupp]

On Tue, 5 Mar 2013 02:25:07 -0800 (PST), ewan.b...@aurecongroup.com
wrote:

>I'm looking for advice about whether or not early 1970s Fortran compilers could implicitly declare double-precision variables.
>
>I have some very old engineering software, written in Fortran in the early 1970s and updated only superficially since then.
>
>Background: the program is Subway Environmental Simulation (SES), engineering software developed for the US Department of Transportation to model air and heat movement in underground railway systems. There is some information about what computer systems the software was originally developed on. The programmer's manual (dated 1974) states that the program was developed on a Univac 1108 running University Computing Company's EXEC 2 operating system. Also that the developers stuck to ANSI Standard Fortran (as it was in 1974) in order to allow it to run on an IBM 360, 370 or CDC 6600; and that the developers "excluded from use many of the machine-dependent tricks that are available on a particular computer, since they might not exist on another computer." I guess this means that the code is either Fortran 66 or one of the development versions that eventually turned into Fortran 77. It certainly looks more like Fortran 66 than 77; I keep coming across arithmetic IF statements.

I would be surprised if there were an ANSI FORTRAN in 1974. A
portable subset of the language, and a few people wise enough to stick
to it, yes (although I certainly wasn't one of those people).

I looked up University Computing Company, and it seems to have been a
service bureau back in the early 70s. They had Univac systems. I'm
not sure if you meant that UCC wrote EXEC 2 (as far as I know, it came
from Univac) or that UCC modified it (in which case they might have
modified the FORTRAN compiler as well).

A search for UCC and Univac turned up this page:

http://www.evolswsys.com/Resume_Body.html

I don't know this gentleman, but if you need information on UCC or old
Univac FORTRAN, he might be able to help you. He might appreciate an
opportunity to wax nostalgic. You never know.

>
>I have been compiling my modifed versions with gfortran 4.6.0. I understand that gfortran is particularly strict in its interpretation of the Fortran standards. My background is Algol 68 (which is strongly typed) so old Fortran's implicit type system induces enough paranoia to make me to turn on all the warnings (gfortran -Wall). As a result, a number of statements make gfortran raise a warning about narrowing variables for double- to single precision. A typical example is:
>
> DUMY1=DBLE((1.0+(MU*(MU+14.0)-399.0)/(768.0*X*X))/SQR2)
> 1
> Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)
>
>DUMY1 was not explicitly declared before this line of code; and there are no "IMPLICIT DOUBLE PRECISION" statements in the routine's header. The variables used in the expression (the constants, MU, X & SQR2) are a mix of double- and single-precision. If I understand the compiler warnings correctly, DUMY1 is initialised as a single-precision real; a double-precision expression is then evaluated; the double-precision value is then narrowed to single precision and is stored in DUMY1.
>
>Further on in the same routine the single-precision DUMY1 is used in the calculation of an explicitly-declared double-precision variable.
>
>My take on the warning message that it is pointless to include the DBLE statement around the expression. Or at least, it's pointless when compiling with modern, strict gfortran.
>
>My question: is the implicit declaration for DUMY1 just sloppy work on the part of the original programmer working in 1974, or were there early 1970s Fortran compilers - running on the UNIVAC 1108, IBM 360/370 or CDC6600 - that would have had the ability to pick up on the presence of the DBLE statement and implicitly declare the DUMY1 as double precision? Was such implicit declaration of double precision data types possible/common practice back then?

My first guess would be sloppy work. An older compiler might not have
warned about these things.

It's also conceivable that the compiler had a command-line option to
make all reals double precision by default. Some modern compilers do
that, and the ancients were just as lazy as programmers are today.

>
>I appreciate this is a question that can probably only be answered by a compiler author with a long memory, but it would be interesting to learn the facts.

Facts? Speculation is lots more fun.

Louis

[timprince]

implicit double precision (a-h,o-z)
was a ubiquitously employed extension for Fortran 66 compilers, once the
substandard IBM 360 single precision was introduced. (There wasn't any
standard about accuracy of single precision other than quality of
implementation at the time; DEC PDP and VAX machines were the first
widely available with adequate precision for 32-bit data type).

You should be able to find the full Fortran 66 standard on line.
Under the f66 standard, implicit changes of data type across assignment
weren't permitted, but that would explain the use of DBLE only in the
case of assignment of a single precision expression to a double
precision. The DBLE does look redundant in the case you pose.

By the way, an application I'm working on now still has instances of
pre-f77 style, but this isn't one of those.

There was no compiler claiming to implement F77 until 1978, and
(extended) F66 compilers continued in use at least until 1985.

I don't know about long memory; mine may be failing me, and I'm
certainly not a compiler author. I did start on Fortran in 1967.

--
Tim Prince

[tim prince]

On 3/5/2013 5:25 AM, ewan.b...@aurecongroup.com wrote:

[Robin Vowels]

On Mar 5, 9:25 pm, ewan.benn...@aurecongroup.com wrote:
> I'm looking for advice about whether or not early 1970s Fortran compilers could implicitly declare double-precision variables.
>
> I have some very old engineering software, written in Fortran in the early 1970s and updated only superficially since then.
>
> Background: the program is Subway Environmental Simulation (SES), engineering software developed for the US Department of Transportation to model air and heat movement in underground railway systems.  There is some information about what computer systems the software was originally developed on.  The programmer's manual (dated 1974) states that the program was developed on a Univac 1108 running University Computing Company's EXEC 2 operating system.  Also that the developers stuck to ANSI Standard Fortran (as it was in 1974) in order to allow it to run on an IBM 360, 370 or CDC 6600; and that the developers "excluded from use many of the machine-dependent tricks that are available on a particular computer, since they might not exist on another computer."  I guess this means that the code is either Fortran 66 or one of the development versions that eventually turned into Fortran 77.  It certainly looks more like Fortran 66 than 77; I keep coming across arithmetic IF statements.
>
> I have been compiling my modifed versions with gfortran 4.6.0.  I understand that gfortran is particularly strict in its interpretation of the Fortran standards.  My background is Algol 68 (which is strongly typed) so old Fortran's implicit type system induces enough paranoia to make me to turn on all the warnings (gfortran -Wall).  As a result, a number of statements make gfortran raise a warning about narrowing variables for double- to single precision.  A typical example is:
>
>       DUMY1=DBLE((1.0+(MU*(MU+14.0)-399.0)/(768.0*X*X))/SQR2)
>             1
>  Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)

This looks like a piece of sloppy coding.
If the MU, X, and/or SQR2 are double precision, then
DBLE does nothing.
If none of MU, X, or SQR2 is double precision,
DBLE performs an unnecessary conversion from single to double,
then the assignment performs the opposite, for no purpose.

I guess it depends on what DUMY1 is used for (you didn't show us)
whether it was a mistake that DBLE was used, or whether
it was a mistake that DUMY1 was not declared.

> DUMY1 was not explicitly declared before this line of code; and there are no "IMPLICIT DOUBLE PRECISION" statements in the routine's header.  The variables used in the expression (the constants, MU, X & SQR2) are a mix of double- and single-precision.  If I understand the compiler warnings correctly, DUMY1 is initialised as a single-precision real; a double-precision expression is then evaluated; the double-precision value is then narrowed to single precision and is stored in DUMY1.
>
> Further on in the same routine the single-precision DUMY1 is used in the calculation of an explicitly-declared double-precision variable.
>
> My take on the warning message that it is pointless to include the DBLE statement around the expression.  Or at least, it's pointless when compiling with modern, strict gfortran.
>
> My question: is the implicit declaration for DUMY1 just sloppy work on the part of the original programmer working in 1974, or were there early 1970s Fortran compilers - running on the UNIVAC 1108, IBM 360/370 or CDC6600 - that would have had the ability to pick up on the presence of the DBLE statement and implicitly declare the DUMY1 as double precision?

Definitely not.

As to your question about sloppy programming,
many errors crept through FORTRAN programs undetected.
Undeclared variables were not treated as errors,
on account of the I to N rule.

>  Was such implicit declaration of double precision data types possible/common practice back then?

Implicit declarations were common back then.

[Gordon Sande]

Very remote chance that the original folks are trying to protect
against cancellation
within this expression. That would only make sense if the thnigs like
MU and X were
"error free" as might happen if this is some sort of interpolation.
More likely it is
just sloppy and they were relying on a compiler switch to get all
doubles. In the good
old days of a mix of 32, 36, 48 and 60 bit machines the "force double"
option was more
common. Still there to deal with 60 bit codes that need to be run on 32
bit chips.

[glen herrmannsfeldt]

ewan.b...@aurecongroup.com wrote:
> I'm looking for advice about whether or not early 1970s Fortran
> compilers could implicitly declare double-precision variables.

> I have some very old engineering software, written in Fortran in
> the early 1970s and updated only superficially since then.

(snip)

> Also that the developers stuck to ANSI Standard Fortran (as it was
> in 1974) in order to allow it to run on an IBM 360, 370 or CDC 6600;
> and that the developers "excluded from use many of the machine-dependent
> tricks that are available on a particular computer, since they might
> not exist on another computer."

(snip)

> DUMY1=DBLE((1.0+(MU*(MU+14.0)-399.0)/(768.0*X*X))/SQR2)
> 1
> Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1)

The OS/360 successor compilers had/have IMPLICIT, and it was often used
such that all default REAL variables were REAL*8. I believe that there
is also a PARM (that is, the JCL term to specify compiler options)
for it, but I never used that one.

IMPLICIT REAL*8 (A-H,O-$)

(IBM believes in a 27 letter alphabet.)

For the CDC6600, I believe it was usual to use single precision,
with its 60 bit words, where double precision would be used for S/360.

The Univac 1108 has 36 bit words, which are sometimes enough more
than 32 that single is enough.

There are some manuals on bitsavers for Univac, but none for the 1108,
and not so many for the 1107.

But a compiler option to turn everything double precision should not,
then, require DBLE. Seems more likely that someone forgot the
appropriate declaration.

-- glen

[Richard Maine]

Louis Krupp <lkr...@nospam.pssw.com.invalid> wrote:

> I would be surprised if there were an ANSI FORTRAN in 1974.

Sure there was. The first ANSI Fortran was published in 1966 and later
became commonly known as Fortran 66.

Programmers paying any attention to it was another matter. I was
programming in that era and earlier (my first Fortran was in 1968), but
the first copy of a Fortran standard I ever saw was f77. I didn't run
across a copy of the f66 standard until substantially later. During the
f66 days, I don't think I was even aware of the existance of a standard.
Neither were the other programmers I worked with. Those that were
particularly concerned about portability just had some word-of-mouth
rules of thumb (a mixed metaphor that evokes images) about what things
were portable. Most programmers didn't seem to care about portability at
all; after all, there was only one computer on site so the question only
came up when sending code to other places or on the rare occasion that
the on-site machine was replaced by one from another vendor.

Other people have adequately answered the OP's question. I'll just echo
the opinion that the problem he showed was almost certainly sloppy
programming. Yes, that's just a guess, but I'd place pretty good money
on it.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Steven G. Kargl]

On Tue, 05 Mar 2013 02:25:07 -0800, ewan.bennett wrote:

> I have been compiling my modifed versions with gfortran 4.6.0. I understand that gfortran is
> particularly strict in its interpretation of the Fortran standards.

Others have answered the possibly sloppy program question. gfortran without the
-std option will actually accept a fairly large boat load of vendor extensions. With
-Wall, she will emit warning but never the less try to compile whatever she was fed.

While I normally discourage the use of the -fdefault-real-8 option, it may allow you
to compile and reproduce known results. If you use this option, which I do not
recommend, then at least try to minimize the use and also include the
-fdefault-integer-8 and -fdefault-double-8 options. If you update to the latest
gfortran 4.7.x, you can use -freal-4-real-8, which is a much better option than
the -fdefault-real-8 option.

--
steve

[Ron Shepard]

In article <1kz92zg.1l57nu61eagonsN%nos...@see.signature>,

nos...@see.signature (Richard Maine) wrote:

> Other people have adequately answered the OP's question. I'll just echo
> the opinion that the problem he showed was almost certainly sloppy
> programming. Yes, that's just a guess, but I'd place pretty good money
> on it.

Just to throw in another opinion on this, I'd say that it is about
50% chance that this was an undetected error in the code.

The other 50% is that the compiler was somehow working in a mode
where variables were double precision by default. That might have
been done with a compiler option at runtime as others have
mentioned. Another possibility is that the compiler itself was
modified by the local system programmers so that this was the
default. There might have been multiple versions of such locally
modified compilers, and the programmer would invoke the one that
closest fit his needs. I used compilers like this for various
reasons -- one that I remember was that the default number of
connected files was limited to, I think 16, but the local system
programmers had a modified version that allowed a larger number.

If it was required at a particular facility to compile a lot of CDC
code (60-bit single precision), then a Univac compiler configured to
facilitate that task might have been available. This would have
included changing the default precisions for reals and maybe also
integers. For example, if a facility had been using CDC hardware,
and then switched to Univac hardware, then the system programmers
might well have made local modifications to their compiler to "help"
their users.

I was programming in fortran in the late 70's, and this was common.
They might have even gotten help from the new vendor to do these
modifications. Compilers at that time were closely tied to the
hardware, and vendors encouraged the use of compiler extensions and
other compiler features to lock users into their systems.

$.02 -Ron Shepard

[ewan.b...@aurecongroup.com]

Thanks to all for the suggestions and information. The consensus confirm what I thought: that the issue raised was most likely poor coding on the part of the original programmer; and that compilers in the early 1970s were not set up to realize that if you had a DBLE() fronting an expression, the compiler should declare a double-precision mode implicitly.

As always happens when a question is irrevocably posted, as soon as I pressed send I realized I should have written it in slightly different terms - a question like "did Fortran 66 compilers have a form of duck typing?" would have been more clear. Fortunately all the responders picked up the right impression from what I posted, and the answer is a resounding no; so I'll mark that one down to l'esprit d'escalier. Gah.

Several responders raised the suggestion that compiler options might have been set to explicitly force all real variables to be double-precision instead of single-precision: this is an interesting possibility. Only a few of the routines need to use double precision and I think that all the double-precision variables in those routines that have external interfaces are explicitly defined as double precision, both in the routines that calculate with double precision and in the routines that call them.

So my uninformed speculation (I am dreaming this theory up as I'm typing) is that they might have compiled object files for the routines where they wanted every real to be a double with a suitable compiler option to force double-precision; then compiled the other routines without that option. Speed was definitely of the essence back in the mid 1970s, so I can't see them forcing double precision for all routines. I will compile a set of object files and check whether the resulting mix of "default-single" and "default-double" object files could be linked into one executable and see what difference it makes to the results, then compare it to the results from the SES v4.1 executable distributed by US DoT in 2002.

The outcome of the tests I've outlined above will be of zero interest to anyone except ventilation engineers who have to modify SES, so I won't post any follow ups here in comp.lang.fortran unless there are major effects, something like a 1 degree Celsius change in PM peak hour temperatures. But any future readers who come across this thread while grappling with SES may be able to get some advice - or at least a sympathetic ear - by getting in touch with me directly.

Once again, thanks to all who took the time to respond,

Ewan

[Tobias Burnus]

ewan.b...@aurecongroup.com wrote:
> So my uninformed speculation (I am dreaming this theory up as I'm typing) is that they might have compiled object files for the routines where they wanted every real to be a double with a suitable compiler option to force double-precision; then compiled the other routines without that option.

Maybe. But in that case one needs to be extremely careful to correctly
pass arguments between subroutines (or functions, though I think
user-written Fortran functions didn't exist back then).

Thus, *if* one uses an option to promote single-precision REAL to double
precision, it is usually best to *do it consistently*. (One has also to
think about promoting "integer" (for storage association like in COMMON)
or how 0.0d0/"double precision" is handled, i.e. whether it stays double
precision or becomes quadruple precision.)

Thus, unless a code has been developed throughout with
single-to-double-precision promotion,* it is usually best to avoid those
options. (* Code developed with such an option often fails if compiled
this option ...)

Tobias

[Robin Vowels]

On Mar 7, 9:33 pm, ewan.benn...@aurecongroup.com wrote:
> Thanks to all for the suggestions and information.  The consensus confirm what I thought: that the issue raised was most likely poor coding on the part of the original programmer; and that compilers in the early 1970s were not set up to realize that if you had a DBLE() fronting an expression, the compiler should declare a double-precision mode implicitly.

They didn't, and couldn't, according to the standard, and they still
don't.

> As always happens when a question is irrevocably posted, as soon as I pressed send I realized I should have written it in slightly different terms - a question like "did Fortran 66 compilers have a form of duck typing?" would have been more clear.  Fortunately all the responders picked up the right impression from what I posted, and the answer is a resounding no; so I'll mark that one down to l'esprit d'escalier.  Gah.
>
> Several responders raised the suggestion that compiler options might have been set to explicitly force all real variables to be double-precision instead of single-precision: this is an interesting possibility.  Only a few of the routines need to use double precision and I think that all the double-precision variables in those routines that have external interfaces are explicitly defined as double precision, both in the routines that calculate with double precision and in the routines that call them.
>
> So my uninformed speculation (I am dreaming this theory up as I'm typing) is that they might have compiled object files for the routines where they wanted every real to be a double with a suitable compiler option to force double-precision; then compiled the other routines without that option.

I very much doubt that. In such circumstances, arguments and
their corresponding dummy arguments may well be mis-matched,
with erroneous results at best, or with a crash at worst.

[michael...@compuserve.com]

On Thursday, March 7, 2013 12:45:05 PM UTC+1, Robin Vowels wrote:
>
> with erroneous results at best, or with a crash at worst.
>

... with erroneous results at worst, or with a crash at best!

Regards,

Mike Metcalf

[glen herrmannsfeldt]

ewan.b...@aurecongroup.com wrote:
> Thanks to all for the suggestions and information.
> The consensus confirm what I thought: that the issue raised was
> most likely poor coding on the part of the original programmer;
> and that compilers in the early 1970s were not set up to realize
> that if you had a DBLE() fronting an expression, the compiler
> should declare a double-precision mode implicitly.

I don't think that they can do that. Well, maybe, but it would
be pretty strange. Until recently, though, the warning was unusual.

(snip)

> Several responders raised the suggestion that compiler options might
> have been set to explicitly force all real variables to be
> double-precision instead of single-precision: this is an
> interesting possibility. Only a few of the routines need to
> use double precision and I think that all the double-precision
> variables in those routines that have external interfaces are
> explicitly defined as double precision, both in the routines that
> calculate with double precision and in the routines that call them.

Well, as usual with separate compilation, you can have different
compiler options for different routines. Also, the 60 bit CDC
machines confused things, as most routines that were double
precision on other machines ran single on CDC machines.

In that case, though, there is no use for DBLE. If all REAL
variables were double precision, then there would be no need
for the DBLE. Even so, there is no need, as the result will
be converted before the assignment. DBLE is usually used for
subroutine and function arguments, to match the type declared
in the called routine. (Or, as noted, with a compiler option.)

> So my uninformed speculation (I am dreaming this theory up as
> I'm typing) is that they might have compiled object files for
> the routines where they wanted every real to be a double with
> a suitable compiler option to force double-precision; then
> compiled the other routines without that option.

Yes, they could have done that.

> Speed was definitely of the essence back in the mid 1970s,
> so I can't see them forcing double precision for all routines.
> I will compile a set of object files and check whether the
> resulting mix of "default-single" and "default-double" object
> files could be linked into one executable and see what difference
> it makes to the results, then compare it to the results from the
> SES v4.1 executable distributed by US DoT in 2002.

For callable subroutines and functions, it was not unusual to
compile both a single precision (often named starting with S)
and double precision (starting with D). In that case, using the
compiler option would make it very easy, though you still have
to change the name.

But still no need for DBLE.

> The outcome of the tests I've outlined above will be of zero
> interest to anyone except ventilation engineers who have to
> modify SES, so I won't post any follow ups here in
> comp.lang.fortran unless there are major effects, something
> like a 1 degree Celsius change in PM peak hour temperatures.
> But any future readers who come across this thread while
> grappling with SES may be able to get some advice - or at
> least a sympathetic ear - by getting in touch with me directly.

You might post one more in the end. People like to know the
ending of the story. But yes, it seems likely that the result
of that expression, despite the DBLE, was stored in single precision.
That the results were close enough, and the error was never noticed
until now.

It is actually fairly rare that results are needed to double precision,
but more often that intermediate values need the precision such that the
final result comes out close enough. (There are no air conditioning
systems accurate to 0.000000000000001 degreee C.)

-- glen

[glen herrmannsfeldt]

michael...@compuserve.com wrote:
> On Thursday, March 7, 2013 12:45:05 PM UTC+1, Robin Vowels wrote:

>> with erroneous results at best, or with a crash at worst.

> ... with erroneous results at worst, or with a crash at best!

There were some machines where the first bits of a double precision
value matched the bits of a single precision value, such that calling
a routine with the wrong type argument didn't give too far off
results. (Sometimes considered a feature.)

In that case, the error might not be noticed until it was run on
a different machine.

-- glen