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