Book: Fortran techniques with special reference to non-numerical applications (1972)

Programming flow diagram, with the flow of a program using subroutines on the left ("closed coding") and the same structure on the right written as a series of GOTO-controlled sections ("open coding") to save computer memory and execution time
“Subroutines do, however, bring with them considerable
overheads in both space and execution time
.”

Imagine you have a programming task that involves parsing and analyzing text. Nothing complicated: maybe just breaking it into tokens. Now imagine the only programming language you had available:

  • has no text handling functions at all: you can pack characters into numeric types, but how they are packed and how many you get per type are system dependent;
  • allows integers in variables starting with the letters I→N, with A→H and O→Z floating point;
  • has IF … THEN but no ELSE, with the preferred form being
    IF (expr) neg, zero, pos
    where expr is the expression to evaluate, and neg, zero and pos are statement labels to jump to if the evaluation is negative, zero or positive, respectively;
  • has only enough memory for (linear, non-associative) arrays of a couple of thousand entries;
  • disallows recursion completely;
  • charges for computing time such that a solo researcher’s work might cost many times their salary in a few weeks.

Sounds impossible, right? But that’s the world described in Colin Day’s book from 1972, Fortran techniques with special reference to non-numerical applications.

The programming language used is USA Standard FORTRAN X3.9 1966, commonly known as Fortran IV after IBM’s naming convention. For all it looks crude today, Fortran was an efficient, sod-the-theory-just-get-the-job-done language that allowed numerical problems to be described as a text program and solved with previously impossible speed. Every computer shipped with some form of Fortran compiler at the time. Day wasn’t alone working within Fortran IV’s text limitations in the early 1970s: the first Unix tools at Bell Labs were written in Fortran IV — that was before they built themselves their own toolchain and invented the segmentation fault.

The book is a small (~ 90 page) delight, and is a window into system limitations we might almost find unimaginable. Wanna create a lookup table of a thousand entries? Today it’s a fraction of a thought and microseconds of program time. But nearly fifty years ago, Colin Day described methods of manually creating two small index and target arrays and rolling your own hash functions to store and retrieve stuff. Text? Hollerith constants, mate; that’s yer lot — 6HOH HAI might fit in one computer word if you were running on big iron. Sorting and searching (especially without recursion) are revealed to be the immensely complex subjects they are, all hidden behind today’s one-liner methods. Day shows methods to simulate recursion with arrays standing in for pointer stacks of GO TO targets (:coding_horror_face:). And if it’s graphics you want, that’s what the line printer’s for:

Damped cosine 2d function density plot rendered as mono-spaced characters, approximately 60 colums across, made up of only X, 0, *, +, - and space characters
“… the most serious drawback to a density plot of the type shown above is the limited number of characters used to represent the height above the page.”
(This image was deemed impressive enough by Cambridge University Press that they used it as the cover of the book. The same function became a bit of a visual cliché, with home computers being able to render it in colour and isometric 3D less than a decade later.)

Why do I like this book enough to track down a used copy, import it, scan it, correct it and upload it to the Internet Archive? To me, it shows the layers we now take for granted, and the privilege we have with these hard problems of half a century ago being trivially soluble on a $10 computer the size of a stick of gum. When we run today’s massive AI models with little interest in the underlying assumptions but a sharp focus on getting the results we want, we do a disservice to the years of R&D that got us here.

The ‘charges for computing time’ comment above is from Colin’s website. Early central computing facilities had the SaaS billing down solid, partly because many mainframes were rented from the vendor and system usage was accounted for in minute detail. Apparently the system Colin used (when a new lecturer) was at another college, and it was the custom to send periodic invoices for CPU time and storage used back to the user’s department. Nowhere on these invoices did it say that these accounts were for information only and were not payable. Not the best way to greet your users.

(Incidentally, if you hate yourself and everyone else around you, you can get a feel of system billing on any Linux system by enabling user quotas. You’ll very likely stop doing this almost immediately as the restrictions and reporting burden seem utterly alien to us today.)

