> 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/