[Bug-gnubg] Re: Bug-gnubg Digest, Vol 9, Issue 9

[Robert-Jan Veldhuizen]

At 12:01 8/4/2003 -0400, Jim Segrave wrote:

> > 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?
>
> My thinking was that the most common operation would be someone
> rolling out some moves in a game, going back to look at the results
> later and deciding that some moves need to be rolled out further (in
> particular when the Python scripting gets more complete, this would be
> a very sensible thing to do).

Well, I don't know how other users work with GNUBG of course. Personally, 
I'm almost always improving play settings, mostly increasing the truncation 
point/make it a full rollout, changing cube play from 0-ply to 2-ply, 
changing checker play from 0-ply to 2-ply.

Doing more trials with the same settings usually just makes sense if the 
initial rollout was not statistically accurate enough. That happens quite 
regulary of course, especially if you do a first rollout, but once you have 
enough trials improving play settings are probably the most often made changes.

>  But to resume a rollout, either gnubg
> needs to remember what settings you were using (so it automagically
> resumes what you were doing before)

Well since GNUBG stores this information, doesn't it make sense to use it? 
There's really no "magic" about it I think. It seems more magical to me as 
it is right now, resuming some old incompatible rollout when I just changed 
all my rollout settings and press "rollout", obviously to start a new 
rollout with these settings.


>  or you need to figure out what
> settings you were using, which might mean exporting the position just
> to see what the settings were, then go in and manually set the rollout
> back to the way it was before. One tiny mistake and the results are lost
> forever.

If a user decides to change rollout settings and press rollout, I think he 
knows previous results will be overwritten. It works the same for 2-ply, 
3-ply, rollout etc.

BTW, as it works right now, I'm not even sure what GNUBG really does when 
it resumes. Does it resume an old rollout and ignore all my settings 
changes except for the # of trials? Or does it mix the old result with the 
new settings rollout (which really makes no sense at all, practically 
speaking)?



> Maybe the best solution is a pop-up dialogue box that warns you that a
> move you have selected for rolling out was rolled out with different
> settings than the current ones with options to
>
>    Cancel/Start Over/Extend Using Original Settings
>
> would address this best?

Maybe that's an idea. Personally though I think the responsibility for 
extending a rollout or starting a new one with new settings lies with the 
user. If the user changes rollout settings beyond just the number of 
trials, I think he will realize that means a new rollout starts when you 
press rollout after that.


--
Robert-Jan (Zorba on FIBS)