Re: [Bug-gnubg] Ver 0.90 -- "extending" rollout doesn't extend the rollout

[Jim Segrave]

On Fri 04 Jul 2008 (14:36 +0200), Christian Anthon wrote:
> Hi Daniel,
> 
> Okay, I think I understand the problem now. It used to be so that the
> random numbers for the game where seeded by a function depending on
> the global seed and the trial number. In the multithreaded code, the
> seed function depends on the global seed and the trial number in the
> current batch. That is the seed of the first game in the _new_ batch,
> will match that of the first game of the _old_ batch...
> 
> The problem is the following:
> 
> InitRNGSeed(prc->nSeed + (i << 8), prc->rngRollout, rngctxRollout);
> 
> where "i" used to be the trial number, but "i" now counts from zero
> each time you stop and restart a rollout. The old code probably didn't
> do the right thing either, for example when some candidates were
> stopped early because of statistics and the started again.

I think that's probably true. I believe I just continued with the RNG
only playing the positions that were behind (it would have been
possible to save the RNG for the stopped move to save the RNG state
when it stopped, but that code wasn't implemented
 
> The natural thing would be to replace "i" with altGamesCount[alt], but
> I'm not quite sure what the threading implications of this would be.
> What do you think Jon?

I'm curious about a few things in the threaded code like
this. Unfotunately, the ability to write .sgf files of games was
broken by the threaded code (each thread would need it's own file
descriptor, among other things), so checking if the various moves are
all rolled out the same is difficult

-- 
Jim Segrave           address@hidden