Prev: parameter incosistency
Next: Suppressing intrinsic assignment of derived type
From: glen herrmannsfeldt on 20 May 2010 19:46
jfh <john.harper(a)vuw.ac.nz> wrote:
> On May 21, 6:17�am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>> mecej4 <mecej4_no_s...(a)operamail.com> wrote:

>> (snip on VS Fortran)

>> IBM is pretty good at marking extensions in their manuals,
>> usually by giving them a grey background.

>> > � � "...Instead, the array declarators appearing in an explicit
>> > specification statement or DIMENSION statement in the subprogram may
>> > contain dummy arguments or _variables_in_common_ (italics mine) that are
>> > integer variables of length 4 to specify the size of the array."

>> I believe the COMMON case is standard Fortran 66. �Is it grey?

> It is standard f66, in section 7.2.1.1.

Somehow I don't see it in 7.2.1.1 or, where it should be, 7.2.1.1.2.

> The thing that surprised me
> about f66 arrays when I looked up the standard was 5.1.3.3, which says
> a subscript expression must be written as one of these constructs: c*v
> +k, c*v-k, c*v, c+k, c-k, v, k, where c and k are integer constants

The ones you have c+k and c-k should be v+k and v-k.

> and v is an integer variable reference. So if A was a one-dimensional
> array, X a scalar and N an integer variable, these statements would
> presumably have been non-standard:

> X = A(N+1)

legal

> X = A(N**2)

Not, according to the standard. But this is one of the most
common extensions, so you will have a hard time finding one
that doesn't allow for it.

But I have seen programs claiming to follow the Fortran 66
standard, presumably even in this case.

-- glen
From: glen herrmannsfeldt on 20 May 2010 19:55
Richard Maine <nospam(a)see.signature> wrote:
> jfh <john.harper(a)vuw.ac.nz> wrote:

>> It is standard f66, in section 7.2.1.1. The thing that surprised me
>> about f66 arrays when I looked up the standard was 5.1.3.3, which says
>> a subscript expression must be written as one of these constructs:
(snip)

> Well, your N+1 example is ok as I recollect. I think you must have a
> typo in there somewhere, as the c+k and c-k cases make no sense (at
> least not in terms of matching my recollection). I bet they were more
> like v+k and v-k. Your N**2 example is certainly non-standard.

> To me, a much more "interesting" oddity that I recall here was
> than n+1 was ok, but 1+n was not.

Yes, but it is usual in algebra to write constant*variable, and
also usual to order in decreasing powers of the variable.

> I put this in a general category of f77 allowing expressions in most
> places where expressions could plausibly make sense, while f66 was
> awfully restrictive. There are several other cases. For example, my f66
> code was full of messes like the following because DO limits could not
> be expressions (and also because of the one-trip problem)

> ip1 = i+1
> jm1 = j-1
> if (ip1 .gt. jm1) goto 250
> do 200 k = ip1, jm1
> ...
> 200 continue
> 250 continue

That one didn't bother me quite as much as no expressions in I/O
lists, resulting in many temporary variables. But only slightly less.

Instead of

DO 200 K=1,J-1

you might instead use

DO 200 K=2,J

and then subtract one from K wherever it is used, likely
in subscripts.

Many DEC compilers didn't have these restrictions, but the IBM
compilers did. That is, both DO and I/O lists. WATFIV followed
the non-yet-standard, Fortran 77, and allowed them in 1973.
That was before I even knew about a standard, Fortran IV usually
being considered the "standard" by many (especially book authors.

-- glen

From: glen herrmannsfeldt on 20 May 2010 20:11
Richard Maine <nospam(a)see.signature> wrote:
> jfh <john.harper(a)vuw.ac.nz> wrote:

>> On May 21, 6:17 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote:
>> > mecej4 <mecej4_no_s...(a)operamail.com> wrote:

>> > > "...Instead, the array declarators appearing in an explicit
>> > > specification statement or DIMENSION statement in the subprogram may
>> > > contain dummy arguments or _variables_in_common_ (italics mine) that are
>> > > integer variables of length 4 to specify the size of the array."

>> > I believe the COMMON case is standard Fortran 66. Is it grey?

>> It is standard f66, in section 7.2.1.1.

> I think you need to reread that part a bit more carefully. It mentions
> COMMON, but not in this context. The mention of COMMON is just to
> explain that an array declarator can appear in a COMON statement. That
> wasn't the question here. The question here was whether the variables in
> an array declarator could be in COMMON.

That is what it looks like to me.

> On the question at hand, 7.2.1.1.2 first says "The dummy argument list
> of the subprograms must contain the array name and the integer variable
> names that represent the adjustable dimensions."

Hard to argue with that one.

> That ought to finish it, as dummy arguments can't be in common (see
> 7.2.1.3, which says "no dummy arguments are permitted").

