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

[Robert-Jan Veldhuizen]

At 15:29 8/7/2003 +0200, you wrote:
> On Thu 07 Aug 2003 (01:12 +0200), Robert-Jan Veldhuizen wrote:
> > At 08:32 8/5/2003 +0200, you wrote:
> > >On Mon 04 Aug 2003 (23:53 +0200), Robert-Jan Veldhuizen wrote:
> > >> At 12:01 8/4/2003 -0400, Jim Segrave wrote:
> > >>
>
> > So... wouldn't it be logical to extend then if either:
> >
> > - settings are the same (GNUBG can read or even copy those from the 
> rollout
> > result already there)
> >
> > or
> >
> > - the user asks GNUBG to resume, then GNUBG uses the old settings and asks
> > for the new # trials.
> >
> > And for all other cases, just start a new rollout with the new settings?
>
> I can see some more things that would have to be addressed:
>
> You analysed a match or a move and perhaps posted it somewhere like
> Gammonline. Someone suggests that some unlikely move would actually
> have been a better choice and claims that your original rollout was
> too short to be definitive. You reload the match with your rollout and
> you want to:
>
> 1) extend the rollout of the original move
> 2) rollout the newly suggested move
>
> How does gnubg deal with this? How is it easily show you what settings
> the original rollout used?

This is an interesting problem. I think more generally, it would be a good 
feature if GNUBG could set rollout settings from an earlier result.

Something like you select a rollout result, and "use these rollout 
settings"; somewhat similar to how a paint program allows one to select a 
pixel and use that ink color from there.

Action 1) doesn't seem too much of a problem. Select the original move, 
give the user a resume button and GNUBG will then use these old settings, 
and give the user a choice of the number of trials. It could default to the 
number of trials that were finished in the old rollout, f.i. Even without a 
resume button, or if the user inadvertently chose the "(new) rollout", 
GNUBG could detect all settings are the same except for the  number of 
trials, and then either resume per default or ask/warn the user that he can 
resume an old rollout with these settings, or start a new one.

Action 2) would be simple if one can copy rollout settings from a result to 
the actual settings, as I suggested above. Then you "copy" the settings by 
selecting the original move, and resume both rollouts from there. Lacking 
that, one would have to find out the original settings himself (easy if you 
already exported before!) and set those manually.


| > Well I had no clue about that really. GNUBG does a lot by itself here
> > without asking for it IMO. At least it could let the user know old 
> settings
> > were used, and which ones they are exactly?
>
> Where? They will show up if you export the move to
> HTML/GOL/text/pdf. There is no place within gnubg where you can see a
> rollout result and the settings used from within the game.

Indeed, however it used to be so that whenever a user started a rollout, 
current rollout settings would be used. Usually settings the user just 
made/changed, so he would probably know what the current rollout is using. 
He could stop the rollout and check rollout settings, or check them after 
the rollout has finished if he wasn't sure.

With this auto-resume, GNUBG is doing a rollout with different settings 
than the current rollout settings, and the only way to check is an 
export/copy. Let's just say I think that's not ideal, I think I made my 
point there by now :-)



> > >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.
> >
> > If I understand correctly, this means the following could happen:
> >
> > I select two moves (that somehow already have a rollout done), change the
> > rollout settings, press rollout and instead I get two resumes of rollouts
> > done, each with different settings than I just entered and also different
> > to each other?
> >
> > This logic is really beyond me I think.... :-)
>
> There is a logic to it - it's planning ahead for better scripting. The
> rollout code does not require that all the moves being rolled out are
> from the same position in a game or match (it can only handle one cube
> decision at a time for now). I can imagine someone analyzing a
> complete match and using different rollout settings at different
> stages of the match - sometimes you are only interested in what will
> happen over the next few rolls, after which a 0 ply rollout will
> suffice, sometimes you want a full untruncated 2 ply rollout, etc. The
> code is designed to support being passed a collection of moves, each
> with its own cube value and owner, match score, rollout settings etc.
>
> There are things that you can do which probably aren't useful -
> comparing a 0 ply truncated rollout with a 2 ply untruncated rollout
> of different move for the same roll is unlikely to be useful.

