ConwayLife.com

Posted: **July 21st, 2022, 12:39 am**

For years, the mainstream database for alternate syntheses, Mark Niemiec's database, is not being updated and is being very outdated. This is especially true due to massive searching on the Glider_stdin symmetries in 2020 and 2022, respectively, leading to numerous improvements in glider syntheses, and many options for alternate syntheses that provides some form of clearance that previously required more gliders.

Therefore, we chose to update either Mark Niemiec's database to accommodate more recent syntheses, or update Shinjuku to make it suitable for storing alternate syntheses. In a poll conducted on Discord, we chose to update Mark Niemiec’s database to accommodate more up-to-date alternate syntheses. Things to do include:

1. We may not have write permission to Mark Niemiec’s life page. Therefore, we may have to create another access point to the new database, possibly integrated into Catagolue, for the updated database. What splits it from updating Shinjuku, however, is that it there is no auto-update process being done, and each synthesis must be manually added.
2. It is a bottleneck to find a still life from a list of hundreds of objects at a specific size when you need to find the Niemiec ID of an object from its apgcode. Therefore, apgcodes should be used instead of Niemiec IDs. To do this, we should design a program that identifies the object that you need to synthesize, and turns it into an apgcode if the object is periodic.
3. Remove the result constellation of each step using a program that parses the steps of the synthesis. This functionality should be in Shinjuku or Catagolue to separate steps in the auto-update process. This makes the syntheses Catagolue-compatible.
4. The largest concern for updating Shinjuku directly is the presence of duplicate syntheses that makes useful syntheses harder to find. Once we figure out a way to autonomously rule out non-useful syntheses, we can switch to Shinjuku format and add the auto-update process. This makes it easier for the community to update alternate syntheses.

Posted: **July 21st, 2022, 12:43 am**

carsoncheng wrote: July 21st, 2022, 12:39 am 2. It is a bottleneck to find a still life from a list of hundreds of objects at a specific size. Therefore, apgcodes should be used instead of Niemiec IDs. To do this, we should design a program that identifies the object that you need to synthesize, and turn it into an apgcode if the object is periodic.

No need for this one. The Catagolue object endpoint already does this -- just input the RLE into the box and Catagolue will identify it for you.

Posted: **July 21st, 2022, 12:44 am**

pzq_alex wrote: July 21st, 2022, 12:43 am
carsoncheng wrote: July 21st, 2022, 12:39 am 2. It is a bottleneck to find a still life from a list of hundreds of objects at a specific size. Therefore, apgcodes should be used instead of Niemiec IDs. To do this, we should design a program that identifies the object that you need to synthesize, and turn it into an apgcode if the object is periodic.
No need for this one. The Catagolue object endpoint already does this -- just input the RLE into the box and Catagolue will identify it for you.

By the bottleneck that was mentioned on the post you quoted, I mean the opposite: The process of finding the Niemiec ID of a still life from its apgcode.

Anyway, thanks for pointing out the unclearness in my post. I have now edited the clarifying details into it.

Posted: **July 21st, 2022, 8:32 am**

It turns out that updating the old database is not needed at all, as suggested by Adam P. Goucher on Discord. Shinjuku is actually capable of storing multiple syntheses of a single object, but the auto-update process only accepts syntheses cheaper than the ones already known for a particular object, and Catagolue only displays that. To update Shinjuku, simply encode your syntheses in your local copy of Shinjuku, and submit a pull request to the original Shinjuku repository.

Posted: **July 21st, 2022, 8:53 am**

carsoncheng wrote: July 21st, 2022, 8:32 am It turns out that updating the old database is not needed at all, as suggested by Adam P. Goucher on Discord. Shinjuku is actually capable of storing multiple syntheses of an object, but the auto-update process only accepts syntheses cheaper than the ones already known for a particular object, and Catagolue only displays that. To update Shinjuku, simply encode your syntheses in your local copy of Shinjuku, and submit a pull request to the original Shinjuku repository.

