Cellsprings Help: RuleTool Panel

The RuleTool is the panel to the right of the CA display in the main window. It is a mini rule editor. Whenever a preset or user rule is loaded, it changes to reflect the new rule's parameters. If the rule type or neighborhood size has changed, the controls themselves change to correspond to the new rulespace. The rulespace can also be changed independently for editing purposes using either the RuleTool's rightmost buttons or the RuleTool menu.

Global Usage Tips

Because of the tie between rulespaces and editor controls, most of the usage information on this page is arranged around the RuleTool rule types. But there are a few general points of which you should be aware. Probably the least obvious of these is that you must press the Enter key in a RuleTool textfield for the entered value to "take". (BTW, the RuleTool and StateMate are different in this respect, for reasons that trace back to the original WebsideCA Java 1.0 oriented design.) Once you have made any changes to a rule definition, the Apply Rule Definition command becomes available to load your custom rule into the CA for running and/or saving. The handiest way to issue the command is to use either the tool button or keyboard shortcut.

Several of the rulespaces permit entry of special rule codes. These are of two sorts. In the first, the bits of the rule table are packed into a numeric value. A common feature of these packed-code fields is their "two-way" relationship to the other controls. That is, if you modify the code the table grid updates, as expected, but also if you alter the table by other means the code is updated to match. Packed codes provide a compact and unambiguous way of referring to and entering particular rules, and can sometimes be a handy means of making systematic changes to a table during editing - a crude example being to enter 0 to clear the table.

The second sort of code does not have this two-way feature. These are the codes entered into popup ASCII "import" fields. As that designation implies, these fields are write-only - that is, they update the rule table but are not updated by it. Also, since import strings can get quite long, the usefulness of the import facilities is at the mercy of whether your Java runtime supports copy and paste between your native OS and Java input boxes, as most but not all do.

General Rulespace Concepts

Neighborhood

