Re: [gnugo-devel] Interference of break-in code with territory estimation

[Arend Bayer]

> 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.
> 

The break-in code is allowed to overrule owl decisions. In this case, it sees
that from the alive stone R3, black can connect to the stones at N2 (by
playing at Q3 or Q1). Hence these stones cannot logically be considered
captured by white.

The only problem is that breakin.c isn't aware of ko results yet, which it
would need to be to correctly evaluate the position above. But it definitely
undestands the position better than the owl code.

Arend