Nice! I am wondering what method you use to find 3-glider collisions that make constellations? I use a really slow method of running gencols and a script of chris_c's to find most of the 3-glider collisions that have a certain final population, and then run dvgrn's find.py script to find the appropriate constellation.

Re: 16 in 16: Efficient 16-bit Synthesis Project

Posted: April 22nd, 2017, 1:47 pm

by chris_c

I added all of those so now we are below 27G for all 16-bit still lifes. Looking ahead at a few of the expensive but rare still life shows that this 16G snake -> hook-with-tail sequence is used in quite a few (16.930, 16.1064, 16.1077, 16.1139 for example):

Re: 16 in 16: Efficient 16-bit Synthesis Project

chris_c wrote:EDIT: We would need a 5G synthesis of 12.103 to solve 16.1064 in 15G using Extrementhusiast's method for 16.1077. I wonder how much brute forcing has been done on 5G syntheses?

As far as I know, Bob Shemyakin's recent survey has been the most ambitious effort along these lines, and it could only be declared "complete" for 4-glider collisions (and it wasn't really). Running his SpaceBattle search utility with a wide enough variety of targets and angles of attack might turn up something, but that's always going to be just random sampling, luck of the draw.

It's probably about time to attempt a more systematic brute-force approach, exhaustive through 3 gliders, then choosing promising branches to explore from there.

Re: 16 in 16: Efficient 16-bit Synthesis Project

Posted: April 23rd, 2017, 10:23 am

by chris_c

dvgrn wrote:It's probably about time to attempt a more systematic brute-force approach, exhaustive through 3 gliders, then choosing promising branches to explore from there.

Yeah I have thought about that. I would love to see a recursive glider synthesis search program that works as follows:

-Keep track of the active reaction and then copy a new glider into the pattern at the latest moment that is consistent with that glider having come from infinity.

-Prune the search tree if the active reaction gets bigger than a certain bounding box.

-Bonus points if the program is clever enough to realise that the active reaction has settled down to an oscillator or still life so that trying arbitrarily distant gliders is futile.

-Bonus points if the program is clever enough to recognise interesting objects that appear in the soup for a limited number of ticks before being destroyed.

EDIT:Oh there's something I forgot that occurred to me recently. The above method only catches cases where every new glider added interacts with the main part of the pattern. It would not catch reactions like below where both gliders would miss the block on their own:

Since 2-glider interactions are relatively easy to enumerate it should be technically possible to recursively add a 2-glider interaction to an already active pattern. This should do a fairly good job up to 5 gliders in total but would start missing stuff at 6G when 3G-with-3G interactions start to appear. /EDIT

Just so this post is not entirely fantasy here are a few interesting "Top 10" lists:

Top 10 most common SLs with 16 bits or less and having no synthesis in 3 gliders:

For example the still life 12.103 that I mentioned previously is the 120th most common still life that does not have any known synthesis in 5 gliders.

Re: 16 in 16: Efficient 16-bit Synthesis Project

Posted: April 23rd, 2017, 10:20 pm

by dvgrn

Just started a new thread on enumerating three-glider collisions, as a starting point for a (maybe somewhat) more exhaustive 5G search... or at least a better prebuilt database of small constellations.

I don't think I'll have time to work on any search code for the next few months at least -- too many other things on my To-Do list right now, and I'm trying not to have it be a LIFO stack...! But I do want to pick this topic up again eventually, if no one else gets to it first.

Maybe let's move any future progress on collision enumeration to that thread, to avoid polluting this thread any further...?

chris_c wrote:-Bonus points if the program is clever enough to realise that the active reaction has settled down to an oscillator or still life so that trying arbitrarily distant gliders is futile.

-Bonus points if the program is clever enough to recognise interesting objects that appear in the soup for a limited number of ticks before being destroyed.

The first item I think happens automatically if we keep a list of hashes of each "final initial" state of the 2G collision plus glider #3, at the last generation before they interact. Once we've backed off the T=0 position of glider #3 far enough that the new pre-collision picture is already in the hash table, we can stop investigating that glider lane and move to the next one.

... Unless there's some kind of spark that curls around behind the glider but dies before the glider reaches the stabilized constellation. Bother. To be safe, maybe we have to keep backing the glider off for some number of extra ticks proportional to the size of the 2G collision's total reaction envelope...? Or we could track cells lining the incoming glider's lane and move on to the next lane only if the hash value is in the table AND those lane cells are all undisturbed.

The interesting-objects-for-a-limited-time bonus points are going to be a lot harder to get, I think. For stabilized ash we have code lying around, like recognizer.py and the various apgsearches. It's going to slow things down a lot if we have to hunt through an active reaction every tick, or even every ten ticks or hundred ticks, looking for interesting still-life islands.

We'd also want to look for much more interesting things than still lifes -- things like a temporary loafer, which there really might be one of, out there somewhere unnoticed in an already-censused Catagolue soup. It's so much easier to run through a pattern and recognize-and-remove everything as we get to it, than to have to check every cell against a huge list of interesting stuff, and end up ignoring most cells because they're still active but not recognizable yet.

chris_c wrote:EDIT:Oh there's something I forgot that occurred to me recently. The above method only catches cases where every new glider added interacts with the main part of the pattern. It would not catch reactions like below where both gliders would miss the block on their own...

This constellation can't be found by adding a fourth glider to my proposed three-glider collision database, because none of the subsets of three out of the four gliders are valid three-glider collisions. So if we ever, Heaven forbid, get to the stage of trying to enumerate all four-glider collisions, we can start with the three-glider-database-plus-one-glider approach, but then as you say we'll have to add all two-glider-collision interactions with other-two-glider-collisions.

But for just three gliders I think this isn't a problem yet. There's no way to set up three gliders such that no two of them interact, but the combination of all three does interact. (Right?) So with a decent 3G database we could kinda sorta reach up to 6G before we start missing huge classes of reactions.

-- I'm sure people have thought of all these problems before, and maybe more, and that's why the collision census hasn't been done yet for more than two gliders. It still seems as if an exhaustive 3G search is a lot closer to being possible than 4G and above, though.