bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Problems using Stop rollout when one move appears to be


From: Neil Robins
Subject: Re: [Bug-gnubg] Problems using Stop rollout when one move appears to be best option
Date: Mon, 24 Aug 2009 07:29:24 +0100


----- Original Message ----- From: "Michael Petch" <address@hidden> To: "Michael Petch" <address@hidden>; "Neil Robins" <address@hidden>; "Christian Anthon" <address@hidden>
Cc: <address@hidden>
Sent: Monday, August 24, 2009 2:21 AM
Subject: Re: [Bug-gnubg] Problems using Stop rollout when one move appears to be best option





On 23/08/09 3:23 PM, "Michael Petch" <address@hidden> wrote:

My progress bar has never ended early Even with 16 threads).

The answer to this is because I never used the "Stop when one move appears
to be best" I the past. Sorry about that, explains why I never saw rollouts
that ended early. Now that I have been using the option in testing, I have
seen it :). I guess that options says is "IF all rolls fall >
#ofJSDsfromBestMoveLimit", then stop rollout.

I assume what you are suggesting is that the rollout stops but there is a
move ranked higher than best that still has a JSD less than the limit you
set (3.1) when it stopped. Correct? (I haven't seen this behavior - yet).
Although I have found an issue that makes a Multithreaded build using 1
thread differs from a non multithreaded build with regards to JSD. I'll post
about that separately.

That is exactly what I have seen several times, but I don't have an example to hand. I believe this will occur if you have moves a,b and c. After say 1200 trials a leads, b is second and c falls outside the JSD limit, c stops. If after 1400 trials the equity of a has declined to bring c back within the limit ,c should (but doesn't consistently) start rerolling. The progress bar will now shift back to 1200. If all moves stay within the JSD limit thereafter and the rollout is set to end after 2000 trials, it will end when a and b have been rolled out 2000 trials with the progress bar showing around the 1800 trials for move c. In early versions of GNU this didn't happen because c always caught up immediately in number of trials to a and b rather than always running 200 behind.






reply via email to

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