ConwayLife.com

Posted: **February 5th, 2017, 8:18 pm**

I request a function that returns true if the soup has stabilized, let it be called stabilized.

Posted: **February 5th, 2017, 9:02 pm**

Saka wrote:I request a function that returns true if the soup has stabilized, let it be called stabilized.

Can't you just pull the necessary code from apgsearch?

Posted: **February 6th, 2017, 3:29 am**

BlinkerSpawn wrote:
Saka wrote:I request a function that returns true if the soup has stabilized, let it be called stabilized.
Can't you just pull the necessary code from apgsearch?

I'm lazy

Posted: **February 21st, 2017, 9:31 am**

I would like a script transforming a non-totalistic rule to its live/dead inversion.

BTW, does golly not support B0 non-totalistic rule yet?

EDIT: I have implemented this function in NTCA_invert.py

Posted: **February 21st, 2017, 11:45 am**

shouldsee wrote:Does golly not support B0 non-totalistic rule yet?

The latest version (2.9b1) runs them just fine.

Posted: **February 21st, 2017, 12:48 pm**

BlinkerSpawn wrote:
shouldsee wrote:Does golly not support B0 non-totalistic rule yet?
The latest version (2.9b1) runs them just fine.

Golly 2.9b1 can run B0 isotropic non-totalistic rules, anyway. Anisotropic rules with B0 can be simulated only in LifeViewer at the moment, and it's a little tricky -- you have to use the MAP and MAPODD script commands, which accept a base64-encoded 512-bit string.

With any luck MAPODD won't be needed in the long run, and Golly might end up supporting the MAP syntax directly without having to have a custom .rule file for each non-totalistic rule -- but ain't no one promising nothing just yet...!

In case anyone is interested, here are my test notes for the encoded 512-bit rule strings used by LifeViewer:

Code: Select all

B0 without S8 --
Even generations:
-- NOT (rule bitstring)
    (zeroes the first bit)
Odd generations:
-- (reversed rule bitstring)
    (puts the zero S8 bit into the first bit)

B0 with S8 --
All generations:
 -- NOT (reversed rule bitstring)

Test conversion of random isotropic rule into 512-bit MAP/MAPODD format -- 

Original rule:  B0124cik/S1c25

Rule for even generations:  B34-cik5678/S01-c34678 = 
00000001000101111010000110010111000101110111101110010111011111100001011101111111000101110111111001101111111111110111111011101001000101110111101110010111011111100111101111111111011111101110100101101111111111110111111011101001101111111111111111101001100101110001011101111101000101110111111001111111111111110111111011101001011110111101111101111110111010011101111101111111111010011001011101111101111101110111111011101001111111111111111111101001100101111111111111111111111010011001011111111111111111111001011101111111
Base64:  ARehlxd7l34Xfxd+b/9+6Rd7l357/37pb/9+6b//6ZcXfRd+f/9+6Xvffunff+mXffd+6f//6Zf//+mX//+Xfw

Rule for odd generations:  B367c/S4etk678 =
00000001000101100000000000000000000101100110100000000000000000000001011001101000000000000000000001101000100000010001000001000001000101100110100000000001000001000110100010000001000001000010000101101000100000010000000000000001100000010001011101000001000101110001011001101000000000000000001001101000100000010000000000001001011010001000000100000000001000011000000100010110001000010001011101101000100000010000000000001001100000010001011100000001000101111000000100010110001000010001011100010110011110100001011101111111
Base64:  ARYAABZoAAAWaAAAaIEQQRZoAQRogQQhaIEAAYEXQRcWaAACaIEACWiBACGBFiEXaIEACYEXAReBFiEXFnoXfw

Even-generation rule bitstring with bits in opposite order, compared with odd-generations rule -- should be exact inverse:
11111110111010011111111111111111111010011001011111111111111111111110100110010111111111111111111110010111011111101110111110111110111010011001011111111110111110111001011101111110111110111101111010010111011111101111111111111110011111101110100010111110111010001110100110010111111111111111110110010111011111101111111111110110100101110111111011111111110111100111111011101001110111101110100010010111011111101111111111110110011111101110100011111110111010000111111011101001110111101110100011101001100001011110100010000000
00000001000101100000000000000000000101100110100000000000000000000001011001101000000000000000000001101000100000010001000001000001000101100110100000000001000001000110100010000001000001000010000101101000100000010000000000000001100000010001011101000001000101110001011001101000000000000000001001101000100000010000000000001001011010001000000100000000001000011000000100010110001000010001011101101000100000010000000000001001100000010001011100000001000101111000000100010110001000010001011100010110011110100001011101111111
... and it is.

