Electric poetry

People quite often ask: “What software do you use, to make these astronomical charts and predictions? Can I find it, or obtain it from you?”

The short answer is that it’s all Fortran programming written by me, a mass too huge to pass to anyone else.

I tried once before to give a coherent answer.

But the answer should be slightly fuller.

I learned the stars gradually, in the mountains of the Middle East, northern England, and Arizona. I was working in a mill in South Carolina when Professor Bill Brantley, head of the Furman University physics department, pulled me out to work for him. I drew posters for his “Energy” course, and helped on his astronomy course, and he got me to take the students out and show them the stars. I put together, with pen and typewriter and numbers from some printed sources, a suggestion for the first Astronomical Calendar.

On the department’s bookshelf was a directory of colleges, from which I typed addresses for a mailing list. The students said: “There’s a computer downstairs, you know.” Someone wrote a program in Cobol (“common business-oriented language”) to make the mailing list repeatable. I had to spend time down in the “terminal room,” typing at a terminal that punched the addresses as holes in cards. To make charts I now typed numbers from tables in the big official book, the Astronomical Almanac, and a student, James Coggins, wrote a program that turned these numbers into marks (apostrophes) on a roll of paper going through a printer called, I think, Calcomp; and I traced my drawings over these.

I found a booklet about how to make a model of the nearest stars, with beads on strings, and a student who became my collaborator, Doug Roosa, made a version of this with bicycle spokes. I tried to draw a picture of it, but it needed trigonometry. Doug taught me, over lunch, what sines and cosines are. James and another student, Jack Schwacke, taught me enough Fortran to plot the picture. (Once Jack remarked “James’s programming never ceases to amaze me,” from which I learned that there are styles in programming.)

I’ve built my Fortran programming ever since. Gradually there were more things that I could calculate for myself instead of having to use parts of the Almanac. At last count I have 474 Fortran programs (not all about astronomy), despite rigorously purging unneeded ones. I no longer waste paper by trying to keep hard copies of the source files, which continually had to be amended (with scissors and tape) and filled five or six large ring-binders

 

Anatomy of Fortran

A program may have just a main part, but usually has any number of subprograms. Both consists mostly of statements that look like algebraic equations (“Fortran” means “formula translation”), but are replacements.

A = (B*(C+D))/2 means that the calculation on the right is done and the result stored as A. The equals-sign could be an arrow: A <- (B*(C+D))/2

The terms are either constants, like 2, or variables, like A and B. The variables don’t have to be single letters, or capitals; they can be anything you choose, such as raVen for “right ascension of Venus in degrees.”

Other statements “call” subprograms. As one of those student friends put it to me: a subprogram is like a little man to whom you give a task, and he runs away and comes back with the answer. The main part of the program calls subprograms, those can call subprograms, and on down to any depth.

call abfix (mg,di,nundi, mgab)

That means (for me only) that subroutine abfix is given the apparent magnitude (brightness) of a star, its distance, and the unit the distance is in (such as “LY” for “light-years”), and makes the calculations and comes back with the star’s absolute magnitude. The part in parentheses is the “arguments”: what is given to the little man, and what he comes back with.

So, more important than any of my individual programs is my “library,” of 650 subprograms (in about 17,000 lines), which any program can call. They range from enormous masses of formulae for finding the positions of Moon and planets (learned from Jean Meeus’s books) to shorter ones for turning calendar dates into Julian dates, or drawing various shapes, or projecting positions in a picture, or opening and closing files and reading from or writing to them, and brief time-saving operations. Generally, when you’ve packed something into a subroutine and made sure it works in any context, you shouldn’t have to think about it again.

I have so much invested in Fortran that I can’t think of trying to convert it all to C or Java or any other modern languages. The only other programming language I used, especially for keeping accounts, was Basic: much handier than Fortran, especially for handling characters as opposed to numbers. But it became unusable after Microsoft Windows made a certain change (32-bit to 64-bit). That change also compromised the Fortran package I was using, and I had to get another from a maker called Approximatrix.

 

Tips for avoiding Fortran woe

I’m not the only dinosaur: Fortran is still being used for science. So just in case you use it or think of doing so, I’ll mention a few safety rules I’ve added for myself.

