LifeSuper rule

For general discussion about Conway's Game of Life.
User avatar
Andrew
Moderator
Posts: 919
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: LifeSuper rule

Post by Andrew » October 3rd, 2020, 12:29 am

yujh wrote:
October 2nd, 2020, 10:40 pm
But i just want to ask if I can run golly 3.3 and 4.0 at the same time?
If you want to continue to use Python 2.x with Golly 3.x *and* use Python 3.x with Golly 4.x then you'll need to ensure that each application uses a separate GollyPrefs file (stored in the same location as the app). So if you haven't already done so, find the current GollyPrefs file (see bottom of Help > File Menu for where it is on your system) and move it into the same folder as the Golly app.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

Donald K Trump
Posts: 64
Joined: November 19th, 2020, 11:13 pm

Re: LifeSuper rule

Post by Donald K Trump » December 24th, 2020, 11:49 pm

All cells disappear if the pattern is a spark, even killer cells.

Code: Select all

x = 35, y = 40, rule = LifeSuper
10.K$9.K$3.A5.3K$4.A$2.3A$11.C$10.C$10.3C2$.E$2.E$3E$15.3M$15.M$9.3G4.
M$9.G$2.3I5.G$4.I$3.I19$32.3O$32.O$33.O!

User avatar
rowett
Moderator
Posts: 3777
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: LifeSuper rule

Post by rowett » December 25th, 2020, 12:39 am

Donald K Trump wrote:
December 24th, 2020, 11:49 pm
All cells disappear if the pattern is a spark, even killer cells.
Fixed, thanks!

User avatar
ColorfulGalaxy
Posts: 407
Joined: July 16th, 2020, 3:37 am
Location: Hacked by Trump {Bot}

Re: LifeSuper rule

Post by ColorfulGalaxy » December 26th, 2020, 4:40 am

rowett wrote:
December 25th, 2020, 12:39 am
Donald K Trump wrote:
December 24th, 2020, 11:49 pm
All cells disappear if the pattern is a spark, even killer cells.
Fixed, thanks!
Thanks for fixing!
Is there a known way to synthesize cycling cells?
Are the cycling cells turing-complete?

User avatar
dvgrn
Moderator
Posts: 10612
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » December 26th, 2020, 10:09 am

ColorfulGalaxy wrote:
December 26th, 2020, 4:40 am
Is there a known way to synthesize cycling cells?
Are the cycling cells turing-complete?
It's going to be a bit tricky to implement logic gates in the cycling cells, I think. The rules are just

State 18: switches to state 22 if a neighbor is state 22
State 20: switches to state 18 if a neighbor is state 18
State 22: switches to state 20 if a neighbor is state 20


The only decent way to process information involves the state-24 rule:

State 24: converts to state 18 if touched by an ON cell

But that's only going to get you one-time-use display circuits -- e.g., labels that start cycling only if a glider-or-something goes by. And similarly they can be stopped from cycling (by some of them being permanently erased) if any "real" (odd-numbered) ON come by and run over them.

I'm not sure that there's anything that the cycling states can do by themselves, that will allow them to store information in a retrievable way, like "state 18 = ON, state 20 = OFF, state 22 = wire tail state". However, I also wouldn't put it past some clever person to figure out that I'm wrong about this.

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

Re: LifeSuper rule

Post by muzik » April 29th, 2021, 5:51 am

While I would very much like to continue the development of LifeUltra and hopefully define it as a standard for all rules, there's a few problems I'm currently having setting it up. Help with these would be appreciated.

- The Reactor and Catalyst states appear to make cells touching them completely immortal. How can I define the transitions to make sure cells around them can die accordingly? The reactor and catalyst cells each count as a single alive cell, with the only difference being that catalysts alone cannot contribute to birth autonomously.

Code: Select all

x = 9, y = 9, rule = LifeUltraLegacy
6.A$6.A.A$6.2A6$pC!

Code: Select all

x = 9, y = 9, rule = LifeUltraLegacy
6.A$6.A.A$6.2A6$pD!

Code: Select all

x = 20, y = 9, rule = ExtendedLife_7
17.A$17.A.A$17.2A4$F$F$F10.F!

Code: Select all

