Fortran Basics
in [Fortran]
|
From: Gordon Sande on 26 May 2010 13:23 On 2010-05-26 13:58:39 -0300, "baalzamon.moridin" <baalzamon.moridin(a)gmail.com> said: > With regards to testing, I have exe files of the original code. > Thus I can test if my code yields the same results. > I intend to write two versions, > (i) Full conversion, > (ii) Call the fortran code directly. > Both will be tested for results. > > On a side note, one of my codes uses Assign a lot. Any ideas on > what this does? ASSIGN is a very old Fortran feature that is often a red flag for spaggetti code. Often very old code. if you have GOTO i ( 100, 200 ) and ASSIGN 100 TO i then the GOTO i ... becomes GOTO 100 in practice. If there had been an ASSIGN to 200 then the GOTO would have the other effect. It is an old way of branching around inside a program with the value of i set differently. And no, i=100 means something very different so do not try this instead. Sometimes the branching will be well disciplined as it is allowing a single piece of code to used repeatedly with the ASSIGN telling where to branch back to. And sometimes you are not so lucky! Now we would design the code differently. At worse there would be a SELECT with a bunch of GOTOs.
From: glen herrmannsfeldt on 26 May 2010 13:30 Richard Maine <nospam(a)see.signature> wrote: > baalzamon.moridin <baalzamon.moridin(a)gmail.com> wrote: >> On a side note, one of my codes uses Assign a lot. Any ideas on >> what this does? > Oh, yukk! Assign is a bit of an abomination from the past, which is no > longer in the language. Although simple enough in some ways, assign has > an arcane collection of warts with surprising consequences. It seems that ASSIGN and assigned GOTO were added before SUBROUTINE and CALL, as a method to allow for internal subroutines. You ASSIGN the statement you want to return to, and then GOTO the subroutine. This is also the reason for "extended range of DO." Now, with subroutine calls we never consider that as going out of, and returning into the range of a DO, though that is exactly what happens. > If used sparingly and in simple ways, it might not be too bad > and can readily be translated into other constructs. > But if a program uses it "a lot", I'd take that as a bad sign. > Most programs I have seen that used it "a lot" were the kind > of incomprehensible mess that was best handled by throwing > them out and restarting from scratch. Last I saw them used, they were generated by a macro processor as an expansion for a fake internal subroutine. It is best not to look at the code generated by many programs generating source code in any language. > The short version is that assign assigns an integer variable with a > value that is a statement label. You can then subsequently use that > integer variable in a few limitted contexts as a stand-in for that > statement label. More specifically, a popular implementation stores the address of the statement in the variable, and the GOTO jumps to that address. Likely faster than computed GOTO using index values, which is one possible replacement for it. -- glen
From: Richard Maine on 26 May 2010 14:40 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > More specifically, a popular implementation stores the address > of the statement in the variable, And some of the messier arcane bits come up when a default integer (the only standard kind in that era) was not large enough to hold such an address. You then often get things like a second "shadow variable" (I'm not sure whether that's quite the right terminology, but something like that), which holds the address, but is not actually in the same memory location as the "regular" integer variable. That in turn has all kinds of subtle consequences that can bite you if you don't follow the surprisingly strict letter of the standard. For example, assign 10 to i j = i !--- save the value. .... do some other things, possibly using i, but leaving j alone i = j !-- restore the value is not guaranteed to work as you'd think. The j=i is only allowed if i is defined with a nnumeric value; a statement label value doesn't count (even though they look like numbers in the source code). -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: baalzamon.moridin on 26 May 2010 15:46 Ah in which case I am doomed. Seriously though changed that progress bar back down to 10%! I think there are around 8 assign labels, along with the usual side dishes of GO TO. On a secondary note, I was informed that if I convert the F77 code (and from what people are telling me - also pre F77) to F90 this will make it easier to read (understand)?
From: Richard Maine on 26 May 2010 15:56
baalzamon.moridin <baalzamon.moridin(a)gmail.com> wrote: > On a secondary note, I was informed that if I convert the F77 code (and > from what people are telling me - also pre F77) to F90 this will make it > easier to read (understand)? Well.... sort of. But then that's probably not a particularly useful comment for your situation because in order to do a good job of converting it into f90, you would first have to understand it. There are some automatic converters for some things, but those are not likely to be silver bullets. Automatic language converters are rather known for producing output that is hard to read. After all, it isn't that being in f90 will inherently make something easy to read. You can write incomprehensible messes in any language. Examples exist. (Plenty of them.) It is more that f90 has facilities that help the programmer write code that is easy to read, if the programmer appropriately takes advantage of them -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |