I haven't thought through all the details, but I think I understand the basic idea here. The metric you're trying to optimize is the number of ticks that it takes to return parity information from a faraway block.simsim314 wrote:I think I have the basic idea how to construct pretty fast integer converter.
For the parity reader, one need to send gliders to collide with SL and leave the SL but will shoot two gliders back. Now one can use this simple fact: in the following gliders position if the distance is even the left reaction will shoot back a glider, if odd the right one... we can shoot glider salvo accordingly to fix the remaining debris.
I think that for this particular project, the parity read time is not a very useful quantity to optimize.
The original plan was to simply pull the encoded recipe block back to zero once and feeding the number of pulls, P, into a binary counter. Calcyman's suggestion was to use two push-and-pull SBM registers, and pull the blocks back log2(P) times and use the parity readings after each pull -- which is slower, but you can throw away the binary counter, which is another kind of simplicity. Calcyman's design will almost certainly reduce the value of N, the maximum number of gliders needed to construct anything glider-constructible.
This new proposal appears to add a nightmare tangle of complex circuitry, just to reduce the number of ticks it takes to read a sequence of parities from a given block position. If we're using this time-to-integer converter for the stated purpose of running a universal constructor to glider-construct larger objects, all that circuitry has to be constructed with gliders, which will hugely increase N.
Whatever N turns out to be, there will be no point in using this mechanism to build anything that can be constructed with fewer than N gliders. I'll do some proper estimates later today, but it seems clear that for an encoding of a slow-salvo construction of more than N synchronized gliders -- a Gemini spaceship, say, or very likely an HBK -- the block will be placed a frankly silly distance away as Kazyan says.
Frankly-silly distances are far enough away that in an actual pattern, Golly won't even be able to send a glider to interact with the block in a reasonable amount of time, at least not without a new specialized simulation algorithm. For example, if we could somehow encode the 38,380-glider recipe for an HBK using just one U.C. operation per resulting glider -- an underestimate by several orders of magnitude -- then the block would have to start at a distance of around 2^76760 cells from the U.C.