Golly suggestions

For general discussion about Conway's Game of Life.
Post Reply
User avatar
KittyTac
Posts: 535
Joined: December 21st, 2017, 9:58 am

Re: Golly suggestions

Post by KittyTac » October 10th, 2018, 9:34 pm

Here's another thing: Ability to simulate Wolfram rules that are not range-1 2-state ones. It's annoying to use Wolfram Alpha for their analysis.

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

Re: Golly suggestions

Post by Redstoneboi » October 11th, 2018, 3:54 am

KittyTac wrote:Here's another thing: Ability to simulate Wolfram rules that are not range-1 2-state ones. It's annoying to use Wolfram Alpha for their analysis.
Explanation
well, golly actually converts elementary wolfram rules into either 2 state asymmetric rule tables or MAP strings
it also can’t run even wolfram rules because of the b0.
since golly only runs 2d rules and instead converts it into a b0 rule, it allows layers below the original pattern to evolve. state 1 cells can’t die either.

Solution
maybe have a “lineLoader” algorithm that runs up to 256 state and range 64 (or whatever) 1d rules, with the height of each cell being the screen’s height.
suggestion: i think 1d tables should either be @LINE, or @WOLFRAM instead of @TABLE
optional: maybe even request a script (please make it .lua) that converts a 1d pattern and a rule into a pattern in a rule where nothing moves.

Suggestion
and while we’re on the topic of adding algorithms, maybe a “blockLoader” that simulates arbitrary state block based cellular automata with 2*2 neighborhoods such as margolus and square4cyclic.
suggestion: block tables should be @BLOCK
maybe even update the margolus patterns?

i guess you can have either of those, and i’d be happy.
it’s more convenient to use these than having to convert them using scripts back and forth with each edit.
Last edited by Redstoneboi on November 4th, 2018, 9:05 am, edited 1 time in total.
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 suggestions

Post by KittyTac » October 22nd, 2018, 3:32 am

What about making random fills obey the paste modes?

User avatar
gameoflifemaniac
Posts: 1242
Joined: January 22nd, 2017, 11:17 am
Location: There too

Re: Golly suggestions

Post by gameoflifemaniac » November 11th, 2018, 10:31 am

Please add LTL rule tables in Golly 3.3!
Or 3.4.
I was so socially awkward in the past and it will haunt me for the rest of my life.

Code: Select all

b4o25bo$o29bo$b3o3b3o2bob2o2bob2o2bo3bobo$4bobo3bob2o2bob2o2bobo3bobo$
4bobo3bobo5bo5bo3bobo$o3bobo3bobo5bo6b4o$b3o3b3o2bo5bo9bobo$24b4o!

wwei23

Re: Golly suggestions

Post by wwei23 » November 11th, 2018, 2:51 pm

Please keep betas available.
I don't have much else to say.

M. I. Wright
Posts: 372
Joined: June 13th, 2015, 12:04 pm

Re: Golly suggestions

Post by M. I. Wright » November 11th, 2018, 4:17 pm

gameoflifemaniac wrote:Please add LTL rule tables in Golly 3.3!
Or 3.4.
It would be a nice thing to have, but I don't think a "please" is going to cancel out the proposal's difficulty. Do you have any ideas yourself regarding how LtL ruletables should be implemented?

The larger the neighborhood, the more inviable the current ruletable system (listing all terms of the transition on one line) is. At range 1, with 8 terms max, it's not so difficult to keep track of positioning, but take this range-2 transition on for size:

Code: Select all

0,a,0,0,b,c,d,0,0,1,2,0,0,0,0,e,f,g,h,i,j,0,0,0,0,1
...and bigger won't be getting any better. The impracticality of name-bound variables is also highlighted here: can you imagine needing to declare 24, 48, 80 different names for the exact same variable — and, worse, keeping track of these hardly-separate names? It's bad enough with a size-8 neighborhood, and perhaps still manageable at size 24 with range 2, but past that you won't even be able to rely on single-letter variables (as seems to be standard); the ensuing visual and cognitive noise won't make writing these tables much fun.

A compass-direction-based system like Nutshell's obviously won't work here, either, so something totally new will have to do. (I have ideas but considering that this whole thing isn't even under consideration yet I'll refrain)

Symmetries aren't going to be much fun, either, if they stay as is. I assume that they work behind the scenes by expanding each transition under a given set of symmetries into symmetries:none for easy lookup, but this means that LtL permutational symmetry will have to be cleverer: finding permutations of a given sequence gets pretty expensive once it reaches a length of about 10 or 11, but we're looking at 24 or more terms in a single transition napkin! That's an upper bound of 620,448,401,733,239,439,360,000 expanded transitions (assuming each term of the original one is unique, which admittedly is likely not to be the case) for range 2.

