Page 1 of 1

The Minimal Cost of Glider Syntheses for Various Objects

Posted: February 3rd, 2015, 7:27 pm
by Freywa
To be honest, I started the Synthesis Spring which found constructions for all 17-bit and fewer still lifes. But Niemiec's site is down and I haven't seen any reports of its replacement. Pentadecathlon is very outdated and possibly broken. The literature on glider syntheses is scattered across countless and sometimes inaccessible realms, each as challenging to interpret as Linear B hieroglyphs.

We need a common, stable and current database for such syntheses. I can provide the hosting if no-one else is willing.

Re: The Minimal Cost of Glider Syntheses for Various Objects

Posted: February 3rd, 2015, 7:44 pm
by Sokwe
Freywa wrote:all 17-bit and fewer still lifes.
It's all 18-bit or fewer still lifes now (see here).

I think that Mark Niemiec was working on an updated database, but I haven't heard anything about it recently. For the vast majority of still lifes, I think Mark is the only one who has recorded syntheses, so anyone wanting to start a glider synthesis database should start by asking him. In the mean time, It might be good to collect together all of the recent "small" syntheses from the soup search and 4-glider syntheses topics.

Finally, Mark's old online database can (mostly) be viewed via the internet archive here.

Re: The Minimal Cost of Glider Syntheses for Various Objects

Posted: February 3rd, 2015, 8:27 pm
by Freywa
Which actually gives us two directions we can work on.

First of all, we need a more precise nomenclature for still lifes than Niemiec's rather subjective component-oriented terms. Take the cis- and trans-boat with tail:

Code: Select all

x = 11, y = 5, rule = B3/S23
3bo5b2o$2bobo3bobo$bob2o2bobo$bo5bo$2o4b2o!
It is not immediately clear that the left one is cis – the classification depends on the single bit on the boat that differentiates it from a tub. I have sketches of another naming system based on real IUPAC chemical nomenclature (I am studying organic chemistry in NUS High School now, alongside maths and other stuff), so the cis "isomer" would be 2-tail boat and the trans "isomer" 3-tail boat (these based on the valid diagonal connection points along the boat, 1 being the bow end). The crux of the idea is that the transitions within Life severely restrict the possible structures that form. I have not yet fully considered the nuances of still lifes and the overall project is still in its infancy but we should begin from here.

The second problem is how to efficiently encode glider syntheses. Owing to their (often) modular nature this should be easier; we can simply open up a coordinate system and define gliders relative to this grid and their timing.

Re: The Minimal Cost of Glider Syntheses for Various Objects

Posted: February 4th, 2015, 1:24 pm
by dvgrn
Freywa wrote:We need a common, stable and current database for such syntheses. I can provide the hosting if no-one else is willing.
Did you see the last progress report on 'Catagolue'? My guess is that this will actually come online at some point -- I would say "soon", but one must take Hofstadter's Law into account.
Freywa wrote:...we need a more precise nomenclature for still lifes than Niemiec's rather subjective component-oriented terms.
It may also be worth resisting the temptation to tackle the naming problem. At the very least, I'd recommend a careful reading of the results of analogous reform efforts first.

The basic problem is twofold.

One, Life enthusiasts are a notoriously independent-minded and often rather stubborn bunch. Suppose you publish a beautifully consistent naming system with no possibility of confusion or ambiguity. Then you start patrolling the forum threads, saying things like, "don't call that a cis-boat with tail -- it's a 2-tail boat now!". Many people won't even hear about about your new system, and most of the rest won't pay any attention, not being inclined to learn how to apply the proper chemical analogies. So they'll keep using the old familiar perfectly good name, figuring that if you can't remember which is cis and which is trans, it's easy enough to look at the pictures. It would take years of common usage by dozens of people before it would even make sense to add "2-tail boat" as an alternate name on the LifeWiki... and you'd have to get past all those otherwise reasonable people who'd insist that "2-tail boat" should be reserved for 6bo$4b3o$3bo$2bobo$bob2o$bo$2o!

Two, any possible structure-based naming system will eventually turn out to be ambiguous. Even IUPAC chemical nomenclature is not immune from this problem. Most complex still lifes can be decomposed in lots of different ways, and "preferred name" rules would quickly have to become so complex as to be nearly impossible to remember and apply correctly. Even an eater is a preblock-with-tail -- or is the tail really a preblock-with-ON-cell? In general it's much easier to design an ambiguous case for any given set of rules, than to design an ambiguity-proof set of rules.

