Cellular Automata Lecture

CINVESTAV

Professor: Harold V. McIntosh.

During Easter Week we had an opportunity to review cellular automata in
general and Rule 54 in particular. A good reference on Rule 54 is:

N. Boccara, J. Nasser, and M. Roger

Particlelike structures and their interactions in
spatiotemporal patterns generated by one-dimensional
deterministic cellular-automaton rules

Physical Review A 44 (2) 866-875 (1991).

Although it is ten years old, it gives a pretty thorough summary of the
properties of this rule. Searching the Internet or elsewhere turns up quite
a large number of references to Rule 54, which some authors regard as "the
most complicated of all the rules," although it is not clear whether they
took Rule 110 into consideration.

Anyway, the question arose, of whether Rule 54 deserved a treatment similar to
the one we have given to Rule 110, which mostly means cataloging its properties
usin LCAU21. Besides the LCAU21 in the files, we have a version which was
modified to go beyond 7 generations with the de Bruijn diagram, namely to do
9, 10, or 11 generations, with tengen.c being the most reliable. The only real
problem consists in handling huge arrays, since the diagram increases by a
factor of 4 with each generation , and ten generations means a million nodes.
The Objective C compiler seems to accept this, but there must be limits.

The log accompanying the program indicates that the last changes were made
three or four years ago, presumably at the time of increasing the memory
allotment for the de Bruijn arrays. In the meantime there has been discussion
of exporting the linkage list to G'ph, which was the basis of a program done
at about that time. But here the changing NeXT environment, among other things,
has meant that little has happened. But the past few days, an alternative to
G'ph has occurred to me, so LilGuph has been modified accordingly. But to see
that through to the end promises to take up a chunk of time.

Graphs can be represented either as a square matrix, but it is huge and sparse
most of the time. That means it is better to use a linkage list, although one
actually needs two; one for in links and one for out links. That is still
better than the fuull matrix, but the mappings between all the styles still
require programming effort. Also, when the full matrix can be used, it is the
easiest way to find shortest paths, least cycles, and similar items.

However, the particular structure of de Bruijn diagrams makes looking for the
linkd especially easy. If KK is the number of states, and hence the number of
links per node, and dd is the order of the de Bruijn diagram (the number of its
nodes) then the nodes should be taken as binary numbers and graphed as binary
increments around the circumference of a circle.

Node i then links to nodes KK*i, KK*i+1, ... , all mod dd, which is easily
enough calculated. What is just as easy but apparently not adequately realized
is that the incoming links arrive from nodes i/KK, i/KK+hdd, i/KK + 2*hdd, ...
where hdd = dd/KK, again mod dd. Note that integer arithmetic discards
remainders. which is what ObjectiveC does, and all is well.

Such a nice formula isn't available in general, and also isn't helpful if the
de Bruijn diagram has been compressed after having found its nucleus, in the
case of applications to shift-periodic sequences. Also for the subset diageam
nor the pair diagram, which is probably why the idea wasn't considered long
ago when the LCAU were first being written.

Given that it is easy to locate the adjacent nodes, the graph editor, which
is a good part of LiulGuph.m, should be able to move them up to sit beside the
node itself. That is done with a double click, or with a double-click option
if there are several possibilities. For out-links, that facility has actually
been in the program, and I have used it to edit diagrams now and then. It is
all rather tedious.