Just as a side note, Mark Niemiec's database is still getting updated behind the scenes. The current status quo seems to be that the public web pages only get updated every five years or so, but it could theoretically happen a lot more often than that.

The build process for all of the interlocking links between web pages is quite convoluted, but it is automated. Whenever Mark gets everything into a good state again for a full build, we could see quite a significant improvement in the search functionality and the underlying data. I only bother him about that every three months or so, but it's probably time for my next quarterly reminder email.

-- All that said, it's definitely true that the conwaylife.com/ref/mniemiec will always inevitably be out of date. There's no way to keep up with the volume of recent discoveries, without some kind of presumably web-based crowdsourcing mechanism.

It doesn't seem likely that people will start making individual merge-request contributions to Shinjuku, anywhere often enough to keep Shinjuku up to date with a full variety of alternate syntheses, either -- at least not until it's a lot more convenient to get a nice stamp collection of the alternatives back out of Shinjuku again! That's the huge advantage of curated stamp collections like the ones in Mark Niemiec's database.

That explains why I'm still going and looking up things via NIemiec's search page all the time. It's really quite convenient, all things considered, and very often helps me solve problems that I couldn't solve otherwise.

Posted: **July 21st, 2022, 9:33 pm**

What are known (occurring in practice) ways in which one glider synthesis/synthesis component can be quantitatively and/or qualitatively different from another glider synthesis/synthesis component? Stated differently, what are known kinds of interesting well-defined problems which are solved by some glider syntheses, but which are not solved by other glider syntheses for the same final object/constellation/flotilla?

Posted: **July 22nd, 2022, 6:18 am**

confocaloid wrote: July 21st, 2022, 9:33 pm What are known (occurring in practice) ways in which one glider synthesis/synthesis component can be quantitatively and/or qualitatively different from another glider synthesis/synthesis component? Stated differently, what are known kinds of interesting well-defined problems which are solved by some glider syntheses, but which are not solved by other glider syntheses for the same final object/constellation/flotilla?

Here are some of the different attributes that need to be optimized in different situations:

1) cost in gliders
2) edginess, in different directions -- might want a recipe to build, say, any orientation of fishhook eater, without disturbing existing objects beyond some nearby orthogonal/diagonal/oblique line, or might even want to be able to push a fishhook eater into a pocket surrounded by existing objects.
3) time to completion
4) speed of cleanup -- with a recipe where all cells except for the target object disappear pretty much immediately, a second object can be constructed in the near vicinity right away, whereas if there are long-lasting dying sparks, that won't be possible. Sometimes a constellation of bait objects needs to be built and then immediately consumed, so a long cleanup period can't be allowed.
5) order of appearance of edge cells -- for example, most block recipes build one cell on the "away" edge of the block, then the other... but sometimes a recipe that builds both "away" edge cells simultaneously is needed, e.g., to successfully turn a block into a biblock.
6) order of construction of composite objects -- for something like a boat tie ship, for example, Mark Niemiec's database will often contain syntheses that build the whole object at once (cheapest) but then also syntheses where the boat is added to an existing ship, and vice versa.

Posted: **July 5th, 2024, 1:36 am**

confocaloid wrote: July 21st, 2022, 9:33 pm What are known (occurring in practice) ways in which one glider synthesis/synthesis component can be quantitatively and/or qualitatively different from another glider synthesis/synthesis component? Stated differently, what are known kinds of interesting well-defined problems which are solved by some glider syntheses, but which are not solved by other glider syntheses for the same final object/constellation/flotilla?

dvgrn wrote: July 22nd, 2022, 6:18 am Here are some of the different attributes that need to be optimized in different situations:

Some things I would add:

speed of the leading edge -- maybe this is just an extension of "time to completion", but for example in the below synthesis step, the glider lane to get the pre-L in meant that (for the known blocker synthesis that fit) I had to get a block in after that glider passed but before the blocker was built and in a pretty narrow time window.

