It's possible for the tree to become too narrow. On a 9x9 board, you might be able to say that there are only one or two playable moves, but on 19x19, I doubt that any pro would claim that the options are that narrow, even accounting for symmetry, It's common to hear that "some pros play A, some B, some C or D in this situation. Moderately strong amateurs play one of these other options, which are mistakes because ... "
An opening book could benefit from knowing how to respond to the options considered by both pros and strong amateurs. As for weaker players like me, we tend to be somewhat more creative, you'll just have to work it out on the fly. I think an efficient opening book would be organized on principles similar to huffman encoding: it would devote space to high-probability branches, and less to the weird stuff - but enough memory might be retained to eventually observe "Gee, opponent X does this a lot, and I have discovered a good refutation Y." Terry McIntyre <terrymcint...@yahoo.com> On general principles, when we are looking for a solution of a social problem, we must expect to reach conclusions quite opposed to the usual opinions on the subject; otherwise it would be no problem. We must expect to have to attack, not what is commonly regarded as objectionable, but what is commonly regarded as entirely proper and normal. But as Don says, this needs to be integrated with the basic search algorithm to scale well. I recently tried a few games against Leela, where the first 8 opening plays were predetermined ( a mini chinese opening ). This is not the usual style of Leela. I find that I can win either side of the same position. When Leela and I start with an empty board, I have a harder time of it; Leela's style is not mine. – John Beverley Robinson, 1897 ________________________________ From: Don Dailey <dailey....@gmail.com> To: computer-go <computer-go@computer-go.org> Sent: Tuesday, May 12, 2009 3:14:55 PM Subject: Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS On Tue, May 12, 2009 at 6:05 PM, Don Dailey <dailey....@gmail.com> wrote: And for MCTS it is much lower than 10. 2009/5/12 terry mcintyre <terrymcint...@yahoo.com> In the opening, among reasonably clueful players, the branching factor is much closer to 10 than to 361. I assume Dave Dyer does not understand alpha beta pruning either, or he would not assume the branching factor is 361. But the pruning we are doing is far more severe than even alpha/beta pruning. (In a theoretical sense this is not true because a proper MCTS eventually would have to explore the tree in alpha/beta fashion to provide a proof.) In practical MC programs the effective BF is extremely low. - Don Terry McIntyre <terrymcint...@yahoo.com> On general principles, when we are looking for a solution of a social problem, we must expect to reach conclusions quite opposed to the usual opinions on the subject; otherwise it would be no problem. We must expect to have to attack, not what is commonly regarded as objectionable, but what is commonly regarded as entirely proper and normal. – John Beverley Robinson, 1897 ________________________________ From: Michael Williams <michaelwilliam...@gmail.com> Subject: Re: [computer-go] Re: Implications of a CPU vs Memory trend on MCTS You have made the assumption that the move that your opponent selected was on average explored equally as much as all of the other moves. That seems a bit pessimistic. One would expect that the opponent selected a strong move and one would also expect that your tree explored that strong move more than it did other moves. I'm not saying keeping the tree is a huge benefit. I'm just saying that I don't think your 99% number is fair. Dave Dyer wrote: > At 02:13 PM 5/12/2009, Michael Williams wrote: >> Where does your 99% figure come from? > > 1/361 < 1% > > by endgame there are still easily 100 empty spaces > on the board. > > > _______________________________________________ > 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/ _______________________________________________ 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/
