Ruletable format extensions proposal

For general discussion about Conway's Game of Life.
Post Reply
User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Ruletable format extensions proposal

Post by muzik » 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:

Code: Select all

x = 7, y = 3, rule = LifeNoted
bo3bo$2obob2o$bo3bo!
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:

Code: Select all

x = 7, y = 3, rule = Life
bo3bo$2obob2o$bo3bo!
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:

Code: Select all

 x = 15, y = 7, rule = HPP
3.P7.P3$P10.N2.P3$3.P7.P!
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:

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!
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?

ColorfulGabrielsp138
Posts: 288
Joined: March 29th, 2021, 5:45 am

Re: Ruletable format extensions proposal

Post by ColorfulGabrielsp138 » August 20th, 2021, 6:03 am

Maybe we can also have "state names" as in LifeHistory.

I have bookmarked this thread.

Code: Select all

x = 21, y = 21, rule = LifeColorful
11.E$10.3E$10.E.2E$13.E4$2.2B$.2B$2B$.2B15.2D$19.2D$18.2D$17.2D4$7.C$
7.2C.C$8.3C$9.C!
I have reduced the glider cost of quadratic growth to eight and probably to seven. Looking for conduits...

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » August 20th, 2021, 12:12 pm

ColorfulGabrielsp138 wrote:
August 20th, 2021, 6:03 am
Maybe we can also have "state names" as in LifeHistory.
This is already the case and has been for a decade:

Code: Select all

x = 11, y = 11, rule = WireWorld
3.CBA2C$2.C2.A2.C$.C7.C$C2.5C2.C$C2.C3.C2.C$2C.C3.C.2C$C2.B3.C2.C$C2.
2A3C2.C$.C7.C$2.C2.C2.C$3.5C!
[[ COLOR "copper wire" 0 255 0 ]]
LifeViewer's support for it is still relatively recent and it's not particularly widespread.

User avatar
bubblegum
Posts: 959
Joined: August 25th, 2019, 11:59 pm
Location: click here to do nothing

Re: Ruletable format extensions proposal

Post by bubblegum » August 20th, 2021, 3:58 pm

muzik wrote:
August 20th, 2021, 12:12 pm
This is already the case and has been for a decade:
Wait, I thought the blue was supposed to be the head and the white the tail.
Each day is a hidden opportunity, a frozen waterfall that's waiting to be realised, and one that I'll probably be ignoring
sonata wrote:
July 2nd, 2020, 8:33 pm
conwaylife signatures are amazing[citation needed]
anything

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » August 31st, 2021, 10:47 am

Another thing probably worth adding: inverse states.

For two-state rules, it's pretty simple: dead is the opposite of alive. However, multistate rules may require different specifications, such as (once again) PCA rules, in which each cell effectively represents four different cells.

This is again something LifeViewer natively supports for PCA, but for other rules like HPP having dedicated specifications for inversion operations (as well as making certain states invariable under inversion) this would be very useful.

erictom333
Posts: 171
Joined: January 9th, 2019, 2:44 am

Re: Ruletable format extensions proposal

Post by erictom333 » December 9th, 2021, 4:23 am

First, codifying some previous suggestions.
State Population: First (optionally), list the names of each medium. Then, for each state, list how much it contributes to each medium. Example for triangular rules:

Code: Select all

@POPULATION
0 0
1 1
2 1
3 2
LifeHistory:

Code: Select all

@POPULATION
names "Cells" "Marked" "Grey"
0 0 0 0
1 1 0 0
2 0 0 0
3 1 1 0
4 0 1 0
5 1 1 0
6 0 0 1
Rotational Equivalence:Format the following way: state; state flipped about rising diagonal; state rotated 90° clockwise; state flipped vertically; state rotated 180°; state flipped about falling diagonal; state rotated 90° anticlockwise; state flipped horizontally. Example for HPP:

Code: Select all

@ROTATE
#NE EN ES SE SW WS WN NW
0 0 0 0 0 0 0 0
1 8 2 1 4 2 8 4
2 4 4 8 8 1 1 2
3 12 6 9 12 3 9 6
4 2 8 4 1 8 2 1
5 10 10 5 5 10 10 5
6 6 12 12 9 9 3 3
7 14 14 13 13 11 11 7
8 1 1 2 2 4 4 8
9 9 3 3 6 6 12 12
10 5 5 10 10 5 5 10
11 13 7 11 14 7 13 14
12 3 9 6 3 12 6 9
13 11 11 7 7 14 14 13
14 7 13 14 11 13 7 11
15 15 15 15 15 15 15 15
Generation Count:@GENCOUNT followed by the generation count per step.
Inverse States: State followed by the inverse. Example for HPP:

