Golly 3.2

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: Golly 3.2

Post by Andrew » August 21st, 2018, 9:34 am

Redstoneboi wrote:are we able to update golly without having to delete and reinstall?
Depends on which platform you are using. The top item in Help > Hints and Tips has this paragraph:

When upgrading to a new version of Golly, Mac users can simply drag all the distributed files and folders into their Golly folder and the old versions will be replaced. On Windows and Linux you'll need to delete the old Help, Patterns, Rules and Scripts folders before dragging in the new folders to avoid ending up with merged versions.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Andrew
Moderator
Posts: 919
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 3.2

Post by Andrew » August 21st, 2018, 9:39 am

muzik wrote:What exactly is planned for Golly 3.3?
I personally don't have much planned at all. Can't speak for the other developers.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
KittyTac
Posts: 535
Joined: December 21st, 2017, 9:58 am

Re: Golly 3.2

Post by KittyTac » August 21st, 2018, 10:47 am

Can you make JvN-family patterns work properly when rotated? They do not rotate the arrows themselves when rotated, breaking all circuits. This would make life for us JvNgineers much easier. :)

User avatar
Andrew
Moderator
Posts: 919
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 3.2

Post by Andrew » August 21st, 2018, 8:00 pm

KittyTac wrote:Can you make JvN-family patterns work properly when rotated?
That would require adding JvN-specific logic to Golly's editing code. Not going to happen (by me at least). The solution is to write a script to rotate JvN patterns.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Macbi
Posts: 903
Joined: March 29th, 2009, 4:58 am

Re: Golly 3.2

Post by Macbi » September 10th, 2018, 5:50 am

Is there a way to use Golly to simulate a bounded grid with live cells around the outside? I thought

Code: Select all

x = 128, y = 128, rule = B0123478/S01234678:P128,128
!
would work, but it didn't.

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

Re: Golly 3.2

Post by dvgrn » September 10th, 2018, 6:15 am

Macbi wrote:Is there a way to use Golly to simulate a bounded grid with live cells around the outside? I thought

Code: Select all

x = 128, y = 128, rule = B0123478/S01234678:P128,128
!
would work, but it didn't.
What should it do that it's not doing? In Golly 3.2 I seem to get a working AntiLife universe that behaves in the normal way at bounded-grid edges -- gliders turn into blocks, you can get half-pulsars, etc. If the cells around the outside were considered to be dead you'd get new births around the edges all the time.

The weird thing is that Golly automatically inverts this kind of B0 rule without doing anything to notify you. That means dead cells are reported as live cells, and vice versa -- just because the dead cells are the interesting ones, worth reporting in population counts and so on, whereas in unbounded grids Golly would have to report infinite population after T=0 in a non-inverted rule.

The particular rule you quoted is recognized specifically as "AntiLife", but the same inversion happens for anti-HighLife, for example, which doesn't have a name defined:

Code: Select all

x = 4, y = 4, rule = B0123478/S0134678:P128,128
b3o$o$o$o!

User avatar
Macbi
Posts: 903
Joined: March 29th, 2009, 4:58 am

Re: Golly 3.2

Post by Macbi » September 10th, 2018, 6:26 am

If the cells around the outside were considered to be dead you'd get new births around the edges all the time.
This is the effect I wanted to look at, in Life. But I knew that cells around the outside were treated as dead. So I switched to AntiLife in the hope that that would make them behave as I wanted.

wildmyron
Posts: 1542
Joined: August 9th, 2013, 12:45 am
Location: Western Australia

Re: Golly 3.2

Post by wildmyron » September 10th, 2018, 7:26 am

Macbi wrote:
If the cells around the outside were considered to be dead you'd get new births around the edges all the time.
This is the effect I wanted to look at, in Life. But I knew that cells around the outside were treated as dead. So I switched to AntiLife in the hope that that would make them behave as I wanted.
I don't believe there's any way to do this with the QuickLife or HashLife algorithms in Golly, but it's very easy with Ruleloader. Here's a pattern in ExtendedLife which exhibits the effect you're after.

