Ruletable format extensions proposal

[muzik]

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]

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

I have bookmarked this thread.

[muzik]

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.

[bubblegum]

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.

[muzik]

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]

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

[muzik]

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]

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.

[muzik]

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...

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

[muzik]

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.

[muzik]

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.

[tommyaweosme]

i came up with some really cool features that maybe you could add to ruletable? tysm
https://docs.google.com/document/d/1fid ... sp=sharing

[confocaloid]

i came up with some really cool features that maybe you could add to ruletable? tysm
https://docs.google.com/document/d/1fid ... sp=sharing

The big problem with so-called "local variables" is that they are non-local.

When a ruletable contains a line like this:

Code: Select all

3, a, a, a, 0, 0, 0, 0, 0, 4

I can immediately understand that all three occurrences of "a" refer to the same variable. That means the line can be expanded to N variable-free lines, where N is the number of possible values of the variable a.

If you add those "local variables" to the mix, the above nice property will fail. It will become impossible to look at a single-line rule and see what it means. You will have to scroll back to the section where "a" is defined, to see whether it's "var" or "lvar". That is a wonderful example of a non-local effect. And non-local effects are a bad thing.

[tommyaweosme]

The big problem with so-called "local variables" is that they are non-local.

When a ruletable contains a line like this:

Code: Select all

3, a, a, a, 0, 0, 0, 0, 0, 4

I can immediately understand that all three occurrences of "a" refer to the same variable. That means the line can be expanded to N variable-free lines, where N is the number of possible values of the variable a.

If you add those "local variables" to the mix, the above nice property will fail. It will become impossible to look at a single-line rule and see what it means. You will have to scroll back to the section where "a" is defined, to see whether it's "var" or "lvar". That is a wonderful example of a non-local effect. And non-local effects are a bad thing.

i saw the lvar thing on another thread somewhere
but what about the rest of the things i suggested?

[confocaloid]

but what about the rest of the things i suggested?

Those might be interesting ideas (not necessarily with that specific syntax, though).
However, look at old forum posts/threads like viewtopic.php?f=7&t=5385 (there were also other discussions of ruletables, scattered in different places over the forum).
In practice, most of suggestions are unlikely to be implemented, because that requires efforts to think about it, design the feature, implement it, test it, document it and maintain it.

[b-engine]

The big problem with so-called "local variables" is that they are non-local.

Well, you can choose if you want writablity or readability.
If you want writablity, then you just define a local variable then use it. If you want readability, you can define much more variables.
Or another workaround: you can define a local variable a then define a,a1,a2,a3,a4,a5,a6,a7,a8,0 where
a# is like a but they don't share values.

[confocaloid]

[...] Well, you can choose if you want writablity or readability. [...]

Look at it from the viewpoint of someone who has to deal with lots of ruletables that are all written by other people.

If that "lvar" thingamajig gets implemented for some reason, then some of those other people will sometimes choose to use it. In their ruletables,

Code: Select all

3, a, a, a, 0, 0, 0, 0, 0, 4

will expand to n^3 variable-free lines (where n is the number of possible values).

Other times, other people will choose to ignore the new feature, and use plain "var". In their ruletables, the exact same line

Code: Select all

3, a, a, a, 0, 0, 0, 0, 0, 4

will expand to n variable-free lines (where n is the number of possible values).

From the viewpoint of someone who got a lot of different ruletables from different sources, that is a problem. Sometimes it expands to N lines while other times it expands to N^3 lines. When one reads many ruletables, which use different syntaxes in a random-ish order, such inconsistencies have a cumulative effect, which is very annoying and irritating. And the reader does not have a free choice between two syntaxes.

[b-engine]

From the viewpoint of someone who got a lot of different ruletables from different sources, that is a problem. Sometimes it expands to N lines while other times it expands to N^3 lines. When one reads many ruletables, which use different syntaxes in a random-ish order, such inconsistencies have a cumulative effect, which is very annoying and irritating. And the reader does not have a free choice between two syntaxes.

