It's true that building an opening book in an automated way can be done off-line which gives us more resources. That's really the basis for this thought that we are trying to solve the same problem.
As a thought experiment, imagine some day in the future, when computers are 1 thousand times faster. What would you do with that extra "time" to make your program more scalable? You might be able to use your book building algorithm, whatever it might be, to find moves for you. If there is a better way, then you would use it instead. But if there is a better way why are you not using it for creating book moves? Of course the details of how to do it may not be exactly the same - because we may be forced to simulate in memory hash tables with disk space for instance, or to deal with other real-world constraints. However I think that at least in principle, we should be doing the same thing. MCTS really feels to me like a superb book building algorithm. Computer Chess books (at least the automated part) are built essentially by taking millions of games from master play and picking out the ones that seem to work best. Those games are like playouts. The moves that score the best are played the most. We have a kind of MCTS here. - Don On Sun, 2008-11-30 at 09:15 -0800, terry mcintyre wrote: > > From: Don Dailey <[EMAIL PROTECTED]> > > > > I've always had this idea that the best way to build an opening book is > > the best way to build a general playing engine. You are trying to > > solve the same exact problem - what is the best move in this position? > > When building an opening book, you have the advantage of not playing against > the clock. In fact, a good opening book ( one which your game-playing engine > knows how to use ) can shave time during the game itself. > > "Knows how to use" can be subtle; many joseki depend on knowing the exact > line of play, the move choices depend on knowing the exact ( not approximate > ) results of ladders and semeai. Against better players, approximate answers > tend toward disaster. A book move might work sometimes, not others, and the > program won't know the difference. > > I think the "opening book" and "general playing engine" solve similar > problems: what is the best move which can be discovered with finite > resources? The opening problem must solve an additional side constraint: it > must suggest moves which can be correctly exploited by the playing engine, > which may have less time and computational power available. A sufficiently > broad and deep book can make up for lack of computational resources during > the game; such a book needs to know the best refutations for each of many > possible plays. Joseki and fuseki books for humans are full of annotations: > "move a > is used when the ladder works; otherwise, b is recommended; c is a > mistake, which can be exploited by ..." A book for computer programs > might need similar annotations. > > Some programs may need different books, depending on whether they have a fast > or slow clock, one or many processors. > > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
