[Top][All Lists]

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

Re: [Bug-gnubg] unwanted extension of rollouts

From: Robert-Jan Veldhuizen
Subject: Re: [Bug-gnubg] unwanted extension of rollouts
Date: Mon, 04 Aug 2003 00:21:24 +0200

At 15:10 8/3/2003 +0200, you wrote:
On Sun 03 Aug 2003 (01:30 +0200), Robert-Jan Veldhuizen wrote:
> Hi,
> When I complete a rollout with certain settings, like f.i. truncated at 8,
> 216 trials and then change to truncated at 16, 648 trials and try to
> rollout again, it starts at trial 217 (using the earlier results). Could
> this be changed so that any sort of change in rollout settings (apart from
> the number of trials) discards old results and starts a brand new rollout?
> Otherwise the feature is excellent!

Trivial fix - click on 0 ply evaluation, which takes no time, then do
your rollout - it will be with the current settings, not the ones from
the previous rollouts.

Yes, that's what I'm using now. This loses previous rollout results though, and one might like to compare two rollouts with different settings directly to each other.

Re: discarding results on a change in rollout setting?

How would you distinguish between a change made just for this one move
and (for example) a change made when rolling out some other move or a
cube decision?

It seems like GNUBG stores rollout parameters for each move/decision individually. So GNUBG might check current rollout settings, compare to stored rollout settings, and only resume an earlier rollout if the current settings are the same as those of the older rollout, except for more trials. Otherwise, GNUBG could start a new rollout from trial 1.

 What do you do with rollout results in an .sgf file
when you open that file?

Identical to the above?

I prefer the 'carry on where you left off', because it's so quick to
force the rollout to be forgotten by using 0 ply evaluation.

Well it's not a big deal, but I think it would be nice if GNUBG itself detects whether an old rollout should be resumed, or a new one should start. When the user changes settings, he obviously doesn't want the older rollout with different settings to resume, but a new one to start?

Robert-Jan (Zorba on FIBS)

reply via email to

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