Code: Select all

x = 130, y = 130, rule = extendedlife:P130,130
130F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F
128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$
F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F
$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.
F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F
128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$
F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F
$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.
F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F
128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$
F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F
$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.
F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F128.F$F
128.F$F128.F$130F!
If necessary, it's easy to reduce the rule to a 3 state rule with Off, On and Perma-On cells.
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.

Semi-active here - recovering from a severe case of LWTDS.

User avatar
Macbi
Posts: 903
Joined: March 29th, 2009, 4:58 am

Re: Golly 3.2

Post by Macbi » September 10th, 2018, 7:33 am

wildmyron wrote:I don't believe there's any way to do this with the QuickLife or HashLife algorithms in Golly, but it's very easy with Ruleloader. Here's a pattern in ExtendedLife which exhibits the effect you're after.
Neat! Thanks.

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

Re: Golly 3.2

Post by dvgrn » September 10th, 2018, 7:43 am

Macbi wrote:
wildmyron wrote:I don't believe there's any way to do this with the QuickLife or HashLife algorithms in Golly, but it's very easy with Ruleloader. Here's a pattern in ExtendedLife which exhibits the effect you're after.
Neat! Thanks.
Another advantage of that approach is that many explosive rules tend to run much faster in unbounded grids, framed with a rectangle of cells like this that simulate whatever boundary conditions you want. For a torus you're stuck with Golly's implementation, but a regular old-fashioned bounded grid will be much happier being simulated in RuleLoader.

Maybe a script would be a good idea: when run in Golly when the current universe is a two-state isotropic rule on a bounded P{x,y} grid, the script could generate the equivalent custom rule with an extra "permanent dead" state, and line an (x,y) rectangle with those cells.

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

Re: Golly 3.2

Post by rowett » September 11th, 2018, 1:07 am

Andrew wrote:
muzik wrote:What exactly is planned for Golly 3.3?
I personally don't have much planned at all. Can't speak for the other developers.
The changes already committed for 3.3 are here. Nothing else planned from me.

User avatar
Redstoneboi
Posts: 429
Joined: May 14th, 2018, 3:57 am

Re: Golly 3.2

Post by Redstoneboi » September 20th, 2018, 5:45 am

Margolus without table/tree conversion when?
c(>^w^<c)~*
This is 「Fluffy」
「Fluffy」is my sutando.
「Fluffy」has the ability to engineer r e p l i c a t o r s.
「Fluffy」likes to watch spaceship guns in Golly.
「Fluffy」knows Natsuki best girl.

User avatar
KittyTac
Posts: 535
Joined: December 21st, 2017, 9:58 am

Re: Golly 3.2

Post by KittyTac » September 22nd, 2018, 11:33 am

Are distance-related overflow errors a thing?

NickGotts
Posts: 101
Joined: November 10th, 2011, 6:20 pm

Re: Golly 3.2

Post by NickGotts » October 1st, 2018, 6:34 am

Hi,

I'm running Golly 3.2, win-64 version, under Windows 7, on a machine with 16 Gb of RAM. I have Python 2.7.5 installed, and in general, the setup works very well.

I tried to run a script which involved importing a large .py file (286 Mb), and after some time the script failed with a memory error, although I had increased the Golly memory allocation to 8,000 Mb. Improting the file should simply create a long list of lists of Golly clists (each of the intermediate lists contains clists of all the rotations/reflections of a specific 8-cell pattern, the same approach has worked fine with smaller files of the same format). Can anyone tell me whether the problem is with Golly, my Python implementation, or with creating such a long/large nested list, and whatever the answer, give any advice?

User avatar
Andrew
Moderator
Posts: 919
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: Golly 3.2

Post by Andrew » October 1st, 2018, 7:51 am

