>> 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
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
