Updating Mark Niemiec's Database

[carsoncheng]

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.

[pzq_alex]

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.

[carsoncheng]

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.

[carsoncheng]

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.

[dvgrn]

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.

[confocaloid]

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]

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.