Test pattern: Golly or Molly can run this correctly, but don't try it in LifeViewer --

Code: Select all

x = 37, y = 13, rule = B0124cik/S1c25
9ob8o3b5o2b9o$4bo5bo9bo5bo5bo$4bo5bo8bo12bo$4bo5bo8bo12bo$4bo5bo8bo12b
o$4bo5bo9bo11bo$4bo5b5o6b4o7bo$4bo5bo14bo6bo$4bo5bo15bo5bo$4bo5bo15bo
5bo$4bo5bo15bo5bo$4bo5bo8bo5bo6bo$4bo5b8o2b5o7bo!

-- and LifeViewer ends up with the same pattern at T=10, if you run this MAP/MAPODD translation:

Code: Select all

x = 37, y = 13
9ob8o3b5o2b9o$4bo5bo9bo5bo5bo$4bo5bo8bo12bo$4bo5bo8bo12bo$4bo5bo8bo12b
o$4bo5bo9bo11bo$4bo5b5o6b4o7bo$4bo5bo14bo6bo$4bo5bo15bo5bo$4bo5bo15bo
5bo$4bo5bo15bo5bo$4bo5bo8bo5bo6bo$4bo5b8o2b5o7bo!
#C [[ MAP ARehlxd7l34Xfxd+b/9+6Rd7l357/37pb/9+6b//6ZcXfRd+f/9+6Xvffunff+mXffd+6f//6Zf//+mX//+Xfw ]]
#C [[ MAPODD ARYAABZoAAAWaAAAaIEQQRZoAQRogQQhaIEAAYEXQRcWaAACaIEACWiBACGBFiEXaIEACYEXAReBFiEXFnoXfw ]]

Again, this is really just an isotropic rule in a format that can support anisotropic rules. Changing bits in the 512-bit strings above could produce a real anisotropic rule, and if the new strings are re-translated into base64 MAP and MAPODD values, LifeViewer could still do a successful flicker-free emulation of the rule.

... Also, I have a v1.0 megafier script now that should be able to program Calcyman's megacells correctly to run B0 rules. Haven't tested it yet -- will post it when I can.

Megacells don't do the flicker-free simulation trick, though, so the cells will flash on and off a lot, and there will be nasty edge effects unless you add p16777216 guns all round the edges for B0-and-S8 rules, or p33554432 guns for B0-no-S8 rules.

Posted: **February 21st, 2017, 2:53 pm**

Glad to hear that much. Actually Golly 2.91b was sufficient for my purpose.

Posted: **February 22nd, 2017, 2:28 pm**

A script to find spaceships by equalling the initial and final state of a given periodically stable (stator) cell, recreating the initial cell at a translation and making the periodic stabilisation disappear in time for the next generation. This should make smaller spaceships with stator cells easier to find and it avoids the "Towering" behaviour of gfind and other similar predecessor-based approaches.

Posted: **February 23rd, 2017, 8:23 am**

Regarding the non-totalistic rules, I would also like a script exchange the diagonal/orthogonal property of a given rule

Posted: **February 23rd, 2017, 11:23 am**

shouldsee wrote:Regarding the non-totalistic rules, I would also like a script exchange the diagonal/orthogonal property of a given rule

What exactly is meant by this?

Posted: **February 23rd, 2017, 1:01 pm**

BlinkerSpawn wrote:
shouldsee wrote:Regarding the non-totalistic rules, I would also like a script exchange the diagonal/orthogonal property of a given rule
What exactly is meant by this?

Say B2e have 2 edge cells, this should be mapped to B2c.
Similarly B2c->B2e, B2i->B2n, B2n-> B2i, B2a->B2a, B2k->B2k. Namely you rotat e the neighborhood by 45 degrees and read off the new config.

At the first instance I thought the dynamics would be invariant under this transformation. Now I am not quite sure of that. A script might be the easiest way to test it.

Posted: **February 23rd, 2017, 1:30 pm**

shouldsee wrote:Say B2e have 2 edge cells, this should be mapped to B2c.
Similarly B2c->B2e, B2i->B2n, B2n-> B2i, B2a->B2a, B2k->B2k. Namely you rotat e the neighborhood by 45 degrees and read off the new config.