If the program is going to be worked on, other changes might as well be
included. There is an old option for ignoring the zero-zero link, but it was
always done by recompiling (the lazy man's choice) rather than editing the
.nib file and so on. Well, that's fixed; it is convenient when zero is an
ideal as it often is in both Rule 54 and Rule 110, and can reduce the clutter
in a diagram markedly. But one good thing leads to another, and it can be seen
that excluding other nodes under mouse control (and later restoring them) would
be very nice! But that also means keeping their ghosts so as to know where they
were. And so on ... .

If both in-links and out-links are to be drawn nigh, they might as well link
in opposite directions. But then the direction of linkage and the distance at
which they sit and even a finer control of the direction all invite putting
sliders or option buttons on an auxiliary panel, so there is no lack of
programming chores for someone who wants to get a more versatile editor.

Not to forget gathering in multiple nodes, not just one. When all the different
variants are taken into account, either the auxiliary panel has grown
complicated (cycle diagrams already show the tendency), or a specialized REC
should be created, or both.

A very small cosmetic change, but which made the de Bruijn diagrams
considerably easier to work with was to adjust the size of the work sheet to
a letter size page and then scale the circular de Bruijn diagram to fill it.
Previously the page wouldn't go to Draw without rescaling and than in an
inconvenient proportion after which the diagram was too small to be seen if it
had not been edited. All of which constitutes a good example of why it is
important to consider the aesthetic aspects of what you are doing, including
its possible insertion into other work projects.

But then, since the first attempts at editing consist in pulling modes out of
an overly full circumference, why not usr cos(theta)+0.1cos(10 theta) or
something similar for the circle in the first place? Maybe I'll try it.

All of this work supposes that de Bruijn diagrams are sufficiently important
to spend this time working on them, rather than graphing plane waves in SERO,
for example. Well, that needs to be done too. However, with the imminent (sic)
publication of Wolfram's book, it is not inappropriate to see if our own
documents are ready for the possibility of some interest.

The concordance is fairly short on examples of lattices in which the different
triangles occur, particularly the larger triangles. That it turn shows that
"Rule 110 as it relates ..." never had the full illustration for generation
7 de Bruijn diagrams, no more than tables for 8 and 9 generations, and not
even that for ten generations. As I recall, I checked through them, but the
diagrams were so messy that all I ever did was to note their size in nodes
and links, but not attempt to visualize them further. An eleven generation
program exists (4 megabyte arrays) but I'm not sure if it works properly - I
tried it on the weekend and the results weren't convincing, but I have no
idea why. But anyway, it ought to be possible to include more information up
to and including ten generations. (Also that factor 4 means that the machine
in the library can take hours to generate a diagram)

The main reason the de Bruijn programming got started was the session last
week in which there was a doubt as to whether Rule 54 deserved the full
treatment. Just at first sight, there are fewer diagrams than for Rule 110
(aside from the fact that it is symmetric and it is only necessary to look
at half of them). Also there isnothing that looks like gliders.

However, there is one feature in common with Rule 110, in that the shift -
periodic structures are far more numerous whan what shows up in random
evolutions, particularly after a hundred generations or less. Just as ether
triangles dominate Rule 110, base-4 symmetric triangles dominate Rule 54.
Superimposed on these, there are two somewhat larger triangles, which position
themselves in columns. Larger triangles just never seem to evolve.

What gives the rule its reputation for complexity is the fact that those
four-cell-base triangles can be staggered in divverent ways, particularly as a
result of their interfacing to the larger triangles. As a misalignment works
its way across the background field, it can move the bounding triangles. Thus
they are subject to a very weak attraction, according wo ehich they can
eventually coalesce and disappear. This is thedynamics which the published
papers have found so interesting, taking Grassberger's Rule 18 as their basis
og comparison.

We found some interesting declarations, such as that the field has to evolve
into parallel irregularities. Apparently no thought was given to solitons
because Rule 54 doesn't have them (or at least, they are hardly apparent).
And of course, they form an important part of Rule 110.

In general, it seems that Rule 54 is similar to others in being a diffusion
problem, of defects or structures against a background. Well, so is Rule 110,
except that it involves propagation instead of diffusion.

It is hard to discuss either Rule 54 or Rule 110 without referring to the
tiling problem, so the week's ruminations included reading some papers on
tilings as shift dynamical systems. But whereas that seems to be a good
approach for Penrose tiles, it still seems rather speculative, that the
existing theory is helpful for these two cellular automata. Although the
tiling seems to conform to definitions, and excluding triangles abutting
on their top edges leads nicely into a shift of finite type, the question
remains, of how we are supposed to use the theory, or what information it
is supposed to give us. We'll just have to keep reading, I guess.

The April issue of The American Mathematical Monthly which has just arrived has
an article,

I hope to make time for SERO, but it wouldn't be a good idea to promise it.

- hvm

Aimee Johnson and Kathleen Madden,
Renewal Systems, Sharp-Eyed Snakes, and Shifts of Finite Type
American Mathematical Monthly 109 (3) 258-272 (2002).

I found it hard to read on the grounds that some presentations are too
detailled (in contrast to those which are not detailled enough), but mostly
because they also don't seem too preoccupied about the matter of why Shifts
Of Finite Type are so special? But they seem to touch on most of the standard
themes, including road coloring.