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: robin on 21 May 2010 10:40 "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:ht2kt5$7tv$1(a)speranza.aioe.org... | 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.) I doubt that, since the only legal subscript was of the general form k1*V+-k2 where k1 and k2 are constants and V is a variable. IBM's SSP used a SUBROUTINE to calculate the position of the desired element in the corresponding vector. It did NOT use a function. Subscripts could not be function references.
From: Ron Shepard on 21 May 2010 11:30 In article <4bf69c61$0$89662$c30e37c6(a)exi-reader.telstra.net>, "robin" <robin51(a)dodo.com.au> wrote: > "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message > news:ht2kt5$7tv$1(a)speranza.aioe.org... > | 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.) > > I doubt that, since the only legal subscript was of the general form k1*V+-k2 > where k1 and k2 are constants and V is a variable. I think he means that a user function was used to evaluate the subscript index, which was assigned to a variable and then used as the 1-D array subscript. That would not be very efficient. However, I have seen code like this use statement functions for index computation. This is a little different because some compilers would inline state functions and optimize away any redundant computation involved, resulting in a good compromise between clarity (which usually suffers with hand-rolled indexing schemes) and efficiency (where the programmer handles the redundancies). Ironically, the compilers that do the nice optimizations for statement functions are also usually the ones that optimize index computations in multidimensional arrays, so this is basically an exercise in diminishing returns. I've seen a lot of C code written using preprocessor macros that do the index computation within 1-D arrays for the same reason -- a compromise between clarity and efficiency. This is because the treatment of arrays in C is very primitive compared to fortran (even compared to f77, not even counting array syntax in newer versions). $.02 -Ron Shepard
From: Richard Maine on 21 May 2010 12:50 Tobias Burnus <burnus(a)net-b.de> wrote: > On 05/20/2010 06:37 AM, glen herrmannsfeldt wrote: > > In PL/I you can do it with BEGIN, to start a new scope and > > new set of automatic variables. > > Ditto in Fortran 2008 with BLOCK: Wow! Good thing checked before posting. I had written up a bit of a rant about the problems with the f2008 BLOCK. It looks so simple, but simple-seeming things sometimes have large consequences. I had bitched at J3 about the large consequences of the way BLOCK was being specified. A quick glance at the FDIS reveals that it looks to have been redone in at least roughly the way I suggested. I didn't read through all the details, but a spot check was enough to see that my fundamental starting point was accepted. (Thank you for listening, J3). Since it was fixed, I'll just mention what the crucial point was without going into all the details. The original BLOCK proposal tried to specify that a BLOCK was not a scoping unit. There was some rationale for that, but I don't think the proposers had much idea of how much of a mess that would have made in multiple places in the standard that assume that declarations have the scope of a scoping unit. They put in special-case hacks for a few of the places, but completely missed other, bigger ones. (Procedure name resolution would have been completely trashed to the extent that I don't know how it could have practically been fixed). But spot-checking the definition of "scoping unit" (1.3.124 in the f2008 FDIS) reveals that "BLOCK construct" is now listed. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: robin on 21 May 2010 21:05
"Ron Shepard" <ron-shepard(a)NOSPAM.comcast.net> wrote in message news:ron-shepard-234818.10305621052010(a)forte.easynews.com... | In article <4bf69c61$0$89662$c30e37c6(a)exi-reader.telstra.net>, | "robin" <robin51(a)dodo.com.au> wrote: | | > "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message | > news:ht2kt5$7tv$1(a)speranza.aioe.org... | > | 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.) | > | > I doubt that, since the only legal subscript was of the general form k1*V+-k2 | > where k1 and k2 are constants and V is a variable. | | I think he means that a user function He cited the IBM SSP. For their SSP, IBM supplied the subroutine. | was used to evaluate the | subscript index, which was assigned to a variable and then used as | the 1-D array subscript. That would not be very efficient. Indeed so, because IBM gave an example of how the user could "inline" the code in each subroutine where it was needed. | However, I have seen code like this use statement functions for | index computation. This is a little different because some | compilers would inline state functions and optimize away any | redundant computation involved, Not IBM's (which manufacturer was the major player in those days), as they did not suggest that "option". In any case, their code looked like a rabbit's nest and the dozen statements didn't look like they would be amenable to a single statement. |