While the book is still very much in copyright, the copy I have sat unread at Lakehead University Library since June 1995; the due date slip’s still pasted in the back. It’s been out of print at Cambridge University Press since May 1987, even if they do have a plaintive/passive aggressive “hey we could totally make an ebook of this if you really want it” link on their site. I — and the lovely folks hosting it at the Internet Archive — have saved them from what’s evidently too much trouble. I won’t even raise an eyebrow if they pull a Nintendo and start selling this scan.


Colossal thanks to Internet Archive for making the book uploading process much easier than I thought it was. They’ve completely revamped the processing behind it, and the fully open-source engine gives great results. As ever, if you assumed you knew how to do it, think again and read the How to upload scanned images to make a book guide. Uploading a zip file of images is much easier than mucking about with weird command-line TIFF and PDF tools. The resulting PDF is about half the size of the optimized scans I uploaded, and it’s nicely tagged with metadata and contains (mostly) searchable text. It took more than an hour to process on the archive’s spectacularly powerful servers, though, so I hate to think what Colin Day’s bill would have been in 1972 for that many CPU cycles … or if even a computer of that time, given enough storage, could complete the project by now.

Keypunch029 — for all your punched card font needs …

A fairly accurate rendition of the 5×7 dot matrix font printed at the
top of punched cards by the IBM Type 29 Card Punch (1965).

Local copy: Keypunch029.zip.
Fontlibrary link: Keypunch029

The 029 (as it is sometimes known) generated a bitmap font from an engraved metal plate pressing on a matrix of pins. A picture of this plate from a field engineering manual was used to re-create the pin matrices, and thus an outline font.

029 Code Plate

029 Code Key

Historical Accuracy

The 029 could have many different code plates, but the one used here contained the characters:

<=>¬|_-,;:!?/.'"()@¢$*&#%+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

The character glyphs have been sized such that if printed at 12 points, the 029’s character pitch of 0.087″ is accurately reproduced. No attempt to research the pin matrix pitch or pin diameter has been made: the spacing was eyeballed from a couple of punched cards in my collection.

The earlier IBM Type 26 Card Punch (“026”) included a glyph for a square lozenge (Unicode U+2311, ⌑). The 029 code plate did not include this character, but I added it here for completeness.

The character set was extended to include:

  • all of ASCII, with lower case characters repeating the upper case glyphs;
  • sterling currency symbol; and
  • euro currency symbol.

While there may have been official IBM renditions of some of these additional glyphs (with the exception of euro) no attempt has been made to research the original shapes. This font set is intended to help with the visually accurate reproduction of 1960s-era punched cards, mostly coinciding with my interest in the FORTRAN programming language. No attempt has been made to use historical BCD/EBCDIC encodings in these fonts. We have Unicode now.

The 029 card punch could not produce any bold or italic font variants, but FontForge can, so I did.

Things I learned in making these fonts

  1. The 029 card punch printer could be damaged if you tried to print binary cards, as there was no way to disengage the code plate from the punch mechanism.
  2. FontForge really hates to have paths in a glyph just touching. Either keep them more than one unit apart, or overlap them and merge the overlapping paths.
  3. EBCDIC is weird.

Sources

Fortran has no STDERR

I suspect it’s comp.lang.fortran‘s second most frequently-asked question, but the language has no concept of stderr, the POSIX error output stream. Or at least, there’s no standard IO unit attached to stderr, if it’s defined at all.

Since writing to stderr is my usual debug message method, this is going to be a slog …

so it might not look much to you …

mapedit10x10.png
Being able to see this represents quite a bit of work on my part. It’s the output from WAsP‘s map editor, reprsenting some terrain roughness data exported from Surfer.

The original data set looks a bit like this:

gridvalues.png

It’s a grid of values. Unfortunately, WAsP wants the boundaries, and it took me a while to work out a (rather inefficient) algorithm to find them.

Now I have to go off and recode this in Fortran 90. I’m glad that the Intel® Fortran Compiler for Linux is available free.

Getting my fortran head together

It’s very strange to be getting back into a language as different to Perl as it is possible to be. I’m fairly conversant with the weird bits of Perl — map, grep, hash usage, objects — but Fortran has a completely different toolkit

That’s not to say it’s a bad toolkit, just very different, F’rinstance, trying to find all the distinct values in an array. In Perl, you just walk through a hash, parallel to the array, incrementing each key for every value found. In Fortran — well, it’s a different story.