# Only our own ruts

``` ENTER THE STATEMENT (70 CHARACTERS):
IS IT A DECLARATIVE SENTENCE (Y/N)?
N
ARE THERE ANY 'UNASSIGNED VALUES' (Y/N)?
N
A PREPOSITION IS A DECLARATIVE SENTENCE WITH NO UNASSIGNED VALUES.
YOU ENTERED:
WAS IT A DECLARATIVE SENTENCE? YOU ANSWERED N
DID IT HAVE ANY UNASSIGNED VALUES? YOU ANSWERED N
DO YOU THINK IT IS A PROPOSITION (Y/N)?
N
IT IS UP TO YOU TO DECIDE!```

# Calculating natural logarithm

Book’s value is 2.7182818 and I get 2.71828198. Pretty close!

```2.7182818
2.71828198```

Sample output (gist):

# Cards in the forest

Field widths almost demand intimacy with the input data – across all possible ranges, even. It was probably easier to punch them from cards or prepared, with all significant digits accounted for, from another trusted program. The stored and subsequent printing of inputs can vary greatly, mostly from these elements:

• user-punched decimal or not ?
• read() field width for FORMAT is Fx.0 or Fx.y ?

Here is sample output from reading in two numbers with different field widths:

And a summary of observations:

• blanks do not become zero
• gaps are collapsed
• arguments are “numbers on a card” and nothing more

# The slow down and pacing of yourself

Fortran 77 is pretty specific about its output. I draw a line and split it into boxes, each holding a letter, number or decimal point. That helps me with the FORMAT() calls. Here is what it looks like diagrammed in Excel (but I use paper):

It takes four notebook-paper lines to sketch out. Between that and flow-chart diagrams, I feel like I am planning programs, designing them, instead of diving straight into coding.

# Incorrigible input

Somewhere before the deep end, I am writing Fortran code.

```       READ (5, 100) COST, DEPREC
100    FORMAT (F7.2, F6.2)
VALUE = COST - DEPREC
WRITE (6, 200) COST, DEPREC, VALUE
200    FORMAT (1X, F12.2, F11.2, F12.2)
STOP
END```

The proper input demands fixed fields themselves. Passing 100 and 10 and the resulting output,

```\$ ./a.exe
0010000000100
100.00       1.00       99.00```

If the input were read in on a card, it would really be just a line of digits. The assumed decimal places are specified by the first FORMAT(); “assumed” as in does not count toward column positions. The second FORMAT() specifies printing position, and this time the decimal point does count toward column position.