Back to writing rules, though: Discord user HactarCE, whom I've hashed out a lot of Nutshell stuff with, has proposed a 2D-transition system -- some variation on which is probably going to be indispensable at range>1. I'll leave it for him to explain if there's interest (both here and on his end), but on a very-basic level -- not showing bindings/mappings or modification of non-center cells or anything -- it could look like this:

Code: Select all

*  *  1  *  *
*  1  0  1  *
1  0  a  0  1  ->  3
*  1  0  1  *
*  *  1  *  *
| a = {3, 4, 5}
Consider also Saka's proposal if the whitespace is too much.

wwei23

Re: Golly suggestions

Post by wwei23 » November 11th, 2018, 4:50 pm

We could order the terms like so:

Code: Select all

1  2  3  4  5
6  7  8  9  10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25

M. I. Wright
Posts: 372
Joined: June 13th, 2015, 12:04 pm

Re: Golly suggestions

Post by M. I. Wright » November 11th, 2018, 10:12 pm

If you're talking about flattening a range-2 neighborhood into a one-dimensional transition, as is done currently with range 1, then of course we could do it that way (although I'd hope that the center cell would be 0 rather than 13, because the input cellstate shouldn't be in the middle). Half of the point of my post, though, was that it's wholly impractical to do this at range>1 -- it'd help immensely to put a 2D system into place instead.

User avatar
Extrementhusiast
Posts: 1966
Joined: June 16th, 2009, 11:24 pm
Location: USA

Re: Golly suggestions

Post by Extrementhusiast » November 13th, 2018, 1:00 am

While we're talking about rule tables, an easier suggestion could be to add compatibility with an optional extra argument at the end of each row to specify that this row has a different symmetry than the one listed at the top of the file (which would become the default symmetry to use if a row lacks this extra argument, for compatibility with older versions of rule tables). I've lost count of how many times I've used rule tables to look for a specific set of consecutive non-totalistic births/deaths/etc., forcing me to use twenty-seven different transitions with rotate4reflect symmetry, instead of just four (or even three) transitions with permute symmetry, and then multiplying this discrepancy by very roughly around half the number of states (e.g. different colors of marking: no need to distinguish between on/off states any more than they already are).
I Like My Heisenburps! (and others)

M. I. Wright
Posts: 372
Joined: June 13th, 2015, 12:04 pm

Re: Golly suggestions

Post by M. I. Wright » November 13th, 2018, 3:05 am

Plugging: Nutshell, which is usable if you're able to install Python 3.6 or higher, has that feature.

It's a somewhat-clunky operation in the back end, though. I do it by expanding transitions into "symmetries: none" and then recompressing into Golly's most-expressive symmetry type encompassing of all requested symmetries... and that in turn is implemented as a strange abuse of hashing + Python's set datatype, and it works, but I'm not sure if it's too high-level a thing for Golly's format to implement.

User avatar
toroidalet
Posts: 1514
Joined: August 7th, 2016, 1:48 pm
Location: My computer
Contact:

Re: Golly suggestions

Post by toroidalet » November 20th, 2018, 1:50 am

Can you please make future versions of Golly store all their layers (at least the initial generation) in a "backup" file?
It would help people from not losing patterns when Golly crashes or has to be quit, or other times such as when one must shut down their computer unexpectedly (this is the most notorious example)

By the way, "permute" symmetry doesn't need to expand to n! (or (n^2-1)! if n is the length of the square) transitions. The program can just count the total number of each state and look up the appropriate transition (also determined by counting).
Any sufficiently advanced software is indistinguishable from malice.

M. I. Wright
Posts: 372
Joined: June 13th, 2015, 12:04 pm

Re: Golly suggestions

Post by M. I. Wright » November 20th, 2018, 2:47 am

Of course! That's the obvious solution. However, as far as I can tell, (I don't quite understand everything in ruletable_algo.cpp but it seems on a rough level) Golly does not do that currently -- which is why I said that "LtL permutational symmetry will have to be cleverer".

Seconding the request for automatic saving; it would be nice to have an "autosave every X minutes" setting like in some text editors, along with a "recover previous session" File menu option.

Additionally, a very-long-term request: could some way perhaps be implemented to hook into rule-generator scripts, such as the bundled one that generates Langton's Ant ruletables, directly from the Set Rule... dialog? In the Discord I've made it so that the server bot, Caterer, accepts a rulestring suffixed by two colons then the name of a given rule-family: LLRR::langton, B3S23::genext, etc., and then invokes the accordingly-named ruletable-generator script with that rulestring. This definitely isn't trivial for Golly to do, but if implementable it would make some niche rulespaces a lot more accessible.

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