x = 20, y = 9, rule = ExtendedLife_7
17.A$17.A.A$17.2A4$G$G$G10.G!
- The "on birthforcer" cell does not appear to work as expected. The first differences appear to crop up at generation 26:

Code: Select all

x = 1, y = 1, rule = LifeUltraLegacy
pF!
[[ STOP 26 ]]

Code: Select all

x = 1, y = 1, rule = StateInvestigator
H!
[[ STOP 26 ]]
How can this one be remedied?

User avatar
dvgrn
Moderator
Posts: 10612
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » April 29th, 2021, 8:17 am

Tangential question: is there really a use case for a generic {Rule}Ultra being backward-compatible with {Rule}Super? The Super extension is good for annotations, pattern collections, and glider syntheses -- but do you really need six colors of trailless ON cells, three colors of with-trail ON cells, and a dozen label states, AND all these birthforcers and deathforcers and so on? An "Ultra" rule sounds nice in theory, but in practice, anywhere above 20 states or so, it's really hard to define a set of distinct colors such that you can tell what states you're looking at by looking at the displayed color. Different states end up looking the same.

Maybe a more workable idea would be a generic "{Rule}Extended" option, adding the birthforcers and deathforcers and so on, but leaving out most of the annotation-specific states from {Rule}Super?
muzik wrote:
April 29th, 2021, 5:51 am
- The "on birthforcer" cell does not appear to work as expected. The first differences appear to crop up at generation 26:

Code: Select all

x = 1, y = 1, rule = LifeUltraLegacy
pF!
[[ STOP 26 ]]

Code: Select all

x = 1, y = 1, rule = StateInvestigator
H!
[[ STOP 26 ]]
How can this one be remedied?
I'll try helping with one of these items, but am going to stay away from LifeUltra for the most part -- with so many states, it seems like it will be too painfully confusing and prone to weird errors like this one. Just keep practicing and you'll eventually get good at troubleshooting this kind of problem.

Here you can reduce the issue to one particular neighborhood, by running the above pattern to T=25 rather than T=26:

Code: Select all

x = 3, y = 3, rule = LifeUltraLegacy
A2B$B2A$BApF!

Code: Select all

x = 3, y = 3, rule = StateInvestigator
A2B$B2A$BAH!
The middle cell turns off in StateInvestigator, but incorrectly stays on in LifeUltraLegacy. This presumably means that you have a rule relating to survival with three ON neighbors that is triggering in LifeUltraLegacy, when StateInvestigator says that it shouldn't trigger. So I would guess that StateInvestigator is falling through to the default "everything else turns OFF" rule, but LifeUltraLegacy isn't. Now you just have to find which rule line is matching this particular neighborhood in LifeUltraLegacy but not in StateInvestigator.

There are other cells in this sample pattern that behave differently in the two rules. It might be worth double-checking those as well.

-- It's also vaguely possible that you have a rule relating to death with four ON neighbors that is triggering in StateInvestigator, but that there's no similar rule in LifeUltraLegacy -- but that doesn't seem likely for several reasons. Usually these rules aren't implemented that way. I haven't tried to track this problem any further yet, so I don't know for sure.

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

Re: LifeSuper rule

Post by muzik » May 7th, 2021, 7:24 am

dvgrn wrote:
April 29th, 2021, 8:17 am
Tangential question: is there really a use case for a generic {Rule}Ultra being backward-compatible with {Rule}Super? The Super extension is good for annotations, pattern collections, and glider syntheses -- but do you really need six colors of trailless ON cells, three colors of with-trail ON cells, and a dozen label states, AND all these birthforcers and deathforcers and so on? An "Ultra" rule sounds nice in theory, but in practice, anywhere above 20 states or so, it's really hard to define a set of distinct colors such that you can tell what states you're looking at by looking at the displayed color. Different states end up looking the same.

Maybe a more workable idea would be a generic "{Rule}Extended" option, adding the birthforcers and deathforcers and so on, but leaving out most of the annotation-specific states from {Rule}Super?
A valid point - it's probably a better idea to work on a functional [R]Extended standard for the time being, and only after that consider tagging it on to the end of [R]Super. As for use cases involving all cell states, we could for example use it to annotate a theoretical period-19 gun or something which can only be constructed using special cells.
dvgrn wrote:
April 29th, 2021, 8:17 am
muzik wrote:
April 29th, 2021, 5:51 am
- The "on birthforcer" cell does not appear to work as expected. The first differences appear to crop up at generation 26:

