Golly 4.0

For general discussion about Conway's Game of Life.
Cyclotrons
Posts: 129
Joined: January 26th, 2021, 12:19 am

Re: Golly 4.0

Post by Cyclotrons » March 23rd, 2021, 2:14 pm

Golly's implementation of weighted HROT is bugged.

Using this pattern:

Code: Select all

x = 20, y = 20, rule = R2,C0,S9,12,14-15,19,21,32,34,37,39,41,43,54,59,64,71,78,83,86-87,97-98,110,122,125,136,139,142-143,145,152,156,163,167,170,173-174,178,187,190,196,198,206,215,225,228,236,239,249,258,266,271,273,279,B3,5,12-14,18,38,52,55,64-65,73-74,76,88,91,99,102,111,113,144,148,179,190,196,200,202,208,237,245,267-268,272,NW76C76BC776C7BF3DBFC76B3D003D6BC7BF3DBFC776C76BC776
bobo2b2ob4o3bo2bo$obobob2obo2b2obob2o$bobob2o2b2obo2b2o2bo$o4bobo9b3o$
2b3o2b9ob3o$bo2b2obo3bob2o3bo$o6bo5bo4bo$b2obobobob4ob4o$o2b3obo2b2obo
bobobo$bo6b2o2b2o4bo$b3ob3obo2bob2o3bo$3obob4o4bo2bo$b3o3b5o2b2obo$2ob
2o4b2o3b6o$2o2b3o2bobo2b2ob3o$6b4o2b2ob2ob2o$2bo4b5ob2o2bobo$5ob4o2b2o
b3obo$b4obobo4b2o3bo$3o2bobo4b2o3b2o!
I get different results every time I run it.
bT6K99z.gif
bT6K99z.gif (93.36 KiB) Viewed 263 times
JD8AdlW.gif
JD8AdlW.gif (128.4 KiB) Viewed 263 times
FYISDyh.gif
FYISDyh.gif (115.18 KiB) Viewed 263 times
OC3HotO.gif
OC3HotO.gif (17.49 KiB) Viewed 263 times
Pictured above: some of the results I get when running the above pattern on the same rule.

It isn't just that pattern, either; it seems to be every pattern.
I wrote a stdin script that generates random soups of a provided number of a given spaceship. It works for all (non-B0) spaceships in the INT rulespace!
A Multistate INT notation + script.

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

Re: Golly 4.0

Post by rowett » March 23rd, 2021, 5:53 pm

Cyclotrons wrote:
March 23rd, 2021, 2:14 pm
Golly's implementation of weighted HROT is bugged.
True. Looks like it's related to negative weights. I'll fix it in due course.

Thanks for reporting!

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

Re: Golly 4.0

Post by rowett » March 24th, 2021, 1:21 am

rowett wrote:
March 23rd, 2021, 5:53 pm
I'll fix it in due course.
This has been fixed and committed to the Golly repo.

It was also an issue in LifeViewer (though different manifestation) and has been fixed and released (build 591).

Schiaparelliorbust
Posts: 3686
Joined: July 22nd, 2020, 9:50 am
Location: Acidalia Planitia

Re: Golly 4.0

Post by Schiaparelliorbust » March 29th, 2021, 1:21 am

Sorry about this, but I get the "Could not load the Python library" message too whenever I try to run a Python script. I tried reading the first page here, but there were some differences (they use Mac) that prevented me from finding help. I use Windows 10. I got the latest version of Python just yesterday too.
Hunting's language (though he doesn't want me to call it that)
Board And Card Games
Colorised CA
Alien Biosphere

User avatar
_zM
Posts: 186
Joined: June 26th, 2016, 3:07 pm

Re: Golly 4.0

Post by _zM » May 6th, 2021, 7:34 am

when running some types of bounded grids (i found the issue with toruses that are bounded in the horizontal direction but not the vertical), quicklife slows down to a crawl after a couple thousand generations, even with a fairly small, completely static pattern. pausing and resuming doesn't fix the issue, but undoing and then redoing does. example:

Code: Select all

x = 128, y = 107, rule = MAPAAARMwwMEbMAETMzDB0zs///MDD//zOz//8wMP//M7MAABEzAAARswARMzMAETOz//8zM///M7MA/zMz//8zsw:T128,0
2o$3o124bo$4o122b2o$5o120b3o$6o118b4o$7o116b5o$8o114b6o$9o112b7o$10o
110b8o$11o108b9o$12o106b10o$13o104b11o$14o102b12o$15o100b13o$16o98b14o
$17o96b15o$18o94b16o$19o92b17o$20o90b18o$21o88b19o$22o86b20o$23o84b21o
$24o82b22o$25o80b23o$26o78b24o$27o76b25o$28o74b26o$29o72b27o$30o70b28o
$31o68b29o$32o66b30o$33o64b31o$34o62b32o$35o60b33o$36o58b34o$37o56b35o
$38o54b36o$39o52b37o$40o50b38o$41o48b39o$42o46b40o$43o44b41o$44o42b42o
$45o40b43o$46o38b44o$47o36b45o$49o33b46o$50o30b48o$51o28b49o$52o26b50o
$53o24b51o$54o22b52o$55o20b53o$56o18b54o$57o16b55o$58o14b56o$59o12b57o
$60o10b58o$61o8b59o$62o6b60o$63o4b61o$64o2b62o$128o$128o$128o$128o$
128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$
128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$
128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o$128o!
(os: xubuntu 18.04 LTS)
moment

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

Re: Golly 4.0

Post by Andrew » May 14th, 2021, 9:43 pm

