The whole article was more like an outline, then a stone-hard definition. For an exact definition I would (reandomly) one of the 4 phases and define a "hot spot" that should reach (0,0) - and call that gliders lane "0".dvgrn wrote:Lane 0 would hit the top left corner -- is that with a 3o$o$bo! glider or a 2o$obo$o! glider? They're actually on different lanes. Other than that, your definitions seem clear, and I think the math would all work as you've outlined it.oblique wrote:Lanes are always defined such that lane 0 would hit exactly the top left corner of the bounding box.
As long as the definition is known by those who actually try to use the results that would be fine.
Besides: as long as the definition is well defined (even if randomly so) the results would work just fine. All that maybe has to be done is adjust the target by one or even two cells.
Space does not matter that much any more. Besides to my experience pattern-DBs seem to be vary well compressable.dvgrn wrote:Ah, this is the exciting part! The original Glue built a database of all the reactions it found that didn't explode -- Paul Chapman called them "simple outcomes", and recently I've been calling them "intermediate targets", or just "targets". The idea was to do the actual search just once and query the database later. But as I mentioned a while back, *WSS generators were among the reactions that Glue automatically threw away.oblique wrote:We could then use the weighted q algorithm and the function above, to search for a specific result.
(start with one state (pat,lane), q all reactions coming from there, then iteratively take the cheapest queued reaction r from the q, add any possible reaction starting with the end pattern of r back to the q, until one is found that yields the desired result)
I seem to recall that even forbidding output gliders and *WSSes, Glue had a hard time getting past about nine gliders -- the database went over 2GB at that point, so doing a complete search with up to ten gliders would have exploded the size to dozens of gigabytes at least.
OK, sharing actually GBs of uncompressable or already compressed Data is a pain still.
That is the base idea, yes. Besides: with my "definition" of lane there would be lanes with negative indices.dvgrn wrote: For example, an eight-glider 0 +9 +18 +27 +5 +14 +23 +1 recipe would cost 1+1+2+3+4+5+6+7 = 29 rephaser/rakes, less than a two-glider 0 +0 recipe (second glider following the first on the same lane -- 1+31 = 32 rephaser/rakes).
Maybe "top most lane that comes close enough to the bounding box to interact" would be better.
Not sure yet. For a "cheap first" search you actually need at least the weights. I bet that each constructor has it's own definition of "cheap".dvgrn wrote: Anyway, it will be very interesting to see how long it takes to boil this search space down into useful information. I could imagine designing either an initial exhaustive search stage, to produce a huge database to be re-searched later -- or an optimized utility that you'd run over and over again with different parameters, each time you want to find something different. (?)
Therefore it might be better to include other limits like "do not collided with my copy 31 places away of me" from the begining.