[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Re: Bug-gnubg Digest, Vol 9, Issue 9
Re: [Bug-gnubg] Re: Bug-gnubg Digest, Vol 9, Issue 9
Fri, 08 Aug 2003 06:03:22 +0200
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
> result already there)
> - 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
> 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
> 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
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
do neither and let the user adjust the current settings to match the
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
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
> 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
> 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.