Re: [Bug-gnubg] Bug in bearoffdump?

[isambard mews]

Hi

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).

However, I guess what I'm getting at is, if you have the probability distribution function, can't you apply this to both sides to determine the correct play? e.g. you see that the other side will bear off in 1 roll with certainty 75% and 2 rolls with certainty 25%. Therefore, you choose the option which maximizes the bearoff in 1 roll regardless if it is the roll minimizing option?

I guess my question is are there any positions which TSD gets correct, where OSD cannot get correct even with this adjustment. Anyway, I will try to do some work to get an answer to this by comparing the two approaches, I'm currently stuck trying to understand the internal combinatorial ordering of the OSD.

Thanks again.

Isambard

---

From: Ian Shaw <address@hidden>
Sent: 03 January 2017 18:01
To: isambard mews; address@hidden
Subject: RE: [Bug-gnubg] Bug in bearoffdump?

 

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