Paul Tooke wrote:I think the principal difficulty with a distributed search would be establishing what searches to perform... there is the potential for a runaway proliferation of searches...
Agreed. For any of these search utilities, if the server automatically generates new searches to try, it's eventually likely to wander off into search spaces larger than the visible universe, and no useful results will ever come back.
This isn't necessarily an insurmountable problem. There are several search spaces where an expert could manually generate in advance enough sets of "interesting" search parameters to stay ahead of a distributed search indefinitely (or until a solution was actually found.) If the list of untested parameter sets start to run short, it would be easy enough to add a new set of somewhat more difficult search problems.
One case I'm thinking of in particular is a 'catalyst' / 'ptbsearch' search for catalyzed signal reactions. Almost ten years ago now I cobbled together a version of Gabriel Nivasch's 'catalyst' with some additional output filters that might make it more amenable to distributed searching. I called it 'catgl' because it caught and counted output gliders, as well as printing an extra 'matched!" message when an output matched an optional target filter.
Here's a sample of the size of message that a distributed client/server system might send back and forth -- this is a reformatted version of the actual batch-file input to 'catgl':
Code: Select all
Explanation of the 'catgl' input data above:
- use the G+Boat = B-heptomino base reaction:
x = 12, y = 10, rule = B3/S23
- collide a glider ('/' = shouldn't exist in the output)
with a boat ('1' = must exist in the output, and
- '0' = must be OFF in the output.)
- Use only catalysts #3 and #7,
- search the space between 75 and 250 ticks,
- pattern must survive at least 49 ticks after catalyst placement,
- maximum number of catalysts to be placed is 3,
- resume search at the point where
1st catalyst reacts at T=78,
2nd catalyst reacts at T=85,
3rd catalyst reacts at T=85
Clients could be set to run a search for a relatively short amount of time -- ten or fifteen minutes, maybe? -- and then if no match is found, return a new partial search result to the server. For example, in ten minutes the search might have reached "79,90,91" instead of "78,85,86" -- that new string is all that would have to be sent back, since all the other parameters would remain the same.
However, a distributed search utility that actually uses this 'catgl' code base is going to be fairly limited, because the catalyst definitions don't allow for transparent reactions -- you can work around this only to a very limited extent, as in the transparent-boat search shown above. Transparent reaction play a role in a fairly large fraction of the useful signal reactions that have been found so far. So it would probably be better to start with something along the lines of Paul Callahan's 'ptbsearch' instead. The messages between the client and server wouldn't have to change much from what's shown above.
A distributed system like this could be used to search for things like new Herschel conduits and converters -- glider outputs on different lanes, direct constructions of various still lifes or even *WSS spaceships. It would also give us a fresh shot at finding a small stable 90-degree reflector, for which the prize has been going begging for almost a decade now. If I were doing any of the programming on this project, I would definitely use $thimbles & care() ...
Keep the cheer,