Re: [gnugo-devel] regarding paul_3_13.8a

[Paul Pogonyshev]

Dan wrote:
> Do you mean I should back the patch out?
>
> If you want I'll back both paul_3_14.1 and paul_3_13.8b out of the cvs,
> or (if you want) I'll back out just paul_3_14.1.
>
> Nando pointed out that it is conceivable that the pattern Arend
> pointed out with D305 could be due to a captured goal element.

i just meant it could be buggy in the same way paul_3_13.8a _might_
have been. however, my investigations show neigther of them was
(almost for sure).

here is some debug output (with paul_3_14.1 and paul_3_13.8b
reverted):

D305 matched at C18:
   A B C D E F G H J K L M N O P Q R S T
19 . . . . . . . . . . . . . . . . . . . 19
18 . . . . O . . . X . . . . . . . . . . 18
17 . . X . . . X . . . X . O . . O . . . 17
16 . X . X O . . . . + . . . . . + . . . 16
15 . . X O . X . . . . . . . . . . O . . 15
14 . . X . . . . . . . . . . . . . . . . 14
13 . . . . . . . . . . O . . . . . . O . 13
12 . . . . . . . . . . . . . . . . X . . 12
11 . . X . . . . . . . . . . . . X O . . 11     WHITE has captured 0 stones
10 . . . + . . . . . + . . . . . + . X . 10     BLACK has captured 1 stones
 9 . . . . . . . . . . . . . . . . X . . 9
 8 . . . . . . . . . . . . . . O X . O . 8
 7 . . . . . . . . . . . . . . O X O . . 7
 6 . . X . . . . . . . . . . . O . X O . 6
 5 . . . . . . . . . . . . . O . O X . . 5
 4 . . . + O . . . . + . . O . X X . O . 4
 3 . . X . . . X . X . O . O X . . O . . 3
 2 . . . . . . . . . . . . . . . . . . . 2
 1 . . . . . . . . . . . . . . . . . . . 1
   A B C D E F G H J K L M N O P Q R S T
Goal at C16

this is just what nando wrote. the pattern is matched against "goal"
at C16. note that E18 is not listed in the goal array. this "match"
is very stupid.

if you are interested, i got this output with this piece of code
(a diff between two local files):

--- matchpat.c  Fri Dec 27 18:37:18 2002
+++ matchpat.debug      Fri Dec 27 18:37:13 2002
@@ -1087,6 +1087,25 @@ check_pattern_light(int anchor, matchpat

   /* A match!  - Call back to the invoker to let it know. */
   callback(anchor, color, pattern, ll, callback_data);
+  if (!strcmp(pattern->name, "D305")) {
+    int move = AFFINE_TRANSFORM(pattern->move_offset, ll, anchor);
+
+    for (k = 0; k < pattern->patlen; k++) {
+      int pos = AFFINE_TRANSFORM(pattern->patn[k].offset, ll, anchor);
+      if (goal[pos] && board[pos] != EMPTY)
+        break;
+    }
+
+    if (k == pattern->patlen) {
+      gprintf("%oD305 matched at %1m:\n", move);
+      showboard(0);
+      for (k = 0; k < pattern->patlen; k++) {
+        int pos = AFFINE_TRANSFORM(pattern->patn[k].offset, ll, anchor);
+        if (goal[pos])
+          gprintf("%oGoal at %1m\n", pos);
+      }
+    }
+  }

 #if PROFILE_PATTERNS
   pattern->reading_nodes += stats.nodes - nodes_before;


i also checked that if paul_3_13.8a is applied to the current cvs
minus paul_3_14.1 minus paul_3_13.8b, then it no longer fails
global:4 and 5. so, they are fixed by some other patch (probably
nando_3_14.2), not by difference between paul_3_13.8b + paul_3_14.1
and paul_3_13.8a.

this doesn't uncover the real reason of failures in global.tst since
mismatched D305 was far away from Q6 point and could barely affect
move valuation. however, i think it must be just another pattern that
was matched against empty goal, just as D305. if Arend shows the way
he discovered that D305 wasn't matched in several cases, i'll be
able to check it.

Paul