[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gunnar Farneback
Subject: Re: [gnugo-devel] arend_1_32.4: hash_(re_)init for new game (revision of gunnar_1_32.8)
Date: Thu, 18 Apr 2002 20:56:28 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Arend wrote:
> Hmm I don't like this idea, but maybe I am not very rational about it.
> I wonder whether there is a way to avoid a "bad seed"? Say if there is a
> 1% of choosing a bad seed (i.e. making hash collisions more likely), I'd
> rather have a bad seed in 1% of the games than have a 1% chance of having
> a bad seed in all games.

No, I don't think you're very rational about it. To begin with we have
never had any indications at all of bad Zobrist numbers, so I think
bad seeds would be extremely rare. Second hash collisions depend both
on the Zobrist numbers and the moves actually played (in the trymove()
sense), so we would hardly get it in every game anyway. Third, the
behaviour of a fixed seed can plausibly be analyzed in detail,
something which is much harder to do for the whole spectrum of random

The main argument for a fixed seed, however, is that it's more robust
in a code maintenance sense. Having to remember to reinitialize hash
values every time one changes the random seed is a burden we don't

But for the time being, i.e. for 3.2, I won't change the behaviour at
all. We have no indication that we have any real problem with the
Zobrist numbers, and I'd rather avoid this late change.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]