Re: Golly suggestions

Post by calcyman » November 20th, 2018, 8:50 am

toroidalet wrote:By the way, "permute" symmetry doesn't need to expand to n! (or (n^2-1)! if n is the length of the square) transitions. The program can just count the total number of each state and look up the appropriate transition (also determined by counting).
As I understand, Golly's 256-state algorithm uses a ruletree internally for speed, so the table needs to be converted into a tree upon loading.

Your suggestion would need a separate algorithm for the 'permute' symmetry that's completely different from the ordinary RuleLoader algorithm.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Golly suggestions

Post by muzik » December 3rd, 2018, 9:40 am

Can native support for isotropic non-totalistic hexagonal notation be added?

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Golly suggestions

Post by muzik » December 6th, 2018, 1:03 pm

...and on that topic, can the remaining apgsearchable rulespaces be supported?

While apgsearch supports higher-range outer-totalistic rules, the notation used for such rules isn't particularly intuitive or easy to understand. I propose that they be notated something like this:

B(birth conditions)/S(survival conditions)/R(n)

Since we can go above 9, we'd have to separate condition numbers using commas. I also propose that ranges could also be implemented to shorten rulestrings, as they could potentially become unwieldy and large. For example, these two would be synonymous:

B7,8,9,10,15,20/S8,9,10,11,12,22,23,24/R2

B7-10,15,20/S8-12,22-24/R2


Since BSFKL can be supported by ruletables, it might be helpful to include a generation script with the official scripts as well.

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

Re: Golly suggestions

Post by dani » December 6th, 2018, 3:17 pm

I feel like this could all be solved if there was some way to simulate things like ECA not through a script (which takes an insane amount of time to make Golly-friendly), but some sort of 'algorithm creator' in Golly. Then someone could make one for ECA, and BSFKL...and there wouldn't be any more rulespace suggestions to annoy Andrew with :p

User avatar
BlinkerSpawn
Posts: 1992
Joined: November 8th, 2014, 8:48 pm
Location: Getting a snacker from R-Bee's

Re: Golly suggestions

Post by BlinkerSpawn » December 24th, 2018, 10:08 am

Allow Golly to integrate .rule files by opening them instead of just through pasting?
LifeWiki: Like Wikipedia but with more spaceships. [citation needed]

Image

User avatar
Saka
Posts: 3627
Joined: June 19th, 2015, 8:50 pm
Location: Indonesia
Contact:

Re: Golly suggestions

Post by Saka » December 24th, 2018, 10:10 am

Speaking of rules, making the yellow area on the right display "search results" for the string in the rule name box

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Golly suggestions

Post by muzik » January 2nd, 2019, 3:42 pm

If higher-range outer-totalistic rules are implemented, can they be made to use white cells instead of yellow cells to better fit with range-1 rules?

M. I. Wright
Posts: 372
Joined: June 13th, 2015, 12:04 pm

Re: Golly suggestions

Post by M. I. Wright » January 4th, 2019, 2:14 pm