The most common source of wrong results, perhaps in all programming languages, may be confusion between data types, which computers turn into digital bits in different ways: integers (0, 1, 2, 3..), real or floating-point numbers (such as 1.5), double-precision real numbers, characters (such as “A”). The rule in Fortran is that any variable is a real number unless its name begins with the letters I to N, in which case it is an integer. Anything else has to be “declared” at the beginning of the program unit. So I have a declaration that I put at the beginning of everything:

implicit double precision (a-i,k-p,r-z)

Julian dates are such long numbers that they have to be double precision, so all real numbers might as well be. (The other way would be to make all double-precision start with K, which I used to do at first.)

My declaration means that I can make all and only names for integers start with J. Thus I can easily see where I’m using them. And if for some reason I want a variable to be single-precision real I could just make it start with Q. And I make all and only character variables start with N (reminiscent of “name”); they have to be declared.

These are self-imposed restrictions added to the rules. If I were re-inventing Fortran, I might add them to the rules and thereby save the tribe of programmers from hours of trouble.

Something else that plagued me in my early programming was the handling of those essential trigonometry functions: sine, cosine, tangent, and the rest. We naturally think of them in degrees. But to mathematicians they have more to do with the unit called the radian (the angle at the center of an orange subtended by a piece of skin that is as wide as the radius of the orange). So if you write SIN(A), you’ll get an answer for A radians, not A degrees. So I instead write SIND(A), that being a function in my library that takes degrees and turns them into radians before making the calculation.

Then there are those “arguments.” With complex subroutines that use many arguments, it can be difficult to remember which of them are supposed to go in and which come out. I use simple spaces (which Fortran ignores) to keep this clear.

call mona3L (jmo, nmo)

converts a month number, such as “6,” into a name with 3 characters and lower case, such as “Jun.” What goes in is before the space, and what comes out is after the space. Many subroutines are far more complex, with many arguments, and some of those can even go in and come out changed, in which case they follow a space and precede another space.

There are other strategies that are just good habits. Such as, making use of a powerful Fortran method called COMMON (which enables subroutines scattered deep in a program to know things without having to have them passed down as arguments). And making use of “batch” files for repeated actions (my batfor.bat runs all the processes needed to “compile” a Fortran source file into an executable one). And having a simple main program that calls the various parts of what you want to do, so that you can easily see the whole structure and change the order if you so decide (for instance, making one feature get drawn on top of another).

And I have my own “vocabulary” of more than 200 mostly two-letter strings that stand for concepts, such as LA for latitude, CJ for conjunction, DA for Julian date, MU for Moon, HU for color (guess why that can’t be CO). You need to be able to trace these concepts through the programming mass.

Most program don’t do just one thing: they can be run over and over again to, for instance, deal with different planets, or different ranges of time, use different colors. So, mostly, they read from files into which their instructions have been written in advance. There are now 399, some of them very long, of these SU files, as I called them from an early misunderstanding that this process is called “submitting,”

This system allows a powerful variety of results, except that: if you decide something more can be done by slightly altering the format of something in a SU file, you have much trouble finding places in programs that will now get errors.

My programs either put out information (which they have found or calculated), or they draw graphics. How they do that is that they end by writing lines in the language that underlies Adobe Illustrator (AI – a third meaning for that acronym!). When AI reads that file, it creates an image on the computer screen. There it can be “dressed,” which is what I call the painstaking use pf the mouse to move and prune labels, which can take hours as against the microseconds in which the computer creates the graphic.

I uncovered AI’s language, which you’re not supposed to do unless you’re an Adobe developer, by studying the huge mystifying file created by drawing one line.

I have built up two main “families” of astronomical graphic-drawing programs: CH, charts, flat maps, such as of the whole sky or of a comet’ course across a region; and SF, views of three-dimensional regions of space, such as a 10-astronomical-unit sphere around the Sun seen from a viewpoint 30 AU from the Sun.

There are now 39 CH programs, and 24 SF programs. I set, say, ten of the programs of one family to run in succession, reading one SU file and creating one picture. One may draw a dark background, or a graded glow; others, abstract features such as the ecliptic, celestial equator, a horizon; the Milky Way (in several styles); deep-sky objects; stars; constellation boundaries and form-lines; meteors; the Moon; moving bodies (MV); and (MVOD) space probes whose orbital elements were vouchsafed to me in various odd formats by NASA authorities to whom I appealed!

A large program that’s almost like a family is GL, which draws the globe of the Earth and has parts for additional features  needed when there are eclipses or meteor showers.

