[gnugo-devel] A tale of two semeai

[Daniel Bump]

My personal goal for 3.2 is to write a decent semeai module.
I think such a module has to do reading, it can't be done by
static analysis as the current analyze_semeai does. I made an
attempt at this once, in the function do_owl_analyze_semeai.
It doesn't work too well.

The game regression/games/pooo.sgf (now in the CVS) is the
basis for strategy4.tst contains two examples of semeai,
one in the bottom left, and one in the top left. In one,
analyze_semeai is called inappropriately. In the other,
it should be called but isn't.

At move 24 of pooo.sgf. After adding one owl pattern, the owl
code correctly sees that B6 kills but still GNU Go does not
play.

Pattern A333
# db added (3.1.10)

OO.?            Jump and block
....
X*.?
...?
----

:8,-,value(75)

This is because the worm at A2 is not recognized as
inessential. That is, the dragon2.safety field should be
classified as inessential. Because it isn't, analyze_semeai
gets called. It thinks that since the stone at A2 dies
first all is well sets the matcher status to ALIVE.

We find worm[A2].inessential == NO and the dragon2[A2].safety
isn't INESSENTIAL either. But there should be enough clues
that A2 should be recognized as inessential. It has a unique
neighbor dragon, and it lives in that dragon's eyespace.

The second semeai occurs at move 74. This one was noticed
by Gunnar. In the top left, we would really like to play
at A15 to kill the corner. It would be good at this point
if analyze_semeai were called. Unfortunately, the owl code
isn't called on B15 because it's escape route is perceived
as too spacious. Consequently the dragon status is used
as matcher status and the dragon is thought alive. The
truth is if W plays first the position is seki.

Dan