apgsearch v2.2

[dvgrn]

I would be happy to work with you to clean those up and get a script checked into Golly, but I think there's one aspect which still needs deciding on, and that is a canonical form for the representation - to avoid having multiple rule files representing the same rule.

However, I think native support in Golly would be a better option.

Not sure about the canonical form yet. Maybe just alphabetize the letters in each clause, and pick the positive or negative representation according to which one uses the fewest letters? If there's a tie, then go for the fewest characters, so a B3aceik clause would be preferable to B3-njqry. I'd recommend including the B and S prefixes for clarity, but the "/" could be dropped when necessary, same as with other RuleLoader rule names.

Looks like native support for Hensel-format rules might not be an unreasonable goal. Here's Tom Rokicki's response on golly-test, with ideas along the same lines about canonical form.

Maybe the right next step would be to post here and/or to the golly-test list, a revised "neighbors2" version of EricG's script (or back-port the relevant pieces from apgsearch-isotropic-v0.2.py?) Sounds like that would give Tom the starting point he asks for. We should double-check some tlife and Just Friends patterns and so on, and as many RLE patterns in Hensel's standard neighbors2-notation as we can get our hands on, to make sure the script is really building the rule tables that it's supposed to build.

[wildmyron]

Maybe the right next step would be to post here and/or to the golly-test list, a revised "neighbors2" version of EricG's script (or back-port the relevant pieces from apgsearch-isotropic-v0.2.py?) Sounds like that would give Tom the starting point he asks for. We should double-check some tlife and Just Friends patterns and so on, and as many RLE patterns in Hensel's standard neighbors2-notation as we can get our hands on, to make sure the script is really building the rule tables that it's supposed to build.

I'll post a standalone form of the rule generator over the next couple of days.

I'm not sure about alphabetizing the neighbourhoods, but minimizing the number of required letters makes sense. I think the rule generator currently uses the row order in the neighbours2.html table to order the letters, but I have to refresh my memory on that. Also, it currently uses '_' in place of '/' for obvious filesystem related reasons. In terms of consistency with the existing rule naming schemes in Golly, the use of '-' as a modifier doesn't have a precedent but if Tom's fine with it I'll start from there. The ambiguity between neighbourhood 'h' and 'H' for hexagonal neighbourhoods is unfortunate, as is the ambiguity between 'c' and 'C' for history states in generations. I suppose that will be mostly resolved with the use of a prefix to indicate the rule family (and which algorithm Golly should use). I'm not sure about using 'N' for that purpose as non-totalistic is a much broader rule space. Something which indicates the isotropic property of the rule space, and perhaps that it is restricted to the Moore neighbourhood.

Feel free to repost to golly-test and apologies for going off-topic. I'll post the script somewhere more appropriate.

[dvgrn]

I'll post a standalone form of the rule generator over the next couple of days.

I'm not sure about alphabetizing the neighbourhoods, but minimizing the number of required letters makes sense. I think the rule generator currently uses the row order in the neighbours2.html table to order the letters, but I have to refresh my memory on that.

Thanks! I suppose any defined order is fine, and the table certainly works as a canonical order.

The ambiguity between neighbourhood 'h' and 'H' for hexagonal neighbourhoods is unfortunate, as is the ambiguity between 'c' and 'C' for history states in generations.

Ow, the "C" ambiguity with Generations is a bad one -- if you take out the slashes and ignore case, you can't tell B3/S2c3 from B3/S2/C3. On the other hand, Golly doesn't support the B/S/C form of Generations rules anyway. And maybe we don't have to ignore case. Hensel's format definitely has a lowercase 'c' by tradition, whereas the usual Generations 'C' is uppercase.

There isn't actually an h/H ambiguity if we're using the "neighbors2" table definition, is there?

I'm not sure about using 'N' for that purpose as non-totalistic is a much broader rule space. Something which indicates the isotropic property of the rule space, and perhaps that it is restricted to the Moore neighbourhood.

Good point... I'd rather not get stuck with a capital letter I as an identifier, though, due to possible confusion with 1's and lowercase L's.

"NI"? "NTI"? "ISO"? "Hensel:"? "isotropic"? None of them seem quite as nice as a simple "N"... but, well, once some arbitrary decision gets implemented, I think it won't be too difficult to live with it.

