Page 5 of 6

Re: Golly suggestions

PostPosted: October 10th, 2018, 9:34 pm
by KittyTac
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.

Re: Golly suggestions

PostPosted: October 11th, 2018, 3:54 am
by Redstoneboi
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.

Re: Golly suggestions

PostPosted: October 22nd, 2018, 3:32 am
by KittyTac
What about making random fills obey the paste modes?

Re: Golly suggestions

PostPosted: November 11th, 2018, 10:31 am
by gameoflifemaniac
Please add LTL rule tables in Golly 3.3!
Or 3.4.

Re: Golly suggestions

PostPosted: November 11th, 2018, 2:51 pm
by wwei23
Please keep betas available.
I don't have much else to say.

Re: Golly suggestions

PostPosted: November 11th, 2018, 4:17 pm
by M. I. Wright
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:
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:
*  *  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.

Re: Golly suggestions

PostPosted: November 11th, 2018, 4:50 pm
by wwei23
We could order the terms like so:
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

Re: Golly suggestions

PostPosted: November 11th, 2018, 10:12 pm
by M. I. Wright
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.

Re: Golly suggestions

PostPosted: November 13th, 2018, 1:00 am
by Extrementhusiast
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).

Re: Golly suggestions

PostPosted: November 13th, 2018, 3:05 am
by M. I. Wright
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.

Re: Golly suggestions

PostPosted: November 20th, 2018, 1:50 am
by toroidalet
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).

Re: Golly suggestions

PostPosted: November 20th, 2018, 2:47 am
by M. I. Wright
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.

Re: Golly suggestions

PostPosted: November 20th, 2018, 8:50 am
by calcyman
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.

Re: Golly suggestions

PostPosted: December 3rd, 2018, 9:40 am
by muzik
Can native support for isotropic non-totalistic hexagonal notation be added?

Re: Golly suggestions

PostPosted: December 6th, 2018, 1:03 pm
by muzik
...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.

Re: Golly suggestions

PostPosted: December 6th, 2018, 3:17 pm
by danny
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

Re: Golly suggestions

PostPosted: December 24th, 2018, 10:08 am
by BlinkerSpawn
Allow Golly to integrate .rule files by opening them instead of just through pasting?

Re: Golly suggestions

PostPosted: December 24th, 2018, 10:10 am
by Saka
Speaking of rules, making the yellow area on the right display "search results" for the string in the rule name box

Re: Golly suggestions

PostPosted: January 2nd, 2019, 3:42 pm
by muzik
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?

Re: Golly suggestions

PostPosted: January 4th, 2019, 2:14 pm
by M. I. Wright
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.

Re: Golly suggestions

PostPosted: January 4th, 2019, 2:48 pm
by dvgrn
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).

Re: Golly suggestions

PostPosted: January 4th, 2019, 2:52 pm
by AforAmpere
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.

Re: Golly suggestions

PostPosted: January 4th, 2019, 5:13 pm
by calcyman
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/blob/master/genera/genuslist.py

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

https://catagolue.appspot.com/rules

Re: Golly suggestions

PostPosted: January 8th, 2019, 11:29 pm
by 77topaz
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.

Re: Golly suggestions

PostPosted: January 10th, 2019, 7:54 pm
by muzik
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.