Code: Select all

x = 1, y = 1, rule = LifeUltraLegacy
pF!
[[ STOP 26 ]]

Code: Select all

x = 1, y = 1, rule = StateInvestigator
H!
[[ STOP 26 ]]
How can this one be remedied?
I'll try helping with one of these items, but am going to stay away from LifeUltra for the most part -- with so many states, it seems like it will be too painfully confusing and prone to weird errors like this one. Just keep practicing and you'll eventually get good at troubleshooting this kind of problem.

Here you can reduce the issue to one particular neighborhood, by running the above pattern to T=25 rather than T=26:

Code: Select all

x = 3, y = 3, rule = LifeUltraLegacy
A2B$B2A$BApF!

Code: Select all

x = 3, y = 3, rule = StateInvestigator
A2B$B2A$BAH!
The middle cell turns off in StateInvestigator, but incorrectly stays on in LifeUltraLegacy. This presumably means that you have a rule relating to survival with three ON neighbors that is triggering in LifeUltraLegacy, when StateInvestigator says that it shouldn't trigger. So I would guess that StateInvestigator is falling through to the default "everything else turns OFF" rule, but LifeUltraLegacy isn't. Now you just have to find which rule line is matching this particular neighborhood in LifeUltraLegacy but not in StateInvestigator.

There are other cells in this sample pattern that behave differently in the two rules. It might be worth double-checking those as well.

-- It's also vaguely possible that you have a rule relating to death with four ON neighbors that is triggering in StateInvestigator, but that there's no similar rule in LifeUltraLegacy -- but that doesn't seem likely for several reasons. Usually these rules aren't implemented that way. I haven't tried to track this problem any further yet, so I don't know for sure.
It does seem that the problem here is that the central cell isn't counting as an alive cell for overcrowding. It still must be working correctly in some other case, as the resulting period of this faulty state differs from both the alive and dead birthforcers from StateInvestigator.

User avatar
dvgrn
Moderator
Posts: 10612
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » May 7th, 2021, 7:56 am

muzik wrote:
May 7th, 2021, 7:24 am
As for use cases involving all cell states, we could for example use it to annotate a theoretical period-19 gun or something which can only be constructed using special cells.
Sure, but that honestly needs only one label cell state. It definitely seems like a reasonable idea to tack [R]Extended onto the end of [R]History, keeping the first six states the same, and presumably using State 4 for annotations as usual. Keeping all of [R]Super's states as well... just seems like will make a system that's so unwieldy that no one will really want to use it in practice.

Something I meant to mention about the [R]Extended idea, though it's probably obvious already: as you're defining the behavior of [R]Extended states, it would be good to write out a careful description of each one that's independent of Conway's Life or the specific rule table you're working on. To make a generalized [R]Extended work we'll have to know exactly how each of the extended states will behave in any INT rule

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

Re: LifeSuper rule

Post by ColorfulGabrielsp138 » May 14th, 2021, 10:01 pm

Edgeshoot a single history cell using gliders

Code: Select all

x = 135, y = 44, rule = LifeSuper 
78.M$79.M$77.3M12$132.M$132.M.M$132.2M2$123.M$122.M$122.3M$91.M$92.M$ 90.3M6$108.A$109.A$107.3A9.A.A$119.2A$120.A$2.M$2.M.M$2.2M3.M$7.M.M$7. 2M$2M$.2M$M2$100.13R.14R!

Code: Select all

x = 61, y = 38, rule = LifeSuper
58.M.M$58.2M$59.M$.M$2.M$3M2$53.Q.Q$53.2Q$54.Q$10.Q$11.Q$9.3Q2$48.O.O
$48.2O$49.O$19.O$20.O$18.3O3$24.A$25.A$23.3A2$36.A.A$36.2A$37.A7$10.20T
.17T$10.2I34.2I$10.2I34.2I!

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: 5614
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: LifeSuper rule

Post by muzik » August 31st, 2022, 7:28 am

State 6 cells seem to kill a lot more than just alive cells - they also kill some even states.

Code: Select all

