From: glen herrmannsfeldt on
robin <robin51(a)dodo.com.au> wrote:
> "Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message
> news:ron-shepard-2CB74D.18574819052010(a)news60.forteinc.com...

> | No, fortran has always allowed variables to be used to declare the
> | dimensions for dummy arrays.

> Actually, no. Early FORTRAN compilers required declarations like
> real x(1) for the dummy argument.

Fortran 66 allows variable dimensions, but it doesn't allow for
expressions. If you pass an N by N array to a rank 1 dummy, there
is no way to do it. You can't:

dimension x(n*n)

for example. I did run into this in WATFIV once, which does bounds
checking (not optional). The only solution was to pass N*N as a
separate argument. But most people used (1) unless there was a
reason not to.

-- glen
From: Ron Shepard on
In article <4bf4b015$0$89674$c30e37c6(a)exi-reader.telstra.net>,
"robin" <robin51(a)dodo.com.au> wrote:

> | No, fortran has always allowed variables to be used to declare the
> | dimensions for dummy arrays.
>
> Actually, no. Early FORTRAN compilers required declarations like
> real x(1)
> for the dummy argument.

I have certainly seen old code written this way, but I did not know
it was a restriction in the language. I thought it was because the
programmers thought they could write more efficient code if they did
the indexing themselves rather than declaring the dummy array as 2-D
and letting the compiler do the indexing.

For example, when moving down a column of a 2-D array, the loop
would look like this (using otherwise modern syntax)

k=...something...
do i = 1, n
...expression involving a(i,k) ...
enddo

The general belief was that the compiler might generate the offset
using the expression (k-1)*n+i on each pass through the loop. If
the array were dimensioned instead as a 1-D array, then the loop
would be written like

k=...something...
koff = (k-1)*n
do i = 1, n
...expression involving a(koff+i) ...
enddo

If this is not the case, then I stand corrected, but I have always
thought this was more a matter of programming style rather than a
restriction of the language.

In any case, this was all corrected by the late 60's and early 70's
when I started programming in fortran. By then, the fortran
compilers for various vendors allowed variables to be used in dummy
array declarations, the optimization eliminated any advantage for
manual computation of offsets into 1-D arrays. This was not true
for many other languages, even those developed after this time,
which allowed only constants in array declarations.

$.02 -Ron Shepard
From: Richard Maine on
Ron Shepard <ron-shepard(a)NOSPAM.comcast.net> wrote:

> In article <4bf4b015$0$89674$c30e37c6(a)exi-reader.telstra.net>,
> "robin" <robin51(a)dodo.com.au> wrote:
>
> > | No, fortran has always allowed variables to be used to declare the
> > | dimensions for dummy arrays.
> >
> > Actually, no. Early FORTRAN compilers required declarations like
> > real x(1)
> > for the dummy argument.
>
> I have certainly seen old code written this way, but I did not know
> it was a restriction in the language.