NickGotts wrote:I tried to run a script which involved importing a large .py file (286 Mb), and after some time the script failed with a memory error, although I had increased the Golly memory allocation to 8,000 Mb.
If you mean the memory setting in Preferences > Control, that has no effect on the memory used by a Python script (other than possibly reducing the amount of memory available to the script).

See Help > Python Scripting > Potential problems. You are probably running into problem 1, and maybe problem 4. There's not much you can do about 1, other than restart Golly whenever you want to run your memory guzzling script. You might consider rewriting the script in Lua. Not only would it be faster, but Lua scripts should deallocate all the memory they use when they exit.

As for problem 4, if your script doesn't call a new/open/save command then Golly might be allocating lots of memory to record any cell changes made by the script.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

NickGotts
Posts: 101
Joined: November 10th, 2011, 6:20 pm

Re: Golly 3.2

Post by NickGotts » October 1st, 2018, 4:22 pm

Thanks Andrew, that's helpful. Can't involve problem 4, as the script doesn't create a pattern.

NickGotts
Posts: 101
Joined: November 10th, 2011, 6:20 pm

Re: Golly 3.2

Post by NickGotts » October 17th, 2018, 4:48 am

I am running a lot of Python scripts which begin by loading lists of cell-lists, and end by storing more lists of cell-lists. In between, there's generally quite a bit of evolving/running patterns. Which is likely to be quicker, doing this using "evolve", or "putcells", "run", and "getcells"? I appreciate the answer may depend on what patterns I'm running/evolving and for how many generations, but any general guidance would be much appreciated.

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

Re: Golly 3.2

Post by dvgrn » October 17th, 2018, 8:32 am

NickGotts wrote:I am running a lot of Python scripts which begin by loading lists of cell-lists, and end by storing more lists of cell-lists. In between, there's generally quite a bit of evolving/running patterns. Which is likely to be quicker, doing this using "evolve", or "putcells", "run", and "getcells"? I appreciate the answer may depend on what patterns I'm running/evolving and for how many generations, but any general guidance would be much appreciated.
Yeah, as you say the answer is definitely "it depends". My rule of thumb in that kind of situation is to try g.evolve() first -- it's usually plenty fast enough, even for fairly long and involved searches.

If you try out the code and the full job will take months or weeks rather than days or hours, then it's probably time to think about using some kind of API like lifelib, rather than sticking with Python and living with the severalfold slowdown. It's not likely that putcells/run/getcells will save you very much, usually, compared with escaping from interpreted scripting languages entirely.

