gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] Semeai weirdness.


From: Gunnar Farneback
Subject: [gnugo-devel] Semeai weirdness.
Date: Fri, 14 Feb 2003 23:21:39 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Consider the position at the end of the NNGS game
gnugo-3.3.16-rcde05-200302140458.sgf (available in CVS), GNU Go is
white,

   A B C D E F G H J K L M N O P Q R S T
19 . O X . . . . . . . . . . . . . X O . 19
18 . O X . . . . . . X . . . . . X X O . 18
17 . O X . X X X X X O X X X X X X O . . 17
16 O X X X O O O X O O O O O O O X O . . 16
15 O O O O . O . O O O . O X X X X O . . 15
14 O X O . O X O O X X O O O O X X O . . 14
13 X X X O O X O X X O . O X X X X X O . 13
12 X X X X X X X X O O O O O O O X O O . 12
11 O X X X O O X O O X O X O X X X O . . 11     WHITE has captured 8 stones
10 O O O X O X X O X X X X O X . X X O . 10     BLACK has captured 3 stones
 9 . O O X O X X X . X . . X X X X O . . 9
 8 . . O O O O X . X O X X O X O O O . . 8
 7 . X O . O X X X X O O O O O O . . . . 7
 6 . O O . O X O X X O X O . . X . O . . 6
 5 . O X . O X O X X X X O X X X X X O . 5
 4 O X . X O X O X O O O X O . O X O O . 4
 3 O X X O . O O X O X X X O O O X X X O 3
 2 O X X O O . . O O X . X O X O O X . X 2
 1 . . X . . . . . . . X O O . . . X O . 1
   A B C D E F G H J K L M N O P Q R S T

A problem here is that the groups on the bottom are unstable. Black
(X) has the tesuji at G2 to get ahead in the semeai between M4 and N4.
There are many shortcomings in the analysis of this position, which
admittedly isn't easy for GNU Go. What I'd like to concentrate on is
the behaviour of the semeai code. This is what DEBUG_SEMEAI tells when
generating a move for black:

Considering semeai between P6 and N4
semeai worm: P6
semeai worm: N4
Result1: DEAD ALIVE PASS, semeai worm: P6
semeai worm: N4
Result2 ALIVE DEAD.
Changing status of S1 from DEAD to ALIVE.
Changing safety of S1 from INESSENTIAL to ALIVE.
Considering semeai between M4 and N4
semeai worm: M4
semeai worm: N4
owl_substantial L1, result 1 (1, 4 nodes, 0.01 seconds)
semeai worm: L1
Result1: DEAD ALIVE PASS, semeai worm: M4
semeai worm: N4
semeai worm: L1
Result2 ALIVE DEAD.
Changing status of N4 from CRITICAL to ALIVE.
Changing safety of N4 from CRITICAL to ALIVE.

It's unfortunate that it misreads the semeais, but what's really
interesting is comparing this to the debug output when generating a
move for white:

Considering semeai between N4 and M4
semeai worm: M4
semeai worm: N4
owl_substantial L1, result 1 (1, 4 nodes, 0.01 seconds)
semeai worm: L1
Result1: ALIVE DEAD J1, semeai worm: M4
semeai worm: N4
semeai worm: L1
Result2 DEAD ALIVE.
Considering semeai between N4 and P6
semeai worm: P6
semeai worm: N4
Result1: ALIVE DEAD K1, semeai worm: P6
semeai worm: N4
Result2 DEAD ALIVE.
Changing status of N4 from CRITICAL to ALIVE.
Changing safety of N4 from CRITICAL to ALIVE.
Changing safety of O2 from TACTICALLY_DEAD to DEAD.

As far as I can tell the semeai results are consistent but the status
and safety modifications are not. Why is this? It doesn't make sense
to me to let the status of dragons vary with the color to move.

Apparently the function new_semeai() in semeai.c is responsible for
this. It's not very easy to read but it seems clear that it's not
symmetrical with respect to the color to move. I'm also fairly certain
that the declarations of a_status and b_status on lines 247 and 248
are buggy since they shadow an earlier declaration of the same
variables at the top of the function. As a result the if statements on
lines 232 and 238 can never be true.

/Gunnar




reply via email to

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