I did my best to fix this issue. The timer doesn't try to guess if or when a rollout will be stopped, but does the right count on rollouts already stopped and takes rollouts with different number of trials in to account. Also a column with the updated number of trials have been added to the rollout view.
Christian. On Tue, Apr 7, 2009 at 10:04 AM, Hardy Hübener <[email protected]> wrote: > Hi everyone, > > > don't know whether this has ever been discussed here. If so, disregard my > mail. > > When you conduct a rollout and find out that the result is not significant > enough and resume this rollout with more trials, the time prediction how > long this rollout will last is of no use. > > I think GNUBG is calculating the remaining time from how long it took to > reach the previous rollout. As the rollout started with the previous result, > it took GNUBG 0 (zero) seconds to reach this amount of trials. So if I > prolong a 1296 trials rollout to 2592 trials GNUBG is predicting that the > rollout will be finished in a couple of seconds. However it's going to take > hours (of course). > > Perhaps another algorithm could be used to calculate the remaining time more > accurate. (There are more important features, but as I do many rollouts, > it's sometimes helpful how long a rollout is going to take approximately.) > > > Thanks, > > Hardy > > > -- > Hardy's Backgammon Pages --> www.hardys-backgammon-pages.com > > > > _______________________________________________ > Bug-gnubg mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/bug-gnubg > _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
