gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Heeroy game?


From: Daniel Bump
Subject: Re: [gnugo-devel] Heeroy game?
Date: Sun, 10 Feb 2002 07:33:49 -0800

Gunnar wrote:

> This game is a good case for generating aftermath moves if the
> opponent insists on continuing to play even though we have passed,
> like Trevor has suggested. When the aftermath code stops generating
> moves, *nothing* bad can ever happen to our living stones (*),
> regardless of rule subtleties, and dead opponent stones will stay
> dead.

I agree that the scheme I'd previously proposed in 
http://mail.gnu.org/pipermail/gnugo-devel/2002-February/001278.html
would not produce a move at move 458 in
heeroy-gnugo-200201251501, while the aftermath code does.

> My suggestion for how to handle this, assuming we have found no move
> up until fill_liberty(), is (in fairly abstract terms):
> 
> 1. If the opponent's last move was a pass, pass.
> 2. If we are behind and territory scoring is used, pass.
> 3. If we haven't passed during the last N moves, pass.
> 4. Generate a move to reinforce the stones adjacent to the dragon of
>    the last opponent move.
> 5. Generate a move to reduce the potential eyespace (in a very broad
>    sense) for the dragon of the last opponent move.
> 6. Generate an aftermath move.

I've put up a patch at devel.html called caution_1_25.1
which implements the following scheme. Note that since an
earlier patch the owl threats are now computed for thrashing
dragons. (If the opponent's last move is a dead stone in our
territory, the dragon it encompasses is called thrashing.)

Steps 1 and 4 are not taken if disable_threat_computation
is true, or if the owl threat status of the thrashing
dragon is CAN_THREATEN_DEFENSE. The hope is that if the
owl threat status is CAN_THREATEN_DEFENSE a prevent threat
move reason is generated but generating prevent threat
reasons is probably an area that needs more work.

The following steps are taken at the end of do_genmove.

1. If we are ahead by 15 points and the largest move found
is worth less than 10 points, change the status of the
thrashing dragon to UNKNOWN then generate a move.

2. As before the patch, if the largest move found is worth less
than 6 points generate an endgame move.

3. If no move is found, run filllib.

4. If we are ahead by any margin and no move has been found,
change the status of the thrashing dragon to UNKNOWN then
generate a move. If this can't be done, run revise_semeai().

5. If no move has been found, and we are ahead by 15 points
or more generate an aftermath move.

Testing this scheme with the heeroy and turbogo games
this seemed to generate pretty good moves instead of
the passes in those games. Most of the moves are not
contributed by the aftermath code, only two out of
many. One of the moves contributed by aftermath is
at move 458 from the heeroy game.

The patch breaks exactly one regression, producing a move
at T5 in strategy4:151.  However this is exactly the type
of safe move the patch is intended to produce.

Dan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]