Re: [gnugo-devel] arend_1_32.4: hash_(re_)init for new game (revision of gunnar_1_32.8)

[Heikki Levanto]

On Fri, Apr 12, 2002 at 10:29:08PM +0200, Arend Bayer wrote:
> [Heikki:]
> > I do like the fixed seed. 
> > 
> > Here is one way to check if a seed is bad: Generate a great number of moves
> > with different hash tables, and see if they produce the same moves. Even
> > better, verify that the top-10 moves are the same, with same values. If this
> > test works for 9 random seeds, and fails for one, we can assume (guess) that
> > the one seed is bad, and managed to produce hash collisions.
> 
> Note that if you get one hash collision in maybe 10000 games, than the
> seed is already a bad one. This would take quite some time to try out...

True, but the argument against a fixed seed was that it is better to have
1% of games play bad because of hash collisions, than to have 1% chance of 
always playing bad. 

To that I counter that we can measure the performance of any seed, and
reject the bad ones. Not to one collision in 10000 games, but well enough
to feel comfortable that we don't have a pathologically bad seed (1 in 10
or 100 games). 

Of course, in the long run, we will meet hash collisions no matter what we
do. All I want to do it to avoid the pathologically bad seeds, Comparing the
trace output of 10 or 100 games should be sufficient to notice any seed that
are obviously bad.

To sum up, I prefer not to have 1% of games playing badly, but rather to
have 1% chance of all games playing badly - after weeding out the bad seeds
and reducing the 1% to 0.001%, or something. But all of this is pretty
philosophical - has anyone ever run into a hash collision when debugging
why a move was made?

-H

-- 
Heikki Levanto  LSD - Levanto Software Development   <address@hidden>