Saturday, March 16
Cellular Automata Lecture
CINVESTAV
Professor: Harold V. McIntosh.




CELLULAR AUTOMATA (8)




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.



Return.