Page 1 of 1

RuleLoader's B0 handling quirks

Posted: March 6th, 2018, 6:05 pm
by dani

Code: Select all

@RULE LifeRLB0
@TABLE
n_states:3
neighborhood:Moore
symmetries:permute

var i={0,2}
var j=i
var k=i
var l=i
var m=i
var n=i
var o=i
var p=i
var a={0,1,2}
var b=a
var c=a
var d=a
var e=a
var f=a
var g=a
var h=a

0,1,1,1,i,j,k,l,m,1
1,1,1,i,j,k,l,m,n,1
1,1,1,1,i,j,k,l,m,1
0,0,0,0,0,0,0,0,0,2
1,a,b,c,d,e,f,g,h,0
2,a,b,c,d,e,f,g,h,0
Above is an example of a phenomenon that only affects RuleLoader as far as I can tell, and it leads to interesting results.

Try running the R-Pentomino at step 8^0. By the time it has settled down after its 437-generation lifespan, it has 6,448,907,850,777,163,651,761,960,265,094,196,856,919,523,022,901,874,049,413,582,873,860,765,412,069,395,257,256,070,018,159,877,781,917,412,048,257,533,309,068,388,031,732,202,945,575,428,955,817,663,624,925,850,287,924,760,212,933,849,426,346,008,132,764,685,751,392,199,964,463,414,424,787,550,567,425,491,046,706,709,753,694,718,256,702,321,466,965 cells. Of those, an immense portion are state two or state zero cells, but there are some CGoL objects formed in this mess. Specifically, a glider, a beehive, 4 blinkers, and 4 blocks.

Now try running it at step 8^1. It's not only quicker, stabilizing sometime before generation 80, it also has much fewer cells, only 69 . Its census is a block, blinker, beehive, and boat. The other 51 cells (73.9%) are state two cells.

Instead of running it immediately, press space (or whatever goes to the next frame) once, as well as twice, before running again. You will observe different results.

Another quirk is that if you put down the R-pentomino, draw a cell, run for one step and undo, the ripples will occur differently, and the results above are only achievable if you start a new pattern every time.

Position matters, too. Plopping down the R-pentomino at (-30,-10) will be different than at the origin, as well as (-2,-2).

Despite all of this, it's still a relatively standard rule. It even has a cute-yet-also-world-breaking 5c/13:

Code: Select all

x = 6, y = 3, rule = LifeRLB0
.3A$3A.2A$.3A!
It can be turned into a blinker puffer:

Code: Select all

x = 7, y = 15, rule = LifeRLB0
.3A$3A.2A$.3A6$4.A$3.A.A$2.A3.A$.2A3.A$2.A3.A$3.A.A$4.A!
It works in both 8^0 and 8^1.

I don't fully understand these oddities quite yet, but hopefully you will get some entertainment out of it.

Re: RuleLoader's B0 handling quirks

Posted: March 6th, 2018, 6:19 pm
by 77topaz
That's really weird behaviour. Doesn't Golly usually automatically invert B0 patterns every generation so that the background always appears dead? And shouldn't, without that, the population in the first generation be infinite, as the entire universe outside of the area of interest is alive? Why is it growing finitely?

Re: RuleLoader's B0 handling quirks

Posted: March 6th, 2018, 7:30 pm
by 77topaz
A bit of explanation about this behaviour, lifted from the Discord:
BlinkerSpawn wrote:quadtrees grow exponentially the higher you go
they're the basis of hashing
77topaz wrote:So, at each generation, it "realises" that an exponentially-larger section of the universe "should" be alive, and so transitions the states for that section?
SuperSupermario24 wrote:basically yeah
the ruleloader algorithm essentially only considers a finite section of the universe at any given time, based on which cells are alive
normally this works fine because in any other rule (LtL uses a completely different algorithm) things can only move at c
but with B0 this becomes apparent because it's not the case anymore
since the size of said section grows exponentially as the B0 repeatedly causes it to fill completely (the width and height each increasing by a factor of 2 each time), so does the pattern
that's basically the ELI5 version coming from someone who knows absolutely nothing about how the algorithm actually works internally

Re: RuleLoader's B0 handling quirks