x = 15, y = 15, rule = B36/S23Super
4.3B.3D.3F$.F2.BFB.DFD.3F$4.3B.3D.3F2$3H.3J.3L.3N$HFH.JFJ.LFL.NFN$3H.
3J.3L.3N2$3P.3R.3T.3V$PFP.RFR.TFT.VFV$3P.3R.3T.3V2$6.3X$6.XFX$6.3X!
To my knowledge, only state 14 should die:

Code: Select all

x = 15, y = 15, rule = B36/S23Super
4.3B.3D.3F$4.B.B.D.D.F.F$4.3B.3D.3F2$3H.3J.3L.3N$H.H.J.J.L.L.N.N$3H.
3J.3L.3N2$3P.3R.3T.3V$P.P.R.R.T.T.V.V$3P.3R.3T.3V2$6.3X$6.X.X$6.3X!
Affects both Golly's implementation of Super and LifeViewer's.

Bottom ring is the stealthy state, which is hard to see in LifeViewer.

User avatar
rowett
Moderator
Posts: 3777
Joined: January 31st, 2013, 2:34 am
Location: UK
Contact:

Re: LifeSuper rule

Post by rowett » August 31st, 2022, 10:58 am

muzik wrote:
August 31st, 2022, 7:28 am
State 6 cells seem to kill a lot more than just alive cells - they also kill some even states.
For [R]Super they should. See the RuleTable for more details.

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

Re: LifeSuper rule

Post by muzik » August 31st, 2022, 11:07 am

rowett wrote:
August 31st, 2022, 10:58 am
For [R]Super it should. See the RuleTable for more details.
This behaviour still seems a tad off to me, since my understanding of boundary cells is that they should interact with living cells, and only living cells. The following inconsistency, for example, demonstrates that the killer cells can kill one type of stationary highlighted region, but not the other:

Code: Select all

x = 31, y = 11, rule = B36/S23Super
8.M17.A$8.M.M15.A.A$8.2M16.2A4$5D3.5D5.5H3.5H$5D3.5D5.5H3.5H$5D3.2DF
2D5.5H3.2HF2H$5D3.5D5.5H3.5H$5D3.5D5.5H3.5H!
I personally don't see the utility of having killer cells delete annotation states - but state 6 is very much the black sheep of the History/Super family, so I'd prefer to wait for Dave to comment on this behaviour to confirm whether or not this was an oversight with the original ruletable which eventually got carried over, intended behaviour, or something else entirely.

User avatar
dvgrn
Moderator
Posts: 10612
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » August 31st, 2022, 2:49 pm

muzik wrote:
August 31st, 2022, 11:07 am
I personally don't see the utility of having killer cells delete annotation states - but state 6 is very much the black sheep of the History/Super family, so I'd prefer to wait for Dave to comment on this behaviour to confirm whether or not this was an oversight with the original ruletable which eventually got carried over, intended behaviour, or something else entirely.
I'd say that the current behavior of gray cells next to other cell types is not something I thought a whole lot about, in the original implementation. It's not exactly an oversight, because I don't see any particular reason why killer cells shouldn't delete annotation states, either.

The only intended functionality of state 6 is to serve as a boundary. It might not have been a great idea to put state 6 into LifeHistory at all, but now that it's there, I'm mostly just worried that the Golly implementation behaves the same as the LifeViewer implementation (e.g., when you run a random multistate soup for N ticks, it should do the same thing in any implementation.)

I agree that it would be slightly more logically consistent to have killer cells not have any effect on OFF states -- but that doesn't imply that it's worth changing the current implementations at this point.

HotWheels9232
Posts: 559
Joined: May 25th, 2022, 9:10 pm
Location: Help! I got dragged away into the middle of nowhere by a LWSS which suddenly launched from a soup

Re: LifeSuper rule

Post by HotWheels9232 » September 5th, 2022, 12:43 am

When will LifeUltra work in LifeViewer? I was alos planning a rule called 'LifeHyper', which was similar.
My rules:
B34q/S23-k(ObliquePufferLife) and
B2n3-n4c5c/S234cz5cPM me to get some help on making rules!

Code: Select all

x = 8, y = 5, rule = B3-k/S23
2o3b2o$obo2bobo$2bo2bo$bo$b2o!

User avatar
dvgrn
Moderator
Posts: 10612
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: LifeSuper rule