EDIT: Either I haven't read everything carefully enough yet, or there's an unmentioned wrinkle: Life32's version of the Neighbors2.html table also uses v instead of n, for some reason that I haven't dug up yet. This is in addition to the bug with y and r being swapped in the actual Life32 code but not in the Help file. [This was mentioned in wildmyron's post, but I missed it.] Will have to hunt around for any non-totalistic pattern archives out there besides Emmanuel Sapin's, that use that Life32 format. Links, anyone?

With some minor pain and suffering, I've extracted the relevant part of Life32.HLP, in case anyone wants to see it:

Table from Life32 v2.16 Help file (The just friends rule implemented)

Non-totalistic-Life32.png (24.2 KiB) Viewed 15833 times

Alan Hensel's Non-totalistic rules extensions

Why non-totalistic, what is it?
'Normal' rules only count the number of neighbors a cell has. Placement of the neighbors is not taken into account.
This is the simplest kind of rule and they are called "totalistic" rules.
However some popular rules DO take the placement of neighbors into account.

Again there is a simple way to take placement into account and a hard way.

The simple way is fully symmetrical (i.e. does not see left, right, up or down as different). The hard way is not symmetrical and thus see left and right as different.

The hard way might have patterns only moving left, or up. This is a bit limiting and thus far nobody has found a real use for this.

The simple way is called non-totalistic and is used for a few popular rules, most notably the "Just Friends" rule.

The "Just Friends" rule states: Survival and 1 and 2 neighbors, Birth on 2 neighbors, if they are not adjacent.
Without the "if" part the patterns would keep expanding due to overpopulation, with the "if" part limiting growth we've got an interesting rule.

How does it work?
The non-totalistic extensions implement the "if" parts mentioned above.
Below is a graphical representation of all the options.
0 and 8 neighbors don't have room for an "if" part, there is only one way to stuff 0 or 8 cells in an 8-cell space.

1 and 7 neighbors haven't got much room for choice either, only 2 options.
With 4 neighbors there are 13 different "if's" to state that are symmetrical.
Each "if" has got it's own letter. Note that the "if" with 1 neighbor need not be all that related to the same labeled "if" with 4 neighbors; however Alan has tried to put similar conditions together.

The letters used are mnemonic; most are based on the shape of a certain orientation of the condition. However the first 4 have a definitive meaning:

c = corners.
e = edges (if you keep neighbors <= 4 and add "e" to all numbers, you effectively have "Von Neumann" space).
k = knight move (as in chess)
a = adjacent

The letters are entered after the number (of neighbors) they apply to. If all letters apply except one, a "-" sign is used to 'rule out' the missing letter.

Because "Just Friends" only has births on not-adjacent neighbors, "-a" is entered after the "B2".

The graphical representation only shows one possible orientation, in reality all rotations/mirror images of that orientation also apply.

[praosylen]

I'm very sorry, but @Calcyman can you move the tlife and klife hauls I submitted to b3s2-i34q and b34vs23 (or if not, just delete them)? I made a last-minute change to the format I want rules to be submitted in for my new apgsearch variant.

[drc]

I'm very sorry, but @Calcyman can you move the tlife and klife hauls I submitted to b3s2-i34q and b34vs23 (or if not, just delete them)? I made a last-minute change to the format I want rules to be submitted in for my new apgsearch variant.

V? It's N, so B34nS23.

[praosylen]

I'm very sorry, but @Calcyman can you move the tlife and klife hauls I submitted to b3s2-i34q and b34vs23 (or if not, just delete them)? I made a last-minute change to the format I want rules to be submitted in for my new apgsearch variant.

V? It's N, so B34nS23.

Sorry, my bad. I incidentally just found the same thing myself.

[drc]

The pictures are all weird now with tlife

[Saka]

http://catagolue.appspot.com/census/b3s2-i34q/C1/xq4 The glider...

[calcyman]

The pictures are all weird now with tlife

That's a frontend issue, and one I intend to resolve in a few days' time.

[Saka]

Actually, come to think of it, WHY are the SVG's broken and all wierd? (For non-totalistic rules)

[Saka]

Why is the ant SVG on tlife just fine?

[praosylen]

Actually, come to think of it, WHY are the SVG's broken and all wierd? (For non-totalistic rules)

Catagolue's rule-parsing algorithm filters out all of the non-totalistic notation in the rulenames, so in tlife, for example, it filters b3s2-i34q to b3s234. Then, it generates the SVG's using the filtered rulename, and the SVG's are actually those for the pattern in some other rule.

Why is the ant SVG on tlife just fine?

In this case, the ant works both in tlife and B3/S234, so it generates the correct SVG.

[Saka]

Actually, come to think of it, WHY are the SVG's broken and all wierd? (For non-totalistic rules)

Catagolue's rule-parsing algorithm filters out all of the non-totalistic notation in the rulenames, so in tlife, for example, it filters b3s2-i34q to b3s234. Then, it generates the SVG's using the filtered rulename, and the SVG's are actually those for the pattern in some other rule.

Why is the ant SVG on tlife just fine?

In this case, the ant works both in tlife and B3/S234, so it generates the correct SVG.

So basically, that mean catagolue has to add support for Hensel notation to fix the problem, right?

[calcyman]

So basically, that mean catagolue has to add support for Hensel notation to fix the problem, right?

Precisely. It's on my to-do list, buried beneath mountains of other things.

[Apple Bottom]

Precisely. It's on my to-do list, buried beneath mountains of other things.

This reminds me, I've been meaning to ask -- since the client code's on Gitlab, is the server-side code available anywhere as well? (Might be worth it so people can submit patches and scratch their own itches.)

[calcyman]

since the client code's on Gitlab, is the server-side code available anywhere as well?

No. It's not even under any form of version control whatsoever.

[drc]

Can you rename the haul for "B2iv3S123a" to "B2in3S123a

[Apple Bottom]

It's on my to-do list, buried beneath mountains of other things.

If I may, here's another for your to-do list, if it ain't on there already: it would be mighty useful if it were possible to get an object in RLE form.

Could be as simple as a link that gives you the right code as text (like the sample soups), auto-generated from the object's extended Wechsler code.

This would make it much easier to paste objects into Golly, these here forums, and so on.

[simeks]

There are currently 221 occurrences of the canonical eater 2 (xs19_4aar0rbzx121) in b3s23/C1 in Catagolue, but only the first 199 of the soups that generated these are accessible on the object page.

Given the importance of eater 2 seeds in current self-constructing circuitry, is there a way to access the soups of the remaining eater 2:s, and any new ones that will appear?

[dvgrn]

I'll post a standalone form of the rule generator over the next couple of days...
Feel free to repost to golly-test and apologies for going off-topic. I'll post the script somewhere more appropriate.

The stand-alone script didn't seem to appear anywhere, and I was all set to be terribly disappointed that I would have to do some actual thinking, to resolve tricky discrepancies between the neighbors.html, neighbors2.html, and Life32 versions of the non-totalistic rule format.

Then a quick inspection of isotropic-rule.py revealed that all the hard work was already done (as far as I can see). Have posted a standalone script in response to a request from Saka on the Rule Request thread.

[The apgsearch-isotropic script uses straight neighbors2.html format, right? -- not the Emmanuel Sapin/Life32-bug variant with the meanings of 'r' and 'y' swapped? It definitely uses 'n' and not 'v', so that's a good sign. I did spot-check 3r and 3y and they seemed okay, but I don't do much with non-totalistic rules and get confused easily, so I could still be wrong...!]

As wildmyron suggests, I think future discussion of non-totalistic rule format and the script can move to the Rule Requests thread now (or somewhere else). To get this thread back on topic, I'll re-ask simeks' question from a couple of days ago:

Given the importance of eater 2 seeds in current self-constructing circuitry, is there a way to access the soups of the remaining eater 2:s, and any new ones that will appear?

[calcyman]

Given the importance of eater 2 seeds in current self-constructing circuitry, is there a way to access the soups of the remaining eater 2:s

No.

and any new ones that will appear?

Yes, I've now upped the limit so that objects from C1 soups will be added if there are fewer than 500 occurrences so far (as opposed to 200).

[Saka]

I. have just. noticed.
SVGs are fixed!!! WHOOOOOOOOO!!!

OMG OMG OMG

[drc]

I. have just. noticed.
SVGs are fixed!!! WHOOOOOOOOO!!!

OMG OMG OMG

Also, you should probably update to the latest apgsearch, cause you submitted 3 hauls with incorrect names

[calcyman]

I. have just. noticed.
SVGs are fixed!!! WHOOOOOOOOO!!!

OMG OMG OMG

How on Earth did you manage to post that within 5 minutes of me applying the patch?

It doesn't work consistently for one of your rules, which contains the completely unrecognised letter 'v':

https://catagolue.appspot.com/haul/b34a ... df05c7ed6d

The transition table I'm using is:

Code: Select all

lord += "_ceaccaieaeaknja_ceaccaieaeaknjaekejanaairerririekejanaairerriri";
lord += "ccknncqnaijaqnwaccknncqnaijaqnwakykkqyqjrtjnzrqakykkqyqjrtjnzrqa";
lord += "ekirkyrtejerkkjnekirkyrtejerkkjnekejjkrnejecjyccekejjkrnejecjycc";
lord += "anriqyzraariqjqaanriqyzraariqjqajkjywkqkrnccqkncjkjywkqkrnccqknc";
lord += "cnkqccnnkqkqyykjcnkqccnnkqkqyykjaqjwinaarzjqtrnaaqjwinaarzjqtrna";
lord += "ccyyccyennkjyekeccyyccyennkjyekenykknejeirykrikenykknejeirykrike";
lord += "aqrznyirjwjqkkykaqrznyirjwjqkkykaqrqajiarqcnnkccaqrqajiarqcnnkcc";
lord += "intrneriaanajekeintrneriaanajekeajnkaeaeiaccaec_ajnkaeaeiaccaec_";

which is a 512-character string which maps 3-by-3 binary images to the equivalent Hensel letter. (There are underscores for 0, 16, 495 and 511 since these correspond to situations with 0 or 8 live neighbours.) I generated it algorithmically using a Mathematica program which reads the images on neighbours2.html, and I notice that the image names don't correspond exactly to the proper notation, so there was a small amount of messing around involved.

[Saka]

I. have just. noticed.
SVGs are fixed!!! WHOOOOOOOOO!!!

O-M-g-o-s-h O-M-g-o-s-h O-M-g-o-s-h

How on Earth did you manage to post that within 5 minutes of me applying the patch?

Doing homework at night