Re: [Bug-gnubg] threading bug

[Jim Segrave]

On Sun 10 Jun 2007 (17:20 +0200), Achim Mueller wrote:
> * Achim Mueller <address@hidden> [070610 17:16]:
> > * Christian Anthon <address@hidden> [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           address@hidden