Luckily this isn't really going to be a problem. Most still lifes will inevitably never have names applied to them at all, because they just plain aren't common enough... but it's still easy to organize them unambiguously. In Catagolue the trans-boat-with-tail will presumably be ""xs9_178ko", and the cis-boat-with-tail will be "xs9_178kc", and anybody can translate between apgcode and common names, however they want to.

Re: The Minimal Cost of Glider Syntheses for Various Objects

Posted: February 4th, 2015, 2:30 pm
by Freywa
dvgrn wrote:One must take Hofstadter's Law into account.
Nailed it.

Inevitably, though, I had to come up with new names, if just for myself. On my copy of apgsearch I manually edited the names of the still lifes of 10 or fewer cells, sometimes assigning them new names in the process. These are provided below.
sl-names.txt
(2.95 KiB) Downloaded 256 times
Fine then, we should use Goucher's apgsearch notation for larger still lifes in the future in this context, not Niemec's numbers (i.e. e.g. 16.447) or his nomenclature.* But we can talk about glider synthesis notation now.

A glider within a synthesis is defined by (1) its position on the lattice and (2) its orientation and phase, the latter of which I will denote as the look. There are 16 possible looks, for which I assign hex digits to them as follows:

Code: Select all

x = 32, y = 32, rule = LifeHistory
.A6.A.A7.A5.A$2.A6.2A5.A.A6.2A$2AC6.AD6.AC5.2AD$5.3D6.D6.3D5.3D$5.D.D
6.D8.D7.D$5.D.D6.D6.3D5.3D$5.D.D6.D6.D9.D$5.3D6.D6.3D5.3D$.AC5.2AD5.
2AC6.AD$A.A6.2A7.A6.2A$2.A5.A8.A6.A.A$5.D.D5.3D5.3D5.3D$5.D.D5.D7.D9.
D$5.3D5.3D5.3D7.D$7.D7.D5.D.D7.D$7.D5.3D5.3D7.D$C2A5.DA6.CA6.D2A$A7.
2A6.A.A5.2A$.A6.A.A5.A9.A$5.3D5.3D5.3D5.2D$5.D.D5.D.D5.D.D5.D.D$5.3D
5.3D5.3D5.2D$5.D.D7.D5.D.D5.D.D$5.3D5.3D5.D.D5.2D$A9.A6.A6.A.A$A.A5.
2A6.A7.2A$CA6.D2A5.C2A5.DA$5.3D5.2D6.3D5.3D$5.D7.D.D5.D7.D$5.D7.D.D5.
3D5.3D$5.D7.D.D5.D7.D$5.3D5.2D6.3D5.D!
The positions of the gliders as they will be seen by the programs are marked. With that fixed we can already draw up the code for a few syntheses, such as this one for the block:

Code: Select all

x = 6, y = 6, rule = B3/S23
bo$2bo$3o$4bo$3bo$3b3o!
which becomes 2,2-0 3,5-E.

For multi-stage syntheses we insert a plain number x between one glider and the next to specify that x generations pass between the placement of the preceding and succeeding glider. For example, 2,2-0 3 7,5-C 2,7-5 means:
  • Place the glider with look 3 (in the above LifeHistory pattern) at (2,2). Step three generations.
    Place the glider with look C at (7,5) and that with look 5 at (2,7).
The following should be obtained:

Code: Select all

x = 10, y = 9, rule = B3/S23
bo$2b2o$b2o4bo$7bobo$7b2o2$2o$b2o$o!
…which happens to produce a long boat.:lol: Nevertheless, I believe the specified delay assists in manually encoding and decoding syntheses as each step then exists in the code independently of the others and can be easily exported for other constructions.

* I have one small improvement to make to the notation: because after "y" there is no available marker for how many additional columns of five zeros there are beyond four, the size can only be represented with the immediate next character and the objects that the program can canonise are restricted to 40*40. I propose using multiple y's to denote that the number of extra columns is encoded in the next two, three, etc. characters, so for example yy1a would denote 50 columns of five zeros (4 + 1 * 36 + 10).