MARTIN 1966 Fortran Code

TCE Options

TCE Open Date: 

Wednesday, November 27, 2019 - 16:55

MARTIN 1966 Fortran Code


In the twitter account of the guru who owns the degenerateconic.com website, he refers to a paper published in 1966 by Martin, I assume the precursor to Marriet Martin. It includes a complete computer program in Fortran for determining space trajectories for vehicles, this is the oldest Fortran I have ever seen, I have worked on a lot of 1968 code from USC Powell's famous group, but not this old.  

It is interesting to read the problems they encountered. 

I did use punch cards in 1976 at Newcastle University and the long slog to the computing center. 

I enclose the paper for anyone who wants a historical read. 

This is 20 years before the PC. 

John

AttachmentSize
Downloadapplication/pdf 19660009743.pdf3.76 MB
25 posts / 0 new

Nice!

What the noobs should do at least is to look at page 28. How many programmers today use a flow chart?

Jim Dempsey


Yes I noticed the flow chart, these programmers are the real Pros from Dover. 

I was tempted to take a day and try the code.  But ODE calls. 

 

John


We had to make flowcharts in my Fortran 2 programming class in high school, where we used an 1960's vintage IBM 1620.

I still have this...

Attachments: 

AttachmentSize
Downloadimage/png template2.png99.55 KB

Not to mention that one of your (our) verification tools was a slide rule..:)

Jim Dempsey


One of our professors does not allow calculators, one of his students was complaining about this and I looked at the student and said buy a slide rule, he had not banned slide rules

The students said how do you use it 

I said get a manual or go to youtube 

We are creating a nation of simpletons

 


