ConwayLife.com

Now, I don't want to overwhelm Andrew, but I have had some ideas (plus things I've seen floating around) that I think may be worthy to add to Golly (which, by the way, is my favorite CA program). If anyone else wants to contribute to the list, feel free.

Additions to the Rule Table format
-Margolus neighborhood support
-Mathematical functions
-Ability to designate a bound or unbound variable
-Hexagonal lattice support

Additions to Golly
-Support for Torus or Klein Bottle
-Multiple rows of states for many-state rules

Some of what you ask for can be done with a script called make-ruletree.py which allows you to include functions in Python to describe your new CA rules. I have tried it, and it is quite nice to use Python statements instead of creating a complex ruletable. Try the example that Andrew posted here. It is in the "Hexagonal life" thread under "General Discussion".

Yeah, I put Hexagonal neighborhood last for that reason. However, emulated Margolus neighborhood rules are very annoying to use.

Is there any way to define rules for Moore/vonNeumann neighborhoods with a range higher than 1?

(as in http://mathworld.wolfram.com/MooreNeighborhood.html)

Is there any way to define rules for Moore/vonNeumann neighborhoods with a range higher than 1?

Not directly, but adding extra states can emulate large-neighbourhood rules.

An update on where we are with Golly now:

Axaj:
Rule Table Format:

- Margolus neighborhood: there's emulateMargolus.py in Golly 2.1. (This script will be replaced by RuleTableToTree.py in 2.2 and later, see recent post on golly-test mailing list, and here:
http://code.google.com/p/ruletablerepos ... ki/RoadMap )
- Nested variables: do you mean e.g. var a={0,1,2} var b={a,3,4} ? Golly 2.2 and later support this, again see a recent post.
- Mathematical functions: make-ruletree.py now supports this, as mentioned.
- Bound/unbound vars: we still only support bound variables. The best place to discuss this is here:
http://code.google.com/p/ruletablerepos ... dVariables
- Hexagonal neighborhood: now supported via RuleTableToTree.py in 2.2 and later.

Golly:

- Torus/Klein bottle: Yes, wraparound has been on the TODO list for a while.
- Multiple rows of states: You mean in the status bar? Yes, good idea. I'll put it on the TODO list.

Axaj: "emulated Margolus neighborhood rules are very annoying to use"

Could you give more details, so we can think of a way to improve it? Calling RuleTableToTree.py (or EmulateMargolus.py) is a slightly annoying step to have to do, but the alternative has Golly load Margolus rule tables automatically, and there's a problem with that approach as discussed here:
https://sourceforge.net/mailarchive/for ... golly-test
The emulation approach itself is also annoying of course (because the user needs export.py and import.py in order to make changes) but that's unavoidable as far as I can see, unless we had Golly support Margolus natively (isn't going to happen unless we come up with lots of amazing rules for it).

ebcube: "Is there any way to define rules for Moore/vonNeumann neighborhoods with a range higher than 1?"

You can *define* them... :) See Moore_radius2 here:
http://code.google.com/p/ruletablerepos ... ki/RoadMap
I had a look at emulating Moore_radius2 by splitting each cell into 4, as mentioned by calcyman. It needs of course N^4 states for an N-state CA: 2 -> 16, 3 -> 81, 4 -> 256. And that causes difficulty in producing a complete rule tree: traversing the whole input space even for N=2 is costly. Converting rule table transitions to a rule tree the quick way (as in RuleTableToTree) is also problematic: a Moore_radius2 CA with permute symmetry (as is usually wanted) means that there are *many* different rule combinations to consider. To see what I mean, compare with the square-splitting code in EmulateTriangular.py here:
http://golly.cvs.sourceforge.net/viewvc ... iew=markup
Some rare rules might be possible to support through emulation but in general I don't think it's going to work very well.
Another possibility is to extend ruletable_algo to support the emulation scheme for permute symmetry only but I'm loath to do this (for the moment at least) because it would be a hack and would cause the same problems as would supporting Margolus emulation natively, as linked above.
We could make another algorithm to support certain rule definitions, e.g. Bugs="R5,C0,M1,S34..58,B34..45,NM", as in MCell. But again it would have to use the emulation approach and so in fact Bugs isn't possible because it's got range 5.
So realistically I think Moore_radius2 and higher will have to wait until Golly's hashlife supports them natively. And the only way *that* can currently happen is if we come up with a pressing need for it and then pester Tom Rokicki enough. :) Some CA I'd love to see implemented include the larger-range ones here:
http://psoup.math.wisc.edu/mcell/rullex_cycl.html
and here:
http://psoup.math.wisc.edu/mcell/rullex_lgtl.html (in particular the work of Kellie Michele Evans)
Any more examples we can add to make the case stronger?