Well that makes sense, but I still dislike the idea that GNUBG - without 
asking - does a rollout with different settings than those in the current 
rollout settings. If I give a rollout command I'd think the current rollout 
settings would be used for that.

| > >That assumes the user knows what the settings were so they know if
> > >they've changed them or not.
> >
> > If one hasn't changed the settings, they'll obviously be the same as last
> > time.
>
> That may not be the case if you've loaded a saved match or if you've
> been using different settings when looking at different situations
> within a game or match.

True, for those cases, a kind of "copy rollout settings" would come in 
handy. A function like that may even be handy in general, to quickly set 
all rollout parameters in one go.


> > Besides, GNUBG could tell the old settings to the user, or just offer a
> > "resume rollout" command?
>
> OK, but take the case where you rolled out one move and now you want
> to roll out a different one for comparision. Your choices are:
>
> rollout the second move using the same settings as the first one
>
> discard the rollout of the first move and roll both out with the
>   current settings
>
> do neither and let the user adjust the current settings to match the
>   saved ones.
>
> Adding a graphical display to show the original settings is a
> non-trivial undertaking. Something coule be added like Analyse->Show
> Move Analysis to produce a display equivalent to
> File-Export->Position->Text produces.

Personally I'd think a "copy rollout settings" might be easiest here, both 
for the user as for the program(mers)? Then the user could rely upon 
settings being the same, so a resume can start, and the resume will  be 
reliable as well. To check settings, if the user still wants that, he could 
just check the current rollout settings after copying them from the older 
rollout result.


> > Right now, the opposite problem is IMO just as bad: I change my rollout
> > settings to start a new rollout and GNUBG uses some older rollout ANd 
> older
> > settings, which I might not remember what they were.
>
> But you do have an easy way of knowing if this is going to happen - if
> the current analysis says it's a rollout, then it will be extended. If
> it doesn't, it won't

Yep.. which for me comes down to knowing GNUBG is gonna be doing the wrong 
thing 95% of the time ;-) It's easy enough to press 0-ply everytime, but 
quite annoying after the 100th time... and while I only got myself to blame 
for this, I do forget it sometimes! If I don't notice that (f.i. by 
starting to work on something else), this can be really annoying.

| > Anyway, I think the best solution to make both the "resumers" and the "new
> > settings" users happy is a seperate "start new rollout" and "resume old
> > rollout" command or something similar. That seems both more user-friendly
> > as a lot clearer as to what GNUBG is doing.
>
> What does it say if you select two moves, one rolled out and one not?
>
> I'm not deliberately being difficult, I'm trying to see how people
> think it should work. I am positive that simply discarding results if
> there are any differences in the rollout settings is not a good
> idea. I don't personally have a problem with having to clear an old
> rollout by asking for a 0-ply evaluation if I do want to discard a
> rollout, but that could well be because I wrote the code and know
> instinctively what it's up to.

Well, I think resuming a rollout is rare enough an operation that making it 
a default is not user friendly. Personally I think users might occasionally 
resume a rollout, but one can pretty much calculate how many trials one 
needs to get a confident result. Also, I personally think it's easier to do 
a first rollout with many trials, and interrupt it if it's giving you 
enough statistical confidence. The new features even allow one to autumate 
this task, so resuming rollouts would seem like a rare event to me. But 
maybe other users work differently.

At least I think it would be very good, and pretty logical as far as I can 
tell, to give the user a choice of whether to resume an old rollout or 
start a new rollout.

I think the current handling is no good really. I especially don't like the 
fact that a current rollout (one that's running), does NOT use current 
rollout settings. That discrepancy seems confusing to me.

Cheers,

--
Robert-Jan