Post by dvgrn » September 5th, 2022, 9:21 am

HotWheels9232 wrote:
September 5th, 2022, 12:43 am
When will LifeUltra work in LifeViewer?
Nobody has come up with a consensus LifeUltra rule in rule-table form. Until LifeUltra actually exists and is in working order (unlike LifeUltraLegacy, for example) it seems a bit premature to talk about whether LifeViewer might support it.

One big key will be systematically defining the transitions for all of the states in a way that can be applied across all INT rules, or rather the subset of INT rules that {Rule}History and {Rule}Super support -- strobing B0-no-S8 rules presumably won't be supported for the Ultra extension.

Anyway, once there's an actual working rule table out there, or (much better) a script that can generate an Ultra rule table for any supported INT rule, then it might make sense to ask whether native support for Ultra rules might happen -- not that anyone is promising anything even then!
HotWheels9232 wrote:
September 5th, 2022, 12:43 am
I was alos planning a rule called 'LifeHyper', which was similar.
The thing that makes LifeUltra less likely to ever happen, is that it's so difficult for a consensus to develop about how all the states should behave -- particularly how the different states should interact with each other. It's something of a nightmare to get all those details cleanly sorted out.

I think my suggestion would be to not attempt to have LifeUltra be backward-compatible to LifeSuper, the way LifeSuper is backward-compatible to LifeHistory (and the way LifeUltraLegacy was attempting to do things). There are just too many special states that people want to have supported in LifeUltra. If all the silly label states in LifeSuper are included also, the rule just gets too complicated for any possible algorithm to evolve efficiently. Not only would it be slow to run, but color pickers would have a huge and unwieldy number of colors to choose from, and it would be even harder to tell states apart from each other visually than it is in LifeSuper.

HotWheels9232
Posts: 559
Joined: May 25th, 2022, 9:10 pm
Location: Help! I got dragged away into the middle of nowhere by a LWSS which suddenly launched from a soup

Re: LifeSuper rule

Post by HotWheels9232 » September 5th, 2022, 12:20 pm

dvgrn wrote:
September 5th, 2022, 9:21 am
HotWheels9232 wrote:
September 5th, 2022, 12:43 am
When will LifeUltra work in LifeViewer?
Nobody has come up with a consensus LifeUltra rule in rule-table form. Until LifeUltra actually exists and is in working order (unlike LifeUltraLegacy, for example) it seems a bit premature to talk about whether LifeViewer might support it.

One big key will be systematically defining the transitions for all of the states in a way that can be applied across all INT rules, or rather the subset of INT rules that {Rule}History and {Rule}Super support -- strobing B0-no-S8 rules presumably won't be supported for the Ultra extension.

Anyway, once there's an actual working rule table out there, or (much better) a script that can generate an Ultra rule table for any supported INT rule, then it might make sense to ask whether native support for Ultra rules might happen -- not that anyone is promising anything even then!
HotWheels9232 wrote:
September 5th, 2022, 12:43 am
I was alos planning a rule called 'LifeHyper', which was similar.
The thing that makes LifeUltra less likely to ever happen, is that it's so difficult for a consensus to develop about how all the states should behave -- particularly how the different states should interact with each other. It's something of a nightmare to get all those details cleanly sorted out.

I think my suggestion would be to not attempt to have LifeUltra be backward-compatible to LifeSuper, the way LifeSuper is backward-compatible to LifeHistory (and the way LifeUltraLegacy was attempting to do things). There are just too many special states that people want to have supported in LifeUltra. If all the silly label states in LifeSuper are included also, the rule just gets too complicated for any possible algorithm to evolve efficiently. Not only would it be slow to run, but color pickers would have a huge and unwieldy number of colors to choose from, and it would be even harder to tell states apart from each other visually than it is in LifeSuper.
Yeah, I ran LifeUltraLegacy and ut is extremely slow. My 537the 63g7$674hc
Vhsh s)#)#
My rules:
B34q/S23-k(ObliquePufferLife) and
B2n3-n4c5c/S234cz5cPM me to get some help on making rules!

Code: Select all

x = 8, y = 5, rule = B3-k/S23
2o3b2o$obo2bobo$2bo2bo$bo$b2o!

Post Reply