At the first instance I thought the dynamics would be invariant under this transformation. Now I am not quite sure of that. A script might be the easiest way to test it.

I wondered if the idea was to make an invariant transformation. But it's definitely not invariant. A simple example will prove that, with no need for a script:

Code: Select all

x = 1, y = 1, rule = B1e/S012345678
o!

The above transformation would produce

Code: Select all

x = 1, y = 1, rule = B1c/S012345678
o!

which starts out (for two ticks) looking like it will do the same thing diagonally that the other pattern does orthogonally. But then it turns out that corner cells don't touch as many neighbors in the neighborhood as edge cells do, so you end up with very different behavior from T=3 on.

If the dynamics were invariant under this transformation, then bishops in chess would be just as powerful as rooks. And I suppose chessboards would have to have eightfold rotational symmetry... it's kind of a mind-bending counterfactual, so I'm not entirely sure.

Posted: **February 23rd, 2017, 2:10 pm**

dvgrn wrote: [...]
If the dynamics were invariant under this transformation, then bishops in chess would be just as powerful as rooks. And I suppose chessboards would have to have eightfold rotational symmetry... it's kind of a mind-bending counterfactual, so I'm not entirely sure.

The reason for such thought is that orthogonal spaceships often have diagonal similars in some other rules, and sometimes they are remarkably similar, thus making me wonder whether we can establish some kind of mapping. As it unrolls, switching edge and corner will definitely not do the job. I will try to compile some examples before any in-depth discussion.

Posted: **February 23rd, 2017, 6:47 pm**

shouldsee wrote:The reason for such thought is that orthogonal spaceships often have diagonal similars in some other rules, and sometimes they are remarkably similar, thus making me wonder whether we can establish some kind of mapping. As it unrolls, switching edge and corner will definitely not do the job. I will try to compile some examples before any in-depth discussion.

You can establish a correlation between diagonal and orthogonal, but over a square lattice you can only do it between the von Neumann neighborhood and its diagonal equivalent, i.e. making these exchanges:

Code: Select all

1c <-> 1e
2c <-> 2e
2n <-> 2i
3c <-> 3e
4c <-> 4e

and having no other transitions.

Posted: **February 23rd, 2017, 10:32 pm**

shouldsee wrote:At the first instance I thought the dynamics would be invariant under this transformation. Now I am not quite sure of that. A script might be the easiest way to test it.

I think there's a way to (dis)prove this from what we already know about standard Life. If the dynamics were invariant under this translation, then I would think that when a glider is translated rotationally by 45°, it would behave the same as a normal glider except orthogonally. But this isn't so.

Code: Select all

x = 18, y = 11, rule = B38/S23
bo15bo$o14b2o$3o13b2o6$o2bo11bo$obo12bobo$bo12bobo!

Posted: **February 24th, 2017, 12:23 pm**

Code: Select all

x = 1, y = 1, rule = B1c2i/S01234-c5678
o!

Posted: **February 24th, 2017, 10:01 pm**

Rhombic wrote:
Code: Select all
x = 1, y = 1, rule = B1c2i/S01234-c5678
o!

I think I prefer that with B78:

Code: Select all

x = 1, y = 1, rule = B1c2i78/S01234-c5678
o!

Posted: **March 2nd, 2017, 4:36 am**

Saka wrote:I request a function that returns true if the soup has stabilized, let it be called stabilized.

PLEASE

Posted: **March 2nd, 2017, 3:18 pm**

Saka wrote:
Saka wrote:I request a function that returns true if the soup has stabilized, let it be called stabilized.
PLEASE

Saka wrote:
BlinkerSpawn wrote: Can't you just pull the necessary code from apgsearch?
I'm lazy

I can't speak for anyone else, but this request isn't a very tempting one for me, as it stands. If the stabilise3() function in apgsearch 1.1 isn't exactly what is needed, then what is needed?

I agree that it would be nice to have a script that could quickly and reliably tell you whether a soup has stabilized or not. You could keep checking the value of the function after each golly.run(1), and you'd know exactly when a soup "goes boring", what tick to use as a methuselah's survival time, etc.

But that "quickly" caveat seems like the difficult part. Maybe we could do this horrendously slowly, with a variant of a recognizer script that checks the current pattern to see if it's all made out of well-separated still lifes and oscillators, and that all gliders and *WSSes are outside the danger zone and won't collide. Have to be careful about cases like this one -- except imagine that the rest of the pattern has settled before the LWSS and glider collide.

