Read Chapts. 2 &3 in your Text, and my discussion of Assignment statements.
PROGRAM, SUBROUTINE, CALL, MODULE, USE, STOP, RETURN, END, READ, PRINT, REAL
Take the time to not only do your homework, but also to type in examples of all programming constructs to check your understanding of their behavior. The best way to learn a language construct is to:
Under Unix, certain "file extensions" (the part of the file name following a ".") have special meaning. In particular the name of any file containing a Fortran program should end with ".f" (some compilers require ".f90" for Fortran 90 files). The name of any C language program should end with ".c".
On Unix machines, the standard convention is to name this translation program "f77", because Fortran 77, was the standard for the language until very recently. However, you will also find compilers named "f90", (follow the Fortran 90 standards) and IBM likes to call its Unix Fortran compiler "xlf" (although IBM Workstations recognize the command "f77") or xlf90.
One source of confusion in this class is that we will be learning Fortran 90, but using the compiler named "f77". In fact on our computer "f77" recognizes all Fortran 90 statements. It is simply convenient because it operates with the older fixed format for statements that I will use for all examples in this class. I'm forcing you to learn this older format rather than the newer free format, so that you can work comfortably with the existing body of Fortran programs.
There is also a Unix convention for naming the file produced by the compiler (actually produced by something called the linker), containing machine instructions,. Unless you use special options that we will discuss later, this file produced by "f77" (or any other compiler) is named "a.out". If I have created a Fortran program in a file called "test.f", then I can compile it by typing the command:
If the compilation is successful, I can execute my program by typing:
Remember that the compiler only produces machine executable instructions in another file. It never produces the results of your program. To get the program results, you must execute the file produced by the compiler.
Nothing from Fortran 77 has been dropped from Fortran 90. It forms the core of the new version of the language. For this reason, and because you will need to be competent in Fortran 77 to utilize the enormous body of existing Fortran 77 applications, we will concentrate on learning this core of Fortran Statements. Many useful Fortran 90 features will also be introduced, but the entire language will not be covered.
Depending on the size of your program and data, the necessary cards were held in a box or bound together with a rubber band for storage. To execute the program the rubber band was removed, or cards removed from the box, and the deck was placed in the input tray of a card reader. From time to time the programmer or computer operator would get clumsy, or a rubber band would break and the cards would be spread across the floor. To ease recovery from such situations, it was decided very early in the history of electronic computing, that some of the columns on the card should be reserved for storing a card sequence number. Card sorters already existed that could use this number to unscramble a deck. For Fortran the last 8 columns were reserved for a card identifier. This was more than enough for any program or data deck length, giving room for other useful identification such as the owner's initials or some other meaningful abbreviation.
So far we have restricted the length of a standard Fortran statement to 72 characters. However, there is more. As you may recall from the second lecture, one of the basic instructions that a computer can perform is to branch around the next instruction in memory to another instruction elsewhere in memory. A means was needed within Fortran to uniquely label statements that are the targets of branches. The card sequence identifier was inadequate, because you wanted to redo these sequence identifiers as your program expanded, but you didn't want to change Fortran statements that contained branch instructions. The result of this need was to reserve the first 5 columns for holding Fortran statement labels. Here is an example of the use of such labels, preceded by two lines to give you an idea of character positions within the line.
c 1 2 3 4 5 c2345678901234567890123456789012345678901234567890This is a very poorly structured piece of Fortran by the way, but we'll learn about that later. If you look carefully at the example, you may notice a couple of odd features. First, I was fairly careless with the use of spaces. This is because Fortran largely ignores spaces, so I am free to use them to improve the way my code looks. You may also notice that I never got down to the serious business of writing a Fortran statement (as opposed to statement label) until at least column 7. The reason here was not simply neatness. At some point during this course you will realize that you can't type everything you want in some of your Fortran statements before bumping into column 72. You need some way to tell the Fortran compiler that you are continuing the statement on the next line. The Fortran convention for permitting statements to span more than one card is to put any character in the 6th column of any card (line) beyond the first of a continued statement.
if(i.gt.1) go to 100 x=1.0 go to 200 100 x = 2.0200 y=2*x
These conventions for leaving the 6th column blank (unless you are continuing a statement), and fitting everything within the first 72 columns are the single largest source of suffering by beginning programmers. If you inadvertently type your statement past the 72nd column, Fortran will ignore everything that you have entered in columns 73 and beyond. This can result in a syntax error message from the compiler (the structure of your Fortran statement doesn't make sense to the compiler), but you will stare at that line in your program and see nothing wrong. Worse yet, you may type your statement in such a way that losing the characters beyond column 72 will not be detected as a syntax error but will give you incorrect results.
Similar problems occur with column 6. If you inadvertently start a statement before column 7, it almost always places a character in column 6. This causes the line to be considered as a continuation of the previous one, and usually (but not always) results in a syntax error. If the statement starts before column 7, but has a blank in column 6, you will receive a syntax error complaining about a bad line label.
One final note on the above example. You may have noticed that I started my two column counting lines with a "c" rather than a "1". This is because they were meant to be contained within the program itself as markers. By placing "c" in column 1, I've told Fortran that the line is a comment and not a regular Fortran statement. The compiler ignores the line. You also have the option of using "C" or "*" in column 1 to designate a comment. Use comments generously in your program to describe its contents. This will assure you of better grades on your homework assignments. However, it has a far more important purpose. Unless your memory is exceptional, you will find that 6 months after you have written a program, you will have trouble understanding the variables and intent of the program. Comments make the job of modifying your program for another task much easier. Use of comments can also be important in a work setting. If someone considers a program important enough to pay you to write it, then it is almost always important enough to be checked by another programmer, and kept for later refinements. Poor internal documentation hampers both validation and later modification, and, hence, could adversely affect your professional standing and salary.
I have provided some examples of pit-falls associated with column position errors in the program errors.f. The results of compiling it on a Hammond Lab, IBM Workstation follow.
A program statement can be up to 132 characters long (including blanks) and may start at any position in the line. The statement can span more than one line simply by placing an ampersand (&) at the end of the line to be continued. There are instances where you don't want to introduce blanks into the actual statement through the process of continuation. The best way to handle this is to use an ampersand as the first non-blank character in the continuation line. The compiler appends whatever follows this ampersand directly to whatever preceded the ampersand ending the previous line. The statement
if (x.gt.0) print *, ' The value & &of x is', xis equivalent to
if (x.gt.0) print *, ' The value of x is', xbut
if (x.gt.0) print *, ' The value & of x is', xis valid but equivalent to
if (x.gt.0) print *, ' The value of x is', x(note the extra blanks).
Comments must begin with an exclamation point (!). They can stand alone in a line or be placed at the end of a line containing a regular Fortran statement (but not after an ampersand used for line continuation).
! This is a Comment
x = a + b ! Add a to b, is also a valid in line comment
In general you need to state:
From here, the program can take on any one of several different forms. I'll provide you
with two approaches. The first is a fairly standard way to write this simple program. However,
it teaches you some bad habits, so I'll also demonstrate a modular approach to the problem, that
is more characteristic of the way the you should generally approach programming.
Read my description of the simple form of the program to get a concise description of the basic Fortran statements needed to accomplish the addition task. Next, read the description of the modular form of the program, showing a more standard method of allocating distinct sub-tasks to separate program units. The class lecture will focus on the modular approach to the program, since my primary purpose here is to introduce programming practices. We will focus on details of Fortran statements in subsequent lectures.
In practice, when I have to do a very simple calculation with a Fortran program, I use a layout similar to that of the simple form of this example. In fact, 99% of the time when I have a simple calculational task that will need to do more than once or twice in my life, I create a spreadsheet, or script for MathCad, or Mathematica, because calculational time is not important, but my time is. I generate Fortran programs when calculations and data processing are lengthy enough that the modular form is the most appropriate way to minimize my time debugging the program initially and understanding and modifying it later.
Unfortunately, I can't give you any firm guidelines on when to use spreadsheets, a mathematics program, or a programming language such as Fortran. You need to pay attention to your own work habits and competency with each of these classes of tools, to develop your own rules. You also need to make some educated guesses about how frequently you will repeat the calculation in the future, and you will need to gage the amount of time that the calculation will require to execute on a computer (some of my calculations run for days).
Take the time to look at this examples "add.f" and add2.f. Save these files on your Unix file space, (I recommend making a subdirectory called "examples" to store these and other such files), then compile and execute the programs.
Authored and Maintained by John Mahaffy : email@example.com