gnugo-devel
[Top][All Lists]
Advanced

[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




reply via email to

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