Re: [Bug-gnubg] Bug in bearoffdump?

[Ian Shaw]

Hi Isembard,

 

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.

 

Best regards,

Ian Shaw

 

 

From: Bug-gnubg [mailto:bug-gnubg-bounces+address@hidden On Behalf Of isambard mews
Sent: 31 December 2016 15:34
To: address@hidden
Subject: Re: [Bug-gnubg] Bug in bearoffdump?

 

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?

Apologies if this is in the wrong list, happy to be directed to the appropriate list/forum.

 

---

From: Philippe Michel <address@hidden>
Sent: 31 December 2016 14:45
To: isambard mews
Subject: Re: [Bug-gnubg] Bug in bearoffdump?

 

On Tue, 27 Dec 2016, isambard mews wrote:

> I tested out bearoffdump on a test database using normal distribution
> format and got the following strange output (running on a 64bit Debian
> system). I was expecting a similar format to a non-ND database and
> wonder if this is a bug:

The problem is fixed in the current sources. If you use the debian package
I suppose you will have to wait until it is updated, but if you compiled
gnubg  yourself you can update it from cvs or get the only changed file
from
http://cvs.savannah.gnu.org/viewvc/*checkout*/gnubg/gnubg/bearoff.c?revision=1.101

Best regards,

Philippe Michel