Tim

Tim Hutton wrote:- Margolus neighborhood: there's emulateMargolus.py in Golly 2.1. (This script will be replaced by RuleTableToTree.py in 2.2 and later, see recent post on golly-test mailing list, and here:
http://code.google.com/p/ruletablerepos ... ki/RoadMap )

[s]So is it going to be native support or emulated in the Moore neighborhood.[/s] Scratch that, I saw the post.

- Nested variables: do you mean e.g. var a={0,1,2} var b={a,3,4} ? Golly 2.2 and later support this, again see a recent post.

Yes, that's what I mean. Unfortunately, I have yet to see any trace of 2.2. And can you link me to that post?

- Mathematical functions: make-ruletree.py now supports this, as mentioned.

Mentioned where?

- Bound/unbound vars: we still only support bound variables. The best place to discuss this is here:
http://code.google.com/p/ruletablerepos ... dVariables

Alright, I'll be checking there.

- Hexagonal neighborhood: now supported via RuleTableToTree.py in 2.2 and later.

[s]On a hexagonal lattice, or emulated on a square lattice?[/s] Scratch that, I saw the post.

- Torus/Klein bottle: Yes, wraparound has been on the TODO list for a while.
- Multiple rows of states: You mean in the status bar? Yes, good idea. I'll put it on the TODO list.

Alright, I've got that cleared up now.

Axaj: "emulated Margolus neighborhood rules are very annoying to use"

Could you give more details, so we can think of a way to improve it? Calling RuleTableToTree.py (or EmulateMargolus.py) is a slightly annoying step to have to do, but the alternative has Golly load Margolus rule tables automatically, and there's a problem with that approach as discussed here:
https://sourceforge.net/mailarchive/for ... golly-test
The emulation approach itself is also annoying of course (because the user needs export.py and import.py in order to make changes) but that's unavoidable as far as I can see, unless we had Golly support Margolus natively (isn't going to happen unless we come up with lots of amazing rules for it).

The annoying thing I find is that it is hard to edit patterns with the emulated rules.

ebcube: "Is there any way to define rules for Moore/vonNeumann neighborhoods with a range higher than 1?"

You can *define* them... See Moore_radius2 here:
http://code.google.com/p/ruletablerepos ... ki/RoadMap
I had a look at emulating Moore_radius2 by splitting each cell into 4, as mentioned by calcyman. It needs of course N^4 states for an N-state CA: 2 -> 16, 3 -> 81, 4 -> 256. And that causes difficulty in producing a complete rule tree: traversing the whole input space even for N=2 is costly. Converting rule table transitions to a rule tree the quick way (as in RuleTableToTree) is also problematic: a Moore_radius2 CA with permute symmetry (as is usually wanted) means that there are *many* different rule combinations to consider. To see what I mean, compare with the square-splitting code in EmulateTriangular.py here:
http://golly.cvs.sourceforge.net/viewvc ... iew=markup
Some rare rules might be possible to support through emulation but in general I don't think it's going to work very well.
Another possibility is to extend ruletable_algo to support the emulation scheme for permute symmetry only but I'm loath to do this (for the moment at least) because it would be a hack and would cause the same problems as would supporting Margolus emulation natively, as linked above.
We could make another algorithm to support certain rule definitions, e.g. Bugs="R5,C0,M1,S34..58,B34..45,NM", as in MCell. But again it would have to use the emulation approach and so in fact Bugs isn't possible because it's got range 5.
So realistically I think Moore_radius2 and higher will have to wait until Golly's hashlife supports them natively. And the only way *that* can currently happen is if we come up with a pressing need for it and then pester Tom Rokicki enough. Some CA I'd love to see implemented include the larger-range ones here:
http://psoup.math.wisc.edu/mcell/rullex_cycl.html
and here:
http://psoup.math.wisc.edu/mcell/rullex_lgtl.html (in particular the work of Kellie Michele Evans)
Any more examples we can add to make the case stronger?

