I'm reading your three last posts very caryfully to try to think straight about all this. I may have more comments later...
I think it will be meaningful to do all of these three things that we've already suggested:
- Have a list of the end results of small common reactions, that are likely to show up in fundamentally different ways. This is what I'm trying to adress with my soup search as discussed before.
On a side-note unrelated to elbow recipes: It would be interesting to find out what the most common predecessor is of each of the results of my soup search. Except for the most generic results, like two blocks close to each other, it seems likely that each result is connected to a small common predecessor.
I'm not very concerned about keeping this list small. We'll insert all orientations of them in a hash table before starting the search, so having a long list won't really hurt performance much.
I think it would be interesting to get to know about it, whenever such a result showed up, and then we can worry later about if it seems worth it to do a deep search with that as a starting point.
- Have a list of intermediate points in known useful recipes. Branching points are the most important, but it doesn't have to be limited to that. The only problem is that the list needs to be updated every time a new recipe is discovered -- I guess it could be automated some way. These would be inserted in the hash table too.
- Report any intemediate result that fit in a small bounding box. This of course is because shouting more gliders at it have a higher probability to reach all objects in the ashes than intermediate results with a bigger bounding box. We could then look at these and decide if it looks promising enough ta start a new search from that staring point.
I'm not quite sure about that. We could try to do deep searches from millions of potential elbows. Maybe we'll find that 99.9% of those searches end at depth 1, because no matter what glider you send second, the reaction always explodes or vanishes or makes a constellation that's bigger than our arbitrary threshold. Then we only have thousands of deep searches to run, and we can choose a meaning of "deep" to allow for a manageable total workload.
I might have not been very clear about what I meant. We will already try to deepen the search from millions of potential elbows as part of the regular search, at least as far as internal memory can hold (maybe a hundred million). For each additional glider at 90+ distance, the number of stable results seems to increase by something like a factor of 3. That means at least 10% of tested salvos create a new potiential elbow. Which is lucky, because if the number of results decreased with each new glider, we'd quickly run out of things to do...
What I meant was more like, can we use some good principles to pick out a few results that would be meaningful to start new deep searches from. And I guess the three ways I mentioned above are indeed possible ways to do that. Maybe we can think of more ways?
Thanks for the links, I took a look at this.
So far, as acknowledged by the author, this project uses a pretty straight-forward way to evolve patterns.
The code I had already written was a bit more efficient, and I already had most components I needed to put together the soup searcher, so I just did
So far, I use a byte grid for cells, and an additional smaller "tile map", where each byte corresponds to a 8-by-8 tile of the cell grid, and simply tells if that part of the grid is empty or not.
The evolve function processes 8 cells in parallel, by using 64-bit integers, and has no conditional statements in the inner loop (conditionals are very expensive if the condition depends on something that is essentially random, like cell states).
I could have used simsim314's LifeAPI, but I really don't see how a 64-by-64 tile would be enough for this search.
Maybe I'll start battling with bit fields and 64 cells parallel evolution eventually, it would probably be at least 3 times faster.
So what do you plan for a next step?
Now when the holidays are over, each step will take much more time...
My search program still doesn't know that the distance from the previous glider doesn't matter (except for the P2 phase), if the target is already stable when the next glider starts reacting with it. When that logic is in place, it will gain a lot of speed.
It just occurred to me that a block in the turns-to-honeyfarm position (instead of the pi-explosion position) might be a solution to the elbow-duplication problem. Just send even-parity gliders at p90 (or whatever) to make a crystal.
This is interesting, but it also gave me an idea for a fast adjustable elbow duplicator. It uses a recipe with a return glider that collides with the input stream. I found it with chris_c's script, and I assumed it's wouldn't be very useful.
For it to work, we need a way to get from a honeyfarm in the "crystal" position, to a block. I'm searching for one, and it looks possible, but not very easy.
To show this idea, I'm cheating and using a recipe with minimum distance 49 ticks to get from a honeyfarm to a block:
Code: Select all
x = 2097, y = 2101, rule = LifeHistory