Another is HO, which draws the horizon scenes I now so often use. They could, and formerly were, applications of the CH family, but that required multiple choices among settings every time, so I started a new program specially for this use, and found it easy to extend with new features.

 

Advised or alone

Besides getting guidance early on from those student friends, I sometimes had conversations with Ray Nanney, professor of computer science and author of a book on it. He told me of a student who complained: “The computer did what I told it to do instead of what I wanted it to do!”

And of “Time flies like an arrow, fruit flies like a banana” as an example of the difference between natural language and unambiguous computer language. And that the $90 charge to me, because a fault in my earliest attempt to program an orbit left the computer running in an endless loop, needn’t be paid, because CPU time (central processing unit time, as opposed to the “wall time” shown on clocks) didn’t really cost anything.

And he told me of the debate as to what is most important in programming: accuracy, brevity, speed, clarity.

There’s no doubt now that it’s the last. When you go back to a program to improve it, you’ll be glad if you made it understandable to yourself: by simplicity of design – elegance – and by the explanatory “comments” you can add – lines beginning with C which the computer ignores.

The computer itself doesn’t understand anything, even though we talk about a subroutine “knowing” some quantity it needs. And even though, when I was building up the amazing layers of trigonometry that find the position of some moving point in a spherical picture, I sometimes feared that the “megaflops” (millions of floating-point operations per second) would overheat the poor computer’s brain, or even that my sphere would pop like a bubble.

Two student friends who at one time helped me in shipping out Astronomical Calendars, Philip and Mark, were taking computer courses. One day the homework they had been set was to write a program to turn numerals into Roman style, 8 into VIII and so on. They discussed the problem with me, then Mark said “That’s enough for now, I’m going for lunch.” I couldn’t let it rest, till I had made “call romnou (jarab, nrom)” work.

Since those days at Furman I haven’t lived in an environment where I could talk with academics, nor have I seen other people’s programming. There are perils when you’re mostly self-taught and work in isolation. Early on I got the impression that all Fortran has to be in capital letters (probably because the printer in that Terminal Room poured out the students’ stuff in capital letters on streams of green-and-white striped paper like pajamas). Only recently did I discover that, except for character variables, Fortran doesn’t care about case. (I’m using capitals occasionally here to show that something is computerese rather than English.)

Another thing Ray told me was: it’s said that any line of programming represents about an hour of thought. Yes, because vast thought goes into improving lines, and if possible making them more compact or deleting them. Another was that someone described programs as “electric poems”. Yes. They are poems that do something. If I were to put together a book of selected programs, I might call it an Electronic Epic.

It would have to include that whole “library,” which is quite a treasury of solutions to a few hundred questions. Though still patchily in capital-letter style.

 

__________

This weblog maintains its right to be about astronomy or anything under the sun.

 

 

