Re: [gnugo-devel] connection reader speed optimization

[Arend Bayer]

On Sun, 28 Sep 2003, Paul Pogonyshev wrote:

> The patch gives a noticeable speedup (`time make fifth_batch'):

(...)

> Unfortunately, the regression delta is not zero:
>
> strategy:34     PASS E17 [E17]
> ego:10          FAIL L3 [S18]
> trevorb:510     PASS C6 [C6|B6]
> 13x13:13        PASS B11 [!G7]
> 13x13:45        FAIL B3 [B4]
> safety:3        PASS F13 [H15|H16|G14|F13|C17]
>
> I'm almost completely sure that these changes are caused by random
> changes in connection queue order (they are caused mainly by the
> delayed constraint evaluations).  However, if Arend could review the
> fails, it would be good (i'm not good at debugging break-in code
> because i don't understand all the details).

13x13:45: Short summary: This one is ok.
Here B3 is absolutely equivalent to B4, and the break-in code
is right in correcting the somewhat optimistic territory estimation
after Black B4. It does a little overcorrecting, so that B3 ends up
higher than B4, but that is a problem in breakin.c (not with your
patch).

ego:10: This is not ok.
After white S18, gnugo thinks black can get a ko with S16 and then T19. The
crucial variation is
(W S18) - B S16 - W R16 - B T18 - W S17 - B T17 - W S15 - B T16.
After your patch, gnugo thinks black has connected S16 with S19. Without
your patch, white tries the atari at T15 and sees that it succeeds due
to damezumari.
I have not yet studied your patch in detail, but it sounds as this might
be solvable.

The test case with which this reading happens is appended below.

Arend


loadsgf games/ego.sgf 190
start_sgftrace
trymove white S18
90 break_in R19 S16 S15 T16 T15
#? [0]
finish_sgftrace xx.sgf