[gnugo-devel] Critical dragons and cache problem

[Stéphane Nicolet]

Here is another example of cache issues affective the
critical status of groups. In the following game Black
plays C13 at move 64, threatening to catch C15-16 in a
ladder and to revive its dead corner.

    White (O) has captured 0 pieces
    Black (X) has captured 0 pieces

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


Gnu Go correctly see that and protects the corner when launched with

   gnugo -l cache_problem.sgf -t -T --until 64 --mode ascii


However when gnugo plays through the whole game, the engine now thinks
that the Black B16 and C17-18 stones are dead (even if it correctly
acknowledges that C15-16 are critical for White). It plays C12, letting
the corner die, which cost maybe 20 points since it means D17-E17-G17
becomes weak as well.

   gnugo -l cache_problem.sgf -T --replay white


This is probably a cache problem : as I anderstand it, the last move
(Black C13) is probably not in the active area used for the owl-reading
of C16 and C17 when they were put dead in the cache.

But I really think we should do something about critical situations
like that, because it means we can fine-tune the regression at will
and still see gnugo play blunders in similar situations in real games.




If this is indeed a cache issue, I can see two ways to solve it :

   1) extend the active area, maybe including second-order liberties
      of stones used to kill a group.

   2) add a rule in examine_position() which says that any dead
      opponent worm adjacent to an own owl-critical dragon should be
      tested owl-critical with the cache, whatever the cache thinks.

   3) any better idea ?


I don't know how to do (1) at the moment nor if it is a good idea.
If nobody objects, I would like to implement (2) and see how it works.


Stephane

cache_problem.sgf
Description: Binary data