I used two slide rules in college. A nice one made out of bamboo with plastic laminate for scales, and a round plastic one with two "hour hands". You could get about 3 to 4 places (4th was more or less a guess when lines didn't fully align).

Jim Dempsey


Hello

Thanks to Adobe Acrobat OCR capabilities, I succeeded to got a source file that can be compiled.

The difficulties I encountered were characters confusions (1 I l ), (0 O) and (. ,) by the OCR.

Only one line is difficult to read (an IF statement  with GT or LT).

Another problem is that it seems to has been targeted for a system with at least 6 bytes integers (read A6 to integer). I have to change that character*6.

I succeeded in building a data file.

But there is something wrong somewhere because it ends in divide by 0 error at the end of the first step.

Maybe, as often, the published source code has some bug.

 

 

 

Attachments: 

AttachmentSize
Downloadapplication/octet-stream prg.for21.98 KB
Downloadtext/plain prg.data_.txt483 bytes

Your READ with FORMAT statements do not correlate with the data file

         11111111112222222222333333333344444444445555555555666666666677777777778
12345678901234567890123456789012345678901234567890123456789012345678901234567890
PRINT   5.                               123                                 
POSITI  0.                -1126.088         -5433.0951        195.9727
VELOCITY18364.879         3152.5321         10624.889               
EFEMERIS93.591177         .54901493         207747.2          .012143289
ACCURACY.0000001                                                   
STOP    70.4              3444.             938.               
PROBLEM 1                                                   

The first field is A8, though can be read with A6,2X provided you can discard TY, IS, CY.

The first line appears to be a header of some sort, and the remaining can be read with:

READ (5,2) WD
2 FORMAT (A6,2X,4D18.0) ! provided you can discard TY, IS, CY

*** However the corresponding READ statement is preceded with a BACKSPACE 5

Not that it matters, WD is dimensioned at (5), and you are reading 4 elements, WD(5) is undefined.

Jim Dempsey

 


More reminiscing . . .

My first encounter with serious, this-had-better-work FORTRAN (as it was always written back then) was the calculation of radiative exchange factors used in thermal analysis back in 1965. NASA developed code used to calculate them for modelling its early 'space capsules'. The attached report (there was a revision and follow-up a couple of years later) was produced by the author. I recall tracking him down and talking with him on the 'phone about details of his code. The report shows an interesting blend of the mathematics involved (always rather simple in the abstract) and the ins-and-outs of doing reliable calculations in arbitrary geometric settings where there aren't closed forms for the governing quadrouple integrals and numerical surface integration has to be used.

The code listing shows sequence numbers at the end of each line of code -- remember those? They saved the day when you dropped your box of punch cards on the way to the university computing center.

David

Attachments: 

AttachmentSize
Downloadapplication/pdf Confac I.pdf9.7 MB

The data input works well. Datas are correctly initialized.

It"s a little bit ugly but it works. I think it has been got from a more complex program.

There is a backspace to read the first line further in the program.

The problem lies in a small vallue raised at power  1.D6.The result is used as a divider so there is a problem before.

The initialized value of PI is not very precise. I think it was a demo program.

 

 


Quote:

jimdempseyatthecove (Blackbelt) wrote:

READ (5,2) WD
2 FORMAT (A6,2X,4D18.0) ! provided you can discard TY, IS, CY

*** However the corresponding READ statement is preceded with a BACKSPACE 5

Not that it matters, WD is dimensioned at (5), and you are reading 4 elements, WD(5) is undefined.

Jim Dempsey

The first field (A6) is readden in wd(1) ( It's how  F66 deal with characters) and the 4D18.0 in wd(2) to wd(5).


My bad. I should have noticed the READ only had the WD in the variable list.

The newer runtime systems may error out on this read. Your corrective action in #8 may then need to use A8

Jim Dempsey


Only 6 bytes are readden into a double precision of 8 bytes so it works here. Just above, an A6 field is readden into an integer that must have been of length 6 bytes or more on the target system and I changed the variable to character*6 (used to print the whole line in case of error).

Character management was very strange in F66. Currently they were readden to integer*2 with A1 or A2 field. Character read or write is just a transfer of the given number of hytes between the variable and the file without any control. Concatenation was managed with arrays and equivalences.


I did not start using Fortran till 1978 so I am lost in your comments 

But did it work?

 


FYI the Confac I paper uses FORTRAN as opposed to Fortran.

I like the extent that the author went to in describing the input data format.

An interesting point I found in the paper is on page 58 and elsewhere, results data where it shows as results:

0.0000000E-38

I do not know if this was typical of the system it ran on for representing a non-zero underflow.

Page 120 is a great example of how card decks were organize for Batch Programming (program source deck followed by data deck(s)).

Page 121 shows how in Fixed Format, columns 73:80 were used to annotate source program deck number and sequence numbering. In the event you dropped the card deck, you could run it through a card sorter to reconstruct the proper sequence. Note, the sequence number was chosen to advance by 10, to leave room for edits (card inserts) as indicated by 37000145, apparently a source line had to expand to continue onto a 3rd line.

Thanks for posting this paper. It gives a great historical perspective.

FYI, the front of the paper indicated the system used was an IBM 7094. A 32K word (36-bit) system. It also stated that the text keywords in the card deck were held in 6 characters - one word, IOW 6-bit ASCII (upper case only).

Here is a nice web page with picture and specs. for 7090/7094

http://www.frobenius.com/7090.htm

The IBM 7090/94 series was the most popular family of large second-generation transistorized mainframe computers and was designed for "large-scale scientific and technological applications".

Jim Dempsey


Yes but can you get it running 

I am buried in 1968 ODE stuff so I do not have time 


0.0000000E-38 is I think the representation for 0

It"s the same in the Martin program results listing (0.D-39 to be precise on page 48 of the pdf).

 


OK I have found the first problem , 2 characters omitted in a line (**2+x in place of **x ).

Now, the results are identical to the listing in the pdf with just some floating point accuracy differences.

 

 

Attachments: 

AttachmentSize
Downloadapplication/octet-stream prg.for21.38 KB

I find it quite painful looking at that old style FORTRAN. It is so much harder to follow the logic with all this jumps. How pleased I am that we have moved on and now have Modern Fortran!   


>>Now, the results are identical to the listing in the pdf with just some floating point accuracy differences

Note, this program was written to run on an IBM 7094 which had a 36 bit word size. The REAL (single precision) format had 1 bit sign, 8 bits exponent and 27 bits for mantissa. "Modern" computers use 32-bit word size with 1 bit sign, 8 bits exponent and 23 bits for mantissa. IOW 4 bits less precision (about 1.5 digits loss). DOUBLEPRECISION will have an 8-bit loss (~2.25 digits).

Any code you borrow could potentially contain convergence code written knowing (requiring) 36 or 72 bit floating point precisions, and that code may need to be adjusted. Try to make use of EPSILON to adjust for potential precision differences.

Jim Dempsey


Additional historical note that is pertinent today.

Recall that the 60's vintage computers such as the IBM 709x, Digital Equipment Corporation PDP-10, and other processors used 36-bit single precision floating point and 72-bit double precision floating point... though the bit field size may have differed. For example the IBM 7090/94 had 1 bit sign, 8-bits exponent (excess 127), and 27-bit mantissa. The Digital Equipment Corporation PDP-8 with 12-bit word used 12-bit exponent, 1-bit sign, 23-bit mantissa.

These systems pre-date any concept of "byte", which came in after the advent of the 8-bit processors.

Therefore there was no contextual meaning for REAL(4) or REAL(8)... Four what? Eight what?

Anyone that has been on the Fortran forum will note that Dr. Fortran (Steve Lionel), who is the Fortran cum laude in this neighborhood, has been stressing us programmers .NOT. to us REAL(4) and REAL(8) or 123.456_8, but rather use a size suitable for a desired precision using SELECTED_REAL_KIND or IEEE_SELECTED_REAL_KIND.

Yes, this is a bit awkward to someone who's accustomed to using REAL(4), (8) or (16), but we programmers should learn from the past. At a point in the past, floating point precision was not expressed in terms of bytes. In the future, who is to say that floating point formats will keep an identity related to the byte. While I do not anticipate a resurgence of 36-bit word size processors, consider what might happen to floating point formats with the introduction of quantum computers.... IMHO there will be no dimensional equivalent to an 8-bit BYTE, 16-bit WORD, 32-bit DWORD, 64-bit QWORD, 128-bit DQWORD.

Jim Dempsey


BTW these systems typically used the term character, but were of differing formats:

36-bit word representations:

Six 6-bit characters
Five 7-bit characters (plus spare bit)
Four 8-bit characters (plus four spare bits)
Four 9-bit characters (8-bit + parity)
Three 12-bit Hollerith characters

Jim Dempsey

 


Pedantic note: The 4 and 8 in REAL(4) and REAL(8) are kind numbers, not byte sizes. Most but not all developers (NAG being a prominent exception) chose kind numbers (mostly) matching byte sizes with their Fortran 90 and later compilers, but one could argue that this just confused users more. (I say mostly because COMPLEX(4) is like COMPLEX*8).

I don't think there are any processors that support Fortran 90 or later which don't have 8-bit bytes. But the Fortran standard is mostly agnostic to the size of a numeric or character storage unit. It's mainly in C interop where it becomes more evident.

Steve (aka "Doctor Fortran") - Retired from Intel

Quote:

jimdempseyatthecove (Blackbelt) wrote:

BTW these systems typically used the term character, but were of differing formats:

36-bit word representations:

Six 6-bit characters

Considering the use of only 6 characters "strings" in the program it confirms that the target system was a 36-bit word system (integer and single precision floating point numbers) and 72 bits for double precision.

I had to change some of the variables to character*6 to allow the program to be compiled successfully witfh CVF. Watcom Fortran is more permissive.

 

Leave a Comment

Please sign in to add a comment. Not a member? Join today