on edginess -- I've had cases where it isn't just a matter of projecting a object "forward" from the gliders but sometimes they need to come back toward the gliders: the synthesis of p111 R hassler is a good example where a lot of gliders need to get to the interior from the corners but pull objects near the side "walls" (all to set up a bunch of one-time turners because some of the objects require 4-direction syntheses)

Code: Select all

x = 84, y = 58, rule = B3/S23
34bobo$35b2o$35bo30bobo$66b2o$67bo$34bo$32bobo$33b2o6$81bo$81bobo$81b
2o2$35b2o$35b2o$24bo$11bo13bo$12bo10b3o8b2obo$10b3o22bobo31bo$36bo31b
o$35b2o5b2o24b3o$20bobo12b2o4bo2bo$21b2o12b2o4bobo$13bo7bo20bo$14b2o53b
2o$13b2o53b2o$41bo20bo7bo$40bobo4b2o12b2o$39bo2bo4b2o12bobo$13b3o24b2o
5b2o$15bo31bo$14bo31bobo22b3o$46bob2o8b3o10bo$58bo13bo$59bo$47b2o$47b
2o2$b2o$obo$2bo6$49b2o$49bobo$49bo$16bo$16b2o$15bobo30bo$47b2o$47bobo
!

Posted: **September 24th, 2024, 4:44 pm**

Just had another thought on "time to completion" as an attribute when synthesizing oscillators. Sometimes, especially for low period oscillators, it's helpful for the synthesis of the active region to be "slow" and the synthesis of the stabilizing objects to be "fast", because otherwise the active region can expand and destroy the pattern before all the pieces can get into place. For example the partial synth below I believe gets the eater in on the exact generation it is needed - the couple other honey farm synths I found with enough clearance were too "fast" or had the glider too far back (I guess the wrong kind of edginess), and I think this was almost the only eater synth I know that fits and definitely the only one fast enough.

Chris857 wrote: July 5th, 2024, 6:06 pm Here is the activation step for a p19 honey farm hassler, unfortunately I'm not sure where to get started with synthesizing the stator still lifes (especially the large welded ones).

Code: Select all

x = 79, y = 73, rule = B3/S23
3bo$4bo41bo$2b3o39b2o$45b2o3$8bo10bo$9b2o6bobo$8b2o8b2o5$23bo$21bobo$
22b2o3$42b2o$41bobo$36b2o2bo$36bo2bob2o$2bo35b2obobo$o3bo37bo$5bo$o4b
o$b5o36bo4bo2b2o$41bobo2bobo2bo17bo$41b2o4b2obo17bo$49bo18b3o$47b2o$47b
o$31b2o16bo$31bo2b2o12b2o$27b2o3bob2o8b2o2bo$27bo2bobo11bobobo$29b2ob
o13bob2o$30bobobo11bobo2bo$30bo2b2o8b2obo3b2o$29b2o12b2o2bo$29bo16b2o
$31bo$30b2o$8b3o18bo$10bo17bob2o4b2o$9bo17bo2bobo2bobo$27b2o2bo4bo36b
5o$73bo4bo$73bo$36bo37bo3bo$35bobob2o35bo$36b2obo2bo$38bo2b2o$35bobo$
35b2o3$55b2o$55bobo$55bo5$59b2o8b2o$59bobo6b2o$59bo10bo3$32b2o$33b2o39b
3o$32bo41bo$75bo!

ConwayLife.com

Updating Mark Niemiec's Database

Updating Mark Niemiec's Database

Re: Updating Mark Niemiec's Database

Re: Updating Mark Niemiec's Database

Re: Updating Shinjuku

Re: Updating Shinjuku

Re: Updating Mark Niemiec's Database

Re: Updating Mark Niemiec's Database

Re: Updating Mark Niemiec's Database

Re: Updating Mark Niemiec's Database