bug-gnubg
[Top][All Lists]
Advanced

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

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


From: Jim Segrave
Subject: Re: [Bug-gnubg] Re: Bug-gnubg Digest, Vol 9, Issue 9
Date: Tue, 5 Aug 2003 08:32:27 +0200
User-agent: Mutt/1.2.5.1i

On Mon 04 Aug 2003 (23:53 +0200), Robert-Jan Veldhuizen wrote:
> 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.

I guess there's the difference - I wanted extendability because I
often found that I needed more trials at the same settings. I don't
change the strengths very often.

> >  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)?

It saves the current settings (so you won't lose them). It then copies
the settings from the old rollout to the current settings with the
exception of the number of trials and the settings for stopping
(stopping on standard deviation or joint standard deviations. It does
the requested rollout and at the end puts the settings back to what
they were before the rollout.

This is done on a per move being rolled out basis, so you could, if
you had some reason to, extend the rollout two different moves one
with two ply and one with 0 ply evaluation or even one cubeful and one
not.

> >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.

That assumes the user knows what the settings were so they know if
they've changed them or not. As I pointed out above, you may need to
export the postion to find out what the rollout settings were. 

-- 
Jim Segrave           address@hidden





reply via email to

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