On Sun 10 Jun 2007 (17:20 +0200), Achim Mueller wrote: > * Achim Mueller <[EMAIL PROTECTED]> [070610 17:16]: > > * Christian Anthon <[EMAIL PROTECTED]> [070610 17:06]: > > > Definitely a threading bug. I get really weird results using two > > > threads as well. Achim, can you confirm that you are using a threaded > > > version? > > > > Yes, this was done on a dual core ... and I already found the reason. If > > you choose more threads than cores you get these weird results. On my pc > > it was set on "2" which is actually "3" when you start counting with > > "0", as gnubg does. > > Sorry, mixed it up. When you choose "0" it takes all cpus, choosing "1" > uses only one thread, "2" uses two. And the weird standard error only > occurs at 0, 2, 3 and so on.
Here's something very odd: I rolled out Achim's first position, interrupting after 581 games and saved it as an .sgf file. At that time, the rollout window was showing a cubeful equity of +1.01988 with a standard error of 0.56934. But in the .sgf file, we find the following data: ;W[double] DA[X ver 3 Eq Trials 581 NoDouble Output 0.7799348235 0.01718181372 0.0001586886356 0.007273085415 9.895129915e-05 0.5677405596 0.7075381875 StdDev 0.02783757448 0.0009133279673 1.405134844e-05 0.0005356273614 2.413918082e-05 0.02059437521 0.0252378732 DoubleTake Output 0.7841442227 0.0157496836 0 0.006656042766 0.0001128451986 0.5762649775 0.7096174955 StdDev 0.001400601584 0.0009878044948 9.480622248e-05 0.0005143946619 2.456640868e-05 0.00280232681 0.000292532146 wheras an export to text of the match says: Cubeful equities: 1. No double +1.01988 2. Double, take +1.06679 ( +0.04691) 3. Double, pass +1.00000 ( -0.01988) Proper cube action: Too good to double, pass (29.8%) Rollout details: Centered 1-cube: 0.77993 0.01718 0.00016 - 0.22007 0.00727 0.00010 CL +0.56774 CF +1.01988 [0.02784 0.00091 0.00001 - 0.02784 0.00054 0.00002 CL 0.02059 CF 0.56934] Player bert owns 2-cube: 0.78414 0.01575 0.00000 - 0.21586 0.00666 0.00011 CL +1.16871 CF +1.06679 [0.00140 0.00099 0.00009 - 0.00140 0.00051 0.00002 CL 0.00534 CF 0.00660] In the .sgf file, the NoDouble Output is the probability of win, win gammon, win backgammon, lose gammon, lose backgammon, cubeless equity, and cubeful equity, the StdDev just after is the Standard error for the above values in the same order. Ahs - I found where it happens, but I'm not sure it's wrong the last value in the NoDouble Output and DoubleTake Output is treated as match winning chance. For cubeless equity, the routine mwc2eq in eval.c is called. It takes the values from the MET for winning or losing and considers the equity to be a straigtline function from equity = -1 for the MET value of losing, +1 for the MET value of winning and finds the corresponding equity value for the MWC which is input: * 2 * rMwc - ( rMwcWin + rMwcLose ) * rEq = --------------------------------- * rMwcWin - rMwcLose (where rEq is the equity to be determined, rMwc is the rollout estimate of the match winning chance and rMwcWin and rMwcLose are the Met mwc's for winning or losing this game at this cube value. This all seems reasonable. For the std error, the caculcation done is: * 2.0 * rSeMwc * rSeEQ = ------------------ * rMwcWin - rMwcLose where rSeMwc is the standard error of the MWC from the rollout This is what you'd get if you used the first formula with the rollout mwc and subtracted the result of using that formula with the rollout mwc minus one standard error. In the case of Achim's game, rMwc - 0.707538188 rMwcWin = 0.706656933 rmwcLose = 0.617999971 rSeMwc = 0.0252378732 the cubeful equity then comes out as 1.01988... but if rMwc is reduced by 1 std error so it becomes 0.6823003148 then the cubeful equity becomes .45054245824484714466 and similarly, if it's increased by 1 std error, it becomes 0.7327760612 and then the cubefule equity becomes 1.58921775821734112657 so plus/minus one std error in the rollout mwc really does appear to correspond to plus minus 0.56933764998624699095 in equity. to -- Jim Segrave [EMAIL PROTECTED] _______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
