Jump to ratings and reviews
Rate this book

Basic FORTRAN

Rate this book
Book by Coan, James S.

235 pages, Paperback

First published January 1, 1980

1 person want to read

About the author

James S. Coan

8 books3 followers

Ratings & Reviews

What do you think?
Rate this book

Friends & Following

Create a free account to discover what your friends think of this book!

Community Reviews

5 stars
1 (33%)
4 stars
2 (66%)
3 stars
0 (0%)
2 stars
0 (0%)
1 star
0 (0%)
Displaying 1 of 1 review
Profile Image for Jerry.
Author 10 books27 followers
August 25, 2019
The supreme joy of learning to program a computer comes when the learner begins to formulate new problems to solve.


AINT is perfectly good grammar if you are writing in FORTRAN.

I typed in more of these programs than in his BASIC books, because I’ve never really used FORTRAN. I think we had to do one very short program in FORTRAN in college, just so that we could say we’d done it. Which is probably fine, because the FORTRAN I would have had to use was the FORTRAN 77 in this book, and I can understand why people often preferred using BASIC even on minicomputers. FORTRAN provided the advantage of speed of execution, but many of Coan’s exercises, which, like his previous books, are mathematical, were easier for him to explain and solve in the minicomputer BASIC of the same era. The MAT functions alone must have been a deal-maker for many programmers.

FORTRAN did provide named subroutines instead of having to mostly use GOSUB and line numbers. On the other hand, while FORTRAN did not require line numbers for every line, it did still require that labels, for GO TO, be line numbers.

In fact, it looks very much like BASIC was based off of making FORTRAN simpler. Making line numbers required for all lines simplified the process of assigning line numbers, and also made it possible for BASIC to be interactive.

I used gfortran to compile the exercises. By using the .f extension on files, gfortran seemed to mostly use FORTRAN 77 conventions. The big differences are that Coan used “write(5, label)” to write to and read from the console; 5 is stdin in gfortran (on Linux), but either 0 or 6 wrote to stdout.

Also, it was very strange reading that string characters weren’t really supported at all by FORTRAN, and that FORTRAN would just convert them to integers. This made the decision by most manufacturers of early microcomputers to leave out lower case a lot more understandable. Even in gfortran, characters can no longer be used interchangeably with integers, as far as I could tell.

It was similarly interesting reading that all output must include a prefatory character to tell the line printer what to do. The assumption was that all output went to a line printer or to a screen that was emulating a line printer.

Also intriguing was the assembly code in the back for implementing a random number function on the Z80. And the recommendation that, if you need random numbers, use BASIC to generate a file of them.

While many computer programming language facilities include the ability to generate random numbers, most FORTRANs do not. You may be using a FORTRAN that does supply a random number generating function, in which case you need only determine how it is to be applied. There are several other ways you can provide yourself with a source of random numbers. If you are working on a computer with a BASIC language that has a random number generator, you may be able to write a couple of thousand random numbers to an external data file, which you can read in any FORTRAN program that requires random numbers.


The lack of bounds checking on arrays, though, was probably the most amazing to me.

Most implementations of FORTRAN do not check to see if the subscript that we use is within the bounds stated in a DIMENSION statement or a type declaration statement. So if we dimension an array to be 20 by 30 and we write a program statement that tries to store a number at subscript position (50, 50), the results may be unpredictable. We might alter some memory location in the operating system and shut down the computer or send it into some strange loop, printing a system error message that appears to have nothing to do with anything in our program. It is the programmer's responsibility to provide valid subscripts.


This has, of course, been fixed, so I was unable to test this, probably to the relief of the Raspberry Pi I was using.

The bulk of the book follows the same pattern he used in his two BASIC books; some of the problems are identical, using identical descriptions, for data analysis, probabilities, and so forth. This undoubtedly would have been a great book for learning FORTRAN, and was a fascinating glimpse into a different era of programming.

Be cautious, but be adventurous and the rewards will be tremendous.
Displaying 1 of 1 review

Can't find what you're looking for?

Get help and learn more about the design.