Page 1 of 1

Ripple

Posted: September 23rd, 2015, 1:09 am
by SeanBP
I've come up with a new rule that is meant to take on some wave-like behaviors. The basic idea is that each cell with a positive integer will get split evenly into its adjacent neighbors in the next tick. If the value can not be divided evenly, the quotient would instead move into the neighbors, and the remainder would be left behind. If given enough space, it will always break down the initial value into its smallest components (all remainder values).

Ex:

Code: Select all

. . .            . 1 .
. 5 .   --->     1 1 1  
. . .            . 1 .       
However, this rule becomes interesting when the grid is confined to a small area. If the value is large enough, and the grid is small enough, the value won't be able to break down into its smallest components, and this produces chaotic behavior inside the confined area. Eventually, it should find a sort of "resonance" inside the area, and turn into an oscillator. This confined area can be produced either by using a torus, or by lining a box of cells with negative values, making them "unavailable" like a barricade.

Although I've written it in Java, it's not very easy to explore. I am including this rule in bprentice's squarecell, but that might take a while. If anyone wants to try to implement this in Golly, feel free. I'm writing a paper on this for my behavior of complex systems class, so I will be sure to cite whoever helps.

Java code: https://gist.github.com/SeanBP/2a2e3f6f77719bf0d7fa

Re: Ripple

Posted: September 23rd, 2015, 8:47 am
by praosylen
There is a similar rule (Bak-Tang-Wiesenfeld sandpile model) on the Rule Table Repository: https://github.com/gollygang/ruletabler ... i/TheRules

Re: Ripple

Posted: September 23rd, 2015, 9:09 am
by SeanBP
A for awesome wrote:There is a similar rule (Bak-Tang-Wiesenfeld sandpile model) on the Rule Table Repository: https://github.com/gollygang/ruletabler ... i/TheRules
This is similar, the main difference being that Sandpile spreads out in small increments at a time, while mine tries to get rid of all values at once. They will share many similar characteristics, but I'm still curious how Ripple will look in comparison.

Re: Ripple

Posted: September 23rd, 2015, 3:16 pm
by Kiran
a new explosive rule
This rule is definitely tot explosive because the total of all the cell values cannot increase:
The clump would spread out until all cells are ones and stop expanding.

Re: Ripple

Posted: September 23rd, 2015, 6:15 pm
by SeanBP
Kiran wrote:
a new explosive rule
This rule is definitely tot explosive because the total of all the cell values cannot increase:
The clump would spread out until all cells are ones and stop expanding.
I suppose "explosive" is the wrong word choice. I mean that the cell count will increase rapidly initially, but yes, eventually it will become stable. I'll edit my post to describe it better. Also, the remaining values can be 2 or 3, since they can't divide into 4, with or without any remainders.

Re: Ripple

Posted: September 25th, 2015, 7:52 am
by Scorbie
I think these kind of rules don't fit well with golly.
When I make the rule with only 16 states, golly chokes pretty much with it.
EDIT: Okay, 16 states works pretty well with small random areas.
However, with 32 states golly takes a lot of time even just to open the rule file. Probably because it isn't optimized. And it takes an eternaty to undo.

I assumed that if the neighbor cells are like the following,

Code: Select all

.N.
WCE
.S.
Then the center cell becomes C' = C%4 + N/4 + W/4 + E/4 + S/4.

It is not hard to make the rule file itself:
ripplemaker.py

Code: Select all

import sys

def transition(c, n, e, s, w):
    return c%4 + n/4 + e/4 + s/4 + w/4

def printtrans(maxstate):
    for c in xrange(maxstate):
        for n in xrange(maxstate):
            for e in xrange(n+1):
                for s in xrange(e+1):
                    for w in xrange(s+1):
                        print '{}, {}, {}, {}, {}, {}'\
                              .format(c, n, e, s, w, transition(c, n, e, s, w))

def printrule(rulename, nstates):
    print '@RULE {}'.format(rulename)
    print '@TABLE'
    print 'n_states:{}'.format(nstates)
    print 'neighborhood:vonNeumann'
    print 'symmetries:permute'
    printtrans(nstates)


# Starts here
rulefilename = sys.argv[1]
numstates = int(sys.argv[2])
printrule(rulefilename, numstates)
invoke it with: (sorry about the redundant params... It's just a throwaway script.)

Code: Select all

ripplemaker.py rulename num_states > rulename.rule
e.g.

Code: Select all

ripplemaker.py sean16 16 > sean16.rule
Warning: Sean's original rule has an unbounded number of states, while this version is bounded. This makes the golly implementation a small quirk.(You can skip to conclusion)
e.g. if there are 5 states (0 thru 4), the center cell in the following becomes state 5 (not allowed!)

Code: Select all

.4.
414
.4.
If there are N states (0 thru N-1) the maximum state a center cell could have is:
3 + 4 * {(N-1)/4}, and this should be less than N.
if N-1=4q+r(q:quotient, r:remainder), 3 + 4q < 4q+r+1, r>2.
Conclusion: N must be 0 or 3 (mod4) in order for the rule to work in bounded number of states.

Re: Ripple

Posted: September 25th, 2015, 10:41 am
by SeanBP
Scorbie wrote:I think these kind of rules don't fit well with golly.
When I make the rule with only 16 states, golly chokes pretty much with it.
Hm, I'm developing a bad habit of making rules that don't fit in with Golly. I think this rule will be easier to explore in SquareCell, where I can make it have an arbitrarily large number of states to work with. I think the easiest way to make sure that the pattern will never produce a state higher than defined is to take the sum of every cell. The total value must be conserved, so no matter how the grid is arranged, it could never go over that amount.

Re: Ripple

Posted: September 25th, 2015, 9:08 pm
by Scorbie
SeanBP wrote:Hm, I'm developing a bad habit of making rules that don't fit in with Golly.
Well, I think golly-compatibility should not be a criteria for a good rule... Not fitting with golly just means it is a little harder to explain the rule, I think.
SeanBP wrote:I think this rule will be easier to explore in SquareCell, where I can make it have an arbitrarily large number of states to work with.
Is there a short tutorial or key bindings of squarecell? I couldn't find any, I think. EDIT: solved; thanks Brian!
SeanBP wrote:I think the easiest way to make sure that the pattern will never produce a state higher than defined is to take the sum of every cell. The total value must be conserved, so no matter how the grid is arranged, it could never go over that amount.
Your description looks like the number of states determined dynamically after you draw the pattern. But in golly the number of states is prefetermined within the rule, and then you draw the pattern.