Hi, Just reproducing the ticket I just opened at http://trac.gnugo.org/gnugo/ticket/43
I witnessed recently something weird while analyzing some OWL reading. It happened that an owl attack against an isolated (invading) stone succeeded (at stackp == 14 or so), just by tactically capturing that original lonely stone, despite the following facts: * the original stone had been at some point cut off from the goal * the rest of the group built along the variations had managed to get life The appended patch is an attempt (IMO incomplete, see below) at fixing this problem. Breakage: auto02:7 PASS 1 S15 [1 (S15|R15)] auto02:8 PASS 1 M18 [!0] Nodes counts: Total nodes: 1651143209 3235170 11909903 I didn't bother analyzing those passes, because the patch looks so much like a bugfix that I strongly doubt that they could be accidental. Moreover there are problems I'd like to discuss before going further. The first problem I can see with this patch, is that it doesn't fix the problem: it is still possible that an owl reading focuses on a target (the str parameter) which is no longer part of the goal. This is due to the fact that I followed the convention previously used for captures in the new static function select_new_goal_origin(), namely that the new origin has to be one of the original strings under attack. Which brings me to the second topic. Given the above mentioned convention, it is likely that GG will refuse to sacrifice a light invasion stone for the sake of making a group alive in the opponent's sphere of influence. Conversely, GG might be too optimistic in the treatment of such opponent stones filled with aji when the opponent is invading GG's moyo. A test of a different policy (use whatever string still present in the goal as new origin) is quickly done and shows 11 passes and 18 failures. Do you guys think this issue is worth investigating or did I miss some important point ? -- nando PS: I'm not too sure how to handle the new trac service and the list, is it ok to use both and duplicate, or is there a better (or preferred) way ? _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
