[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] 0-ply cubes rolled out and GNUBG's cube efficiency parameter
[Bug-gnubg] 0-ply cubes rolled out and GNUBG's cube efficiency parameters
Mon, 18 Dec 2006 23:20:11 +0100
I ran a short session, gnubg 0-ply against itself, analysed cubes at
2-ply just like Christian did.
Again, 2-ply criticises 0-ply several times for cubing too early
("wrong doubles below DP") compared to just 1 instance of cubing too
late, which is very borderline anyway ("missed double").
Then I rolled out those cube decisions. I only had time for some
simple rollouts so far, so the reliability is not that great yet, but
out of 66 doubles in total, from the 9 wrong ("too early") doubles it
looks like 8 are indeed too early. Only 1 of these 9 it looks like
0-ply rightly doubled whereas 2-ply failed to double.
Here's the statistics after rollouts:
g0 White g0 Blue
Total cube decisions 736 749
Close or actual cube decisions 216 152
Doubles 36 30
Takes 24 20
Passes 6 16
Missed doubles (below CP) 1 (-0.001 ( -0.001)) 0
Missed doubles (above CP) 0 0
Wrong doubles (below DP) 2 (-0.091 ( -0.180)) 7
(-0.258 ( -0.258))
Wrong doubles (above TG) 1 (-0.002 ( -0.002)) 0
Wrong takes 2 (-0.108 ( -0.118)) 1
(-0.038 ( -0.038))
Wrong passes 0 2 (-0.076
Error rate (total) -0.202 ( -0.302) -0.372 ( -0.372)
Error rate (per cube decision) -0.9 ( -0.001) -2.5 ( -0.002)
Cube decision rating Supernatural World class
So, a bit more evidence that 0-ply cubes too early, but better
rollouts and more cube decisions would need to be studied.
Checking the actual rollout results, then in general it doesn't seem
like 0-ply doubles too early because of too high equity estimates.
Often, 2-ply gets higher w/g/bg percentages yet doesn't double whereas
0-ply does. So, I also found a bit more evidence that 0-ply's cubing
probably systematically overestimates volatility (which is similar to
saying it underestimates cube efficiency in general).
The GNUBG manual has something to say about this:
The cube efficiency
The cube efficiency is obviously an important parameter, unfortunately
there haven't been much investigation carried out, so GNU Backgammon
basically uses the values 0.6-0.7 originally suggested by Rick
Position Class x (Cube efficiency)
Two-sided (exact) bearoff n/a
One-sided bearoff 0.6
Race linear interpolation between 0.6 and 0.7
So, there's the parameter I'm talking about. The fact that apparently
not much investigation has been carried out might well explain why
0-ply cubing shows a bias. Therefore, fine-tuning could help improve
0-ply's cube decisions which hopefully would also improve its 2-ply
cube decisions even further.
It looks like the values quoted above are too low in general (most
players also assume higher cube efficiencies in my experience, more
like 0.7 overall although that in itself doesn't prove anything), but
more research would be needed to seperate the different position
classes. I could imagine that in crash positions the cube efficiency
might actually be lower than 0.68, for instance. The race values
really seem on the low side, especially for long races. This is
consistent with the earlier rollout I posted.
Hope this at least sparks some interest.
|[Prev in Thread]
||[Next in Thread]|
- [Bug-gnubg] 0-ply cubes rolled out and GNUBG's cube efficiency parameters,
Robert-Jan Veldhuizen <=