bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Plays ranked in wrong order in rollout window


From: Jim Segrave
Subject: Re: [Bug-gnubg] Plays ranked in wrong order in rollout window
Date: Sun, 25 Feb 2007 13:35:50 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

It turns out if your main settings (Options->Rollouts) is marked
Cubeful/Cubeless and you try to do a rollout which is
Cubeless/Cubeful, then the ranking (and the decision on when to stop,
etc. would use the Cubeful or Cubeless settings from the options, not 
from the rollout you've selected.

This used to work, before the multithreaded changes, because the
rollout code saved a copy of the Options->Rollout settings, then
modified them to match the moves being rolled out. At the end of each
step of rolling out a move, it put the saved copy back, so if you
interrupted the rollout, your regular settings remained.

The threaded version does the rankings and check for stopping after
the saved copy has been put back, so in this case it was doing a
cubeless rollout, then doing the rankings assuming it was cubeful. 'm
curious why at DMP the cubeful and cubeless equities differ, but they
do - maybe gnubg isn't bothering to calculate cubeful equity at DMP,
I'm not sure. At any rate, the ranking was based on cubeful equity.

I don't know how soon this fix will get back into the stable branch
(it's a tiny change) and how soon Windows binaries will appear.

There is a workaround:

If you intend to do a rollout or extend one, go to
Settings->Options->Rollouts and make sure that's also set to the
Cubeful/Cubeless of the rollout you are about to work on. You probably
want to make sure that stop on JSD settings are the same as what you
are about to rollout or extend, otherwise it will use what you see
under Settings->Options->Rollouts, not what you set on the toolbar or
what it finds in a saved .sgf file.

Foro the developers:

We need to examine all the places rcRollout is used and replace it
with a pointer to a rollout_context. That would allow Rollouts to be
properly thread safe.

Some of the problem areas:

RolloutGeneral wants to ensure that Cubeful/Cubeless is consistent for
all the moves/cube decisions it's rolling out, so it currently saves
rcRollout and if need be, alters the Cubeful/Cubeless flags in
rcRollout. Similarly, it may turn off the Stop on JSD settings if
there's only one move. We don't want extending a rollout or doing a
quick and dirty rollout from the Hint or Analysis windows to
permanently change the user's settings, but references to rcRollout
can be found in a very large number of files. The old, copy it,
rollout an iteration, put back the copy doesn't work with threaded
code (and in fact that's not actually what's done here anymore, since
RolloutLoopMT does the post iteration processing, after rcRollout has
been restored.


-- 
Jim Segrave           address@hidden






reply via email to

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