I believe this to be a good idea, but I couldn't get around some minor problems. Essentially, because the local searches are coupled to one another, it ends up exploding as you consider this coupling (scaling to larger regions). You then have to trade accuracy or have more computing power than I have access to... There are cases though where you can find local solutions that are independent in some sense from the rest of the board and the program I am working on now does that. I'm sure someone smarter than me will be able to figure out a better way though. There are certain times when this technique is highly useful. For a simple example, imagine a board with two walls down the middle bordering on each other. In some sense, as long as both those walls live, there are 2 subgames taking place. This type of situation is where I see your approach as being the most useful. Just my thoughts.
- Nick On 1/30/07, Weston Markham <[EMAIL PROTECTED]> wrote:
I have an idea in the back of my mind that is an extreme version of this: Divide the board into 361 separate local searches, then use information from these to guide a global search. The local searches would be done on the full board, but would only search for strategies that will capture or defend individual intersections. I suspect that this first phase could potentially benefit from parallelization for a significant portion of the game. Eventually this parallelism will break down because there will only be a limited number of local battles, and the eventual status of points that are in the same chain will almost always be the same. Any practical program would need to deal with this gracefully, of course, rather than duplicate its effort many times. Also, I only have a vague idea of how to take advantage of the information gained from the local searches, when performing the global search. Weston On 1/30/07, Dave Dyer <[EMAIL PROTECTED]> wrote: > The idea isn't more than lightly toasted (less than half baked), but > the kernal is turn the full board search into set of searches on > much smaller boards, using the overlapping strips as boundary > conditions, then do some unifying final step to pick the move. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