Posted: March 8th, 2018, 12:38 am
by SuperSupermario24
That's interesting how there's no exponential growth when running at a step size that's a multiple of 2 (any multiple of 2, even something like 6^n, will work). I would expect it to happen regardless, but I guess multiple generations running within a single step are treated differently than generations being run individually.

Another interesting thing is that if you use a script to run n generations using g.run(n), there will be no exponential growth at all if n is an even number, but exponential growth will happen n times if it's an odd number. For example, if you start with a single state 1 cell at the origin, g.run(12) will result in a single state 2 cell at the origin, but g.run(11) results in a population of 53,665,251. (I would expect it to happen once if it's an odd number, given its behavior with even numbers. I guess it's not as simple as "generations within a step vs. generations individually", then.)

On the other hand, repeating g.run(1) n times will always result in exponential growth, even if it's an odd number, so it doesn't have anything to do specifically with Golly updating the display or anything (since scripts won't update the display until the end by default).

Re: RuleLoader's B0 handling quirks

Posted: March 17th, 2018, 4:17 pm
by muzik
Seems exceeding a population of 2^1024 produces nan.

Re: RuleLoader's B0 handling quirks

Posted: March 18th, 2018, 6:40 pm
by SuperSupermario24
muzik wrote:Seems exceeding a population of 2^1024 produces nan.
I think that limitation might only apply to the iOS version. I seem to remember running into that at one point on iOS Golly, but on desktop it can easily go well beyond that: after a few thousand generations, the population count is displaying 8.21442e+2282.

Although now I wonder what the maximum population that can be displayed on the desktop version is.

Re: RuleLoader's B0 handling quirks

Posted: December 10th, 2021, 5:22 pm
by muzik
LifeViewer appears to just have this grow quadratically, likely due to not using HashLife:

Code: Select all

x = 2, y = 2, rule = LifeRLB0
2A$2A!
[[ AUTOFIT GRAPH STEP 2 NOTHROTTLE ]]

Re: RuleLoader's B0 handling quirks

Posted: December 11th, 2021, 12:41 am
by FWKnightship

Code: Select all

@RULE LifeRLB0_emulated
@TABLE
n_states:5
neighborhood:Moore
symmetries:permute

var i={0,2,4}
var j=i
var k=i
var l=i
var m=i
var n=i
var o=i
var p=i
var a={0,1,2,3,4}
var b=a
var c=a
var d=a
var e=a
var f=a
var g=a
var h=a

0,1,1,1,i,j,k,l,m,3
1,1,1,i,j,k,l,m,n,3
1,1,1,1,i,j,k,l,m,3
0,1,a,b,c,d,e,f,g,2
1,a,b,c,d,e,f,g,h,2
2,2,2,2,2,2,2,2,2,4
2,3,3,3,i,j,k,l,m,1
3,3,3,i,j,k,l,m,n,1
3,3,3,3,i,j,k,l,m,1
0,4,a,b,c,d,e,f,g,2
4,a,b,c,d,e,f,g,h,2
3,a,b,c,d,e,f,g,h,0
2,a,b,c,d,e,f,g,h,0

Code: Select all

x = 7, y = 36, rule = LifeRLB0_emulated
.3A$3A.2A$.3A19$.3A$3A.2A$.3A6$4.A$3.A.A$2.A3.A$.2A3.A$2.A3.A$3.A.A$
4.A!

Re: RuleLoader's B0 handling quirks

Posted: December 11th, 2021, 11:42 am
by muzik
muzik wrote: December 10th, 2021, 5:22 pm LifeViewer appears to just have this grow quadratically, likely due to not using HashLife:

Code: Select all

x = 2, y = 2, rule = LifeRLB0
2A$2A!
[[ AUTOFIT GRAPH STEP 2 NOTHROTTLE ]]
For example, here's a pattern with an identically growing bounding box: (EDIT: I miscalculated, this actually grows much faster)

Code: Select all

x = 2, y = 2, rule = R31,C0,S0-3968,B1-3968
2o$2o!
[[ AUTOFIT GRAPH STEP 2 NOTHROTTLE THEME Mono ]]

Re: RuleLoader's B0 handling quirks

Posted: March 8th, 2023, 2:27 pm
by muzik
I've been trying out RuleLoader B0 handling again lately. In Golly, this kind of stuff does not interact well with bounded grids, which is weird since bounded grids would probably be the best environment for running true B0 rules. Playback just gets slower and slower and slower. I presume that as the range grows exponentially, the amount of loops across the bounded grid must also grow exponentially, meaning that the processing time gets ridiculous before you even reach the double digits in generations.

If we run the same test pattern I used in Golly in LifeViewer instead, well, you can see the results for yourself:

Code: Select all

x = 75, y = 75, rule = AntiLife-RuleLoader:T75
75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o
$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$
75o$34ob3o3b34o$34o3b2ob35o$35ob39o$75o$75o$75o$75o$75o$75o$75o$75o$75o
$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$
75o$75o$75o$75o$75o$75o$75o$75o$75o$75o!
#C [[ MAXGRIDSIZE 9 ]]
@RULE AntiLife-RuleLoader
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,0,1
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,1,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,0,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
0,1,1,1,1,1,1,1,1,1
1,0,0,0,1,1,1,1,1,0
I really don't want to see B0 ruletables removed for either program. They're a lot of fun to mess with. I would like to see bounded grids work correctly with them in Golly though, since these rules are a very useful device for demonstrating how B0 emulation works, among other things.

Re: RuleLoader's B0 handling quirks

Posted: March 13th, 2023, 11:01 am
by rowett
muzik wrote: March 8th, 2023, 2:27 pm If we run the same test pattern I used in Golly in LifeViewer instead, well, you can see the results for yourself:

Code: Select all

x = 75, y = 75, rule = AntiLife-RuleLoader:T75
75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o
$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$
75o$34ob3o3b34o$34o3b2ob35o$35ob39o$75o$75o$75o$75o$75o$75o$75o$75o$75o
$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$75o$
75o$75o$75o$75o$75o$75o$75o$75o$75o$75o!
#C [[ MAXGRIDSIZE 9 ]]
@RULE AntiLife-RuleLoader
@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0,0,0,0,0,0,0,0,0,1
0,0,0,0,0,0,0,0,1,1
0,0,0,0,0,0,0,1,1,1
0,0,0,0,0,0,1,1,1,1
0,0,0,0,0,1,1,1,1,1
0,0,1,1,1,1,1,1,1,1
0,1,1,1,1,1,1,1,1,1
1,0,0,0,1,1,1,1,1,0
LifeViewer now has improved support for RuleLoader B0 rules. They require a finite grid (i.e. a Bounded Grid with no infinite dimensions).

Re: RuleLoader's B0 handling quirks

Posted: January 4th, 2024, 9:12 am
by Antonin Duda
The behaviour of B0 jumpscares me a lot.

Re: RuleLoader's B0 handling quirks

Posted: July 18th, 2024, 4:38 am
by Haycat2009
Can we have infinite B0 rules?

Re: RuleLoader's B0 handling quirks

Posted: July 18th, 2024, 4:45 am
by pifricted
Haycat2009 wrote: July 18th, 2024, 4:38 am Can we have infinite B0 rules?
Yes(But Lifeviewer only)

Code: Select all

x = 15, y = 17, rule = test_b0:T64,64
11b4o$10b2o$9bo$8bo$7bo$6bo$5bo$4bo$4bo$3bo$3bo$2bo$2bo$bo$bo$o$o!

@RULE test_b0

@TABLE
n_states:2
neighborhood:Moore
symmetries:permute
0, 0,0,0,0,0,0,0,0, 1
1, 1,1,1,1,1,1,1,1, 0

Re: RuleLoader's B0 handling quirks

Posted: July 18th, 2024, 5:41 am
by unname4798
Haycat2009 wrote: July 18th, 2024, 4:38 am Can we have infinite B0 rules?
B0 rules require a bounded grid.

Re: RuleLoader's B0 handling quirks

Posted: July 18th, 2024, 8:02 pm
by Haycat2009
unname4798 wrote: July 18th, 2024, 5:41 am
Haycat2009 wrote: July 18th, 2024, 4:38 am Can we have infinite B0 rules?
B0 rules require a bounded grid.
Why is this so?

Re: RuleLoader's B0 handling quirks

Posted: July 19th, 2024, 1:42 am
by unname4798
Haycat2009 wrote: July 18th, 2024, 8:02 pm
unname4798 wrote: July 18th, 2024, 5:41 am
Haycat2009 wrote: July 18th, 2024, 4:38 am Can we have infinite B0 rules?
B0 rules require a bounded grid.
Why is this so?
Because LifeViewer can't emulate B0 ruletables.

Re: RuleLoader's B0 handling quirks

Posted: July 19th, 2024, 2:10 am
by b-engine
Haycat2009 wrote: July 18th, 2024, 8:02 pm Why is this so?
There's no known algorithm that converts normal strobing multistate rules into non-strobing rules with more states. Neither Golly nor LifeViewer directly supports strobing rules. However, strobing rules can been simulated by splitting the grid into "chunks" and not simulating any chunks with only a color and no neighboring chunks of different pattern inside.

Re: RuleLoader's B0 handling quirks

Posted: July 19th, 2024, 5:32 am
by confocaloid
b-engine wrote: July 19th, 2024, 2:10 am [...] There's no known algorithm that converts normal strobing multistate rules into non-strobing rules with more states. [...]
I think RuleLoader ruletables where cellstate 0 is quiescent can be used to emulate n-state cellular automata [with the same neighbourhood and the same symmetries] where neither of n cellstates is quiescent, for n <= 16. (OEIS A002061) Three cellstates are needed to emulate a 2-state CA, seven cellstates are needed to emulate a 3-state CA, and so on.

Re: RuleLoader's B0 handling quirks

Posted: July 19th, 2024, 8:19 am
by Drelectron8
Haycat2009 wrote: July 18th, 2024, 8:02 pm
unname4798 wrote: July 18th, 2024, 5:41 am
Haycat2009 wrote: July 18th, 2024, 4:38 am Can we have infinite B0 rules?
B0 rules require a bounded grid.
Why is this so?
A strobing rule gives the effect of cells becoming alive, then dying again, but in a large area, this can be laggy or just too big to handle (can you imagine the computation for all those cells?) Below is what would happen if there is no bounded grid. See? The bottom says it's only valid with a finite grid.

Code: Select all

x = 4, y = 4, rule = Wickstretcher_And_The_Parasites_True_Emulator
ob2o$2obo2$obo!
@RULE Wickstretcher_And_The_Parasites_True_Emulator
@TABLE
n_states:2
neighborhood: Moore
symmetries: permute
0,0,0,0,0,0,0,0,0,1
0, 1,0,0,0,0,0,0,0, 1
0, 1,1,1,0,0,0,0,0, 1
0, 1,1,1,1,1,0,0,0, 1
0, 1,1,1,1,1,1,0,0, 1
1, 1,1,1,1,1,1,0,0, 0
1, 1,1,1,1,1,1,1,0, 0
1, 1,1,1,1,1,1,1,1, 0

Here's an example using my rule:

WARNING: CONTAINS FLASHING LIGHTS.

Code: Select all

x = 4, y = 4, rule = Wickstretcher_And_The_Parasites_True_Emulator:T100,100
ob2o$2obo2$obo!
@RULE Wickstretcher_And_The_Parasites_True_Emulator
@TABLE
n_states:2
neighborhood: Moore
symmetries: permute
0,0,0,0,0,0,0,0,0,1
0, 1,0,0,0,0,0,0,0, 1
0, 1,1,1,0,0,0,0,0, 1
0, 1,1,1,1,1,0,0,0, 1
0, 1,1,1,1,1,1,0,0, 1
1, 1,1,1,1,1,1,0,0, 0
1, 1,1,1,1,1,1,1,0, 0
1, 1,1,1,1,1,1,1,1, 0
You can play around with it if you want.

However, for the solution to the problem is simple, make an alternating rule for the strobing rule. This can be done by finding the strobing equivalent of the strobing rule, which makes the strobing rule turn back to a normal rule, in this case it's B2478/S678, then we can trace the second black and white reversal, which is B012/S0146. Using the same method, we can determine that the other rule is B345678/S23578.

Now that we have both rules, we can make it alternate. So the rulestring becomes "B2478/S678|B345678/S23578" and actually does emulate the strobing rule above. This is a method used by most cellular automata programs "Golly, Lifeveiwer ect." to emulate these rules.

Code: Select all

x = 4, y = 4, rule = B2478/S678|B345678/S23578
ob2o$2obo2$obo!
That's better than having a whole area turn on then off and on again and lag a machine.


This only applies to true B0 rules, which should be the topic they're discussing about.