Re: [gnugo-devel] owl testcase

[Gunnar Farneback]

Evan wrote:
> A simple owl testcase from a game today.

A wonderful illustration why static eye analysis is so terribly
difficult. The position in the lower right corner is this:

. . X . O . . . . 8
. O . X O . . . . 7
. O X X X O . . . 6
. O O X O O O O . 5
. . . X X O X . O 4
. O . X O O X . O 3
. . O O X X . X X 2
. . . . X . . . . 1
L M N O P Q R S T

The black eyeshape is of the type

 h
....

or if we expand the halfeye

 !
 .
....

which indeed is worth 2 eyes and life. However, white finds an owl
pattern to try to attack at R1 (only chance, of course). After that we
might expect the eyeshape to turn into

 !
 .
.X..

(which is what the local game model requires) but that is not what
happens. In this position

. . X . O . . . . 8
. O . X O . . . . 7
. O X X X O . . . 6
. O O X O O O O . 5
. . . X X O X . O 4
. O . X O O X . O 3
. . O O X X . X X 2
. . . . X . O . . 1
L M N O P Q R S T

black can no longer safely (in the tactical sense) play at S3 (white
attacks at S1) so the topological analysis declares R2 to be a false
eye, and we get the eyeshape

 !
.X..

which is only worth one eye. Then of course, if black would try S1 the
eyeshape unexpectedly transforms to

 !
 .
.X .

and two eyes.

I think it's clear that correct eye analysis in cases like this would
require reading. Two questions appear:

1. How do we find relevant moves to read without getting a too slow
   analysis?
2. What data structure would be appropriate for reading?

/Gunnar

PS If a white stone is added at O1 in the original position, there is
still no way for white to kill all black stones in the corner,
although it requires an under the stones tesuji to save black.