_zM wrote:
May 6th, 2021, 7:34 am
when running some types of bounded grids (i found the issue with toruses that are bounded in the horizontal direction but not the vertical), quicklife slows down to a crawl after a couple thousand generations, even with a fairly small, completely static pattern.
Thanks for the report. This problem has been fixed (and in the process of fixing it, Tom made some changes to the QuickLife code that significantly improves the generating speeds of patterns in bounded grids). In the meantime, if you notice the slow down problem, just switch to HashLife.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Gustone
Posts: 744
Joined: March 6th, 2019, 2:26 am

Re: Golly 4.0

Post by Gustone » May 30th, 2021, 5:46 am

when running golly 3.2 i had the nvidia driver crashing occasionally
i think that damaged the graphics card
the whole pc started crashing some months later

has this problem been fixed by now?

i am worried about the health of my new pc

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

Re: Golly 4.0

Post by Andrew » May 30th, 2021, 8:49 pm

Gustone wrote:
May 30th, 2021, 5:46 am
when running golly 3.2 i had the nvidia driver crashing occasionally ...
Try these steps:

* Upgrade Golly to the latest version, or at least to 3.3 (where according to Help > Changes we did fix a crash caused by buggy NVIDIA drivers).

* Install the latest driver for your graphics card.

* If using Windows 10 then try this tip (thanks to Extrementhusiast):
Settings > System > Display > Graphics settings > Graphics performance preference > set Golly to "High performance".

If none of those steps fix the problem then you might need to replace the graphics card. (It's highly unlikely that Golly did something to damage it.)
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

User avatar
Gustone
Posts: 744
Joined: March 6th, 2019, 2:26 am

Re: Golly 4.0

Post by Gustone » May 31st, 2021, 6:08 am

Andrew wrote:
May 30th, 2021, 8:49 pm
* Upgrade Golly to the latest version, or at least to 3.3 (where according to Help > Changes we did fix a crash caused by buggy NVIDIA drivers).

* Install the latest driver for your graphics card.

If none of those steps fix the problem then you might need to replace the graphics card. (It's highly unlikely that Golly did something to damage it.)
i have a new pc and i the latest compatible drivers installed

i'll see

User avatar
LaundryPizza03
Posts: 2295
Joined: December 15th, 2017, 12:05 am
Location: Unidentified location "https://en.wikipedia.org/wiki/Texas"

Re: Golly 4.0

Post by LaundryPizza03 » July 23rd, 2021, 2:41 am

Has anyone noticed this before? As I use Golly, it consumes an increasing share of the RAM, typically on the order of a gigabyte; this is most noticeable when running searchRule_matchPatt2.py (the main spaceship-finding tool of the 5s project) or doing engineering work, although I once got over 6 GB of usage during a searchRule_matchPatt2 run. This is especially problematic for those who have small RAM (my computer has 8 GB). Clearing tabs sometimes helps, but not always. The problem is noticeably worse for Golly 4.0.1. Is there a memory leak with the undo and redo actions?

Code: Select all

x = 4, y = 3, rule = B3-q4z5y/S234k5j
2b2o$b2o$2o!
LaundryPizza03 at Wikipedia

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

Re: Golly 4.0

Post by Andrew » July 23rd, 2021, 4:35 am

LaundryPizza03 wrote:
July 23rd, 2021, 2:41 am
Has anyone noticed this before? As I use Golly, it consumes an increasing share of the RAM, typically on the order of a gigabyte; this is most noticeable when running searchRule_matchPatt2.py ...
From Help > Python Scripting > Potential Problems:

1. The Python interpreter's memory allocator doesn't always release memory back to the operating system. If you run a complicated or buggy script that uses lots of (Python) memory then that memory is no longer available for use by Golly, so you might need to quit Golly and restart.

This is one of the reasons I prefer Lua over Python.
Use Glu to explore CA rules on non-periodic tilings: DominoLife and HatLife

GUYTU6J
Posts: 2200
Joined: August 5th, 2016, 10:27 am
Location: 拆哪!I repeat, CHINA! (a.k.a. 种花家)
Contact:

Re: Golly 4.0

Post by GUYTU6J » August 19th, 2021, 4:47 am

Just came across https://oeis.org/A268754 and got confused by the description. Later I realized it needs to specify a bounded plane and a single live cell to start with.

Code: Select all

x = 1, y = 8, rule = B1/S:P1,8
3$o!
Then here comes two questions.
1)If the pattern is copy&pasted into Golly, then the live cell is at the fourth place from top, while in LifeViewer it is at the sixth place. Why is there inconsistency?
2)In Golly, oscar.lua (both the one shipped with Golly and EV2's modification) claims it to be a spaceship with speed=c, while in LifeViewer the identify function correctly tells me it is a p14 oscillator. Does that mean oscar.lua needs fixing?

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

Re: Golly 4.0

Post by rowett » August 19th, 2021, 7:37 am

GUYTU6J wrote:
August 19th, 2021, 4:47 am
1)If the pattern is copy&pasted into Golly, then the live cell is at the fourth place from top, while in LifeViewer it is at the sixth place. Why is there inconsistency?
LifeViewer uses the actual bounding box for the pattern and then centers it. Golly, I suspect, uses the defined bounding box [x = 1, y = 8] and then centers.
GUYTU6J wrote:
August 19th, 2021, 4:47 am
2)In Golly, oscar.lua (both the one shipped with Golly and EV2's modification) claims it to be a spaceship with speed=c, while in LifeViewer the identify function correctly tells me it is a p14 oscillator. Does that mean oscar.lua needs fixing?
LifeViewer's oscar equivalent (Identify) is more rigorous. Once it finds a potential match it then plays forward to verify. oscar stops as soon as it finds a potential match.

Post Reply