Re: [gnugo-devel] Bug report gnugo-3.3.8

[Gunnar Farneback]

Markus wrote:
> I tried reset_position before each examine_position and managed to play 3 
> games (about 10000 calls to examine_position), then GnuGo crashed with:
> 
> ***assertion failure:
> board.c:909 - board[pos] == EMPTY near H8***
> 
>  (variation 538163)
>    A B C D E F G H J
>  9 . X . . X . . O X 9
>  8 X X O X . . X X X 8
>  7 X X X . X . O . . 7
>  6 . O . . . O X . X 6
>  5 . . . O O . . X . 5
>  4 . X . O O X . O O 4
>  3 X . + . . O O . . 3
>  2 . . . . O . O . . 2     WHITE has captured 0 stones
>  1 . . . . O O X . O 1     BLACK has captured 1 stones
>    A B C D E F G H J
> 
> gnugo 3.3.8 (seed 0): You stepped on a bug.

Can you reproduce this crash and/or produce a backtrace?

> Unfortunately reset_position before each examine_position slows down
> GnuGo by a factor of 5, which makes a training of NeuroGo not
> feasible. Since two subsequent positions where I call
> examine_position differ only by retracting and playing a move, I
> really would like to avoid the complete initialization and profit
> from the reading cache. Is there a way to do this?

Not with any reliability.

Roughly speaking reset_engine() does the following operations:
1. Clears the (non-persistent) reading cache.
2. Invalidates
   * partitioning of stones into worms and dragons,
   * influence computations,
   * status of worms and dragons.
3. Clears the lists of move reasons.

To avoid the crash you described in a previous message it would
suffice to do step 3.

Skipping 2 is probably what causes the great speedup but also means
that the engine may have completely wrong information about important
stones.

Skipping 1 has consequences somewhat similar to skipping 2 but
probably less pronounced.

If you don't mind a degradation in the quality of play you could try
to skip 1 or both 1 and 2 but I can't guarantee that the engine won't
crash or come up with illegal moves then.

A better (and supported) way to gain speed at the cost of strength is
to reduce the level setting.

I might add that GNU Go also has a persistent cache for the purpose of
reusing read results between moves. This you do benefit from even if
you call reset_engine() at each move.

/Gunnar