[gnugo-devel] A connection case

[Portela Fernand]

Following position occured in a twogtp game :

   A B C D E F G H J K L M N O P Q R S T
19 . . O X X . . . . . . . . . . . . . . 19
18 . O . O X . . . . . . . . . . . . . . 18
17 . . . O X X . . . X . . . X . . . . . 17
16 . . . O . O X . . X . . . . . + X . . 16
15 . . . . . O X . . . . . . . . . . . . 15
14 . O O O . . . . . . . X . X . X . . . 14
13 . X . . . . . . . . . . . . . . . . . 13
12 . . X . . . . . . . . O . . O . X . . 12
11 . . . . . . . . . . . . . . . . . X . 11
10 . . . + . . . . . + . . . . O + O . . 10
 9 . . X . . . . . . . . O . . . . . . . 9
 8 . . . . . . . . . . . . . . O . . . . 8
 7 . . . . O . . . . . . . . X . . . . . 7
 6 . X X . . . . . . . . . . . . O O O . 6
 5 . O . . . . . . X . . . . X . O X X . 5
 4 . X O O . O . O . + X . . . . + X . . 4
 3 . O O . . . . . . O O . X X . X . . . 3
 2 . . . . . . . . . . . O O X . . . . . 2
 1 . . . . . . . . . . . . . . . . . . . 1
   A B C D E F G H J K L M N O P Q R S T

Black (X) just played S11 and GG is now thinking for White (O). The
owl_status display indicates that GG didn't amalgamate R10, most probably
due to a CB17 pattern match (the tower poke at Q11 I guess)

           owl_status display:

   A B C D E F G H J K L M N O P Q R S T
19 . . z A A . . . . . . . . . . . . . . 19
18 . z . z A . . . . . . . . . . . . . . 18
17 . . . z A A . . . A . . . B . . . . . 17
16 . . . z . z A . . A . . . . . + B . . 16
15 . . . . . z A . . . . . . . . . . . . 15
14 . z z z . . . . . . . B . B . B . . . 14
13 . C . . . . . . . . . . . . . . . . . 13
12 . . C . . . . . . . . y . . y . B . . 12
11 . . . . . . . . . . . . . . . . . B . 11
10 . . . + . . . . . + . . . . y + x . . 10
 9 . . C . . . . . . . . y . . . . . . . 9
 8 . . . . . . . . . . . . . . y . . . . 8
 7 . . . . w . . . . . . . . D . . . . . 7
 6 . C C . . . . . . . . . . . . y y y . 6
 5 . w . . . . . . E . . . . D . y D D . 5
 4 . F w w . w . w . + G . . . . + D . . 4
 3 . w w . . . . . . w w . D D . D . . . 3
 2 . . . . . . . . . . . w w D . . . . . 2
 1 . . . . . . . . . . . . . . . . . . . 1
   A B C D E F G H J K L M N O P Q R S T

I was surprised to observe that GG didn't think that S10 would connect
R10 to the Q6 dragon. In the debug output, following can be observed :

pattern 'Conn106'+7 matched at S10
pattern 'CB101'+2 matched at H10

The absence of '...connects (...)' indicates that the engine rejected S10
as a connecting move. Looking at the code now, I find in shapes.c :

  if ((class & CLASS_C) && experimental_connections) {
    for (k = 0; k < my_nstrings; k++)
      for (l = k+1; l < my_nstrings; l++) {
        if (disconnect(my_strings[k], my_strings[l], NULL)
            && !play_connect_n(color, 0, 1, move,
                               my_strings[k], my_strings[l])) {
          add_connection_move(move, my_strings[k], my_strings[l]);
          TRACE("...connects strings %1m, %1m\n",
                my_strings[k], my_strings[l]);
        }
      }
  }

Indeed, since P10 and R10 cannot be cut, the connection move is ignored.
The problem I see here, is that absolutely no move will be considered as a
connecting move, not even the solid connection at Q10. Confirmed, I can
find in the debug output :

pattern 'Conn101'+0 matched at Q10
pattern 'Conn101'+1 matched at P9

I thought about changing the test to following :

        if ((!is_same_dragon(my_strings[k], my_strings[l])
             || disconnect(my_strings[k], my_strings[l], NULL))
            && !play_connect_n(color, 0, 1, move,
                               my_strings[k], my_strings[l])) {
          add_connection_move(move, my_strings[k], my_strings[l]);

but this is incorrect. In the above presented case, this code doesn't
guaranty that the problem caused by an X move at Q11 is solved (although
it's the case here). On the other side, a possibly overvalued 'connection
reinforcement' is maybe better than nothing.

Still, I think it stays out of question to solve the issue by adding lots
of patterns to deal with these fragile double connection cases. And I see
no clear way to deal with it algorythmically.

/nando