Ruletable format extensions proposal
Posted: August 19th, 2021, 10:34 am
This initially started out as a LifeViewer suggestion (https://www.conwaylife.com/forums/viewt ... 253#p88253), but since these would involve changes to ruletable files and their formatting and interpretation, as well as the fact that other programs use ruletables as well, I figured it might be better to suggest these proposals separately for a wider audience and such.
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:
It can be seen that this rule is just Life, with extra dead states to indicate how many neighbours the cell had when it died. Note, however, that despite the Life pattern clearly dying, no "Life ended at generation" message was displayed, unlike with usual Life:
The reason is obvious - these functionally dead cells are still registered as alive cells by the viewer as there is absolutely no way for it to tell that these are supposed to be dead cells in the first place. This can be confirmed in either Golly or LifeViewer, where population counts include all of these meant-to-be-dead cells.
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:
It's clear to see that this rule contains cell states with a sense of directionality - some will only go in an certain direction, and so on. However, there exist states for any of the four desired directions. Despite the existence of these states, though, rotation and flipping transforms applied to the pattern result in something with completely different behaviour. This can be clearly seen to be the result of the states being preserved in these transforms, rather than being replaced with equivalent states facing the new expected directions.
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:
As the rule is meant to be the same as Life, but with each evolution taking twice as long, wouldn't it be fair to say that each generation of evolution would only count as half a generation? Having an ability to specify this somewhere in the ruletable, such that the generations count up in 0.5s rather than the usual 1s, might be better than it is currently, but this is probably nowhere near as important as the other two suggestions above.
----
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?
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?