It wasn't. If you have a choice between getting Fortran information from
um... one of the regular posters here... or your local palm reader, I'd
go with the palm reader for better accuracy. :-(

While using a dimension of 1 was common practice, it was not required.
In fact, strictly speaking, the practice violated the standard. A
declaration like that says that the array has size 1, and any reference
to an element other than the first one would be an out of bounds
reference. It was just that very few compilers actually enforced that
requirement. Those that did bounds checking often made an exception for
a dimension of 1, though that was not universal. I recall that the
bounds checking options for the CDC compilers that I used to use a lot
were almost worthless for any code I tried them with because they did
not special-case a size of 1, so you ended up buried in a million "false
positives".

The trick of using sequence association to pass rank 2 actual arguments
to rank 1 dummies was ok (and still is, with a bunch or caveats). But
using 1 for the size was not. In fact, I have seen compilers that will
give a compilation error if you dimension x as 1, but then refer to x(2)
with the 2 being a literal constant so that it can easily be noticed at
compile time. There wasn't even an option to tell the compiler to accept
that; it was just a fatal error that could only be addressed by fixing
the code (an easy fix, changing the 1 dimensions to use assumed size).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote:
> In article <4bf4b015$0$89674$c30e37c6(a)exi-reader.telstra.net>,
> "robin" <robin51(a)dodo.com.au> wrote:

>> | No, fortran has always allowed variables to be used to declare the
>> | dimensions for dummy arrays.

>> Actually, no. Early FORTRAN compilers required declarations like
>> real x(1) for the dummy argument.

> I have certainly seen old code written this way, but I did not know
> it was a restriction in the language. I thought it was because the
> programmers thought they could write more efficient code if they did
> the indexing themselves rather than declaring the dummy array as 2-D
> and letting the compiler do the indexing.

I am not so sure about efficiency. One that I remember used a
function to do the subscript calculation, probably not so efficient.
More specifically, it allowed for a full, triangular, or diagonal
matrix as arguments, so the subscript calculation depended on
which choice was made. (I believe that is the IBM SSP, Scientific
Subroutine Package.)

> For example, when moving down a column of a 2-D array, the loop
> would look like this (using otherwise modern syntax)

> k=...something...
> do i = 1, n
> ...expression involving a(i,k) ...
> enddo

Well, also it was (maybe still is) common for FFT routines to
use a REAL array, where the calling routine used COMPLEX.
That might be for efficiency, as it is somewhat faster than
REAL, AIMAG, and CMPLX all over, trying to take apart and put
back together to halves of a complex variable.

> The general belief was that the compiler might generate the offset
> using the expression (k-1)*n+i on each pass through the loop. If
> the array were dimensioned instead as a 1-D array, then the loop
> would be written like

> k=...something...
> koff = (k-1)*n
> do i = 1, n
> ...expression involving a(koff+i) ...
> enddo

There is likely some of that, and also some might have gone
back to Fortran II.

> If this is not the case, then I stand corrected, but I have always
> thought this was more a matter of programming style rather than a
> restriction of the language.

I would say all of the above. Some from older, pre-Fortran 66, code.
Some for efficiency. Some for the ability to allow for different
matrix types.

> In any case, this was all corrected by the late 60's and early 70's
> when I started programming in fortran. By then, the fortran
> compilers for various vendors allowed variables to be used in dummy
> array declarations, the optimization eliminated any advantage for
> manual computation of offsets into 1-D arrays. This was not true
> for many other languages, even those developed after this time,
> which allowed only constants in array declarations.

It was standard in Fortran 66, though how well compilers optimized
it, I don't know.

-- glen
From: Gordon Sande on
On 2010-05-20 01:43:51 -0300, Ron Shepard
<ron-shepard(a)NOSPAM.comcast.net> said:

> In article <4bf4b015$0$89674$c30e37c6(a)exi-reader.telstra.net>,
> "robin" <robin51(a)dodo.com.au> wrote:
>
>> | No, fortran has always allowed variables to be used to declare the
>> | dimensions for dummy arrays.
>>
>> Actually, no. Early FORTRAN compilers required declarations like
>> real x(1)
>> for the dummy argument.
>
> I have certainly seen old code written this way, but I did not know
> it was a restriction in the language. I thought it was because the
> programmers thought they could write more efficient code if they did
> the indexing themselves rather than declaring the dummy array as 2-D
> and letting the compiler do the indexing.

I think there are two different issues at play here. One is the old
school use of a "1" where a "*" would now be preferred. The (single)
trailing dimension does not enter into the addressing calculation so
there is no effect on the generated code. Confuses the wits out of those
who are not memebers of the club. The other is the use of adjustable
dimensions. In Fortran II all dimension were fixed but Fortran IV (and
Fortran 66) cured that. The form of the allowed expession in a subscript
was rather restricted so the expressions were calculated elsewhere.
There was some amount of misunderstanding of the details which gave rise
to various superstitions. Likewise for what the adjustable dimension
variable could be. Rather than sort through the mess the "I am from
Missouri" crowd did their own subscript expressions. One of the issues
was what happened if the value of the adjustable dimension was changed
during execution of the subroutine. Just because the guy telling you the
rules had forgotten the line saying not to do it was not really a good
reason for not expecting it to work even if you changed you story of
what "worked" meant!

The "1" for "*" was so common that some subscript checkers special cased
a "1" to meam "*".

If one was a very foolish^H^H^H^H^H^H^Hbrave Fortran II programmer one
would pick a constant that was not otherwise used (say 13) and then use
another subroutine to overwrite the literal 13 with the desired value of
the leading dimension. The subscripting calculations were outside the
loop but just before it. So it was OK. Later compilers moved all that
stuff before the first executable line so the trick no longer worked but
with adjustable dimensions it was no longer needed. Back then portable
meant that it worked on the same model mainframe at another university
as long as neither place had overly ambitious systems programmers. One
would run into things like the compiler and the run time used different
conversion routines for floating point that did not always generate
exactly the same last bits.

> For example, when moving down a column of a 2-D array, the loop
> would look like this (using otherwise modern syntax)
>
> k=...something...
> do i = 1, n
> ...expression involving a(i,k) ...
> enddo
>
> The general belief was that the compiler might generate the offset
> using the expression (k-1)*n+i on each pass through the loop. If
> the array were dimensioned instead as a 1-D array, then the loop
> would be written like
>
> k=...something...
> koff = (k-1)*n
> do i = 1, n
> ...expression involving a(koff+i) ...
> enddo
>
> If this is not the case, then I stand corrected, but I have always
> thought this was more a matter of programming style rather than a
> restriction of the language.

The "1' for "*" is an early restriction issue. F77 took a long time
to become widely available so "*" was not available for a long time.
The other is a programming style with origins in superstitions about
restrictions in F66.

> In any case, this was all corrected by the late 60's and early 70's
> when I started programming in fortran. By then, the fortran
> compilers for various vendors allowed variables to be used in dummy
> array declarations, the optimization eliminated any advantage for
> manual computation of offsets into 1-D arrays. This was not true
> for many other languages, even those developed after this time,
> which allowed only constants in array declarations.
>
> $.02 -Ron Shepard