Code: Select all

@INVERSE
0 15
1 14
2 13
3 12
4 11
5 10
6 9
7 8
8 7
9 6
10 5
11 4
12 3
13 2
14 1
15 0

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » December 11th, 2021, 9:26 pm

An extension of the state population contributions suggested in this thread: would it be a good idea at all for population counts to be able to contain multiple distinct orthogonal values rather than only having one?

Example case:

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_Moore
A!
[[ ZOOM 8 AUTOSTART STOP 22 ]]
For this pattern, generation 22 has a total of 1344 non-state-0 cells, as is reflected in its alive count in the T menu. As stated previously, though, this count contains both state 1 and state 2, and there's no way to see how many state 1 cells there are specifically (512), or state 2 cells (832).

It may be possible to solve this by having each state contribute to a different independent constant. In the rule above, states 1 and 2 act identically, and are effectively each's direct counterparts. Perhaps we could say state 1 is "positive", and state 2 "negative", in analogy to antimatter, with these respectively abbreviated p and n?

With this, we could say that state 1's contribution to the population is "1p" and state 2's is "1n", and for generation 22, the population count would therefore be "512p+832n".

There may end up being situations where a total population count is required though where this sort of formatting would be undesirable, so I'm not sure if this would be a good thing to implement, or if we should have some sort of secondary definition where all state counts can be transformed into a single number.

erictom333
Posts: 171
Joined: January 9th, 2019, 2:44 am

Re: Ruletable format extensions proposal

Post by erictom333 » December 12th, 2021, 4:52 am

muzik wrote:
December 11th, 2021, 9:26 pm
An extension of the state population contributions suggested in this thread: would it be a good idea at all for population counts to be able to contain multiple distinct orthogonal values rather than only having one?

Example case:

Code: Select all

x = 1, y = 1, rule = Fredkin_mod3_Moore
A!
[[ ZOOM 8 AUTOSTART STOP 22 ]]
For this pattern, generation 22 has a total of 1344 non-state-0 cells, as is reflected in its alive count in the T menu. As stated previously, though, this count contains both state 1 and state 2, and there's no way to see how many state 1 cells there are specifically (512), or state 2 cells (832).

It may be possible to solve this by having each state contribute to a different independent constant. In the rule above, states 1 and 2 act identically, and are effectively each's direct counterparts. Perhaps we could say state 1 is "positive", and state 2 "negative", in analogy to antimatter, with these respectively abbreviated p and n?

With this, we could say that state 1's contribution to the population is "1p" and state 2's is "1n", and for generation 22, the population count would therefore be "512p+832n".

There may end up being situations where a total population count is required though where this sort of formatting would be undesirable, so I'm not sure if this would be a good thing to implement, or if we should have some sort of secondary definition where all state counts can be transformed into a single number.
That 's what I've suggested, with the additional ability to name each medium.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » December 12th, 2021, 11:54 am

erictom333 wrote:
December 12th, 2021, 4:52 am
muzik wrote:
December 11th, 2021, 9:26 pm
An extension of the state population contributions suggested in this thread:
That 's what I've suggested, with the additional ability to name each medium.
Somehow I overlooked that and the fact I had already mentioned it in the start of the thread... :oops:

This should at least serve as an example of a case where distinct counts would be desirable.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » December 12th, 2021, 8:06 pm

I've had some other ideas for cell properties, which would currently apply more to LifeViewer than Golly, but I want to give it some time before saying too much for sure:

- Whether a cell is counted in Select All
- Whether a cell should be considered "alive" (such that the first generation without them produces "Life ended at...")
- Whether a cell is counted in AUTOFIT/HISTORYFIT
- Whether a cell is counted in Identify

Again, I want to see how LifeViewer's treatment of multistate rules ends up changing in the near future, as a lot of things are still rather new and there's been several bugs lately that needed fixing.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Ruletable format extensions proposal

Post by muzik » August 24th, 2022, 10:14 pm

Another minor addition to this proposal that just came to mind minutes ago that I want to put out there: LifeViewer has a concept of "cell height", which is used to indicate how tall a cell appears when layers are enabled. It might make sense for there to be an ability to assign individual states such a value.

Post Reply