Tim

I think if MCell has >1 ranges, so should Golly.

Axaj wrote:

- Nested variables: do you mean e.g. var a={0,1,2} var b={a,3,4} ? Golly 2.2 and later support this, again see a recent post.

Yes, that's what I mean. Unfortunately, I have yet to see any trace of 2.2. And can you link me to that post?

Golly 2.2 should be coming out in a couple of months. Until then you can build it yourself from the source code:
https://sourceforge.net/scm/?type=cvs&group_id=139354

Here's the post where we discussed nested variables:
https://sourceforge.net/mailarchive/for ... golly-test

Axaj wrote:

- Mathematical functions: make-ruletree.py now supports this, as mentioned.

Mentioned where?

knightlife mentioned it earlier in this thread.

Alright, thanks for clearing this up.

Noticed a glitch: In QuickLife and HashLife (and maybe other modes, I haven't tried), the paste selection (in the red frame before specifying a location) does not flip colors if the rest of the board is flipped in color.

You need a simple Weighted Life format, like MCell has. And, maybe, Larger Than Life format?

One little thing I'd love, is for Golly to SHUT UP. I'm so tired of it beeping every time I zoom in and can't go further, even though I know I couldn't of and didn't intend to. Or when I click the screen when it is zoomed out too much to draw. Really, I don't mind being told that I can't zoom in further, but the beeping is just awful.

That. It would also be nice if it didn't show a million consecutive message boxes when you try to load an invalid ruletable file. Put all the errors in one box. And don't irreversibly erase the pattern when that happens.

One little thing I'd love, is for Golly to SHUT UP.

One solution is to simply disconnect the speakers.

calcyman wrote:

One little thing I'd love, is for Golly to SHUT UP.

One solution is to simply disconnect the speakers.

I.e. no listening to music (on the PC) while doing stuff with Golly.

My Golly makes no noise (version 2.1 in Linux).

Geez, do I need to be any more specific?
On windows, and while listening to music, the unnecessary beeping that golly does is very annoying.
Is there really a need for denial that this happens, or suggestions that I probably would've done already unless I was stupid?
Thanks.

What I'd most like to see in Golly is multi-threading. Could the hashlife algorithm be modified to be threaded?

Could the hashlife algorithm be modified to be threaded?

That's what Tom Rokicki is working on at the moment.

calcyman wrote:That's what Tom Rokicki is working on at the moment.

Nice. I hope it's also possible to make other algorithms (Quicklife, Generations etc.) threaded.

Nice. I hope it's also possible to make other algorithms (Quicklife, Generations etc.) threaded.

JvN, RuleTable, RuleTree and Generations are all HashLife algorithms, so the same principles apply. QuickLife is similar to the algorithm used in Life32, and should be easier than HashLife to parallelise.

One thing I'd like to see would be the option of making a random soup. It might already be in there, but I haven't found it, so just like a "random soup" button in the control menu would be nice.

There's a 'random fill', which fills the selection randomly at a predetermined density.

Oh, I didn't know that! Thanks!

I think it would be cool to have a Census functiuon, like WinLife32 has.
Golly is better than MCell or WinLife32, but I have to keep all 3 because of these 'unique' featues of them.