Why so little interest in multistate rules?

[wirehead]

The OCA form's description just says "For discussion of other cellular automata," yet I've always noticed that the forum is mostly used for discussion of life-like cellular automata (i.e two-state, isotropic, etc), and occasionally Generations and HROT rules. Threads about other multi-state rules, such as Wireworld, tend to die out fairly quickly, and bumps (by me or others) are largely ignored. Where are all the Wireworld aficionados? Am I the only one?

[hotdogPi]

Most OCA threads I see are INT, not Life-like, mainly because there's a lot more unexplored space in INT.

[wirehead]

Most OCA threads I see are INT, not Life-like, mainly because there's a lot more unexplored space in INT.

Okay, maybe I misspoke when I said "non-Life-like" rules. I mean ones not in the Hensel/Generations/HROT rulestring rulespace. Things like Wireworld.

[silversmith]

I would say the main issue with multistate rules is accessibility. It is relatively easy to make an interesting INT rule, such as one with ships, oscillators, circuitry or bizzare patterns. One can start with an interesting rule, change a few transitions, and get another, never before seen rule with potentially unbounded exploration of new patterns.

With something like multi state ruletables, there are several times more changes and transitions to be considered. This makes the rulespace much larger, and to some degree, makes finding interesting rules much more difficult.

As such, many ruletable-style rules are made with the creator knowing exactly they want in the rule(eg. wire-world, sticky, NTAA), or they are an extension of an existing INT rule (eg. brew, symbiosis, state investigator). With many engineered ruletables, there is little potential for additional exploration, except for circuitry such as computation and construction, neither of which is particularly accessable to a casual user. On the other hand, ruletable rules based on INT rules often have as least as much potential for exploration as their parent rule, at the cost of losing something fundamental about the rule. For example, CGOL based rules with immortal cells lack the universal construction and destruction from CGOL.

There are multistate rules which are accessable and with high potential for exploration; generations rules. However these rules have a stark lack of support in terms of search programs. As far as I know, APGsearch and rlifesrc are the only commonly used programs which support generations rules, and for good reason. Many algorithms for two state rules simply don't work in multistate rules, and those that do are significantly slower.

One way to make multistate rules more popular would be to go out and make search programs to make finding rules easier(like EPE, LLS, etc.), or help with finding patterns(like gfind, JLS, etc). Or even better, take an existing open source search program, add in some functionality for searching multi-state rules, then submit a pull request to have your upgrade published for everyone.

On a final note I would like to point out that there are many interesting multistate rules. Sticky and Flow6 have many features and untapped potential for interesting patterns. Symbiosis and the state investigator rules are both well explored with unique constructions. WWEJ3 is a wire rule with many circuitry based patterns and some naturalistic exploration. There are many interesting rules to be found in older threads.

Edit:fixed spelling

[wirehead]

...With many engineered rule tables, there is little potential for additional exploration, except for circuitry such as computation and construction, neither of which is particularly accessable to a casual user. ...

I would disagree; if only something like this simulator by John Walker where the user could easily modify the rule function to get something slightly different -- and it should also be noted that that environment, while it is finite, allows arbitrary neighborhood emulation (i.e Margolus, etc.) in the same manner.

