       "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.

