Currently ruletables only really allow for the customisation of a few things about the functionality of cells and states in a rule, namely their interactivity and nothing else. This makes sense for basic isotropic rules and the like, but ruletables have been used for far more diverse things than just these, such that they become problematic limitations in many cases. Here are some example cases where the format falls short, as well as proposals to fix them:
State Population Counts
Consider the following rule:
Code: Select all
x = 7, y = 3, rule = LifeNoted
bo3bo$2obob2o$bo3bo!
Code: Select all
x = 7, y = 3, rule = Life
bo3bo$2obob2o$bo3bo!
Rule tables could implement a solution to this by including a new section which includes the "population value" each cell contributes. In this case, it'd be simple: the Life cells would have a value of 1, and all the dead cells would each have a value of 0. Other rules would be able to make more extensive use of this section, for example PCA ruletables would be able to have living cells use a value between 1 and 4 depending on how many of the four directions are contained within. (LifeViewer already supports such functionality natively for PCA rules.)
It may even be possible to have multiple orthogonal values for differently-behaved cell states, such as gray LifeHistory cells being counted as a different type of cell than Life cells in a LifeHistory pattern where both are present, but that may be too complicated so I'm open to leaving that one out and only counting real numbered state counts.
Rotationally Equivalent States
Consider the following pattern:
Code: Select all
x = 15, y = 7, rule = HPP
3.P7.P3$P10.N2.P3$3.P7.P!
Again, a section in the ruletable to create relationships between states for rotation would solve this issue. Any state could be linked to any other state upon a desired rotation or flipping. For a square grid, there would be 0, 90, 180 and 270 degree rotation transforms, alongside either horizontal and vertical flipping.
Rotation state switching is another thing LifeViewer natively supports for PCA given their directional elements. (This is also the reason why Identify can calculate Mod data for PCA rules, and the reason why the above pattern isn't identified as having a mod half its period even though it really should.)
Generation Incrementation Value
While most rules are fine with increasing the generation count by 1 per generation, this logic does not apply universally. Reversible rules are a classic example where the incrementation value would be -1 for the relevant reverse rule.
There are also stranger cases, such as SlowLife:
Code: Select all
x = 46, y = 41, rule = SlowLife
2$24.2A$24.A$25.A$22.4A$13.2A7.A$13.A11.3A$10.2A.A11.A2.A.2A$8.A2.A.
2A2BA9.2A.A2.A$8.2A.A3.2C.AB2.2A6.A.2A$11.A2.B2C.2C3.AB5.A$11.2A2.A2.
2CB.BA5.2A$16.CBA.C.C3$17.2A$17.2A3.3A$22.3A$17.2A$17.2A3$19.A$11.2A
5.2A9.2A$11.A5.2A.A9.A$8.2A.A6.A.A9.A.2A$8.A2.A.2A4.2A6.2A.A2.A$10.2A
.A11.A2.A.2A$13.A11.3A$13.2A7.A$22.4A$25.A$24.A$24.2A!
----
Are there any other things that might be worth adding to the rule specification, stuff I haven't thought of in regards to the three above, complaints, or anything else?