Well, it's a trade-off of course, but a?mercy rule threshold of 20?might be?pushing it a bit. For 9x9, I typically use 30. If you only invoke the rule for external nodes at least N plys away from any internal nodes, then the tree will catch some of these problems.
Some playout policies tend to capture dead strings earlier than others. - Dave Hillis -----Original Message----- From: Brian Sheppard <[email protected]> To: [email protected] Sent: Tue, Aug 18, 2009 4:24 pm Subject: [computer-go] Mercy rule position 1 2 3 4 5 6 7 8 9 A - X - O - - O - - B - - O - O O - O O C O O O X O - O O X D X X O O O - O X X E - X X O X O O X - F X - X X X X X X - G X X O O O O O X X H X O O X X O O O X J - O - X X - O O O O to play and win :-) The "play and win" is a joke, of course. O has a big, dead, one-eye group at bottom. But Pebbles simulations was winning this position at over 84% for O, no matter how long it searched. When I investigated, it turns out to be because of the "mercy rule." I had set the threshold at 25% of the board, or 20 stones difference between the sides. Here is a position: 1 2 3 4 5 6 7 8 9 A O - O O O - O - O B O O O O O O - O O C O O O - O - O O X D X X O O O X O X X E - X X O X O O X X F X - X X X X X X - G X X O O O O O X X H X O O O O O O O X J O O - X - O O O O O "wins" by mercy rule, 45 stones to 24 I can move the threshold, of course, and that "fixes" the problem. But I am wondering if there is a more reliable approach. What do you do in your program? _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
