Re: [gnugo-devel] Opponent not passing

[Daniel Bump]

> >In this case, GNU Go will believe all liberties have been
> >filled, so the opponent's last move either fills his own
> >territory, in which case it is definitely safe to continue
> >passing, or it adds a stone to a dead dragon. In the latter
> >case, to generate a move, change the status of the dragon
> >to ALIVE then generate a move. This should produce an
> >endgame move blocking off territory, hence tending to
> >surround the dragon that's trying to come back to life.
> 
> This is an interesting suggestion, however, I'd be concerned about
> what would happen in seki situations, for example.  An advantage 
> to generting an aftermath move is that it's guaranteed to be safe,
> and is nearly trivial to implement.  This is not the kind of
> situation that will occur very often, so simple seems appropriate.

I think if we're going to make changes along the lines it
will pay to do it right. Calling aftermath is not the
right approach. This type of situation will happen often
enough to matter, since it frequently happens that the
opponent will try to make some trouble in GNU Go's
territory, and GNU Go may pass or tenuki. It happened
today, for example, see GNU Go's tenuki at move 201
of niko-gnugo-3.1.23-200202031722.sgf, available at
http://www.lysator.liu.se/~gunnar/gnugo/nngs/.

About implementation difficulty, we already do something
like this in genmove around line 453. 

The issue with seki might come up if GNU Go misevaluates
the opponent's seki stones as DEAD. Hopefully soon such
a dragon will reliably have safety ALIVE_IN_SEKI. But in
any case this slight danger can be handled by making the
move subject to confirm_safety.

Dan