nelson_p@apollo.HP.COM (Peter Nelson) (02/12/90)
Well, I have a rudimentary version of my little CA tool running
on my monochrome XT clone (Leading Edge Model D).
The application currently interfaces to it via #include's....
I originally thought I might compile the applications
separately and link them in, but I found it better for the
application to supply a structure definition for the individual
cells, as a typedef 'CELL', which the CA program uses to define
and manipulate the arrays. Also, this way the application
can customize the CA program with #defines, which can then be
used in conditionally compiling certain paths, which results
in better run-time performance and smaller code than having to
check flags at runtime.
Currently the application supplies:
1. an initialization routine, which may either be called on a
per-cell basis or once for the whole array (or both).
2. An "action" routine, which the CA program calls once for
each cell being processed. This implements the rules.
3. A display routine which decides whether or what to draw
for each cell.
4. Data information: mostly, a definition of the cell, called
CELL, the SIZE of the universe, and
the number of generations to run. The
appliaction may also #define conditions
here for customizing the CA program.
The CA program allocates the necessary space. It calls the
init routine(s). It cycles through every cell in the universe
for time T and calls the action routine.
[ A quick and dirty solution to the "collision" problem that
I raised earlier was suggested by one emailer who credits the, "'Wator'
ecological simulation published long ago in Scientific American's
Computer Recreations column". Basically it involves resolving
collisions on a first-come, first-served basis and minimizing
order-dependent effects by processing the cells in *random* order.
I accomplish this by creating a 1d array of size n, where n is
the total number of cells in the "universe", containing the values
0 thru n-1 in scrambled order. This array is used as an index for
processing the cells in their arrays. The disadvantages of this
approach are the added memory and processing overhead involved
and the the fact that it doesn't "really" solve the problem.
Also random processing of arrays defeats many compiler optimizers
out there. Anyway, the cells are thus processed in random order. ]
After processing a generation it draws the results to the screen
using the application-supplied graphics rules. It also copies
generation T_plus_1 to T and starts over.
The CA program supplies a number of utilities to read the states
of neighboring cells and to do the graphics. By supplying functions
for doing the graphics I can offer a simpler graphics interface to
the application than the one supplied by Zortech, and also make
the application less-dependent on the particular compiler's
graphics library. I expect that I will eventually have a huge
collection of CA applications and I don't want to have to rewrite
them if I go to a different platform or compiler.
I've written two applications so far: Life, and a Parity Rule
application. They were very small and took minutes to write using this
this interface.
What next: (besides getting a faster PC, with VGA display 8-) )
Graphics input: I need an easy way to create starting patterns
instead of saying things like:
cell[32][34].state = 1; <etc>
...maybe mouse support?
File support: Saving the state of a universe could be helpful
on simulations that run for days, both to avoid
starting 'from scratch' after crashes or power
failures, and also so I can use the computer for
other things.
Simple-cell support: I designed my program for supporting fairly
complex definitions of cells, perhaps including
floating point vectors and other state information.
So the *minimum* chunk of info per cell is a byte.
For many CA applications a bit or two is all that's
needed and a byte is the maximum (or more) on many
commercial CA's. If I can find a *SIMPLE* way (for
the application interface) to support arrays of a
few bits per cell then I can support bigger universes.
Hard-copy: I don't have any good way make hardcopies of my
hercules graphics screen. (For you PC people, the
*print screen* function doesn't work with Herc,
becuase Herc isn't supported on IBMs) Being able
to convert the state of my universe to a standard
graphics file format would be helpful for printing it.
Performance: This doesn't exactly scream. "Life" takes about
6 seconds to do one generation on a 110 X 110
wraparound grid ( on a 7Mhz 8088 ). Probably 40%
of this is graphics bound since I can get a huge
speedup by only doing the graphics every nth generation.
Still, I think there are other opportunities for
efficiency in my program, as well. The whole design
of this has favored simplicity and ease of application
writing over performance and I don't want to violate that.
( suggestions? Since I've never used a commercial CA program
I have no idea what they typically offer )
The whole source is currently less than 200 lines long, including plenty
of comments. After I've cleaned it up and improved it I may be willing
to post it if there is any interest.
---Peter