[Top][All Lists]

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

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

From: Massimiliano Maini
Subject: Re: [Bug-gnubg] Plays ranked in wrong order in rollout window
Date: Tue, 27 Feb 2007 09:11:12 +0100

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

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

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


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

reply via email to

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