|Subject:||Re: [Bug-gnubg] Bug in bearoffdump?|
|Date:||Wed, 4 Jan 2017 01:55:27 +0000|
Thanks for your answer. I guess that if you use the OSD by selecting only the expected roll minimizing choice, then this can lead to mistakes (as you note).
From: Ian Shaw <address@hidden>
Sent: 03 January 2017 18:01
To: isambard mews; address@hidden
Subject: RE: [Bug-gnubg] Bug in bearoffdump?
The 1-sided database gives the most efficient bearoff by minimising the average rolls required.
Sometimes, this isn’t the best play. When the opponent is close to the end, it may necessary to increase the probability to bear off in fewer rolls than your opponent, at the expense of increasing the average rolls required.
For example, consider when you have 2 on the four point, 1 on the five and 1 on the six, and roll 21.
If your opponent has the same position as you, then the best play is 4/3 4/2 to bear off in the fewest rolls, on average.
If your opponent has all 4 on the one point, then 6/4 5/4 is the best play, so that 66, 55 and 44 all win for you on the next roll. It doesn’t help you at all to optimize your chance of bearing off in 2, 3, 4, 5, or 6 rolls, because you’ll never get the chance.
A 2-sided database calculates this.
Having said that, even a gnubg 0-ply analysis gets this decision correct, so I’m not sure what’s going on.
Thanks! Out of interest, I was wondering if someone could give an example of a case where the 2 sided database would be different from the one-sided database? I had assumed that if you apply the database to both sides and have the full distribution, you could work out the optimal move just using this one-sided database?
From: Philippe Michel <address@hidden>
On Tue, 27 Dec 2016, isambard mews wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|