Re: [gnugo-devel] New semeai patch

[Arend Bayer]

On Sat, 5 Jul 2003, SP LEE wrote:

> In the attached game of gnugo 3.3.22 played on NNGS, gnugo played rather
> strangely, lost a winning game. This is a good case of semeai, black should
> play R12, but gnugo played O13 which gave white a lot of chance to thrash
> around.
>
>    A B C D E F G H J K L M N O P Q R S T
> 19 . . . . . . . . . X O . . . . . . . . 19
> 18 . . X . . . . . . X O . O . X . . . . 18
> 17 . . . . . . X X . X O . . O . . . . . 17
> 16 . . . X . X O O X X O . X . . X . . . 16
> 15 . . X X . X X O O O O X . . . . . . . 15
> 14 . X . X O O O O . . O X . X X . . . . 14
> 13 . . X O O . . O X X X O X . O X X . . 13
> 12 . X X O . . X X O X O O O O O O . . . 12
> 11 . O X O X . . . O X X X O . X . . . . 11     WHITE (O) has captured 2
> stones
> 10 . O O X X X X . O X . X O . X X . . . 10     BLACK (X) has captured 2
> stones
> 9 . X O O . O X O O . O X O O O . X . . 9
> 8 . . X O O . O . O . O X X X . O X X . 8
> 7 . X . X O O X O O . . X . O O O O X . 7
> 6 . . X . X X X . . O . . X X X O O X . 6
> 5 . . . . . . . . X . O . X O X O X X . 5
> 4 . . . X . . . . . X . O . O X X O O . 4
> 3 . . . . . . . . . . X . O . O O X O . 3
> 2 . . . . . . . . . . . . . . . . . . . 2
> 1 . . . . . . . . . . . . . . . . . . . 1
>    A B C D E F G H J K L M N O P Q R S T
>
> Then I found that the semeai module only generates one move if it's a
> winning move.

That's indeed a problem.

> The attached patch will put all outside liberties of the
> opponent group under semeai on the move list if the semeai module thinks
> filling outside liberty can win the semeai. Self atari liberties will not be
> counted as candidate moves. Also if the result of semeai module is a ko or
> snap-back, only this move is a candidate.

We discussed this briefly on NNGS a while ago, and I still think this
patch is a little too optimistic. For example, the winning move could be
the nakade point of 3-pt eye, and you would add all outside liberties as
semeai winning moves, too. Or the move found could be blocking an
important connection, or capturing important cutting stones,...

What I think we need instead is a find_more_semeai_moves() function
in value_moves.c. The moves you are considering would be very good
candidates for such a function.

Btw, in the problem above, I also feel that the semeai module itself
should try R12 before O13. So this looks like a move ordering problem in
do_owl_analyze_semeai.

Arend