|
996
|
1
|
|
|
2 As documentation for the program life.i, I am including below the original
|
|
|
3 posting message, with the program itself deleted. The present program
|
|
|
4 life.i is nearly identical to the one that was posted. The only two
|
|
|
5 changes are that I have fixed a bug where a 32-bit number was assigned
|
|
|
6 to a 16-bit variable, and I have streamlined the decrement routine---
|
|
|
7 entry points (2000) and (2010)---by eliminating a temporary variable.
|
|
|
8 The old versions of these code fragments are included at the end of
|
|
|
9 the file.
|
|
|
10
|
|
|
11 Louis Howell
|
|
|
12 November 24, 1991
|
|
|
13
|
|
|
14 -----------------------------------------------------------------------------
|
|
|
15
|
|
|
16 Subject: Life with Intercal (long)
|
|
|
17 Newsgroups: alt.lang.intercal
|
|
|
18 From: Louis Howell
|
|
|
19 Date: Mon, 28 Jan 91 09:17:36 PST
|
|
|
20
|
|
|
21 I suppose some of you are wondering if anyone ever actually writes anything
|
|
|
22 in Intercal, or if we all just sit around beating on the compiler and
|
|
|
23 talking about how wonderful this crock would be if XXX feature were added
|
|
|
24 to it. I submit the following beast as a demonstration that a vaguely
|
|
|
25 interesting program can be written in the language. Of course, none of
|
|
|
26 you can actually RUN this program, since the 0.6 compiler doesn't handle
|
|
|
27 arrays. Take my word for it that it works, and I promise to finish up
|
|
|
28 a couple of remaining details in the array implementation and send it
|
|
|
29 off to Steve Real Soon Now (sometime this week, with luck).
|
|
|
30
|
|
|
31 The program first takes three numbers as input: The dimensions of the
|
|
|
32 grid and the desired number of time steps. It then accepts pairs of
|
|
|
33 numbers indicating which cells are live in the initial state; this
|
|
|
34 list of pairs is terminated by a ZERO or OH. Then it plays Life.
|
|
|
35 When the final timestep is reached, or when the system overflows the
|
|
|
36 grid, the program prints out pairs of numbers indicating which cells
|
|
|
37 were live in the last state reached, followed by the number of time
|
|
|
38 steps that were actually executed.
|
|
|
39
|
|
|
40 The implementation is not as efficient as it could be by a long shot---
|
|
|
41 I just wanted to get something that worked. I use two arrays, ,1 and ,2,
|
|
|
42 both with dimensions .11 BY .12. At each time step the next position
|
|
|
43 based on data in ,1 is computed and stored in ,2 for all cells in the
|
|
|
44 interior of the grid. Then this portion of the grid is copied back
|
|
|
45 into ,1. (The cells on the edge of the grid are never changed, they just
|
|
|
46 hold zeroes that are seen by the neighborhood calculations of interior
|
|
|
47 cells.) Then the current time step is incremented, and if equal to the
|
|
|
48 desired final time step the program jumps to the output routine. If
|
|
|
49 not, it checks the ring of cells next in from the edge cells. If it
|
|
|
50 finds three live cells in a row on one of the interior edges it jumps
|
|
|
51 to the output routine, since on the next timestep the configuration
|
|
|
52 would overflow into the boundary ring. Note that this boundary check
|
|
|
53 is not done until after the first time step, so the user is responsible
|
|
|
54 for providing an input state that is not about to overflow.
|
|
|
55
|
|
|
56 An overflow recovery procedure that actually increased the size of the
|
|
|
57 grid might be interesting, but wouldn't be terribly practical since
|
|
|
58 any configuration that throws off gliders would quickly push it to the
|
|
|
59 limit.
|
|
|
60
|
|
|
61 The following configuration has four live cells and grows into traffic
|
|
|
62 lights. To see the blinkers in the other position, change the final
|
|
|
63 time step from ONE OH to NINE or ONE ONE.
|
|
|
64
|
|
|
65 ONE ONE
|
|
|
66 ONE ONE
|
|
|
67 ONE OH
|
|
|
68 FIVE
|
|
|
69 SIX
|
|
|
70 SIX
|
|
|
71 SIX
|
|
|
72 SEVEN
|
|
|
73 SIX
|
|
|
74 SIX
|
|
|
75 SEVEN
|
|
|
76 OH
|
|
|
77
|
|
|
78 This is a glider aimed up the main diagonal. Specifying ZERO for the
|
|
|
79 final timestep tells the program to run until overflow, since the first
|
|
|
80 test is at step one. In this case it halts at step XVI with the glider
|
|
|
81 translated four cells up the diagonal. You can make it run longer by
|
|
|
82 increasing the dimensions of the array.
|
|
|
83
|
|
|
84 NINE
|
|
|
85 NINE
|
|
|
86 ZERO
|
|
|
87 TWO
|
|
|
88 FOUR
|
|
|
89 THREE
|
|
|
90 FOUR
|
|
|
91 FOUR
|
|
|
92 FOUR
|
|
|
93 FOUR
|
|
|
94 THREE
|
|
|
95 THREE
|
|
|
96 TWO
|
|
|
97 OH
|
|
|
98
|
|
|
99 Here are a few of the features of the program which may be of interest to
|
|
|
100 Intercal programmers. One obvious one not mentioned in the manual is the
|
|
|
101 test for equality: XOR the two numbers and test if the result is zero.
|
|
|
102 There are many examples of indexed loops. The loops over array indices
|
|
|
103 fall into two different classes, decrement and branch on zero, and
|
|
|
104 decrement and branch on equal. The time step loop uses increment and
|
|
|
105 branch on equal. The nested loop computing the next state has three
|
|
|
106 indices for each dimension, since it is easier to keep i-1, i and i+1
|
|
|
107 around than to recompute them on the fly. This also allows me to use
|
|
|
108 the simpler branch on zero test at the base of these loops since i-1 was
|
|
|
109 already available.
|
|
|
110
|
|
|
111 Three new subroutines may be of general interest. Line (2000) is the
|
|
|
112 entry point for a decrement routine setting .1 <- .1 minus #1. This
|
|
|
113 is very similar to the increment routine (1020) in the system library,
|
|
|
114 which I also use. Line (2010) is the decrement and branch on zero
|
|
|
115 operation. It decrements .1, then if .1 is not zero returns to the
|
|
|
116 calling point, but if .1 is zero pops an additional entry off the
|
|
|
117 RESUME stack and returns to that point instead. Line (2020) is an
|
|
|
118 alternative entry point to the (1020) routine which performs an add
|
|
|
119 bit operation. It sets .1 <- .1 plus .2, where .2 is already known
|
|
|
120 to be either #0 or #1.
|
|
|
121
|
|
|
122 The need for some kind of string I/O is painfully obvious. It would be
|
|
|
123 so much nicer to be able to show the final state using a grid of O's and
|
|
|
124 .'s instead of having to print out all the coordinates. I have some more
|
|
|
125 ideas about string I/O which I will post later.
|
|
|
126
|
|
|
127 Enough talk, on with the program:
|
|
|
128
|
|
|
129
|
|
|
130 [Program deleted, see life.i for the current version.]
|
|
|
131
|
|
|
132
|
|
|
133 This is where the original program had an assignment type error:
|
|
|
134
|
|
|
135 DO .2 <- #0$#65535
|
|
|
136 DO .1 <- "?'"V.1$,1SUB.7.8"~.2'$#3"~.2
|
|
|
137 DO ,2 SUB .7.8 <- "?!1~.1'$#1"~#1
|
|
|
138
|
|
|
139 This is the old, less efficient version of the decrement routine:
|
|
|
140
|
|
|
141 (2010) PLEASE ABSTAIN FROM (2004)
|
|
|
142 (2000) PLEASE STASH .2 + .3
|
|
|
143 DO .2 <- #1
|
|
|
144 DO (2001) NEXT
|
|
|
145 (2001) PLEASE FORGET #1
|
|
|
146 DO .1 <- '?.1$.2'~'#0$#65535'
|
|
|
147 DO .3 <- "?!1~.2'$#1"~#3
|
|
|
148 DO (2002) NEXT
|
|
|
149 DO .2 <- !2$#0'~'#32767$#1'
|
|
|
150 DO (2001) NEXT
|
|
|
151 (2003) PLEASE RESUME .3
|
|
|
152 (2002) DO (2003) NEXT
|
|
|
153 PLEASE RETRIEVE .2 + .3
|
|
|
154 (2004) PLEASE RESUME #2
|
|
|
155 PLEASE DO REINSTATE (2004)
|
|
|
156 PLEASE RESUME '?"!1~.1'~#1"$#2'~#6
|
|
|
157
|
|
|
158 --
|
|
|
159 Louis Howell
|
|
|
160
|
|
|
161 "But when we got into the street I viddied that thinking is for the gloopy
|
|
|
162 ones and that the oomny ones use like inspiration and what Bog sends."
|
