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