I would patch something like this (and Hashlife, and incremental table-to-tree compilation, and a lot of other algorithm speedups) into LifeViewer myself, but it's closed source, so no bueno. I also don't know how Golly/Python/Lua works past the documentation provided (and I don't know Lua), so I can't add it there either. Hopefully Chris Rowett will see this paragraph and have another think at leaving it closed source.

On a final note I would like to point out that there are many interesting multistate rules. Sticky and Flow6 have many features and untapped potential for interesting patterns. Symbiosis and the state investigator rules are both well explored with unique constructions. WWEJ3 is a wire rule with many circuitry based patterns and some naturalistic exploration. There are many interesting rules to be found in older threads.

I wouldn't really count Symbiosis and StateInvestigator because they are just an "extension" over an arbitrary Life-like or INT rule.

[Naszvadi]

Basically, every (blinking) B0 INT rule is a 3-state rule For example, no gliders could exist in a 2-state rule on the d-dimensional Euclydean grid - unless it is a blinking one.
Related umbrella topic for 2d grid is here: ../forums/viewtopic.php?f=11&t=2233

[confocaloid]

There is the multi-way distinction between
(a) just playing with a rule and looking what comes out "naturally" without any attempts at cleverness, vs.
(b) collecting sufficiently many reusable things and trying to use them to engineer some pattern, vs.
(c) trying to prove or disprove something about a rule,
...

The rulespace of INT rules is sufficiently large so that lots of strange nameless things can be found there - yet this rulespace is sufficiently simple and sufficiently explorable, so that it is possible to "just play" with it and look for interesting rules.

Other rulespaces, like Generations and Larger than Life, are even larger, but are still sufficiently "intuitive" and "explorable", and probably much more strange nameless things can be found there.

In comparison, the whole rulespace of multi-state rules definable as a ruletable/ruletree is hopelessly large and much less explorable, so that it seems like the option (a) above is not available anymore. There is the separate task of designing a multi-state ruletable - which requires some effort over "just playing with a rule", and is not necessary for simpler rulespaces.

As a consequence, multi-state rules might be more "interesting" for those who would anyway put in more effort by choosing (b) or (c) above - i.e. if someone wants a rule to engineer something big in it, or to prove something interesting about it, then the effort needed to design and specify the rule itself may be negligible.

I mean ones not in the Hensel/Generations/HROT rulestring rulespace. Things like Wireworld.

One thing that could make difference in terms of "popularity" is whether or not there is a well-known compact rulestring notation to specify a rule from the rulespace. The Hensel notation allows to encode an arbitrary INT rule in a compact way. I think the following is one of longest possible canonical rulestrings, and it still easily fits on a single line:

Code: Select all

B01c2ckn3ceikn4aceikny5ceikn6ckn7c8/S01c2ckn3ceikn4aceikny5ceikn6ckn7c8

I think this ability to specify an arbitrary rule from the rulespace on a single line in a compact readable way is one thing that makes it much easier to "play" with rules from the rulespace. You can add or remove elements of the rulestring and understand what is changed in the rule (although not everyone can remember what each of these letters stand for, without looking in the table), you can explore the resulting rule using a well-known tool, and you can easily share patterns you found.

In comparison, multistate rules could be less popular because of the combination of the lack of compactness and lack of easy ways to "just play with rules and share them". It is necessary to
(a) define the rule as a ruletable or ruletree,
(b) when sharing patterns you found, it is not enough to share the patterns themselves - the rule definition is shared separately,
(c) ruletables require filenames, and once you share a named rule, you cannot easily change your mind and rename it without potentially breaking patterns that depend on it. This does not happen with a rulestring, which avoids the issue by specifying the rule directly,
(d) when sharing the ruletable/ruletree, it might be a good idea to add comments with a higher-level description/explanation explaining how it works, but that is yet another separate task which also takes some effort.

(I do understand that the large size of ruletables/ruletrees is more or less the price for being able to specify lots of range-1 multi-state rules all in the same way. Trying to fit all that information in a single-line rulestring would probably result in very long rulestrings unlikely to be human-readable.)

I wouldn't really count Symbiosis and StateInvestigator because they are just an "extension" over an arbitrary Life-like or INT rule.

I think I'm going to disagree -- that might actually be an advantage, in terms of being able to "just play" with a rule! When you start with a "base" two-state rule given in Hensel notation, and incrementally add additional cellstates each of which works in some specific way, it seems relatively easy to understand what is going on at each step. Chaining cellstate extensions could be an easy way to "play" with multi-state rules and be able to reach a large number of them, without having to design the whole ruletable at once. (The same probably goes for other multi-state rules which can be reached by combining simpler rules and adding cellstates - e.g. alternating rules implemented as multi-state ruletables, or layered rules obtained by making two or more independent universes and modifying the resulting rule in some way, or perhaps making two independent universes each with two alternating Generations rules and making them interact in some way.)

[silversmith]

Related to this discussion is a series of posts by Cyclotrons

In it is a generalization of the INT generations rulespace which has a significantly shorter notation than ruletables/trees.

Something along these lines might be able to address certain issus with multistate accessibility and readibility.

[wirehead]

One thing that could make difference in terms of "popularity" is whether or not there is a well-known compact rulestring notation to specify a rule from the rulespace.

I have been thinking about things like making a rulestring for Wireworld-ish rules, and I haven't got vary far. The first step to be able to make a rulestring is to define a set of constraints so you can more easily notate a rule that fits a limited set of constraints, but I never got a well-written set of constriants as I realy needed to to be able to get any farther on a Wireworld rulestring spec. See here.

[GUYTU6J]

Given the numerous links in this thread, I would not say there is little interest in wire rules. And no, multistate rules is far more diverse than wire rules; there are various evolution-simulating loop rules both in Golly and on forums, for example.

...
I wouldn't really count Symbiosis and StateInvestigator because they are just an "extension" over an arbitrary Life-like or INT rule.

In the same logic, WireWorld is just an extension of /12/3, Bliptile is just an (easily rediscovered) extension of /1e2ak3inqy4ny5e/3 (converted from von Neumann outer-totalistic 1V), and BGRainbowR2 is just an extension of 23/3 (CGoL) over state 1-2 and 23/2/4 over state 3-6 (see more in this thread).

On the same topic, EvinZL made this user page earlier today. I think it is feasible to take a further step, i.e. to make the class of wire rules supported natively by Golly and LifeViewer. Hypothetically, appending "IW" (meaning "in wire") to the back of a rulestring inserts a wire state as new state 1, and indices of the original states shift higher by 1. So WireWorld is systematically /12/3IW and Bliptile is systematically /1e2ak3inqy4ny5e/3IW (or /1/3VIW). Even HROT may be adapted in this way. This notation is as easy to modify and "just play with" as existing rulestrings. Of course this scheme fails to cover many other rules in the first link of this post, but it is a start intuitive enough for me, who has zero experience in wire rules.

[silversmith]

...
I wouldn't really count Symbiosis and StateInvestigator because they are just an "extension" over an arbitrary Life-like or INT rule.

...
Hypothetically, appending "IW" (meaning "in wire") to the back of a rulestring inserts a wire state as new state 1, and indices of the original states shift higher by 1.

A equivalent option would be adding some support of extendedLife variations, such as Stateinvestigator, to the INT generations rulespace. In the case of a rule like Wireworld, this would become "/12/3StateInvestigator" or perhaps "/12/3SI". If implemented similar to the already supported stateinvestigator modifier, then the wire would be state 0, signal state 1, tail state 2, and insulator state 6.
- It would be only marginally more complex than the already popular StateInvestigator rules
- It would support a large rulespace of non-universal construction rules
- If I understand the above proposition, then the INT generations extended rules should be a super set, at the cost of having more states.

[Heav]

i somewhat disagree with the notion of "the rulespace is too big to do anything with". i don't think the density of interesting findable rules actually scales like that, as some are implying. or at least not in the case of multi-state rules.

it's not too hard to mess around for a bit and create interesting naturalistic 3 or 4 state rules. it's not too different from regular rulegolfing. if anything, you get more freedom to use transitions like B1 and B2 without horrible explosions. i haven't really tried with more states, but it's like any other rulespace. you modify the rule repeatedly, figuring out what makes it explosive/dead and what doesn't, until you get your desired properties.

otherwise, i'd wager it's mostly a problem of notation and a lack of widespread support, as with many things. ruletables are sort of annoying for actually doing things with, and there's no widely adopted generalized notation for such rules that i know of. there's also the other issues, such other supporting software like search programs not existing much.

[wirehead]

A equivalent option would be adding some support of extendedLife variations, such as Stateinvestigator, to the INT generations rulespace. In the case of a rule like Wireworld, this would become "/12/3StateInvestigator" or perhaps "/12/3SI". If implemented similar to the already supported stateinvestigator modifier, then the wire would be state 0, signal state 1, tail state 2, and insulator state 6.
- It would be only marginally more complex than the already popular StateInvestigator rules
- It would support a large rulespace of non-universal construction rules
- If I understand the above proposition, then the INT generations extended rules should be a super set, at the cost of having more states.

I think a worthwhile project would be to abandon all hope of ever coming up with a way of notating a specific class of rules (such as Hensel extensions or Wireworld variants) and focus on how to notate the transitions between two different rule types (probably more in a script form rather than a rulestring) -- such as the stuff in the "Hybrid CAs" thread. That way a casual user could say "I want a rule with behavior X and behavior Y," and find two rules (one with behavior X and the other with Y) and easily mash them together to get what they want. I believe this would be a whole stinkin' lot easier if could could "name" a state and not have to refer to it by number.

That way you could create something like WireworldRYGB by creating three "instances" of Wireworld (all set up as B12/S/3) and then add rules to states, such as "red.wire += B2(green.wire)" to make red wire turn on when it is next to 2 green heads. Or "wrap" a 2-state rule like "History(B3/S23)" or "StateInvestigator(B3/S23)". An extension to the syntax could be writing the "wrapping" function after a Hensel rule string, to make it backwards compatible.

And of course you can define aliases, like "Life" instead of "B3/S23".

[Yoel]

Check out my posts. I invented the concept of multistate symmetric rules, started threads on many such rules, and well as various other ones with more than 2 states. Many other forum members research various multistate rules. Threads related to building computers are mostly dedicated to them.

As for WireWorld, I very much like this classic rule, but I prefer my FireWorld in which I'd built a large computer. Its main advantages are free signals (and the entire substrate Generations rule somewhat confusingly called Fireworld with a small "w") and the stable dot, which largely eliminates the synchronization difficulty. I am slowly working on an insane project: to construct a new FireWorld computer about as complex as a VAX machine with a minimalistic instruction set and simplified memory architecture capable of running a Unix-like OS.

...With many engineered rule tables, there is little potential for additional exploration, except for circuitry such as computation and construction, neither of which is particularly accessable to a casual user. ...

I would disagree; if only something like this simulator by John Walker where the user could easily modify the rule function to get something slightly different -- and it should also be noted that that environment, while it is finite, allows arbitrary neighborhood emulation (i.e Margolus, etc.) in the same manner.

The Golly ruletables format is trivial and easy to comprehend. I write new rules by hand all the time and tweak them the way I like. If I need to explore a particular subset of rules, I write scripts that produce them, which is also very easy. I would guess most people on this forum have some coding experience.

Even HROT may be adapted in this way.

It may, but neither Golly nor any existing software piece I can think of would currently support it. It would not be too hard to write a custom Golly script for this purpose though.

(c) ruletables require filenames, and once you share a named rule, you cannot easily change your mind and rename it without potentially breaking patterns that depend on it. This does not happen with a rulestring, which avoids the issue by specifying the rule directly

Just make a fork of it and name it "Rule_X-2" or something. Or even attach your own notation to the names of new variants. Using them is then as simple as tweaking the rulestring.

[breaker's glider gun]

Though not cellular automata, this is a really fun multi-state rule maker:
https://neuralpatterns.io/
look at the "Conway's game of life" one to see how to make a 2-state (or 3- or 4-state or something) cellular automata.

[Entity Valkyrie 2]

On the other hand, ruletable rules based on INT rules often have as least as much potential for exploration as their parent rule, at the cost of losing something fundamental about the rule. For example, CGOL based rules with immortal cells lack the universal construction and destruction from CGOL.

When I created the rule StateInvestigator, I had no intent to make it universally constructable. In fact, universal construction is an area that I know almost nothing about.

[silversmith]

When I created the rule StateInvestigator, I had no intent to make it universally constructable.

That makes sense, as the features of StateInvestigator make it useful for different reasons. Conveniently, for the purpose of making a super set of rules like wire world, universal construction is irrelevant and immortal states are necessary.

We could try implementing a standard for the StateInvestigator extension of generations rules, which might generate additional interest for multistate OCA.

One question is whether to place the refractive states of generations rules before or after the StateInvestigator states. I personally would prefer if the generations states were placed in the lower index states, since usually there are fewer refractive states than StateInvestigator states.

[hotdogPi]

I personally would prefer if the generations states were placed in the lower index states, since usually there are fewer refractive states than StateInvestigator states.

This would mean that when switching from e.g. 11-state to 10-state, all the SI cells would be bumped by one state because they begin at a different number.

[AlbertArmStain]

When I created the rule StateInvestigator, I had no intent to make it universally constructable.

That makes sense, as the features of StateInvestigator make it useful for different reasons. Conveniently, for the purpose of making a super set of rules like wire world, universal construction is irrelevant and immortal states are necessary.

What about in Symbiosis?

[silversmith]

This would mean that when switching from e.g. 11-state to 10-state, all the SI cells would be bumped by one state because they begin at a different number.

Yes. Would that be a significant issue?

What about in Symbiosis?

Unfortunately, I don't understand the question.

[confocaloid]

That way a casual user could say "I want a rule with behavior X and behavior Y," and find two rules (one with behavior X and the other with Y) and easily mash them together to get what they want. I believe this would be a whole stinkin' lot easier if could could "name" a state and not have to refer to it by number.

I personally would prefer if the generations states were placed in the lower index states, since usually there are fewer refractive states than StateInvestigator states.

This would mean that when switching from e.g. 11-state to 10-state, all the SI cells would be bumped by one state because they begin at a different number.

Yes. Would that be a significant issue?

Losing a stable way of referring to cellstates would be a problem. It is convenient to have numbering fixed so that the number and function of each cellstate can be remembered. Also, if the number of generations is changed in an existing pattern, higher-numbered cellstates should continue to work the same way as before. I like the idea of "naming" cellstates, as another way of referring to them regardless of their numbers. E.g. ability to add a "history envelope" cellstate to an arbitrary multistate rule, or merging two multi-state rules into a single rule, while keeping backwards compatibility with already existing patterns.

[silversmith]

In that case it would make sense to place the state investigator rules before the additional generations states. Doing so shouldn't be very difficult to implement, although this is up to the makers of CA programs.

I think the combination of multiple rules would be significantly more difficult to implement. Assuming that rules would be combined automatically and interact with each other, the program would have to decide how they interact. For example in WWlife only state 2 counts toward the CGOL transitions, but a program could count any of states 2, 3 or 4 toward the transitions.

[Cyclotrons]

Related to this discussion is a series of posts by Cyclotrons

In it is a generalization of the INT generations rulespace which has a significantly shorter notation than ruletables/trees.

Something along these lines might be able to address certain issus with multistate accessibility and readibility.

I'd note that the related scripts I shared shouldn't be used, as I'm pretty sure they're bugged.

[wirehead]

In that case it would make sense to place the state investigator rules before the additional generations states. Doing so shouldn't be very difficult to implement, although this is up to the makers of CA programs.

I think the combination of multiple rules would be significantly more difficult to implement. Assuming that rules would be combined automatically and interact with each other, the program would have to decide how they interact. For example in WWlife only state 2 counts toward the CGOL transitions, but a program could count any of states 2, 3 or 4 toward the transitions.

I think a better solution would be to abandon all hope of using numbers for states, and instead refer to them by names. In the RLE it can use an abbreviated form of the name. For example if the names of the states are "background" and "on" then the usual "b" "o" work and there is basically no change. For Wireworld, one might use "background", "head", "tail", and "wire", shortened to "b", "h", "t", "w". I have an idea of an algorithm that (a) given an abbreviation and a list of possible names, will expand it or complain if it doesn't work, and (b) shorten a name without making it ambiguous. Do you think this would be a good idea?

[silversmith]

The suggestion doesn't address the ambiguity of choosing how two rules would interact, which seems to be the larger issue with arbitrarily "hybrid rules"