M. I. Wright wrote:Additionally, a very-long-term request: could some way perhaps be implemented to hook into rule-generator scripts, such as the bundled one that generates Langton's Ant ruletables, directly from the Set Rule... dialog? In the Discord I've made it so that the server bot, Caterer, accepts a rulestring suffixed by two colons then the name of a given rule-family: LLRR::langton, B3S23::genext, etc., and then invokes the accordingly-named ruletable-generator script with that rulestring. This definitely isn't trivial for Golly to do, but if implementable it would make some niche rulespaces a lot more accessible.
Fleshing this out:
  • The "Set Rule..." dialog either (a) has a separate field for "Rule Family" or (b) accepts a rulespace name after a delimiter in the main input box. The user additionally inputs a rulestring that's valid under this rulespace.
  • Golly finds the Lua or Python script registered under the rulespace's name.
    • The script defines a function for each rulefile section it supports: table(), tree(), icons(), etc., and Golly calls each of these functions in some desirable order to piece together the rulefile from them. Each function is passed the given rulestring, which it can either ignore or extract relevant info from. (Should a function return a string or an array of lines?)
    • Additionally, the script defines a rulename() function that takes a rulestring and returns the rule's rulespace-normalized name (as a string) for Golly to display.
    • I'm not sure that the script should be allowed to define rule() for the @RULE section, because I don't think these rulefiles should be stored permanently for human access (which is the main purpose of @RULE). I'm also not familiar with how Golly handles rulefile-parsing internally: if it needs all sections to be given at once and can't do them individually, the @RULE could be improvised from the return value of rulename(). (I'll have a look at ruletablealgo.cpp & related files later on)
  • The pieced-together rule is loaded and can then be used as normal. (Should recent rules be cached in case a script is slow to generate?)
I have no expectations right now, just throwing out this template. The Langton's Ant generator that comes with Golly could be converted to this format, for instance, and if implemented this would also answer the BSFKL part of danny's request above.

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

Re: Golly suggestions

Post by dvgrn » January 4th, 2019, 2:48 pm

M. I. Wright wrote:
  • Golly finds the Lua or Python script registered under the rulespace's name.
To make this idea just a little bit more ambitious: it seems as if the "registered scripts" for each rulespace wouldn't necessarily have to be installed with Golly.

It might work to have an online archive of rulespace scripts, such that if a request is made for a given rulespace and it's not found in Golly's local collection of rulespace scripts, Golly can go check the online archive and get a copy of the script if it finds a match.

Probably this would be a curated online archive, not just a place where anyone could upload any script they want -- just to keep the potential for malicious code down to a manageable level. (?).

Come to think of it, it's already possible to put ZIP files in the Online Archives that contain Lua scripts -- including an "installer" script that could drop a rulespace script into the right location for Golly to get hold of it. So maybe this online-archive idea doesn't really need much in the way of coding, except for figuring out the details of a Lua-script-based delivery system.

With that kind of setup the rulespace scripts could be updated independent of new Golly releases, just like the rest of the Online Archives (even though I never seem to manage to get around to actually doing that).

AforAmpere
Posts: 1334
Joined: July 1st, 2016, 3:58 pm

Re: Golly suggestions

Post by AforAmpere » January 4th, 2019, 2:52 pm

I think one thing that would be nice for that would be extended neighborhoods that you can define rulespaces for. After that, pretty much anything is possible.
I manage the 5S project, which collects all known spaceship speeds in Isotropic Non-totalistic rules. I also wrote EPE, a tool for searching in the INT rulespace.

Things to work on:
- Find (7,1)c/8 and 9c/10 ships in non-B0 INT.
- EPE improvements.

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

Re: Golly suggestions

Post by calcyman » January 4th, 2019, 5:13 pm

M. I. Wright wrote:Additionally, a very-long-term request: could some way perhaps be implemented to hook into rule-generator scripts, such as the bundled one that generates Langton's Ant ruletables, directly from the Set Rule... dialog? In the Discord I've made it so that the server bot, Caterer, accepts a rulestring suffixed by two colons then the name of a given rule-family: LLRR::langton, B3S23::genext, etc., and then invokes the accordingly-named ruletable-generator script with that rulestring. This definitely isn't trivial for Golly to do, but if implementable it would make some niche rulespaces a lot more accessible.
Another idea, instead of having the rulespace be explicit, is to have an implicit pattern-matching. The way lifelib handles it is to have a list of regular expressions, and the rulespace is the first one to match the rulestring (similar to how ruletables work, with special cases at the top and general cases at the bottom):

https://gitlab.com/apgoucher/lifelib/bl ... nuslist.py

This file is also downloaded and parsed by Catagolue to generate the new pages of rules:

https://catagolue.appspot.com/rules
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
77topaz
Posts: 1496
Joined: January 12th, 2018, 9:19 pm

Re: Golly suggestions

Post by 77topaz » January 8th, 2019, 11:29 pm

The program Square Cell is in general a lot more difficult to work with than Golly, but it does support a range of neighbourhoods and Generations-like mechanics. So my suggestions would be to implement these rulespaces into Golly (SC is open-source, which should make it easier), so that the un-user-friendly interface of SC is no longer needed.

User avatar
muzik
Posts: 5612
Joined: January 28th, 2016, 2:47 pm
Location: Scotland

Re: Golly suggestions

Post by muzik » January 10th, 2019, 7:54 pm

Since LifeViewer has faced such changes as of recently I felt it would make sense to suggest that the colourings of rulespaces should be standardised;

- All two-state rules (i.e. QuickLife and HashLife-runnable rules, Larger than Life rules with two states specified, 2-state HROT rules (if implemented), and possibly Generations rules with 2 states) should use the default white-on-gray colour scheme;

- Rules with more than two states (Generations, LtL Generations, and ruletables without specified colours) should use a yellow-to-red colour scheme instead of a red-to-yellow colour scheme, since it's easier to see on the darker background.

Of course, it's possible to manually adjust them to be these in the settings, but having these be the default options would help things be more consistent overall.

Post Reply