20 thoughts on “Electric poetry”

  1. Guy, I’ve always been mystified as to how you created such magnificent, clear as day illustrations. To find out you are self taught raise my respect even further. Thank you so much for the peak behind the curtains. Please forgive the nit: there are two spots in the article where I see “wee” where “were” was better suited. Maybe I am missing something??

  2. Thank you for this in-depth explanation of how you’ve learned to do your work, which is such an essential part of my enjoyment of all things astronomical. When the time comes that you retire from your endeavors, will your vast body of knowledge and programming be passed on to the next generation, to continue the publication of the Calendar?

    1. I think not, unless some astronomical body expresses interest, to whom I could donate the files. And they are not even responding to my plea to take up the Astronomical Companion, a simpler (though not simple) endeavor.

  3. Wow. That’s an amazing accomplishment. Your work with Formula Translation computer language is like building a house, one step at a time. Or it reminds me of Michelangelo’s frescoes in the Sistine Chapel. First he had to have the scaffolding built, decide what would tell the next part of the biblical study, have the plaster laid for the day’s work, then use he chemical technique to fuse colors to the wet plaster.

    Babe Ruth once said, “You just can’t beat the person who never gives up”.

  4. Thank you very much for this memoir of the poetics of computer programming.

    Recently a pompous fool on the internet criticized the Voyager ground control crew for mistakenly misdirecting the transmitter antenna of the Voyager 2 space probe a fraction of a degree, causing the spacecraft to temporarily lose the ability to transmit data to Earth. A few days later, when interplanetary geometry aligned, they sent a message to the spacecraft realigning the antenna and reestablishing two-way contact.

    Before two-way contact was reestablished I did a little research in order to castigate the critic. Each Voyager spacecraft has 64KB of total computer processing power divided among three pairs of redundant computers, each with a different function. They are programmed with Fortran and assembly language. It currently takes 37 hours for a message to get to Voyager 2 and a response back to Earth. Enter a few lines of code, wait a day and a half to see how it worked, enter a few more lines … .

    The last original Voyager engineer, Larry Zottarelli, retired in 2016, so the current team are all second and third generation Voyager engineers. I think of it as a sort of priesthood, although unlike the Catholic priesthood, women and trans people are welcome.

  5. Having followed you for many years, well, decades, I have always had an intuitive appreciation for the amount of work and planning that goes into creating your almanacs and periodic updates. This behind the scenes report heightens that appreciation, but now I think more about your successor! I receive a number of astronomical reports, but none of them provide what you provide.

  6. As the only of a couple decades or so of Astronomical Calendar I ways wondered how it all got started and the programs that you used to make those special diagrams that not other yearly almanac made.
    Thank You..

  7. Really enjoyed reading your programming journey while reminiscing about my own parallel trip, some of which included astronomical programming. I fondly remember FORTRAN, punch cards, green striped fanfold paper and Jean Meeus’s work. My start in astronomical computing was sparked by a fascination with celestial navigation and I coded many useful programs from Nathaniel Bowditch’s prodigious work in “The American Practical Navigator”. As a sailor with mathematical inclinations, it was a wondrous, illuminating journey! Your work has always been equally inspiring. Thanks for sharing.

  8. Hello Guy, thanks for the explanation. I’m not a programmer but my husband was (not in Fortran). I used a lot of his business applications in my career, so I love the explanation of good programming – much appreciated.
    A long time admirer from southern Vermont.

  9. Thank you, Guy. You make me glad that humans have evolved, and survived, thus far.

  10. Thank you for sharing this very interesting information. Back in the late 1990s, I was, for a couple of years, on the staff of the Royal Greenwich Observatory in Cambridge, England. I was a member of Her Majesty’s Nautical Almanac Office. One of the projects I worked on was to create a set of star charts for the publisher Dorling-Kindersley, to be used in a book to be called “Eyewitness Guide to the Stars and Planets”, which they had commissioned Ian Ridpath to write. I wrote a FORTRAN program which generated the star charts as a set of Encapsulated Postscript (EPS) files. The EPS format was another creation of Adobe, Inc., and it had the advantages both of being plain text and of being compatible with Adobe Illustrator. The people at Dorling-Kindersley who were preparing the book could simply import my EPS files directly into Illustrator.

    Alas, shortly after I delivered the files for the book, the UK government closed down the Royal Greenwich Observatory, and I changed career direction, joining the Sanger Institute, which was then one of the principal partners in the International Human Genome Project. I changed programming languages too, there not being much demand for FORTRAN in computational genomics. I worked mainly in Perl and Java.

    Fast-forward 18 years to early 2017, and I became involved in the rescue of the Yearbook of Astronomy, led by a talented and dedicated Yorkshireman named Brian Jones. I volunteered to create a set of star charts for the new incarnation of the Yearbook. This time around, I wrote the software in Java, using star positions from catalogues stored in a MySQL database, but still generating the charts in Encapsulated Postscript, because that’s still compatible with Adobe’s InDesign software, the successor to Illustrator.

    1. Yes, my illustration files end up in EPS, but I decided not to mention that – too much complication already.

  11. Egads. – and I thought that I was a dinosaur kling-on.
    ForTran 77 or 90?
    After spending $500 for a Fortran 90 compiler that would work on MS PCs (DOS 5.0) I found that I ended up abandoning my OE (mostly near-shore wave modelling) routines (to attrition of need) and REwriting Astronomical routines in lower level language (FORTH) for planetarium use. I thought of ForTran as a special kind of hell.
    Mercy! Now I can see why you balked at my wondering about other-centric analemmae a couple of months ago. Head for the Hills!

  12. Beautifully written Guy. As someone who has been programming for 50+ years you’ve expressed a great deal of wisdom. Take note new programmers!

  13. Ah…Fortran. I remember learning and using it while studying for my actuarial degree. Great fun. However, after graduating and getting a job at an insurer, I found that it did all of its programming in APL. So I had to learn a new language.

Write a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.