On Sun, 2008-10-12 at 08:08 -0700, terry mcintyre wrote: > > From: Don Dailey <[EMAIL PROTECTED]> > > > > I've always had this idea that the best way to build a book might also > > be the best way to build a game playing program. For instance we have > > done these big studies to determine based on games of Leela and others > > what the best main line of play is. Computer Chess programs analyze > > huge databases of games and make tree's sometimes to build opening > > books. > > > > But it seems like this resembles to a remarkable degree a Monte Carlo > > Tree Search program. > > Yes, there are analogies. The databases of games in Chess include many > high-quality grandmaster-level games, do they not? I hope that Go databases > also sample professional Dan-level games, otherwise we're just diving into a > pool of ignorance and drawing up a sample.
The downside is of course that little exploration is done. In chess it is still common to find "theoretical novelties" or previously unknown moves that turn out to be be interesting or even good. So mini-maxing the choices of Grandmasters is not going to be innovative. Even MCTS depends on a certain amount of exploration (as opposed to exploitation.) I guess you could view chess opening theory as this huge tree built up over decades of time by very intelligent agents. > Joseki databases are "brittle" in a sense. Playing the "almost right" move is > often a failure. I was just reading a particular line in "38 Basic Joseki", > where the author commented that if White plays A in a certain diagram, Black > should reply with B; a difficult semeai follows, which Black wins by one move > if he plays correctly. The result is a gain for Black. On the other hand, if > Black does not know how to play that dificult semeai, Black should not start > down that path at all; it will be a gain for White. > I've always thought Joseki for computers is pretty dicey, but I'm not really qualified to judge this well as I don't play go. But perhaps joseki is nothing more that a pattern database to suggest moves and you still just combine it with MCTS? - Don > Imagine a program analyzing such a position. Is the program smart enough to > figure out the correct way for Black to win the semeai? If so, the program > will evaluate White A as a dubious move, and avoid it; if playing Black, will > respond correctly and win the battle - and probably the game. But if the > program is not smart enough to play the semeai correctly, it will believe > that White A is a good move. > > That's what I mean when I say that evaluation can be brittle. Playing a > semeai properly might mean evaluating the exact min-max (local) outcome of a > chain of 20 moves, assuming best play by both sides. Any mis-step will lose > the battle. Any mistake will lead to an evaluation which is off not by a > fraction of a percent, but off by nearly 50% - the difference between > balancing at the edge, 50% win/loss, and losing abjectly. Many joseki are > that finely balanced - make the wrong move and your position collapses. Fail > to follow up on your advantage, and your opponent gains at your expense. > > In short, I'd say that including joseki and fuseki databases is a Good Thing, > but they must be as complete as possible, and integrated properly into the > move evaluation function. Traps, spoilers, and blunders should be part of the > knowledge base, signposts for the unwary to avoid deep pits. > > There are many well-known trick plays which are actually unsound against > correct play, but gain an advantage against weaker players. Imagine the > "fool's mate" multiplied hundreds of times; the field is liberally sown with > such trick plays. Eradicating such blunders will require qualitative > analysis; statistical comparisons of one fool's winrate against another won't > help much. > > >
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/
