parameter incosistency
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: parameter inconsistency (now adjustable dimensions of arguments)
From: glen herrmannsfeldt on 20 May 2010 00:42 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 20 May 2010 00:43 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 20 May 2010 01:49 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 20 May 2010 02:29 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 20 May 2010 09:30
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 |