If you're doing something like running Mystery Pattern 1 through Mystery Pattern 1,000,000 to stability, then it's probably better to drop them into a HashLife universe, because then you can run lots of extra ticks at not much extra cost, just to be sure. (With the kind of patterns you've traditionally been interested in, "lots of extra ticks" might not always be enough to be sure of anything... but it doesn't seem like you'd be interested in storing a cell list at the end of a long run of a growing pattern, anyway.)

User avatar
calcyman
Moderator
Posts: 2932
Joined: June 1st, 2009, 4:32 pm

Re: Golly 3.2

Post by calcyman » October 17th, 2018, 9:54 am

NickGotts wrote:I am running a lot of Python scripts which begin by loading lists of cell-lists, and end by storing more lists of cell-lists. In between, there's generally quite a bit of evolving/running patterns. Which is likely to be quicker, doing this using "evolve", or "putcells", "run", and "getcells"? I appreciate the answer may depend on what patterns I'm running/evolving and for how many generations, but any general guidance would be much appreciated.
I've checked the source code, and py_evolve() in Golly creates a temporary universe of the same type as the current layer, emplaces the cells there, runs it, and returns the cell list. So it's essentially the same as new --> putcells --> run --> getcells, except with fewer calls between Python and Golly. As such, evolve() should always be a smidgen faster.

(Why are you using cell lists, just out of interest?)
What do you do with ill crystallographers? Take them to the mono-clinic!

rokicki
Posts: 80
Joined: August 6th, 2009, 12:26 pm

Re: Golly 3.2

Post by rokicki » October 17th, 2018, 12:09 pm

On drawing outside +/- 2B: if we did decide to support it, another decision that needs to be made
is whether we support drawing inside bounds of 2^63 (about +/- 9E18), or whether we truly support
all editing in bignums throughout. The latter is probably a fair bit of work; the former would
probably be moderately easy now that 64-bit integers are a common thing. But like Andrew says,
convince us this is something interesting to do.

NickGotts
Posts: 101
Joined: November 10th, 2011, 6:20 pm

Re: Golly 3.2

Post by NickGotts » October 19th, 2018, 7:38 am

calcyman:
Why are you using cell lists, just out of interest?
Thanks very much for the information about run/evolve. I've embarked on a project to look at all the patterns with up to 10 cells, with the main aims of (1) confirming Paul Callahan's finding that there are no infinite growth patterns with <10 cells and (2) discovering all the infinite growth patterns with 10 cells. The first stage of this is to catalogue all the patterns - by no means a trivial task. I've found cell-lists more convenient for this task than any other Golly-compatible way of specifying patterns.

I should say I have no expectation of finding any <10 cell infinite growth patterns. However, as Paul himself said in a note he made on the search he undertook (in a temporary post at the University of Aberystwyth while I was a lecturer there in 1996):
Extended exhaustive survey to 9-cell case, obtaining negative results. This implies that the above patterns {three 10-cell infinite growth patterns he found - NG} are the smallest possible in terms of cell count (but since this is essentially a computerized-proof, more care is needed to make sure the programs work as claimed and that the enumeration is exhaustive).
The best way of checking a computerized proof is to re-do it using different languages and algorithms. My implementation is undoubtedly less efficient than Paul's, as I'm using Python rather than C (which I never learned), and he's a much more accomplished programmer! However, 20 years of increasing computer speed and memory make it feasible on my desktop machine.

I'll report to the list when I have findings of interest, and make the Python scripts and pattern catalogues available to anyone who wants them once they are complete. I've reported a couple of trivial 8-cell Methusaleh results already on the appropriate thread. I hope to finish the search up to 9 cells within a couple of weeks.

Hooloovoo
Posts: 38
Joined: July 11th, 2015, 8:59 pm

Re: Golly 3.2

Post by Hooloovoo » November 3rd, 2018, 3:19 am

Does anyone else use gentoo, and can help to push this through the system?
https://bugs.gentoo.org/661360
(is there a packaging thread that would be more appropriate?)

wildmyron
Posts: 1542
Joined: August 9th, 2013, 12:45 am
Location: Western Australia

Re: Golly 3.2

Post by wildmyron » November 3rd, 2018, 8:04 am

Hooloovoo wrote:Does anyone else use gentoo, and can help to push this through the system?
https://bugs.gentoo.org/661360
(is there a packaging thread that would be more appropriate?)
I can't really help as I don't use Gentoo, but I was curious about the process compared to other Linux distributions and I noticed that today is the monthly Gentoo bugday https://wiki.gentoo.org/wiki/Bugday
As version bumps is on the topic list I suggest you bring it up at that event, hopefully someone will be able to help it along.
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.

Semi-active here - recovering from a severe case of LWTDS.

Hooloovoo
Posts: 38
Joined: July 11th, 2015, 8:59 pm

Re: Golly 3.2

Post by Hooloovoo » November 5th, 2018, 3:59 am

Welp, I seem to have missed it. I'll still ping the official maintainer about it. I'll bring it up on the IRC channel, and I'll definitely make sure to join for the next one.

dani
Posts: 1222
Joined: October 27th, 2017, 3:43 pm

Re: Golly 3.2

Post by dani » November 16th, 2018, 1:37 pm

Lua's gp.getedges doesn't seem to work properly. Using this:

Code: Select all

g.show(gp.getedges({0, 0, 10, 10}))
Just returns '0'. This is the 32-bit version on Windows 10.

EDIT: In particular, it just returns x. I'm assuming it tries to return a table but can't for some reason.

Post Reply