> But just in case we got it right the first time, the last sentence of
> 7.2.1.1.2 confuses the issue by redundantly saying "In a subprogram, a
> symbolic name that appears in a COMMON statement may not identify an
> adjustable array."

I suppose I believe it is worth saying twice.

But just to be confusing, the IBM S/360 S/370 Fortran Reference,
in the 11th edition, allows the dimensions (but obviously not the
array) in COMMON, and doesn't gray it out (as an extension).

In the list of changes for the last three editions, top of the
list is: "Certain errors in the shading of IBM extensions to ANS
Fortran have been corrected."

> As f90/f95 editor, I sure would have given a hard time to anyone who
> tried to put something like that sentence in. After saying that both the
> array name and the integer variable names have to be dummy arguments, we
> then feel it necessary to remind people that this means the array can't
> be in common. I suppose this implies that the integer variables can?

IBM seems to think so. Somehow I thought it was allowed last time
I looked it up, too.

> Nope. We just thought we'd say this about one of them but not the other
> just to make sure people thought there was a difference. And then there
> is the obvious implication that it must be ok to do this in the main
> program because the restriction explicitly says it applies only to
> subprograms. Argh! Yes, I've let things as bad or worse slip through.
> That doesn't keep me from cringing when I read things like this.

Maybe one that I remember taking a long time to learn.

-- glen
From: Tim Prince on 20 May 2010 20:40
On 5/20/2010 4:55 PM, glen herrmannsfeldt wrote:
> Richard Maine<nospam(a)see.signature> wrote:

>
>> To me, a much more "interesting" oddity that I recall here was
>> than n+1 was ok, but 1+n was not.
>
> Yes, but it is usual in algebra to write constant*variable, and
> also usual to order in decreasing powers of the variable.
A persistent consequence might be the possibility of compilers
optimizing the f66 form better or more reliably, simply because more
legacy code results in more thorough testing.

>
> Instead of
>
> DO 200 K=1,J-1
>
> you might instead use
>
> DO 200 K=2,J
>
> and then subtract one from K wherever it is used, likely
> in subscripts.

Or, as we still see in C++ code, conditionals inside a loop from 1 to j
to skip the k==j case, throwing off optimizing compilers, and helping
boost the proponents of new C++ namespaces which support data parallel
constructs reminiscent of f90.

--
Tim Prince
From: jfh on 20 May 2010 22:10
On May 21, 10:30 am, nos...(a)see.signature (Richard Maine) wrote:
> jfh <john.har...(a)vuw.ac.nz> wrote:
> > It is standard f66, in section 7.2.1.1. The thing that surprised me
> > about f66 arrays when I looked up the standard was 5.1.3.3, which says
> > a subscript expression must be written as one of these constructs: c*v
> > +k, c*v-k, c*v, c+k, c-k, v, k, where c and k are integer constants
> > and v is an integer variable reference. So if A was a one-dimensional
> > array, X a scalar and N an integer variable, these statements would
> > presumably have been non-standard:
>
> >       X = A(N+1)
> >       X = A(N**2)
>
> Well, your N+1 example is ok as I recollect. I think you must have a
> typo in there somewhere, as the c+k and c-k cases make no sense (at
> least not in terms of matching my recollection). I bet they were more
> like v+k and v-k. Your N**2 example is certainly non-standard.
>
> To me, a much more "interesting" oddity that I recall here was than n+1
> was ok, but 1+n was not.

Apologies: Richard is right on all the above points! And I thought I
had checked carefully before posting:-(

-- John Harper
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: parameter incosistency
Next: Suppressing intrinsic assignment of derived type