"Life" plays the game of Life, in which a collection of very simple

rules causes two dimensional patterns to change, and to survive or to die

out, in complicated and surprising ways.  This program can manage large

patterns (up to 46x120), can save and load patterns, and can show on one

screen the successive generations of a pattern's evolution.







REQUIREMENTS



        The program itself occupies a little under 3000 bytes of memory,

but will use more memory to examine larger patterns.  At most it might use

another 2500 bytes. The demonstration pictures and display program will

occupy around 13500 extra bytes, but you don't need them to run the

program.



THE RULES OF LIFE



        The fate of every pixel is determined by its neighbors.  If four or

more of the neighboring pixels are on (overpopulation), or if only one

neighbor is on (underpopulation), the pixel will be off in the next

generation. If the pixel is currently on, and if it has two or three

neighbors that are also on, then it will remain on (survival).  If the

pixel is currently off, it will remain off unless exactly three neighbors

are on (reproduction).



        These rules can be thought of as modeling, loosely, the behavior of

bacteria, or of some other organism whose survival and reproduction depend

on the availablity of certain resources (e.g. food), and hence on the

number of neighbors in competition for this resource.



        Some patterns do not change (a square of four contiguous pixels,

for instance, will not change), some patterns die out (a diagonal line will

always disappear in a time a little over half its diagonal length), some

patterns oscillate (a 3 unit long vertical line will become a 3 unit long

horizontal line, which will in turn become a vertical line, ad infinitum),

and I don't know whether it has been settled if there are or are not

patterns which never degenerate into one of the above conditions, but

instead continually renew themselves.



        There are also various gliders (which move across the screen),

emitters (which emit gliders), and a considerable menagerie of other

structures.  Two 1972 issues of _Scientific American_ have good discussions

of the game, and examples of interesting patterns, but I'm sure that more

work has been done since then.  I noticed that in this month's _Scientific

American_ (Jul '94), it was mentioned that it had been proven that a

pattern in the game of Life could represent a Turing machine, which means

that it could emulate a digital computer, and thus anything that a digital

computer itself could emulate (even, perhaps, conscious minds like our

own--although it would probably be somewhat of a dullard, full of banal and

unwitty conversation, if run on so slow a machine as the TI-85).



HOW TO USE THE PROGRAM, HOW IT WORKS



        Before first running the program, set the variable "LConfig" equal

to zero.  Everything is menu-driven, and about as simple as it seems.  But

there are some bugs (or features):



*       What you see is not necessarily what you get.  The pattern in

memory is not necessarily the same as the pattern on the screen, even if

Auto-View is on.  Be sure to run the View command whenever you're in doubt.



*       A pattern's world is NOT closed (i.e. wrap-around).  If it hits the

edge there will be problems.  The edge is NOT the drawn border lines, but

is instead the pixels directly next to those lines; so if you see that in

the next cycle any of those pixels should be lit, then it is time to abort

the cycle and enlarge the world to accomodate the pattern's growth. Since

it's hard to predict how large a pattern will become, this is a real

problem.  If there's enough interest, then I'll write another version of

the program that will automatically enlarge the pattern's world, or will

make the world wrap-around (though this would further slow each cycle), or

will simply stop once the pattern hits the edge.



*       Since the TI-85 does not have a Pt-Status command, and since its

memory is insufficient to store a screen as a matrix, the program stores

the patterns as lists, where each element represents in binary the status

of every pixel on a column.  Because of this, the program evaluates empty

columns much faster than it evaluates empty rows; so if you want your

patterns to run faster, make them wide and short, not tall and thin.



*       The generation mode is only for cycling the pattern.  I have no

idea what will happen if you try to load, save, or edit the pattern while

in generation mode, nor do I care to know what results such perverse

behavior brings.



*       All settings are saved in the real variable LConfig, which must be

set to zero before first running the program.  When running, the program

uses the real variables X,Y,x,y,q,I,BX,BY,ZX,ZY, & Ans, and the lists T,S1,

& S2, all of which may be deleted between runnings.



*       The program runs slowly, but as fast I know how to make it just

now.  The central problem is that the program must examine every pixel and

all its neighbors.  If someone can think of some clever way to do this

faster, maybe using some bit operation that handles it all at once, then

I'd be delighted to hear about it.



MENUS



The Main Menu



Cycle:  Evolve the pattern in the calculator's memory, and view it

        if in Auto-View mode.  If in Generation mode,  show as many

        cycles of the pattern's evolution as will fit on the screen.

        While the program is computing a generation, it will proceed

        up the rightmost column, drawing dots everytime it has

        finished computing a column of the pattern.



View:   Draw on the screen the pattern currently in the calculator's

        memory.



Edit:   Go the Edit menu, from which the current pattern can be

        edited.



Setup:  Go the Setup menu, from which the mode can be changed, and the

        current pattern saved, or a new pattern loaded.





The Edit Menu



Clear:  Clear the pattern currently in memory.



Edit:   Edit the current pattern.  Move the cursor to the point you

        want changed, and press Enter--that point will change from on

        to off, or from off to on.  To stop editing take the cursor

        outside the boundaries of the current pattern's world, and

        then hit Enter.



Shift:  Shift the current pattern right or left, and up or down in the

        pattern's current world.  At the x=? prompt, enter the

        desired x displacement of the pattern, using a negative

        number if you want it shifted left.  At the y=? prompt, enter

        the desired y displacement of the pattern, using a negative

        number if you want it shifted down.  WARNING: There is no

        bounds checking in the up direction, so be careful not to

        shift the pattern up outside of its current world.





The Setup Menu



Load:   Load a pattern into memory, and automatically readjust the

        current world dimensions as needed.  Patterns are represented

        by the program as lists, so you must enter the appropriate

        list name to load that particular pattern.



Save:   Save the current pattern to the SAVED list.



Auto-View:

        Toggle the program into or out of Auto-View mode.  When in

        Auto-View mode, the program will automatically display the

        new pattern after the "Cycle", "Edit", "Load", and "Clear"

        commands.



Generation Mode:

        In Generation mode, the "Cycle" command does not cause only

        the computation (and possible display) of the next pattern,

        but instead causes the causes the calculator repeatedly to

        recompute the pattern, displaying each cycle (each

        generation) on the screen at once, going from the bottom left

        to the top right.  You can hit Enter to stop the process.

        (The pictures in the demonstration programs were produced in

        generation mode.)





ME!



        If anyone cares to diddle with the code and wants some

questions answered, drop me a line at agallagh@fas.harvard.edu.