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

[Arend Bayer]

On Mon, 9 Sep 2002, Markus Enzenberger wrote:

>
> > Are you calling reset_engine()? You have to do so after every change to
> > the board position before you call examine_position. gg_srand also gets
> > called automatically from there.
>
> I need to call gg_srand before init_gnugo to make init_gnugo work.
>
Ah I see, hashdata_recalc is called from there. We should move the
gg_srand(random_seed) to init_gnugo.


> 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.
How did that happen? Was it caused by an undo or play_move?

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

Well, clearing the reading cache is not necessary as far as I can see,
so you could just comment out the call there from reset_engine() and
call it yourself once the board has really changed. But the other part
of reset_engine() is to tell examine_position that the results about worm
status' etc. are no longer valid; so the speed-up you got by not calling
reset_engine() was mostly due to incorrectness I am afraid.

Arend