Re: [gnugo-devel] cosmic patch

[Gunnar Farneback]

Dan wrote:
> But the function gtp_reg_genmove explicitly sets the random seed to 0.
> So both regression runs were done with the same random seed 0.
> 
> But I tend to think that Stephane's observation that this test
> result depends on the random seed makes the spurious change seem
> less significant even if the exact mechanism is unclear.

The tables of Zobrist hash numbers are initialized when the engine
starts with the random seed specified when starting GNU Go (usually
none at all which means seed with current time). These are not
regenerated when the random seed is changed by e.g. gtp_reg_genmove.

Previously the Zobrist numbers never had any effect on the reading
(except in the extremely unlikely occurence of a board hash
collision). The new cache together with Evan's killer heuristic
changes this. The Zobrist numbers affect the placement within the hash
table implementing the cache. More to the point they affect which
positions/read routines/targets/komasters compete about the same
entries in the hash table. Due to the design of the new cache, it
doesn't matter much with respect to performance if some cached result
has to move out of the way, but it can affect the killer heuristic and
thereby the result of the reading.

The simplest solution to make the regressions deterministic once more
is to populate the Zobrist hash numbers from a fixed seed.

/Gunnar