In practice, the most reasonable way to tell if a pattern has stabilized is to run it for a lot of ticks in HashLife and see if it changes. So... let's say you have a 10001-tick methuselah on your hands. With a function that just returns TRUE or FALSE as you're suggesting, and with my silly golly.run(1) suggestion, you'd actually be running more or less the same pattern and getting FALSE back ten thousand times, and then finally a TRUE at T=10001.

That's going to be ridiculously slow, too. You could cut down the inefficiency a lot with some kind of binary search... but really, it seems like it makes a lot more sense to run the pattern just once, find out exactly when it stabilizes, and return the exact number of ticks to stabilization instead of a TRUE or FALSE.

Once you have that time_to_stabilization() function, your requested function will be easy, I suppose:

Code: Select all

def stabilized():
     return (time_to_stabilzation()==0)

The time_to_stabilization() function could be easy to write and fast to run, or fairly difficult to write and slow to run, depending on how accurate you need it to be. Would it be okay if it returned too high a value sometimes -- say, the first power of two at which the pattern has definitely settled down? Then stabilized() would return false negatives sometimes, of course. But you could run

Code: Select all

golly.run(time_to_stabilization())

and then you'd be guaranteed a TRUE result. Is that good enough?

If not, then maybe you could post a precise definition of what it means for a pattern to be stabilized. Is it just the first tick when it's "gone boring" -- guaranteed no new novelty -- even if it has switch engines or pufferfish or p30 guns or whatever, still increasing the population?

The stabilise3() function from apgsearch still seems like a good place to start, in that case.

Posted: **March 6th, 2017, 10:59 am**

I would like a Lua script that creates the Fibonacci fractal, the fractal made by stacking Fibonacci numbers in binary, for example:

Code: Select all

x = 7, y = 11, rule = B3/S23
6bo$6bo$5bo$5b2o$4bobo$3bo$3b2obo$2bobobo$bo3bo$b2ob3o$ob2o2bo!

Posted: **March 6th, 2017, 11:10 am**

gameoflifemaniac wrote:I would like a Lua script that creates the Fibonacci fractal, the fractal made by stacking Fibonacci numbers in binary...

Start a new Scripts thread and post your best attempt at writing it, and it's a sure thing that someone will be unable to resist helping you finish it.

It's just a couple dozen lines of code or less -- seems like a perfect size for a first Lua coding project, and a thread like that might help other people learn Lua as well as you.

Posted: **April 2nd, 2017, 10:06 pm**

A python/lua script which works like this:

You provide an RLE, for example:

Code: Select all

x = 2, y = 3, rule = B3/S23
bo$2o$bo!

And you can turn on and off isotropic transitions, via two dialogue boxes:

Always On (Base Rule): B3/S23
Always Off: B012a4ar6e/S014ar

A third dialogue box would signify the amount of generations to check for, to prevent exploding rules from halting the script and overusing your RAM.

The rest would be optional on/off, and would be tested as so.

It would give you options whether to test for oscillators, spaceships, still lifes, linear growths, quadratics, or any combination of those. It would then run the pattern and see if it turns into a single object of the type you describe. If it isn't, move onto the next. After it's all done, it would display it in a big list of rules it works in, along with period for good measure.

I don't think this should be too hard, but I'm bad at programming, so if someone could give it a shot, that would be sweet.

Posted: **May 15th, 2017, 7:53 pm**

Is it possible to make a script which could take any given glider and calculate where it would have been (and in what phase) N generations ago?

Posted: **May 15th, 2017, 8:33 pm**

Ethanagor wrote:Is it possible to make a script which could take any given glider and calculate where it would have been (and in what phase) N generations ago?

Yes, that's fairly simple as these things go. Does the glider rewinder script do what you need? Just run it N times, or add a getstring() call at the beginning and call the rewind function N times in a row.

Doing the rewinding one step at a time is very inefficient, but it does keep you from skipping through impossible situations while rewinding (e.g., a glider passing through a block, or two gliders passing through each other). Do you need to check for and avoid cases like that?

Posted: **May 15th, 2017, 8:50 pm**

I would like a script that makes a random nt rule without b2a. I tried this once but had lots of problems so I abandoned it.

ConwayLife.com

Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread

Re: Script request thread