[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnugo-devel] Interference of break-in code with territory estimation
From: |
SP LEE |
Subject: |
[gnugo-devel] Interference of break-in code with territory estimation |
Date: |
Thu, 24 Jul 2003 10:31:27 -0700 |
In my experiment I analyzed the case in trevord.tst:260, which is
loadsgf games/trevor/auto/d02.sgf 142
260 reg_genmove white
#? [Q2]
Although currently the result is correct, the territorial estimate is terribly
wrong.
A B C D E F G H J K L M N O P Q R S T
19 . . . . . . . . . . . . . . . . . X . 19
18 . . . O O O X . . . . . . . . . X O O 18
17 . . O . X O X X . . . . . . . . X X O 17
16 . . O X . X . X . + . X . X . X . O . 16
15 . . O O X . X . . . . . . . X . O X . 15
14 . O X X . . . . . . . . . . . . O O . 14
13 . O . . . . . . . . . . . X X X X O . 13
12 . X X . . . . . . X X X X O O X X O . 12
11 . . . . . . . . . . O X O . O O O . . 11
10 . . . + . . . . . + O X O O O + . . . 10
9 . . X . . X . . . X O O O . . . . . . 9
8 . . . . X O . X X X X . . . . O O . . 8
7 X X . . X O . . X O . O . . O . O O . 7
6 O X X . O . O . . O . . . . . O X X . 6
5 O O X . . . . X X O . . . . . . O X . 5
4 O . O O . . X . X + . O . O . O . X . 4
3 . O O . . O O X X O O X O O . . X . . 3
2 . . . . . O X O O X X X X O X . . . . 2
1 . . . . . . . . . . . . . X . . . . . 1
A B C D E F G H J K L M N O P Q R S T
When white plays at Q2, 7 black stones are captured and the territorial change
is more than 20 points. However, gnugo only see 8 points. The debug output is:
Q2: owl attack/defend for M3
Erasing territory at N1 -b.
Erasing territory at M3 -b.
Erasing territory at N2 -b.
Erasing territory at K2 -b.
Erasing territory at L2 -b.
Erasing territory at L2 -b.
Erasing territory at M2 -b.
Q2: - P4 territory change 1.00 (0.00 -> 1.00)
Q2: - P2 territory change 1.00 (0.00 -> 1.00)
Q2: - H1 territory change 1.00 (0.00 -> 1.00)
Q2: - J1 territory change 1.00 (0.00 -> 1.00)
Q2: - K1 territory change 1.00 (0.00 -> 1.00)
Q2: - L1 territory change 1.00 (-1.00 -> 0.00)
Q2: - M1 territory change 1.00 (-1.00 -> 0.00)
Q2: - Q1 territory change 1.00 (-1.00 -> 0.00)
Q2: 8.00 - change in territory
Q2: - M3 territory change 1.00 (0.00 -> 1.00)
Q2: - K2 territory change 1.00 (0.00 -> 1.00)
Q2: - L2 territory change 1.00 (0.00 -> 1.00)
Q2: - M2 territory change 1.00 (0.00 -> 1.00)
Q2: - N2 territory change 1.00 (0.00 -> 1.00)
Q2: - O1 territory change 1.00 (0.00 -> 1.00)
Q2: 6.00 - total followup value, added 6.00 as territorial followup
Q2: 3.00 - added due to followup (6.00) and reverse followup values (0.00)
Q2: 0.20 - connects strings (connect value 2, shape factor 0.040)
Move generation values Q2 to 11.20
Then I found the "erasing territory" comes from the break-in code. I suppose
this "erasing" work may result in not seeing the captured stones in the
function influence_delta_territory, so that the estimated territorial value is
too low. This would have a great impact on the move valuation and I think the
break in code needs to be checked on this point.
SP Lee
- [gnugo-devel] Interference of break-in code with territory estimation,
SP LEE <=