The local variable was never meant for readability, but to shorten ruletables (thus more writablity). If a ruletable needs not to be bulky then the writer needs to sacrifice readability.

[confocaloid]

The local variable was never meant for readability, but to shorten ruletables (thus more writablity). If a ruletable needs not to be bulky then the writer needs to sacrifice readability.

Well, to be clear, my take on this question is that it would be a bad idea to allow the writer to sacrifice readability.
Therefore it would be a bad idea to implement "lvar", because that feature would allow the writer to sacrifice readability in a specific new way.
Readability is important. Especially considering that most ruletables are undocumented.

[b-engine]

Well, to be clear, my take on this question is that it would be a bad idea to allow the writer to sacrifice readability.
Therefore it would be a bad idea to implement "lvar", because that feature would allow the writer to sacrifice readability in a specific new way.
Readability is important. Especially considering that most ruletables are undocumented.

What's important with readability? I see most users don't read the ruletable itself. Plus, the "lvar" is for shortening ruletables, and may be useful when the entire ruletable uses only lvar. If you don't want local variables you still can use normal variables.

[confocaloid]

You already wrote before that the aim is "to shorten ruletables". I already replied to that, saying that that would come at the expense of readability.

If you don't want local variables you still can use normal variables.

Also already answered before. As a user, I will not have the choice to either use "lvar" or use "var". Instead, I will receive a ruletable written by someone else, and I will likely have to read it to understand what it does.

Further, if you are going to create a sufficiently complicated ruletable, then you will have to read it yourself many times while you're writing it and debugging it.
Several months later, you will want to add something to the ruletable, and you will have to read it again to remember what it does and what should be changed.

https://old.reddit.com/r/ExperiencedDev ... nciseness/

[b-engine]

Maybe a workaround: If a ruletable was never meant to been read, then lvar can been used. Otherwise var must be used.

[confocaloid]

Maybe a workaround: If a ruletable was never meant to been read, then lvar can been used. Otherwise var must be used.

(1) That would basically be an explicit permission to create ruletables that were "never meant to been read" sacrificing readability. I already answered to that.
(2) I reported this entire discussion as offtopic (not about the website) and apparently nonproductive.

[dvgrn]

... I reported this entire discussion as offtopic (not about the website) and apparently nonproductive.

It was probably getting a bit off-topic, though LifeViewer's support for rule tables means that it's maybe not entirely irrelevant after all.

The discussion doesn't seem non-productive at all, though -- there are some interesting subtopics here. I've moved the discussion here to a previous thread with related ideas.

Re: the bound vs. unbound variables question: @tommyaweosme, you might be interested in trying out Nutshell. Here's a quote from the documentation:

Variables
All variable names are unbound, always, because needing to define eight separate "any state" vars is ridiculous.

That's not to say, however, that there is no concept of binding variables in Nutshell! It's just that you don't bind by name. Nutshell's actual idea of binding is explained later on.

Nutshell is a fairly thoroughly thought-out and implemented project, and EvinZL made a Nutshell loader for Golly four years ago. It would be great if more people would try that out and see if it works and is helpful.

My sense is that some version of Nutshell might be the most likely ruletable format extension to be supported in the relatively near future. It's a much less dangerous option in terms of the amount of coding, review, and testing that would have to be done to implement it -- because Nutshell format transpiles directly to Golly's existing ruletable format, and we have a lot of years of user testing already done on that.

By contrast, whenever we make any changes to the ruletable interpretation code, there's a really huge amount of review and testing that really ought to be done -- to try and make sure we haven't broken anything while we're adding new features.

Five years ago it definitely seemed like Nutshell was the direction that things were going. There's even a ".ruel" file (Nutshell's version of a ".rule" file) buried in Golly's pattern collection, in Patterns/Other-Rules/NoTimeAtAll-demo.zip. It doesn't seem like it has gotten mentioned much in the last couple of years, unfortunately -- most recent mentions either here or on Discord seem to be various kinds of unfortunate false positives.

[confocaloid]

forwarded