Each built-in rulespace is defined on one of the two standard nearest-neighbor neighborhoods, depicted below. (But note that Cs/DT's springlet facility offers freedom from this limitation.)

`von Neumann :`	`N W C E S`	`Moore :`	`NW N NE W C E SW S SE`

There are a few notational quirks of mine to clear up, and I regret burdening you on the subject, but I have found myself borrowing terms from certain subcultures whose taste for terminological brevity, at least, is admirable. Hence, I often abbreviate neighborhood as hood and occasionally refer to an unspecified member of the hood as a homie. The latter term allows neighbor to exclude the center cell, as any common reading of the word would, and I've often found myself needing the distinction. As for hood type, who in his or her right mind wants to keep saying 'von Neumann', so I have sometimes referred to the types in terms of hoodsize (H), which, since the center cell is counted as part of the hood (but is not a neighbor!), is always 5 or 9 in the built-in types.

Cellsize

I use this term or its symbolization as C to refer to the number of permissible values for a cell under a given rule, the values normally being numbered 0..C-1. Perhaps this parameter could more precisely have been called 'cell resolution', but that's more awkward, and if anything is even more likely to engender confusion with the width in pixels of the on-screen representation of a cell's value. (To me this other common CA program usage is a misnomer - a cell is a mathematical entity, not a graphics widget. It seems a good idea to maintain the distinction between a CA and its representation, at least where it's convenient to do so.)

Built-in Rule Types

Outer Totalistic

These are counting rules. The number of 1-valued neighbors are tallied up and the next value of the center cell depends on its last value and this neighbor count. "Outer" totalistic rules distinguish the center cell in this way from the other cells in the neighborhood. Both Moore and von Neumann neighborhood OT rules are directly supported. The checkbox table changes to reflect the differing hoodsize.

As with the other rule types having binary rule tables, you can set the Cellsize (C) field to something greater than 2 to define a decay rule. In a decay rule, when a cell goes from 1 to 0 it passes through C - 2 intermediate states, one at each CA step. Further, these decay states are "refractory" -- that is, a cell has to cycle back to 0 before it can be "turned on" again as per the look-up table.

The Decimal Code uses the encoding published in an article by Stephen Wolfram available online as "Two-Dimensional Cellular Automata". (BTW, if you enter codes from this article, be aware that a few of the listed codes are misprints.)

General 1Bit

Type Description

This type constitutes a look up table indexed by all possible neighborhood state vectors, where the individual cell input and output values contain only 1 bit of information. Thus it encompasses all possible 2-state rules definable on a given neighborhood. As such it includes the outer totalistic rules, but, since it would be a more cumbersome way to specify them, the interest here is of course in non-OT rules - rules where not all neighbors are created equal, so to speak. Where, for instance, the rule distinguishes opposite from adjacent neighbors or North neighbors from South ones.

While the lookup table is binary, as in the OT case we have extended this type to allow cellsize to vary independently, with the understanding that the additional states are refractory decay states.

There are an immense number of G1B rules. For von Neumann rules there are 2^2^5 (> 4 billion) unique lookup table configurations, while for Moore hoods the number explodes to a staggering 2^2^9 (> 10^154). And the decay parameter multiplies these numbers still further. Given a search space on this scale, it's no wonder that new discoveries are being made on what seems like a daily basis among non-OT binary rules, by Ben Schaeffer and others, whose new tools have, as it were, opened up a trade route into this exotic empire.

Editing

As with OT rules, both von Neumann and Moore neighborhoods are directly supported. The rule table grids show all the current entries, where blue is 0 and green is 1 (as in the default color map). Each birth/survival pair of table entries has a unique configuration of neighbor states, which are shown for the currently-selected pair via the neighbor-state checkboxes. Positioning the mouse cursor over the grid selects an entry pair, whereas clicking a square also toggles the corresponding entry. You can also select a specific entry pair by setting the neighbor-state checkboxes directly.

The von Neumann editor features a Hex Code field, which is simply a packed numerical representation of the 32 lookup table bits. The code is formatted in hexadecimal for the sake of compactness and consonance with table size. The ordering of the table entries is that provided by an ascending walkthrough of the neighborhood states, where the cell states are mapped to the table index bits in the order EWSNC (from high bit to low bit). As for the packing order of the table entries in the code, the table index is mapped directly to code bit-significance. My neighbor-ordering is the same as that given in the book Cellular Automata Machines by Tommaso Toffoli and Norman Margolus, but my packing order is opposite to that used in their code examples on page 33. (BTW, their code for the Parity rule is in error - binary 1001 is hex digit 9, not D. So using their packing order the code should be 69969669.) My ascending bit-significance packing order makes the G1B code consistent with the Wolfram OT code.

The G1B editor is mainly low-level, and would have been equipped with an array of time-saving transformations had I the time to develop them. However, there are a couple of minor but useful aids to editing. The first has already been alluded to in the preamble: you can use the hex code as an editing aid. The second potential time-saver involves the fact that when you flip from the OT type to the G1B type the OT table is used to initialize the G1B table. That is, you get the more diffuse G1B representation of the OT rule. This OT to G1B expansion facilitates an approach to designing rules in which one makes small nontotalistic modifications to totalistic rules, as, for example, by discriminating between North and South neighbors or between adjacent and opposite neighbor-pairs.

Lastly, as a late addition that was somewhat tacked on, the Moore G1B editor has an Import button that pops up a dialog box for entering a rule definition in the Weighted Life format supported by MCell and other software. Take care to enter only the raw ASCII definition, all on one line.

General 2Bit

Type Description

These are exhaustive tables as in the 1-bit case, but here the table entries and the individual cells in the neighborhood vectors that index them may take on additional values, as determined by the cellsize parameter. Thus, in contrast to our 1-bit rules, cellsize here equates to table entry size - there is no concept of "decay".

This type is restricted to cellsizes 3 and 4 (hence the 2-bit designation), and only von Neumann hoods are presently supported. The CAR file spec actually supports larger C and H in its general model, but since such tables increase in size as C^H they quickly blow up to unmanageable size. (Actually, though, the Cellsprings restrictions are conservative. It would be easy enough to load and run H5 rules of somewhat larger cellsize, and H9C3 rules. But run-ability and edit-ability are two different things, and since the editor is still rudimentary even for presently supported table types, it's hard to justify further extensions.)

As given by the above formula, the rule table sizes under this type are 3^5 = 243 and 4^5 = 1024 for the C3 and C4 cases respectively, leading to 3^243 and 4^1024 numbers of definable rules. The former, while a staggeringly monstrous number, is actually less than the 1-bit Moore case. The C4 case, however, blows 'em all away. When I try to translate it into base 10 terms, the Windows calculator freaks out, since it goes up to "only" 2^1023, which is about 10^307.

Editing

The editing functions are presently quite limited, and there is no graphical display of the table contents. Basically all you can do is (1) randomize the table within a single constraint, and (2) import a raw ASCII table. The randomization constraint is the percentage of nonzero entries in the table; you can either (1a) perturb the table to a new percentage by entering it in the textfield, or you can (1b) reshuffle the entries at the present percentage by pressing the Scramble Table button.

The Import button pops up an entry box that first asks you specify the significance of each homie in the table indexing scheme. The native Cellsprings ordering is the same as that given above for 1-bit rules, viz., EWSNC. But you can use any other ordering and the facility will translate it. An ordering you might run across is that used by the MCell "Neumann Binary" rulespace, CNESW. In the second field of the dialog you supply the rulestring proper, that is, a continuous one-line text string representing the table contents, in ascending order according to the walk-through scheme you just provided.

If you do import rulestrings from MCell, note that you must omit the leading digit in that program's raw code. Instead it should be entered in the usual RuleTool Cellsize field. Also, take care to enter the cellsize before using the import function, because cellsize determines the type of table to be filled. The import facility is for setting table contents only.

As for the CRC32 readout, that's just there to provide a "fingerprint" of the table contents in lieu of a graphical display. Though I don't know the details of the computation, I take it to be unlikely that you'll come upon two tables with the same CRC32 value without contrivance.

Cyclic Threshold

This is a parameterized subset of multibit rules. The only parameter specific to this rule type as we implement it is the totalistic Threshold field. Our implementation only supports the two nearest-neighbor hoods and thus lacks Griffeath's range parameter.

The template rule for the type goes as follows, where C is the cellsize and T is the threshold: If a cell of value x has at least T neighbors of value (x + 1) mod C, then the cell is "cycremented" to equal those neighbors. Otherwise it keeps its current value.

There's not much to the RuleTool for this type. When the neighborhood, the cellsize, and the threshold are set to your liking, you're done.

Springlets

The Springlets item appears at the bottom of the RuleTool's type menu. A springlet is a special Java class written according to a mini API built into Cellsprings, that defines either a hardcoded rule or, more typically, a rulespace defined on one or more parameters. When the Springlets menu item is selected the RuleTool provides a list of installed springlets to choose from, together with a list of parameter fields for the currently selected springlet - assuming the springlets programmer has defined any for it.

The other RuleTool controls function as usual with springlets, except that the hood controls are disabled in favor of letting the programmer define the neighborhood(s). The Cellsize field may or may not be editable, depending on whether the programmer has chosen to parameterize it.