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

[Massimiliano Maini]

>> Just uploaded on gnubg.org  new install
and exes rebuilt from this
>> morning's code. If you have a recent (i.e. 2007) intall, just
download
>> the updated exes (with and/or without multi-thread, but the problem
was
>> probably visible only in the multi-thread exes).
>
>No, it affected anyone doing rollouts cubeful or cubeless if their
>standard rollout options had a different choice for cubeless or
>cubeful. The ranking was done using cubeful or cubeless based on the
>user's normal rollout settings, the rollout was done cubeful or
>cubeless based on the settings used with the rollout. It affects
>single processor, non-threaded as well (just verified on a single CPU
>non threaded machine - extending Chase's rollout when
>Settings->Rollouts->cubeful was checked gave incorrect rankings,
>extending the same rollout when it was unchecked gave correct
>rankings.

Hmmm, strange. I thought Jon, wise man, had left all
the old non-MT code
in place and surrounded all the new MT code with #if
USE_MULTITHREAD ...
What exactly did you test ? Did you use an executable
compiled with
#define USE_MULTITHREAD 1 on a single proc PC or did
you use executables
compiled WITHOUT USE-MULTITHREAD ?

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

I'm lost : isn't the problem only related to 0.16
branch or is the
stable branch affected too ? My understanding, from
your explanations
besides the last two lines, is that 0.16 code only
has the problem ...

Win binaries appears ... as soon as I realise they
are needed :))

MaX.

P.S.
There has been at least one fix in the 0.15 stable
branch since my
last build (maybe even 2), if anyone can put a cvs
snapshot of the
0.15 stable branch under www.gnubg.org/media/sources
(like the existing
one, gnubg-source-rel-0_15_20061120.tar.gz) I'll rebuild
0.15 Win
(GTK version has also changed since then).

You need (of course) CVS access and admin access to
gunbg.org