RE: Mutant cube skills; Two birds in the bush better than one in the hand?

[Bug reports for and general discussion about GNU Backgammon.]

MK, I'm absolutely not a spokesperson for the group. I'm merely an enthusiastic 
user who tries to take some the load off the devs by answering those questions 
that I'm able to. If they are not commenting, it's for their own reasons and 
that shouldn't be interpreted as a tacit endorsement of my opinions. 

MK: 1) You acknowledged that the bot becomes inadequate against even a most 
primitive mutant cube strategy, (hopefully we will discuss my more elaborate 
ones later also), and is obligated to adjust its "cube skill theory",

The gnubg cube strategy assumes that the other player plays like gnubg. I 
suggested a strategy that I thought could better if it was known that the 
opponent was always taking. Ways to improve results when playing against humans 
as opposed bot v. bot move arises frequently in bg discussions.  

MK: 2) You switched to a strategy of minimizing your losings instead of 
maximizing your winnings, which is the exact opposite of what the "cube skill 
theory" is supposed to promote

I don't know how you conclude that. I consider improving net points difference, 
be that + or -. Nor have I considered whether my strategy would be optimal. My 
answer to why I "wouldn't double at 99%" is indeed about minimizing losses, but 
it's in the context of maximising net points won. The only reasons to double 
"now" rather than wait a turn is that (a) your position might improve to a 
point where they will drop the cube and you only win one point - you "lose your 
market" (b) the game might end before your next turn, so you only win one point 
(c) the game might go badly, and you regret doubling.

My strategy was to maximise the points won through a & b, and to minimise the 
points lost at c. Crudely speaking:
a) doesn’t apply if your opponent will never drop the cube
b) if you are >50% and <= 4 crossovers left so doubles could end the game, cube 
(This is an oversimplification to illustrate the concept)
c) minimise the losses on the 1% of games that go badly. Given condition a, it 
is always correct to wait a turn because your opponent will still take. You can 
never lose your market. 

MK: After 1,000 games mutant won 1,411 points (56.66%) vs bot's 1,079... there 
was almost no fluctuation with the cube never going past 2, with the mutant 
almost always reaching GWC > 50% and doubling early in the game and your bot 
never doubling at GWC < 100%, at which the mutant dropped. There were also a 
few 1-point wins.

My strategy was not to double until 100%, on the understanding that your 
strategy would always take (which also means that it would never be Too Good to 
Double). But since your bot WAS dropping when win chances were 100%, then mine 
was always losing its market. Your experiment demonstrates the importance of 
doubling before you lose your market. 


-Original Message-
From: Murat K  
Sent: Wednesday, April 10, 2024 7:51 AM
To: bug-gnubg@gnu.org; Ian Shaw 
Subject: Mutant cube skills; Two birds in the bush better than one in the hand?

Hi Ian,

On the one hand, since nobody else in this forum negates, nor even adds 
anything to support your arguments, I feel that I'm debating with a 
spokesperson for the group, but on the other hand I feel that our ideas don't 
attain their full potential.

With this thread having become too long and more about mutant cube strategies 
than value of cube ownership, I will take the opportunity to start a new thread 
responding to your last post, not only here in bug-gnubg but also in 
rec.games.backgammon and bgonline.org forums where you had posted in the past, 
for the sake of creating more interest on the subject and hoping that you will 
participate in those forums also.

 > -
 > *From:* MK 
 > *Sent:* Wednesday, April 3, 2024 10:29:11 pm  > *To:* Ian Shaw 
 > ; GnuBg Bug   > *Subject:* Re: 
 > Interesting question/experiment about value of cube ownership  >  > On 
 > 4/2/2024 7:08 AM, Ian Shaw wrote:
 >
 >> A cube strategy against a bot that never passes:
 >
 > Not never but we loosely say that since it takes at GWC > 0,  > i.e. even at 
 > 0.0001%  >  >> only double when (a) you are 100% to win  >  > I don't 
 > understand why you wouldn't double at 99%? Can you  > explain this?
 >
 >> (b) it's the last roll of the game and you have an advantage.
 >
 > Yes, this is very bad for the mutant and already happens now.
 >
 >> So the take point is 16.7%. Gammons complicate it, but I'm  >> sure you get 
 >> the idea.
 >
 > If you can clearly define your strategy, I would be glad to  > create a 
 > script to run the experiment to see what will happen.
 >
 > BTW: you are still avoiding the issue of how much the mutant  > will win 
 > compared to what it would be expected to win based on  > its total "cube 
 > error rate".
 >
 > What win rate would you say a mutant that takes at GWC > 0.0001  > even on 
 > the last roll, (which must be the biggest possible cube  > error), will 
 > achieve? Any 

RE: Cubeful and matchful training a BG bot

[Bug reports for and general discussion about GNU Backgammon.]

MK: I didn't say the selection was random. The self-play moves were random.

These two statements appear contradictory to me. What do you mean by 
"selection" if not the "self-play moves"? Please clarify your understanding of 
which parts of the training are random.

My understanding is this:
0) the weights of the neural net are initialised to random values. This is the 
only random part of the process.
1) the bot generates a list of legal moves. 
2) the neural net evaluates each move and gives it a score for wins, gammon 
wins, bg wins, gammon losses, bg losses
3) the bot plays the HIGHEST scoring move (This is NOT a randomly selected 
move, but a simple calculation - a sort - to find the move with the best equity)
4) the bot uses the outcomes of the games to adjust the weights of the neural 
network according to an algorithm
5) repeat the process of steps 1 - 4 many times until the bot gets good at 
backgammon

Which steps, if any, do you disagree with? You seem to be saying that you think 
step 3 is random selection of a move.

Based on my understanding of step 3, I wrote:

IS: How do you propose to rank double vs no double, and take vs pass?
MK: To answer your last question, just like checker decisions, cube decisions 
to double, take, pass, etc. would be random

If my understanding is correct, your response above does not successfully 
answer my question, so I come back to it: How do you propose to rank double vs 
no double, and take vs pass (at step 3 of the above procedure)?

Regards,
Ian

-Original Message-
From: Murat K  
Sent: Wednesday, April 10, 2024 10:48 PM
To: bug-gnubg@gnu.org; Ian Shaw 
Subject: Cubeful and matchful training a BG bot

Hi Ian,

Since this specific subject also strayed from the value of cube ownership, I'll 
do the same with it by creating a new thread and posting it also to RGB and 
Bgonline. My response to you is below the quoted posts.

 > -
 > *From:* MK 
 > *Sent:* Wednesday, April 3, 2024 10:01:17 PM  > *To:* Ian Shaw 
 > ; GnuBg Bug   > *Subject:* Re: 
 > Interesting question/experiment about value of cube ownership  > On 4/2/2024 
 > 5:13 AM, Ian Shaw wrote:
 >
 >> What would be your proposed structure for training a  >> cubeful bot? What 
 >> gains and obstacles do you foresee.
 >
 > I don't know what you mean by "structure". What I propose  > is doing the 
 > same thing done training TD-Gammon v.1, i.e.
 > random self-play, but this time also cubeful and matchful,  > i.e. random 
 > cube as well as checker decisions.
 >
 > Apparently Tseauro still works at IBM with access to huge  > CPU powers. 
 > Perhaps he can be put to shame for the damage  > he caused to BG AI by what 
 > he did with TD-Gammon v.2 and  > be urged to redeem himself.
 >
 > In other forums, people talk about doing "XG rollouts on  > Amazon's cloud 
 > servers", etc. Doing more biased rollouts  > is plain stupid/illogical. Any 
 > such efforts would be put  > to better use in training a new bot instead. 
 > The question  > is who would volunteer to do it.
 >
 > People like the Alpha-Zero team, etc. don't seem to want  > to touch 
 > "gamblegammon" with a ten feet pole, possibly  > because of the gambling 
 > nature of the game.
 >
 > In the past, I have suggested in RGB that random rollout  > feature can be 
 > added to GnuBG and results from trustable  > users can be collected over 
 > time in a central database  > to gradually create a bot that won't rely on 
 > concocted,  > biased/inaccurate cube formulas and match equity tables.
 >
 > Unfortunately the faithfuls are happy with their dogmas  > and no better 
 > bots are likely in the near future... :(

 > --

On 4/3/2024 11:44 PM, Ian Shaw wrote:
 > MK: What I PROPOSE is doing the same thing done training  > TD-Gammon v.1, 
 > I.E. random self-play, but this time also  > cubeful and MATCHFUL, i.e. 
 > random cube as well as checker  > decisions.
 >
 > As I remember it (though it's many years since I read the  > research), the 
 > self-play wasn't accomplished by picking  > random moves. It was the initial 
 > network weights that were  > random. The move picked was the best-ranked 
 > move of all  > the evaluated moves. This is a calculation, not a random  > 
 > selection.
 >
 > How do you propose to rank double vs no double, and take  > vs pass?

 > --

I didn't say the selection was random. The self-play moves were random. There 
were no "calculations" either. Moves were compared and better performing ones 
rose up in rank. It was kind of a "bubble sorting" of large numbers of 
statistical data. I remember that Tom Keith had used the expression 
"percolating up" in describing how he trained a Hypergammon bot through 
cubeless random self-play. It's the only way, (using "empirical data and 
scientific method"), to train a "non-human-biased" BG bot, (at least as best as 

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: I don't understand why YOU wouldn't double at 99%? Can you
explain this?

If the oppenent will still take at 100% then why risk losing 2 points 1% of the 
time?

I thought I answered your question about win rates previously.

A bot that always doubles, I'd expect to lose 0.3 ppg. It's hard to search back 
on my phone app, so maybe that's incorrect.)

A bot that doubles immediately it's ahead, I'd expect to lose about half that.

Those values assume the bot plays as well as gnubg for the remainder of the 
game. If the opponent will make further cube errors, then it should be a little 
bit more.





From: MK 
Sent: Wednesday, April 3, 2024 10:29:11 pm
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 4/2/2024 7:08 AM, Ian Shaw wrote:

> A cube strategy against a bot that never passes:

Not never but we loosely say that since it takes at GWC > 0,
i.e. even at 0.0001%

> only double when (a) you are 100% to win

I don't understand why you wouldn't double at 99%? Can you
explain this?

> (b) it's the last roll of the game and you have an advantage.

Yes, this is very bad for the mutant and already happens now.

> So the take point is 16.7%. Gammons complicate it, but I'm
> sure you get the idea.

If you can clearly define your strategy, I would be glad to
create a script to run the experiment to see what will happen.

BTW: you are still avoiding the issue of how much the mutant
will win compared to what it would be expected to win based on
its total "cube error rate".

What win rate would you say a mutant that takes at GWC > 0.0001
even on the last roll, (which must be the biggest possible cube
error), will achieve? Any guesses by anyone..?

MK

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: What I PROPOSE is doing the same thing done training TD-Gammon v.1, I.E. 
random self-play, but this time also cubeful and MATCHFUL, i.e. random cube as 
well as checker decisions.

As I remember it (though it's many years since I read the research), the 
self-play wasn't accomplished by picking random moves. It was the initial 
network weights that were random. The move picked was the best-ranked move of 
all the evaluated moves. This is a calculation, not a random selection.

How do you propose to rank double vs no double, and take vs pass?


From: MK 
Sent: Wednesday, April 3, 2024 10:01:17 PM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 4/2/2024 5:13 AM, Ian Shaw wrote:

> What would be your proposed structure for training a
> cubeful bot? What gains and obstacles do you foresee.

I don't know what you mean by "structure". What I propose
is doing the same thing done training TD-Gammon v.1, i.e.
random self-play, but this time also cubeful and matchful,
i.e. random cube as well as checker decisions.

Apparently Tseauro still works at IBM with access to huge
CPU powers. Perhaps he can be put to shame for the damage
he caused to BG AI by what he did with TD-Gammon v.2 and
be urged to redeem himself.

In other forums, people talk about doing "XG rollouts on
Amazon's cloud servers", etc. Doing more biased rollouts
is plain stupid/illogical. Any such efforts would be put
to better use in training a new bot instead. The question
is who would volunteer to do it.

People like the Alpha-Zero team, etc. don't seem to want
to touch "gamblegammon" with a ten feet pole, possibly
because of the gambling nature of the game.

In the past, I have suggested in RGB that random rollout
feature can be added to GnuBG and results from trustable
users can be collected over time in a central database
to gradually create a bot that won't rely on concocted,
biased/inaccurate cube formulas and match equity tables.

Unfortunately the faithfuls are happy with their dogmas
and no better bots are likely in the near future... :(

MK

Re: question

[Bug reports for and general discussion about GNU Backgammon.]

Hi Max,

GnuBg can import match files and analyse them.

You can also copy an XG position id and paste it into gnubg.

Like XG, it can identify errors and estimate how lucky the rolls are. The 
results won't be exactly the same as XG because the analysis engine is 
different. But it will be very similar.

Does this answer your question?

Regards,
Ian Shaw





From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 on behalf of Max S 

Sent: Wednesday, April 3, 2024 2:39:07 AM
To: bug-gnubg@gnu.org 
Subject: question

HI
Am I able to import a file of a position, match score etc and you would return 
the XG analysis to me?

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Of course I don't assume that gnubg always wins. That would be naive.

A cube strategy against a bot that never passes: only double when (a) you are 
100% to win (b) it's the last roll of the game and you have an advantage. The 
bot can also take a double deeper than normal, since the mutant will always 
take the recube to 4. So the risk is 1 point and the reward is 5 points 
(instead of 3). So the take point is 16.7%. Gammons complicate it, but I'm sure 
you get the idea.




From: MK 
Sent: Tuesday, April 2, 2024 12:08:49 pm
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/31/2024 4:18 AM, Ian Shaw wrote:

> If the mutant strategy is always to take, then gnubg GAINS when > Mutant 
> takes a D/P because that increases the points GnuBg wins.

Yes, of course, but only and only if the GnuBG wins. Obviously you
faithfully assume that GnuBG will always win and keep raking in the
higher cube points but experiment like the ones I did may prove it
otherwise.

And this is only speaking about winning more than 50% of points. To
this day, I have never been able get you guys to talk about mutant
strategies winning more than what would be expected from their cube
error rates, which is even more important in debunking the elaborate
so-called "cube skill theory" a complete mound of cow pies...

> Currently, gnubg is assuming it is playing against a player using
> it's own cube strategy.

And this is why they are as easy to derail as toy trains on tracks
around the xmas tree and to beat even by people like me, who is a
nobody compared to gamblegammon giants.

See my 10-years old experiments against various bots at my site:

https://montanaonline.net/backgammon/

I do however believe that future bots, trained through cubeful and
matchful self-play, will come very close to "perfect" play that no
human may possibly beat but current bots, including GnuBG, are not
even worth a mention by that measure.

> It could be reprogrammed to take advantage of knowing that it's
> opponent would never pass.

Okay, well, I'm daring to tell me how do you propose the bot could
be reprogrammed to do that?

You don't need to post the programming code here. Just explain how
the bot would achieve that in plain language.

I bet you won't be able to do. Empty talk is cheap...

Let me hold your hand to make another baby step: even if you could
reprogram a bot to to that, it would become just another version of
the same toy train on tracks going in circles around the xmas tree,
with the same weakness of exploitability by being totally predictable.
After that, you would have to reprogram you bot by revising your
jackoffski cube formulae again... Do you see your problem..?

MK

> 
> *From:* MK 
> *Sent:* Friday, March 29, 2024 2:28:09 AM
> *To:* Ian Shaw ; GnuBg Bug 
> *Subject:* Re: Interesting question/experiment about value of cube ownership
> On 3/19/2024 3:54 AM, Ian Shaw wrote:
>
>> MK "Those numbers are based on how the bot would play against itself.
>> If you accept the bot's decisions as best/perfect and if you try to
>> play just like bot, assuming that your opponent will also try to play
>> just like the bot, of course you wouldn't/shouldn't double."
>
>> Agreed. Against a worse player, you can take with fewer winning chances.
>> If your opponent will give up enough equity in errors to overcome the
>> error of the bad take (and your own subsequent errors), then you should
>> still come out ahead.
>
> I hope you are realizing that you are agreeing with the bot, not with me.
> What you quoted from me above was in response to your previously saying:
>
>  "I wouldn’t double.  As shown by the rollouts, I'd be giving
>  "up 0.36 points per game, on average. Even if I knew you would
>  "roll 66, I would still take, because the equity of -0.276 * 2
>  "is still better than giving up a whole 1.000 point.
>
> Would you drop if you knew that the mutant would roll 77? You wouldn't.
> (Just exaggerating to make a point, while reminiscing how Jellyfish was
> not only rolling 77's but shamelessly playing them to escape 6-primes:)
>
> Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in
> case it wins the opening roll), you will become hostage to its strategy,
> or in better sounding words, you will be dancing to its tune... ;)
>
> Reaching a D/P later won't help you either because the mutant will not
> drop and will force you to keep playing until the last roll, perhaps
> trading the cube more times back and forth.
>
> Letting the bot play for both side after the "opening double" actually
> defeats the purpose of the experiment but since there is no "separately
> existing, fully functional mutant bot (that would play like me;)" to
> make it play against GnuBG 2-ply, this is the only way we can do it and
> it's better than nothing.
>

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Yes, I am referring to theoretical continuous model for the 20% value, and 
agree it would apply to any suitable game, not just backgammon.

But backgammon isn't a continuous game. It has jumps in equity betewen one 
opportunity to double and the next.

The concept of cube efficiency is the estimate to allow for this. What other 
approximations are there? If course, at deeper plies than 0, bots look at the 
outcomes of all possible sequences so the effect of the cube efficiency 
approximation diminishes.

What would be your proposed structure for training a cubeful bot? What gains 
and obstacles do you foresee.

If course I think similarly about your other insulting terminology. Speaking 
personally, it reduces the amount of pleasure I get from the discussion and 
therefore the amount of time I'm prepared to put in.


From: MK 
Sent: Tuesday, April 2, 2024 11:43:40 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/31/2024 3:53 AM, Ian Shaw wrote:

> I'm glad we agree on the basic 25% take point. Do you also agree on
> the the theoretical 20% take point for perfect cube efficiency?

If by "theoretical" you mean a purely mathematical proposition, i.e.
not specifically related to cubeful backgammon, cubeful hopscotch,
cubeful snakes and ladders, etc., or (to repeat myself) as applied
in simple games where you can calculate those 25% and 20% accurately
and consistently, then I would say I agree with you.

> As far as I know, the only part of cube theory not calculated
> mathematically is the estimate made for cube efficiency. But it's
> a long time since I read Janowski so I may be wrong on that.

Since no bot was ever trained through cubeful self-play, all cubeful
calculations of all kinds are "mythematically" calculated, by using
repeatedly adjusted constants to produce the results desired by the
humans of faith...

> (I think you are using "gamble gammon" as a pejorative. I suspect
> that every time you do so, you lose credibility with anyone likely
> to read this. You may wish to take this into account, bearing in
> mind that most backgammon with the cube isn't played for money.)

I like writing poems, coining new expressions, country music lyrics,
word plays, puns, etc. and ta times I use them pejoratively but not
so much with "gamblegammon", for which I used worse names.

There was a game called "backgammon" before the "doubling cube" was
introduced to it for gambling purposes, which changed it drastically
enough for it to be considered a "variant" of backgammon, just like
any other such variants.

I have argued for over 20 years that the "cubeful backgammon variant"
needs to be given a new name and I proposed "gamblegammon", which I
thought was quite appropriate. I have been calling it "gamblegammon"
in other forums like RGB ever since and invited others to suggest
other names for it if they didn't like my "gamblegammon". Feel free
to offer your suggestion.

While on the subject, I'm surprised that you didn't catch on to many
other expressions that I have been using pejoratively, such as my
"fartoffski cube skill formula" against the "jackoffski cube skill
formula", etc.

Focus on understanding and refuting my arguments. If you (all) can't,
then I really don't care about my credibility with people who can't
understand my arguments, let alone rise up to defeat my arguments.

MK

> 
> *From:* MK 
> *Sent:* Friday, March 29, 2024 4:34:39 AM
> *To:* Ian Shaw ; GnuBg Bug 
> *Subject:* Re: Interesting question/experiment about value of cube ownership
> On 3/19/2024 7:44 AM, Ian Shaw wrote:
>
>> I don’t "divinely believe" in the current cube theory. I understand
>> the maths behind it. If you have found errors in the maths, then I
>> would be glad to re-evaluate.
>
>> Let's find out where you disagree by starting from the beginning.
>> What is your analysis of the basic 25% takepoint calculation?
>
>
> I'm not questioning whether a simple doubling theory, (assuming it
> can be called a "theory"), can be applied in simple game where you
> can calculate that 25% accurately and consistently.
>
> I'm questioning whether some doubling strategy can be applied in
> gamblegammon, based on a jumble of incomplete/inaccurate empirical
> statistics and mathematical calculation formulas that were several
> times retrofitted to produce some expected results, and call it a
> "cube skill theory".
>
> In RGB, some mathematicians had argued that it could be called a
> "theory" because it was mathematically proven, which can not be
> because the so-called "cube skill" is not a purely mathematical
> proposition.
>
> In a game involving luck like gamblegammon, (more luck than skill
> in my personal opinion), the proposition is necessarily statistical,
> empirical one and thus needs to be empirically proven.
>
> You say "let's start from the 

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

If the mutant strategy is always to take, then gnubg GAINS when Mutant takes a 
D/P because that increases the points GnuBg wins.


Currently, gnubg is assuming it is playing against a player using it's own cube 
strategy. It could be reprogrammed to take advantage of knowing that it's 
opponent would never pass.


From: MK 
Sent: Friday, March 29, 2024 2:28:09 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/19/2024 3:54 AM, Ian Shaw wrote:

> MK "Those numbers are based on how the bot would play against itself.
> If you accept the bot's decisions as best/perfect and if you try to
> play just like bot, assuming that your opponent will also try to play
> just like the bot, of course you wouldn't/shouldn't double."

> Agreed. Against a worse player, you can take with fewer winning chances.
> If your opponent will give up enough equity in errors to overcome the
> error of the bad take (and your own subsequent errors), then you should
> still come out ahead.

I hope you are realizing that you are agreeing with the bot, not with me.
What you quoted from me above was in response to your previously saying:

"I wouldn’t double.  As shown by the rollouts, I'd be giving
"up 0.36 points per game, on average. Even if I knew you would
"roll 66, I would still take, because the equity of -0.276 * 2
"is still better than giving up a whole 1.000 point.

Would you drop if you knew that the mutant would roll 77? You wouldn't.
(Just exaggerating to make a point, while reminiscing how Jellyfish was
not only rolling 77's but shamelessly playing them to escape 6-primes:)

Once the mutant conditionally pre-doubles, (i.e. if rules allow it, in
case it wins the opening roll), you will become hostage to its strategy,
or in better sounding words, you will be dancing to its tune... ;)

Reaching a D/P later won't help you either because the mutant will not
drop and will force you to keep playing until the last roll, perhaps
trading the cube more times back and forth.

Letting the bot play for both side after the "opening double" actually
defeats the purpose of the experiment but since there is no "separately
existing, fully functional mutant bot (that would play like me;)" to
make it play against GnuBG 2-ply, this is the only way we can do it and
it's better than nothing.

So, this way the really "semi-mutant" play will lose but it still will
not lose more than what would be expected from the cube error rate that
the mutant incurs from this "opening double". This alone is enough to
prove that the currently dogmatized "cube skill theory" is a jarful of
cow chip cookies...

MK

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

I'm glad we agree on the basic 25% take point. Do you also agree on the the 
theoretical 20% take point for perfect cube efficiency?

As far as I know, the only part of cube theory not calculated mathematically is 
the estimate made for cube efficiency. But it's a long time since I read 
Janowski so I may be wrong on that.

(I think you are using "gamble gammon" as a pejorative. I suspect that every 
time you do so, you lose credibility with anyone likely to read this. You may 
wish to take this into account, bearing in mind that most backgammon with the 
cube isn't played for money.)


Regards,

Ian Shaw


From: MK 
Sent: Friday, March 29, 2024 4:34:39 AM
To: Ian Shaw ; GnuBg Bug 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/19/2024 7:44 AM, Ian Shaw wrote:

> I don’t "divinely believe" in the current cube theory. I understand
> the maths behind it. If you have found errors in the maths, then I
> would be glad to re-evaluate.

> Let's find out where you disagree by starting from the beginning.
> What is your analysis of the basic 25% takepoint calculation?


I'm not questioning whether a simple doubling theory, (assuming it
can be called a "theory"), can be applied in simple game where you
can calculate that 25% accurately and consistently.

I'm questioning whether some doubling strategy can be applied in
gamblegammon, based on a jumble of incomplete/inaccurate empirical
statistics and mathematical calculation formulas that were several
times retrofitted to produce some expected results, and call it a
"cube skill theory".

In RGB, some mathematicians had argued that it could be called a
"theory" because it was mathematically proven, which can not be
because the so-called "cube skill" is not a purely mathematical
proposition.

In a game involving luck like gamblegammon, (more luck than skill
in my personal opinion), the proposition is necessarily statistical,
empirical one and thus needs to be empirically proven.

You say "let's start from the beginning". Yes, let's do so indeed.

TD-Gammon v.1 was empirically trained through self-play of cubeless
"money games", including gammons but not backgammons, and perhaps
not enough trials. That's it. That's your beginning...

To that, you use all kinds of "maths and mirrors" to add backgammon
rates, cubeful equity formulas, cubeful matchful equity tables, etc.
to "estimate" your winning chances, in order to apply to it what you
a "basic 25% take point". And I'm questioning sanity of all this, in
fact I'm arguing that it's all a pile of cow pies.

Shortcuts was taken in the days of TD-Gammon because of not having
enough CPU power, which is no longer true. Yet, there is no signs
of any willingness out there to create cubefully, matcfully trained
better gamblegammon bots.

It's easier to destroy a falsely claimed "theory" by poking holes in
it than to prove a proposition so that you can call it a theory, and
this is what I'm trying to accomplish with my experiments.

Since I can't single-handedly create a better bot, I'm trying what
I can do to create a need for, thus an incentive for the creation of
such a bot, "from scratch".

My "fartoffski mutant cube strategy", (based on arbitrary stages of
game and double/take points), in my experiments 11 and 12 came within
margin of error of beating GnuBG 2-ply. Folks, it's time for better
gamblegammon bots...

MK

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: Even though I think most of you won't absorb what I wrote above, because 
you all "divinely believe" in the current "cube skill theory", I won't consider 
it a total waste of my time even if it sows a seed of doubt in just one mind.

I don’t "divinely believe" in the current cube theory. I understand the maths 
behind it. If you have found errors in the maths, then I would be glad to 
re-evaluate.

Let's find out where you disagree by starting from the beginning. What is your 
analysis of the basic 25% takepoint calculation?

-- Ian 

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK: This is why I am doing my various experiments. One of which that I had 
previously mentioned in this very thread involves a "mutant cube strategy" of 
doubling at GWC > 50% and taking at GWC > 0%. In that experiment of 20,000 
money games, the mutant won 40.80% of total points against GnuBG 2-ply. Since 
winning the opening roll gives the player GWC > 50%, I ran a variant of the 
above experiment making the mutant also double if it wins the opening roll. 
This time, after 20,000 money games the mutant won 45.77% of total points.

These sound similar enough that I'll combine them.  Overall, the mutant 
strategy if doubling as soon as you had an advantage lost 0.1343 points per 
game. Always doubling immediately lost 0.36 ppg. So, not doubling until you are 
winning appears to be a better strategy than always doubling. But, as you 
expected, the mutant strategy isn't as good as the current cube algorithm, 
which loses 0 ppg.

However, I don’t think 4 trials is enough. Your strategy has huge variance. 
Have you calculated the statistical significance as suggested by one of the 
earlier responders? I recall that he suggested a similar experiment with lower 
variance to reduce the required number of trials, but you didn't want to try 
it.  I can't find that post at the moment, so I don’t know how many trials he 
calculated, but since your cube can get very high you would inevitably need 
more trials. 

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK "Those numbers are based on how the bot would play against itself. If you 
accept the bot's decisions as best/perfect and if you try to play just like 
bot, assuming that your opponent will also try to play just like the bot, of 
course you wouldn't/shouldn't double."

Agreed. Against a worse player, you can take with fewer winning chances. If 
your opponent will give up enough equity in errors to overcome the error of the 
bad take (and your own subsequent errors), then you should still come out ahead.

Fwd: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

MK,

You wrote "Not the "equity" but the "equity difference" between the "from" 
position and the "to" position."

I can't see any difference in outcome between selecting the play that maximises 
the equity of the move made, and maximising the equity gain between the current 
position and the new position. The latter option just adds an unnecessary 
subtraction step, so I doubt that's how it's programmed.

I agree that the Temp Map you posted is showing the equity with doubles 
allowed. I've put then into a spreadsheet so you can see the calculations. 
https://docs.google.com/spreadsheets/d/17XFvQPvWNqGMRgZScl2qcTW2ovNeCISq/edit?usp=sharing=117015456330598325471=true=true

The equity of 31 after returning to the opening position is +0.219. The equity 
after an opening 31 is also +0.219.  I conclude that there is no problem with 
the equity calculation that would affect how gnubg plays.

The temp map was a later addition to gnubg, so I don't think it's used in the 
luck calculation. Even if the luck calculation is down as per the temperature 
map, and there is an error in the luck calculation of the opening roll, it 
won't permeate through to other rolls. The luck calculation is based on the 
actual roll compared to the other 21 (14 in the opening) possible rolls.

The luck of 31 after returning to the opening position is +0.112. It's a good 
roll but not as good as any double. It's just above the average of +0.107. The 
worst roll is 14 at -0.113.
The luck of an opening 31 is +0.219. It's a great roll, compared to the average 
of 0.000. The worst roll is 14 at -0.219.

You want to make a distinction between the game not started being on roll 
before the move. For example, if you tossed a coin to see who started and then 
the winner rolls any non-double and plays it.
Then winning the opening roll would show a luck of +0.052.
The luck of an opening 31 is +0.167.
This adds to +0.219, the same as above.

This all seems consistent to me.

Your argument about a fallacy appears to be a semantic one. When I say, "the 
equity before the opening roll is zero", I'm aware that the opening roll also 
defines who rolls first, and I'm using it in that context.

If the opening roll were a coin toss, I wouldn’t speak in the same terms. I 
would say, "the equity before the toss is zero" because that's the average 
equity of all 30 possible outcomes (player 1 wind the toss & rolls, player 2 
wins the toss and rolls). I would also say, "the equity having won the toss is 
+0.052 before rolling" because that's the average equity of the remaining 15 
possible outcomes.

Do you agree with the preceding paragraph?

Knowing the absolute equity is only useful for cube actions, and since the 
rules prohibit doubling on the opening roll, it's not very useful to me  to 
make a distinction.

"In fact, I'd argue that with the cube centered, you should be allowed to 
double if you want before you open your eyes but this is a whole different 
subject and for one of the experiments that I have done and will share soon."

I wouldn’t double.  As shown by the rollouts, I'd be giving up 0.36 points per 
game, on average. Even if I knew you would roll 66, I would still take, because 
the equity of -0.276 * 2 is still better than giving up a whole 1.000 point.

A couple of final points.

I'm sure the match equity tables are calculated correctly. The starting player 
of any subsequent game is equally likely, so the equity of each game starts at 
zero.

I did read some of the old rgb threads.  They descended into rudeness and I 
lost interest.

For some reason, your last 2 messages got caught in my spam filter, hence the 
late reply.


Regards,
Ian

-Original Message-
From: MK 
Sent: Wednesday, March 6, 2024 9:35 PM
To: Ian Shaw ; bug-gnubg@gnu.org
Cc: Philippe Michel 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/4/2024 5:26 AM, Ian Shaw wrote:

Since at least you care to continue this discussion, I will invest more of my 
time and effort mainly for the sake of improving GnuBG.

> Sorry, MK, I didn't read back over the old threads,

It was in my a previous post in this current thread here but it's no big deal. 
However, if you are serious about discussing this issue, which one of many 
related ones, you really need to read at least this thread in RGB (which I had 
mentioned in my last post):

https://groups.google.com/g/rec.games.backgammon/c/QU1jM9aatO0/m/peIBhLJNAgAJ

There is a lot in there, including a bug that I had pointed out in "analysis.c" 
that had been there since 2014, which is still there. See lines 243-246 in 2022 
and 272-275 in current version:

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.241=markup

https://cvs.savannah.gnu.org/viewvc/gnubg/gnubg/analysis.c?revision=1.263=markup

Too bad that the development/maintenance team isn't hearing me.

> You asked earlier about the GNUBG ID I used. It was:
> 4HPwATDgc/ABMA:cAkA This is the ID obtained after the 

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

Sorry, MK, I didn't read back over the old threads, to see what links you had 
referenced, before I replied. It was late at night, and I was using my phone 
rather than a PC.



In that case, I must have misunderstood what you meant by, "Is making the bot 
auto-play the same as doing rollouts?" It seemed to me that, since only you 
know what’s in your scripts, it was most likely that you were asking about 
rollouts are, although that also seemed unlikely.



You asked earlier about the GNUBG ID I used. It was:   
4HPwATDgc/ABMA:cAkA

This is the ID obtained after the sequence I suggested:   
4HPwATDgc/ABMA:cAkA

(Thanks for the link to the BKGM post. I’d forgotten about it, but fortunately 
it had recently been discussed on Daily Gammon, where someone else also found 
your 4-roll solution!)



They are identical, so there is no indication in the ID to indicate whether it 
is the opening roll. Therefore, the evaluation is the same. The Contact Net 
does not have an input for Opening Roll, which makes sense. The bot plays by 
maximizing the equity of the next position. The opening layout – with doubles 
prohibited - is never the next position.


Comparing evaluation, Rollout as Normal Position, Rollout as Initial Position, 
we can see that the evaluation is close to the value of the rollout. The 
rollout as the initial position is lower since it doesn’t include those useful 
doubles.
Ply

Cube

Pwin

Pwin2

Pwin3

Plose

Plose2

Plose3

E cubeless

E No Double

E Double/Take

Action

2 eval

n/a

0.5248

0.1495

0.0069

0.4752

0.1248

0.0053

+0.0759

+0.0982

‑0.1712

NB (23.0%)

2

1Cen

0.5256

0.1532

0.0082

0.4744

0.1287

0.0053

+0.0785

+0.1187





Normal

2Opp

0.5274

0.1521

0.0074

0.4726

0.1295

0.0056

+0.1586



-0.2127

NB (27.3%)

2

1Cen

0.5130

0.1461

0.0069

0.4870

0.1336

0.0058

+0.0395

+0.0580





Initial

2Opp

0.5147

0.1468

0.0068

0.4853

0.1332

0.0059

+0.0881



-0.3002

NB (27.6%)




I don’t think the value of 0.36 ppg for cube ownership that we both obtained is 
a "coincidence". I think it's evidence that your script is a good emulation of 
a rollout. If you think 0.36 is inaccurate, I’m open to persuasion. Do you have 
a theory as to why it’s wrong, or what you think the correct value is?



Regarding the equity at the beginning of the game, I’m not aware of any 
“age-old fallacy”. It's well established that winning the opening roll confers 
an advantage. I don’t think there's any theory that says the equity (between 
equal opponents) is non-zero before the opening roll. Indeed, the construction 
of most match equity tables is based on the equity at the start of the game 
being zero (unless they are assuming unequal players).



Finally, please lay off the disparagement. “What will it take for you guys to 
give some credit/benefit of the doubt to others than just yourselves?” is 
unnecessary. I’m not sure which group of ‘guys’ you lump me into; I’m just a 
gnubg user and a moderate player. I give lots of credit to loads of people who 
have contributed far more to backgammon than I ever will.



Ian



--Original Message-

From: MK mailto:playbg-...@yahoo.com>>

Sent: Monday, March 4, 2024 3:17 AM

To: Ian Shaw mailto:ian.s...@riverauto.co.uk>>; 
bug-gnubg@gnu.org

Cc: Philippe Michel mailto:philippe.mich...@free.fr>>

Subject: Re: Interesting question/experiment about value of cube ownership



On 3/1/2024 6:02 PM, Ian Shaw wrote:



> "Is making the bot auto-play the

> same as doing rollouts?"

>

> It sounds like you are asking what a rollout is?



I wasn't.



> https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-ro

> llouts.html



I had read it many a times before.



> https://www.bkgm.com/openings/rollouts.html



This is funny. You are referring me back to the same link that I had given in 
my reply to you on February 10, here in this very same thread... :) What will 
it take for you guys to give some credit/benefit of the doubt to others than 
just yourselves?



> Your auto-play script sounds very similar but I don't know exactly

> what it does.



Fair enough. My explaining in my previous post about what it does in this 
specific experiment was probably too brief and not very clear.



> The main difference would be that you can make your scripts double

> using your own algorithm.



Yes, in some experiment I did that but not in this one.



> Or indeed, veer from the bot's best chequer play.



I haven't done any checker experiments yet but I may.



> Minor differences might be the play settings for search depth and

> pruning.



Okay. You now made me realize that even unchecking all of the optional settings 
in roll-outs, it will not be the same as bot auto-playing. We both must have 
come up with the same 0.36 ppg by coincidence. Regardless, I believe that it's 
inaccurate in either case anyway.



> Try this manual sequence, and evaluate the next move.

> This gets you back to 

Re: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

"Is making the bot auto-play the
same as doing rollouts?"

It sounds like you are asking what a rollout is?  There are plenty of resources 
on the net.
https://www.gnu.org/software/gnubg/manual/html_node/Introduction-to-rollouts.html

https://www.bkgm.com/openings/rollouts.html

Your auto-play script sounds very similar but I don't know exactly what it does.

The main difference would be that you can make your scripts double using your 
own algorithm. Or indeed, veer from the bot's best chequer play.

Minor differences might be the play settings for search depth and pruning.

Try this manual sequence, and evaluate the next move. This gets you back to the 
start position. But doubles would be allowed, so the bot evaluation should not 
be the same as that of the opening roll.

64: 13/7 24/20

33: 24/18* 13/7

21: bar/24 20/18*

51: bar/24 18/13

32: 18/13




From: MK 
Sent: Friday, March 1, 2024 10:46:29 PM
To: Ian Shaw ; bug-gnubg@gnu.org 
Cc: Philippe Michel 
Subject: Re: Interesting question/experiment about value of cube ownership

On 3/1/2024 6:22 AM, Ian Shaw wrote:

> 27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply.
> There’s almost no difference in value between the rollout
> that took 8 minutes and the one that tool 23 hours, which
> speaks to the strength of the initial evaluation.

This is good to know. Can you post the position ID so that
there is no misassumptions.

> The rollout suggests that the value of cube ownership in
> the initial position is worth about 0.36 points.

This is very interesting. Is making the bot auto-play the
same as doing rollouts? During the past weeks, I have done
12 different experiments with 20,000 games in each. I'm now
putting it all on a neatly organized web page which I will
share here soon.

Six of my experiments were about the value of winning the
opening roll and/or owning the cube from the start (i.e.
before the first move for the mutant but before the second
move for the bot since it always auto-plays and there is no
way to intercept before its first move).

Very interestingly I also came up with 0.36 ppg and 0.28 ppc
("points per cube" decision).

I collected and tabulated quite a lot of various stats which
will be on my web page, along with the actual scripts I ran,
saved games, log files, etc. so that you all can derive your
own conclusions with or without replicating my experiments,
with the important ones being about "mutant cube strategies".

> One thing to notice is that the rollout has the on-roll
> player winning about 1% less than the evaluations posted
> by MK. I think this is due to the evaluation assuming that
> initial doubles may be played, whereas I set the rollout
> to play as the initial position.

I'm not sure what you are referring to here. What I had posted
was the GnuBG's 2-ply evaluation of the opening position (i.e.
without initial doubles). So, that 1% must be the difference
between that and your rollouts?? (as well as my experiments?)

> I haven’t found a way toa ask gnubg for an evaluation for the
> initial roll. Is there one?
> You could get a 1-ply evaluation by combining all 15 0-ply
> evaluations of the first roll, and so forth.

I don't understand these. Hopefully others will pitch in their
comments in response...

MK


> *From:*bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org
>  *On Behalf Of *Ian Shaw 
> via Bug reports for and
> general discussion about GNU Backgammon.
> *Sent:* Thursday, February 8, 2024 11:39 AM
> *To:* playbg-...@yahoo.com; bug-gnubg@gnu.org
> *Cc:* Philippe Michel 
> *Subject:* RE: Interesting question/experiment about value of cube ownership
>
> It just so happens that I rolled out the opening position a few days ago for 
> another reason. This
> was at 7-away 7-away rather than $ play, because I was interested in match 
> play. I doubt that makes
> a huge difference.
>
> This was using gnubg-1_08_dev-20240103-setup.exe not the newest 
> gnubg-1_08_001-20240204-setup.exe
> that Philippe released recently.
>
> Philippe, am I correct in thinking that the cube handling on these two 
> versions is the same? Your
> announcement emails both include the same comment.
>
> “Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error 
> rates are approximately
> halved and the repartition of errors (premature doubles vs. missed doubles 
> vs. take or pass errors)
> is now similar to higher plies instead of being mostly premature doubles.”
>
> The rollout results indicate about 1% fewer wins for the roller than the 
> evaluations.
>
> 4HPwATDgc/ABMA:cAngAAAE
>
> Cube analysis
>
> Rollout cubeless equity +0.0408 (Money: +0.0396)
>
> Cubeful equities:
>
> 1. No double   +0.0655
>
> 2. Double, pass+1.  (+0.9345)
>
> 3. Dou

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

I've rolled at the opening position again, at money play.
27000 trials at 0-ply and 1-ply. 135000 trials at 2-ply.  There's almost no 
difference in value between the rollout that took 8 minutes and the one that 
tool 23 hours, which speaks to the strength of the initial evaluation.

The rollout suggests that the value of cube ownership in the initial position 
is worth about 0.36 points.

One thing to notice is that the rollout has the on-roll player winning about 1% 
less than the evaluations posted by MK. I think this is due to the evaluation 
assuming that initial doubles may be played, whereas I set the rollout to play 
as the initial position.

Ply

Cube

Pwin

Pwin2

Pwin3

Plose

Plose2

Plose3

Ecl

End

Edt

Action

0

1Cen

0.5135

0.1425

0.0065

0.4865

0.1310

0.0055

+0.0395

+0.0599





8 m

2Opp

0.5141

0.1428

0.0064

0.4859

0.1317

0.0056

+0.0804



-0.2941

NB (27.4%)

1

1Cen

0.5136

0.1472

0.0071

0.4864

0.1352

0.0059

+0.0405

+0.0594





38 m

2Opp

0.5136

0.1495

0.0074

0.4864

0.1350

0.0060

+0.0867



-0.2977

NB (27.5%)

2

1Cen

0.5130

0.1461

0.0069

0.4870

0.1336

0.0058

+0.0395

+0.0580





23 h

2Opp

0.5147

0.1468

0.0068

0.4853

0.1332

0.0059

+0.0881



-0.3002

NB (27.6%)



I haven't found a way toa ask gnubg for an evaluation for the initial roll. Is 
there one?
You could get a 1-ply evaluation by combining all 15 0-ply evaluations of the 
first roll, and so forth.

Cheers,
Ian



From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of Ian Shaw via 
Bug reports for and general discussion about GNU Backgammon.
Sent: Thursday, February 8, 2024 11:39 AM
To: playbg-...@yahoo.com; bug-gnubg@gnu.org
Cc: Philippe Michel 
Subject: RE: Interesting question/experiment about value of cube ownership




It just so happens that I rolled out the opening position a few days ago for 
another reason. This was at 7-away 7-away rather than $ play, because I was 
interested in match play. I doubt that makes a huge difference.



This was using gnubg-1_08_dev-20240103-setup.exe not the newest 
gnubg-1_08_001-20240204-setup.exe that Philippe released recently.



Philippe, am I correct in thinking that the cube handling on these two versions 
is the same? Your announcement emails both include the same comment.

"Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error 
rates are approximately halved and the repartition of errors (premature doubles 
vs. missed doubles vs. take or pass errors) is now similar to higher plies 
instead of being mostly premature doubles."



The rollout results indicate about 1% fewer wins for the roller than the 
evaluations.



4HPwATDgc/ABMA:cAngAAAE



Cube analysis

Rollout cubeless equity +0.0408 (Money: +0.0396)



Cubeful equities:

1. No double   +0.0655

2. Double, pass+1.  (+0.9345)

3. Double, take-0.2999  (-0.3654)

Proper cube action: No double, take (28.1%)



Rollout details:

Centered 1-cube:

  0.5129 0.1480 0.0083 - 0.4871 0.1351 0.0073 CL +0.0408 CF +0.0655

[0.0001 0.0002 0.0001 - 0.0001 0.0001 0.0001 CL  0.0003 CF  0.0008]

gnubg owns 2-cube:

  0.5156 0.1522 0.0091 - 0.4844 0.1375 0.0150 CL +0.1216 CF -0.2999

[0.0001 0.0002 0.0001 - 0.0001 0.0002 0.0002 CL  0.0007 CF  0.0012]

Full cubeful rollout with variance reduction

186624 games, rollout as initial position, Mersenne Twister dice generator with 
seed 823069761

Play: world class 2-ply cubeful prune [world class]

keep the first 0 0-ply moves and up to 8 more moves within equity 0.16

Skip pruning for 1-ply moves.

Cube: 2-ply cubeful prune [world class]



Cheers,

Ian



-Original Message-
From: 
bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org<mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org>
 
mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org>>
 On Behalf Of MK
Sent: Thursday, February 8, 2024 2:23 AM
To: bug-gnubg@gnu.org<mailto:bug-gnubg@gnu.org>
Subject: Interesting question/experiment about value of cube ownership



I'm chugging along with my mutant cube skill experiments as I can spare time, 
saving all games, which I will share on my web site, when I'm done, along with 
my scripts.



While doing the double at > 50% experiment, I remembered an old question I had 
asked in RGB about a year ago: What if the winner of the opening roll is 
allowed pre-double?



See thread:

https://groups.google.com/g/rec.games.backgammon/c/BVEnaqGM6dg/m/2c685q4DAAAJ



When you evaluate the opening position in GnuBG, this is what you get:



=

Position ID: 4HPwATDgc/ABMA

Match ID:cAkA



Evaluator:Contact

 Win W(g)W(bg)   L(g)L(bg)   EquityCubeful

static:  52.115.4 0.813.0 0.8   +0.067+0.084

  1 ply:  52.714.8 0.912.9 0.5   +0.076+0.098

  2 ply:  52.514.9 0.712.5

Cubeless rollout of a cube position

[Bug reports for and general discussion about GNU Backgammon.]

Does it make sense to do a cubeless rollout of a cube position? I see that if I 
ask for one, gnubg automatically ticks the Cubeful Rollout box and does a 
cubeful rollout.

But if the bot doesn't understand the position, it may erroneously pass future 
cubes and give a bad result. For example, 9 out of these 36 games ended in 
Double/ Pass on the 2-cube rollout, and 14/36 on the 4-cube rollout. This is 
only a test; I know more than 36 games are required to draw any conclusions.

This is a position that Frank Berger has suggested, on DailyGammon, that the 
bot doesn't understand. "XGID=--a--BBCCBBAn-:1:1:1:00:0:0:0:0:10 XG 
believes to be a 60-70% favorite for the straggler player depending on 
ply/rollout but the positions is only about 6%" . I wanted to see what Gnubg 
thinks.

The 2-ply evaluation suggest 40% wins; rollouts suggest 70%. But can I trust 
this if the cube actions are wrong? I would expect a cubeless rollout to help 
eliminate this bias so that games are played to a conclusion (leaving only 
chequer play errors)


/z8AAAEAANvdFg:UYkNAAAE

Note that the Copy window is reversing the players' win-loss breakdown in the 
results below. The GUI has them the correct way.

Cube analysis
Rollout cubeless equity -0.1968

Cubeful equities:
1. No double   -0.6901
2. Double, pass-1.  (-0.3099)
3. Double, take-0.5094  (+0.1808)
Proper cube action: No redouble, take (36.8%)

Rollout details:
ianshaw owns 2-cube:
  0.2934 0.2533 0.0028 - 0.7066 0.0398 0. CL -0.1967 CF -0.6901
[0.0418 0.0370 0.0019 - 0.0418 0.0144 0.0002 CL  0.1242 CF  0.1798]
gnubg owns 4-cube:
  0.2856 0.2425 0.0010 - 0.7144 0. 0.0001 CL -0.3652 CF -0.5094
[0.0442 0.0414 0.0011 - 0.0442 0.0235 0.0005 CL  0.2649 CF  0.3471]
Full cubeful rollout with variance reduction
36 games, rollout as initial position, Mersenne Twister dice generator with 
seed 2147483647
Play: world class 2-ply cubeful prune [world class]
keep the first 0 0-ply moves and up to 8 more moves within equity 0.16
Skip pruning for 1-ply moves.

Regards,
Ian

Cube Analysis has win breakdown reversed

[Bug reports for and general discussion about GNU Backgammon.]

On the GUI cube decision window, the win breakdown has the player on roll 
wining 58.3% (36.8% gammons).

Yet when I use the Copy to get the text window, the results are the opposite 
way round.

I get the same result when starting a match from the beginning or pasting in an 
XG id.

Chequer play breakdowns are correct in the Copy window.

As an aside, it would be good if the Copy button automatically put the contents 
of the window into the paste buffer. This would save us having to Select All 
and Copy each time.


GNU Backgammon 1.08.001-mingw 32-Bit 20240204


XGID=-CCBbaa-c--a-c-d-A:0:0:1:00:0:0:0:5:10

4DlxoAZ3AwAAAQ:cAmmAAAE


Cube analysis
2-ply cubeless equity -0.592 (Money: -0.556)
  0.417 0.000 0.000 - 0.583 0.368 0.022
Cubeful equities:
1. Double, take-0.717
2. Double, pass-1.000  (-0.283)
3. No double   -0.690  (+0.027)
Proper cube action: Double, take

Cube analysis
Rollout cubeless equity -0.526 (Money: -0.498)

Cubeful equities:
1. Double, take-0.564
2. Double, pass-1.000  (-0.436)
3. No double   -0.534  (+0.030)
Proper cube action: Double, take

Rollout details:
Centered 1-cube:
  0.440 0.000 0.000 - 0.560 0.353 0.024 CL -0.526 CF -0.534
[0.001 0.000 0.000 - 0.001 0.001 0.000 CL  0.001 CF  0.004]
gnubg owns 2-cube:
  0.443 0.000 0.000 - 0.557 0.352 0.025 CL -1.066 CF -0.564
[0.001 0.000 0.000 - 0.001 0.001 0.001 CL  0.003 CF  0.005]

Full cubeful rollout with variance reduction
5184 games, Mersenne Twister dice gen. with seed 1404349941 and quasi-random 
dice
Play: world class 2-ply cubeful prune [world class]
keep the first 0 0-ply moves and up to 8 more moves within equity 0.16
Skip pruning for 1-ply moves.
Cube: 2-ply cubeful prune [world class]



Regards,
Ian Shaw

RE: Suggestion for improvement of Temperature Map for Cube decisions.

[Bug reports for and general discussion about GNU Backgammon.]

Oops, I thought I'd started a $ in my previous post, but it was a 3-pointer! 

The values in this money game DO look to be on a consistent scale.  So, you are 
correct that the issue only affects match play. 
My observations about the shading are still correct. 

0HPhATDgc/ABMA:MAEA

Cube analysis
2-ply cubeless equity +0.021
  0.506 0.146 0.010 - 0.494 0.140 0.007
Cubeful equities:
1. No double   +0.031
2. Double, pass+1.000  (+0.969)
3. Double, take-0.293  (-0.324)
Proper cube action: No double, beaver (25.1%)



-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of Ian Shaw via 
Bug reports for and general discussion about GNU Backgammon.
Sent: Thursday, February 22, 2024 9:04 AM
To: Philippe Michel 
Cc: bug-gnubg@gnu.org
Subject: RE: Suggestion for improvement of Temperature Map for Cube decisions.

I get the same issue in a $ game. 

0HPhATDgc/ABMA:MAFgAAAE

Cube analysis
2-ply cubeless equity +0.024 (Money: +0.021)
  0.506 0.147 0.010 - 0.494 0.140 0.008
Cubeful equities:
1. No double   +0.028
2. Double, pass+1.000  (+0.972)
3. Double, take-0.265  (-0.293)
Proper cube action: No double, take (23.2%)

The top-left corner reads:
Centred-1-cube =+0.34 (1-ply)   +0.022 (2-ply)
Player0 owns 2-cube:-0.134 (1-ply)  -0.129 (2-ply)
(I couldn't get the values to match the Analysis Pane exactly. I would expect 
either 2-ply to match 2-ply, or 1-ply map to match 2-ply overall - since the 
map is inherently 1-ply deeper than the overall analysis.)

The range of the scale bar is -0.701 to +0.560 but the limits of the map are:
1-cube 44 = +0.560
2-cube 52 = -0.333 (doubled  = -0.666)

I think the colouring of the 2-cube side uses the doubled values:
1-cube 42:   +0.173 rgb(255, 78, 78) is paler than 
2-cube 66:   +0.162 rgb(255, 44, 44)


-Original Message-
From: Philippe Michel 
Sent: Wednesday, February 21, 2024 9:49 PM
To: Ian Shaw 
Cc: bug-gnubg@gnu.org
Subject: Re: Suggestion for improvement of Temperature Map for Cube decisions.

On Wed, Feb 21, 2024 at 10:08:49AM +, Ian Shaw wrote:

> In the Facebook group Backgammon News, Wayne Joseph raised some 
> questions about the values displayed in the Temperature map. I've 
> posted extracts from the discussion below for context, but the gist of 
> it is.
> 
> The user was confused by the equities in the Temperature map being 
> normalised to a 1-cube for both cube actions. This obscures the effect 
> of doubling the stakes.
> 
> 
> 1. I think the values in the doubled part of the map should be 
> normalised to a 2-cube rather than a 1 cube.

This looks like a bug when the position is from match play. For money play the 
numbers are right (or at least they seem reasonable and the extreme values 
match the scale).

RE: Suggestion for improvement of Temperature Map for Cube decisions.

[Bug reports for and general discussion about GNU Backgammon.]

I get the same issue in a $ game. 

0HPhATDgc/ABMA:MAFgAAAE

Cube analysis
2-ply cubeless equity +0.024 (Money: +0.021)
  0.506 0.147 0.010 - 0.494 0.140 0.008
Cubeful equities:
1. No double   +0.028
2. Double, pass+1.000  (+0.972)
3. Double, take-0.265  (-0.293)
Proper cube action: No double, take (23.2%)

The top-left corner reads:
Centred-1-cube =+0.34 (1-ply)   +0.022 (2-ply)
Player0 owns 2-cube:-0.134 (1-ply)  -0.129 (2-ply)
(I couldn't get the values to match the Analysis Pane exactly. I would expect 
either 2-ply to match 2-ply, or 1-ply map to match 2-ply overall - since the 
map is inherently 1-ply deeper than the overall analysis.)

The range of the scale bar is -0.701 to +0.560 but the limits of the map are:
1-cube 44 = +0.560 
2-cube 52 = -0.333 (doubled  = -0.666)

I think the colouring of the 2-cube side uses the doubled values:
1-cube 42:   +0.173 rgb(255, 78, 78) is paler than 
2-cube 66:   +0.162 rgb(255, 44, 44)


-Original Message-
From: Philippe Michel  
Sent: Wednesday, February 21, 2024 9:49 PM
To: Ian Shaw 
Cc: bug-gnubg@gnu.org
Subject: Re: Suggestion for improvement of Temperature Map for Cube decisions.

On Wed, Feb 21, 2024 at 10:08:49AM +, Ian Shaw wrote:

> In the Facebook group Backgammon News, Wayne Joseph raised some 
> questions about the values displayed in the Temperature map. I've 
> posted extracts from the discussion below for context, but the gist of 
> it is.
> 
> The user was confused by the equities in the Temperature map being 
> normalised to a 1-cube for both cube actions. This obscures the effect 
> of doubling the stakes.
> 
> 
> 1. I think the values in the doubled part of the map should be 
> normalised to a 2-cube rather than a 1 cube.

This looks like a bug when the position is from match play. For money play the 
numbers are right (or at least they seem reasonable and the extreme values 
match the scale).

Suggestion for improvement of Temperature Map for Cube decisions.

[Bug reports for and general discussion about GNU Backgammon.]

Hi all,

In the Facebook group Backgammon News, Wayne Joseph raised some questions about 
the values displayed in the Temperature map. I've posted extracts from the 
discussion below for context, but the gist of it is.

The user was confused by the equities in the Temperature map being normalised 
to a 1-cube for both cube actions. This obscures the effect of doubling the 
stakes. 


1.  I think the values in the doubled part of the map should be normalised 
to a 2-cube rather than a 1 cube. 
This would make the value in the Top left to f the Doubled Box (Item 2) on the 
screen shot equal to the Double, Take Equity in the Analysis window.
It would also make it easier to compare the value of each roll, with and 
without a double. 

2.  The scale bar display does seem to anticipate that the right-hand side 
will show the doubled equity. In the example below, the max scale of +1.385 is 
about twice the value of the best roll 66 +0.659 for 66 and the minimum scale 
-0.077 is about twice the value of the worst roll -0.036.


I also think the map could benefit from showing market losers in a different 
colour. I don't find the shades of red all that easy to  follow. 


https://www.facebook.com/groups/1017340842031433/posts/1897126800719495/?comment_id=1899875730444602_id=1707695820400391_t=feedback_reaction_generic=notif

Transcript follows:

Wayne Joseph
Sho Sengoku's Temperature Map is very useful to visualize the dangers and 
jokers of a move, as well as the volatility of cube decisions. 
Can anyone give clear definitions for what the items labelled 1-4 represent? I 
couldn't find a full explanation in the manual. [Ian notes - my previous 
attempt to post his screenshot of the temperature map failed].

HdvGAAiw3w0YAA:UQmgAAAE 

GNU Backgammon  Position ID: HdvGAAiw3w0YAA
Match ID   : UQmgAAAE
+24-23-22-21-20-19--18-17-16-15-14-13-+  O: gnubg
| O  OO  O |   | O  O X  O|  0 points
|OO  O |   | O  O X  O|  
|O |   |  |  
|  |   |  |  
|  |   |  |  
|  |BAR|  |v 5 points match
|6 |   |  |  
|X |   |  |  
|X |   | X|  
| X  X |   | X  X |  On roll
|   O X  X |   | X  X |  0 points
+-1--2--3--4--5--6---7--8--9-10-11-12-+  X: ianshaw (Cube: 2)
Pip counts: O 103, X 113


Cube analysis
4-ply cubeless equity +0.273 (Money: +0.270)
  0.618 0.092 0.003 - 0.382 0.060 0.001
Cubeful equities:
1. No double   +0.513
2. Double, pass+1.000  (+0.487)
3. Double, take+0.384  (-0.129)
Proper cube action: No redouble, take (20.9%)

 


Ian Shaw
1 & 2 are the overall equities of each option (the sum of the 36 rolls).
3 & 4 should be the max and min range of the colour scale. But the outliers on 
the map in your picture are -0.036 to +0.659, so I'm not sure.

Wayne Joseph
For items 1+2, please could anyone explain in layman's terms why cubing to 4 
(ownership) results in around a noteworthy 60% decrease in the overall 
normalised equity (equivalent money game), given they are based on *exactly* 
the same 36 rolls? 60% less equity sounds like a lot to give up 'just' for 
redoubling.

Ian Shaw
If you look at the top-left corner of the 4-cube map, the value (+0.221 )is 
about half the value of the Double/Take Cube Analysis (+0.424).
That's because the values are in emg, so they have been re-normalized. This 
allows you to compare the value of the individual rolls on an equal basis, to 
see how much better they are.
For instance, the equity for 66 is +0.648 on a 4-cube, but on a 2-cube it is 
+0.965. This will be because after 15/3*(2) you can probably cash most 
sequences if you own the cube, but having redoubled you must still complete the 
bearoff to win.

Wayne Joseph
It's highlighted to me I still don't have my head around 'equity' (which 
internally, cognitively I kind of interpret as 'overall reward-overall risk'). 
Or the utility of those numbers.
>> +0.648 on a 4-cube,
>> but on a 2-cube it is +0.965.
Attached is a screenshot of the position after rolling 66 and hitting.
Looking at the screenshot, those numbers feel very counterintuitive (probably 
just me)
To me, OTB, at 83% favourite I would much prefer to be on a 4 cube (opponent 
held) in the screenshot, rather than holding a 2 cube. It feels like I would be 
fairly confident of bringing this home, for more reward (equity?) i.e. 4 points 
is better than 2
...but then I would have substantially *less* 'equity'. In a situation that 
feels 'better'???
>> +0.648 on a 4-cube,
>> but on a 2-cube it is +0.965.
May I sense check - OTB at 83% favourite would you (or others) prefer to be in 
the post 66 position on a 4 cube (opponent held). Or 

Does this list accept html posts?

[Bug reports for and general discussion about GNU Backgammon.]

Yesterday I posted about the Temperature Map, but it doesn't seem to have 
appeared on the mailing list.

Is this because the message for formatted as html and included screen shots and 
text highlighting?

Should I only post plain text?


  *   Ian

Display bug in Analyse, Clear Analysis, Move

[Bug reports for and general discussion about GNU Backgammon.]

The menu item for Display bug in Analyse, Clear Analysis, Move displays:

"noun|Move"

Instead of just "Move"

This appears in en_US.po, which I assume is the cause.


#: gtkgame.c:4028 gtkgame.c:4039 gtkmovelist.c:63 gtkrolls.c:198 html.c:2161


6382

#: sound.c:351

6383

msgid "noun|Move"

6384

msgstr

RE: GNUbg version 1.08.001 available

[Bug reports for and general discussion about GNU Backgammon.]

I installed the latest version, and all my settings appear intact. At least, 
the board colours and number of threads are as I remember them. 

I've tried on 2 PCs and both are OK. 

I still have the problem on my desktop where I have to move a dialog window a 
few mm before I can click a second option. The laptop is OK.

The Windows build is the same, but they are different gen processors.
Desktop: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz   2.90 GHzWindows 
10 Pro 22H2 OS Build 19045.3930 Windows Feature Experience Pack 
1000.19053.1000.0
Laptop: 12th Gen Intel(R) Core(TM) i7-1265U   1.80 GHz  Windows 
10 Pro 22H2 OS Build 19045.3930 Windows Feature Experience Pack 
1000.19053.1000.0

-- Ian 


-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of Isaac Keslassy
Sent: Sunday, February 11, 2024 7:13 AM
To: bug-gnubg@gnu.org
Subject: Re: GNUbg version 1.08.001 available

1) SAVING SETTINGS: I have also had the problem of gnubg 1.08 not saving 
settings, or rather, reporting that it is saving them but not loading them. 
Reinstalling gnubg doesn't help. It only worked for me once I selected to 
remove all of my preferences during the installation process (you need to make 
sacrifices to help debug!). I noticed in the faulty installation that I had 
both a ".gnubgautorc" and a "gnubgautorc" file in my preferences folder. This 
may be the reason: it may save in one file and read from the other. I tried to 
correct the error in gnubg.c, but cannot do it due to the 2nd problem below:

2) WINDOWS COMPILATION: I cannot compile and run gnubg 1.08 on Windows using 
MSYS2. Once compiled, gnubg cannot open any of its needed files (MET, weights, 
textures, etc). Jon kindly helped and encountered the same issue on his 
computer. He mentioned it could be an issue with g_fopen. Any idea anyone?



On 10-Feb-24 11:56 PM, Murat K wrote:
> On 2/9/2024 10:59 PM, Murat K wrote:
> 
>> It replaced my gnubgautorc with a default file. I installed it on 
>> another computer to make sure. It did the same thing. Is this 
>> intentional? What is the fix to use my previous settings??
> 
> I had never installed 1_08_dev-20240103. I tried it and it does the 
> same thing. Interesting that nobody else noticed or complained about 
> this. I went back to 1_08_dev-20230709 and all is fine. I guess I'll 
> just have to do without the latest and greatest improvements... ;)
> 
> MK
> 
> External e-mail, be judicious when opening attachments or links

RE: Interesting question/experiment about value of cube ownership

[Bug reports for and general discussion about GNU Backgammon.]

It just so happens that I rolled out the opening position a few days ago for 
another reason. This was at 7-away 7-away rather than $ play, because I was 
interested in match play. I doubt that makes a huge difference.



This was using gnubg-1_08_dev-20240103-setup.exe not the newest 
gnubg-1_08_001-20240204-setup.exe that Philippe released recently.



Philippe, am I correct in thinking that the cube handling on these two versions 
is the same? Your announcement emails both include the same comment.


“Improvement to cube decisions at 0- and 1-ply and weaker levels. Cube error 
rates are approximately halved and the repartition of errors (premature doubles 
vs. missed doubles vs. take or pass errors) is now similar to higher plies 
instead of being mostly premature doubles.”



The rollout results indicate about 1% fewer wins for the roller than the 
evaluations.



4HPwATDgc/ABMA:cAngAAAE



Cube analysis

Rollout cubeless equity +0.0408 (Money: +0.0396)



Cubeful equities:

1. No double   +0.0655

2. Double, pass+1.  (+0.9345)

3. Double, take-0.2999  (-0.3654)

Proper cube action: No double, take (28.1%)



Rollout details:

Centered 1-cube:

  0.5129 0.1480 0.0083 - 0.4871 0.1351 0.0073 CL +0.0408 CF +0.0655

[0.0001 0.0002 0.0001 - 0.0001 0.0001 0.0001 CL  0.0003 CF  0.0008]

gnubg owns 2-cube:

  0.5156 0.1522 0.0091 - 0.4844 0.1375 0.0150 CL +0.1216 CF -0.2999

[0.0001 0.0002 0.0001 - 0.0001 0.0002 0.0002 CL  0.0007 CF  0.0012]

Full cubeful rollout with variance reduction

186624 games, rollout as initial position, Mersenne Twister dice generator with 
seed 823069761

Play: world class 2-ply cubeful prune [world class]

keep the first 0 0-ply moves and up to 8 more moves within equity 0.16

Skip pruning for 1-ply moves.

Cube: 2-ply cubeful prune [world class]



Cheers,

Ian



-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of MK
Sent: Thursday, February 8, 2024 2:23 AM
To: bug-gnubg@gnu.org
Subject: Interesting question/experiment about value of cube ownership



I'm chugging along with my mutant cube skill experiments as I can spare time, 
saving all games, which I will share on my web site, when I'm done, along with 
my scripts.



While doing the double at > 50% experiment, I remembered an old question I had 
asked in RGB about a year ago: What if the winner of the opening roll is 
allowed pre-double?



See thread:

https://groups.google.com/g/rec.games.backgammon/c/BVEnaqGM6dg/m/2c685q4DAAAJ



When you evaluate the opening position in GnuBG, this is what you get:



=

Position ID: 4HPwATDgc/ABMA

Match ID:cAkA



Evaluator:Contact

 Win W(g)W(bg)   L(g)L(bg)   EquityCubeful

static:  52.115.4 0.813.0 0.8   +0.067+0.084

  1 ply:  52.714.8 0.912.9 0.5   +0.076+0.098

  2 ply:  52.514.9 0.712.5 0.5   +0.076+0.099



Cube analysis

2-ply cubeless equity +0.076

52.5  14.9   0.7 -  47.5  12.5   0.5

Cubeful equities:

1. No double   +0.099

2. Double, pass+1.000  (+0.901)

3. Double, take-0.171  (-0.270)

Proper cube action: No double, take (23.0%) 
=



I have created a Python script to intervene if the human player wins the 
opening roll, to set the cube at 2 owned by the bot, and then to execute "end 
game" command, for the bot to play for both sides at the same checker and cube 
skill settings.



So, you know the equity gained by winning the opening roll and the equity lost 
by making the cube error at the same time, before the first move. Can anyone 
tell me what I will be expecting to see after, let's say,

10,000 games, in terms of which side will win/lose by what percentage?



BTW: I already know. ;) I'm asking to see how confident are you in GnuBG's 
equity and/or error calculations and how competent are you to make mathematical 
predictions?



MK

Re: Problems with auto-roll and auto-play functions

[Bug reports for and general discussion about GNU Backgammon.]

Hi Murat,

Good luck with your project.

No, I'm not one of the developers. I can just about read C if I stare at it 
long enough. But I've never devoted time to learn it properly.

I've just been on the mailing list a long time, contributed bug reports and 
rollout time, and answered questions when I can to save the real devs the 
bother.

My coding skills are specific to industrial control systems. It's rather 
different to standard high level languages.


Regards,

Ian Shaw



From: MK 
Sent: Friday, January 19, 2024 11:25:10 PM
To: Ian Shaw ; bug-gnubg@gnu.org 
Subject: Re: Problems with auto-roll and auto-play functions

On 1/19/2024 2:37 AM, Ian Shaw wrote:

> I know nothing of Python, so I can’t help you with that. Good luck.

I just spent a couple hours on Python today, starting with this
post from Michael Petch in December 2013:

https://lists.gnu.org/archive/html/bug-gnubg/2013-12/msg00013.html

It briefly explain how to start using the GNUBG module. Then I
visited https://docs.python.org/3.10/tutorial/index.html and
selectively read from the Python tutorial some sections to get
a quick start.

If you know other programming languages, you'll pick it up very
fast. I really like it. I was able to quickly figure out the
individual parts of the script that I need already, using the
interactive interpreter. Hopefully I will be able to assemble
them into an actual script file and will share it freely when
I get it working. I would encourage you and anyone who wants
to experiment with GnuBG to take a look at it.

Are you one of the GnuBG development team? My other comments
about the auto-roll and auto-play functions, (unrelated to the
specific subject of the script making cube decisions for the
bot), are still valid and hopefully will be heeded by the GnuBG
team. In fact, they cause problems in the GUI also. If interested
you guys can look at this thread in RGB for example:

https://groups.google.com/g/rec.games.backgammon/c/ikCPgBiZHvs/m/SW66d7ZACAAJ

Thanks for your trying to help. You did at least motivate me.

MK

RE: Problems with auto-roll and auto-play functions

[Bug reports for and general discussion about GNU Backgammon.]

Hi MK, 

I know nothing of Python, so I can’t help you with that. Good luck.

-- Ian

-Original Message-
From: MK  
Sent: Friday, January 19, 2024 12:20 AM
To: Ian Shaw ; bug-gnubg@gnu.org
Subject: Re: Problems with auto-roll and auto-play functions

On 1/18/2024 2:22 PM, MK wrote:

> On 1/18/2024 6:31 AM, Ian Shaw wrote:

>> You can’t make the gnubg engine only be itself for some moves, and 
>> ask you to make the choices for other moves.

> There is no reason for this arbitrary, unnecessary limitation. Bot can 
> wait to roll and/or move until it's told to do so (i.e. "play" 
> command). If the user wants it to play automatically, he can just 
> select the auto-roll and auto-play setting. Simple logic and clean 
> implementation...

After looking at things some more, I realized that I had a misunderstanding how 
much can be done with a script. I thought you could intercept bot's play and 
inject a different play through the script. I see what you mean now that even 
though checker and cube settings are separate for players, you can't mix and 
match to have a half human half bot player.

So, the script has to parse the best checker hint and make the move also as you 
suggested. I guess we can continue to work towards a script with that in 
mind...?

MK

RE: Improved gnubg filenaming convention - suggestion

[Bug reports for and general discussion about GNU Backgammon.]

The file file.c has a function GetFilename which includes the line

if (mi.nYear)
sz = g_strdup_printf("%s-%s_%dp_%04u-%02u-%02u.sgf", ap[0].szName, 
ap[1].szName, ms. nMatchTo, mi.nYear, mi.nMonth, mi.nDay);


I couldn’t find where mi is set, but  if it includes the parameters nHour and 
nMinute it would be easy to add these to the name.

The else condition of (mi.nYear) contains code that does appear to use the hour 
and minute, so it looks like there might be some inconsistency:


if (strftime(tstr, 14, "%Y-%m-%d-%H%M", localtime()) == 0)

*tstr = '\0';



sz = g_strdup_printf("%s-%s_%dp_%s.sgf", ap[0].szName, 
ap[1].szName, ms.nMatchTo, tstr);



From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of Wayne Joseph
Sent: Thursday, January 18, 2024 11:33 AM
To: bug-gnubg@gnu.org
Subject: Improved gnubg filenaming convention - suggestion


Is the way gnubg names files something that just I find sub-optimal, or is it 
fine for everybody else?

I imagine like many of us, some days, I will play multiple matches (5-10) 
against gnubg backgammon. I like to analyse and save each of them afterwards

When I click save, by default, it auto names the file with the following 
convention:

gnubg–profilename_matchlength_-mm-dd

like.. gnubg–skope_5p_2024-01-18.sgf

I then click Save.

I might then play another match, analyse it and then try and save it

Unfortunately, it then tries to save with exactly the same naming convention

gnubg–profilename_matchlength_-mm-dd

gnubg–skope_5p_2024-01-18.sgf

Of course, this leads to a file name clash and an error message is presented 
each and every time:

File "\gnubg–profilename_matchlength_-mm-dd.sgf" exists. Overwrite?

--

To propose a relatively 'easy' solution to this, I think it would make better 
sense to add an hour-minute timestamp to the existing file name convention?

i.e.

"\gnubg–profilename_matchlength_-mm-dd_hh-mm.sgf

That way one could save multiple matches played the same day without repeatedly 
encountering the error message and the need to manually rename each saved match 
file to something unique.

In addition, for a cherry on top, it would be even better if the error rate for 
each analysed match was also appended to the file name i.e. -4.3 or -8.5 or 
whatever. This could allow for even easier searching and filtering/foldering of 
match files with blunders for retrospective study on each user's PC

-

To make it clearer -

Old style filename:

gnubg–skope_5p_2024-01-18.sgf

vs

New style auto-unique filename:

gnubg–skope_5p_2024-01-18_17-05_4.3.sgf

-

I'll admit, the proposed file name convention is longer and perhaps less 
'readable' but the benefit is it contains more valuable information, adds 
utility and is unique.



Who is the best person in the bg community to speak to in order to give this 
feature request the best chance of being implemented please?

RE: Problems with auto-roll and auto-play functions

[Bug reports for and general discussion about GNU Backgammon.]

Hi Murat,



The code doesn’t "make an exception for the bot". The bot already ALWAYS 
automatically decides whether to roll or move. The exceptions are for the 
human, to speed up our play when the decision is trivial. The human is allowed 
to roll, EXCEPT if the auto roll is checked and he doesn’t have cube access; 
the human allowed to make their own move, EXCEPT if the auto play options are 
checked for forced moves or greedy bearoff, in which case it makes the move 
generated by the bot.



If the bot looked at the auto-roll or auto-play options, how would you expect 
behaviour to differ from what it does now?
[cid:image003.png@01DA4A11.D6B50D20]

  *   The bot will always roll if it can’t double. Auto-roll can't change this.
  *   The bot will always play a forced move. Play forced moves can't change 
this.
  *   The bot will always select the best bearoff play. It wouldn’t save any 
time by enforcing greedy bearoff, but it would lead to occasional errors.



As I understand it. what you are trying to do is make have Player 1 make 
decisions that are not the one the bot would make. If you want a Player to make 
moves that gnubg would not make, then gnubg can’t be the player. You can’t make 
the gnubg engine only be itself for some moves, and ask you to make the choices 
for other moves.



That is I why I suggested setting Player 1 as Human, because you can make your 
own choices, but also ask gnubg for a Hint as to what it recommends. (What you 
seem to want to do is to make gnubg ask YOU for a hint and play that move 
instead of its own!)



The Options, Players dialogue does have a 3rd option for an external player. 
But I’ve never heard of anybody using it and I don’t know whether  it works.



[cid:image001.png@01DA4A0E.0C9FAE80]



You didn’t say what script language you are using. As far as I know, gnubg only 
supports Python. You can also run  a simple file of gnubg commands, but there 
is no calculation of choice options there if I recall correctly (any scripts I 
wrote were at least 2 computers ago and I’ve lost them ☹).


The simplest way to ensure both sides are using the same evaluation parameters, 
set Player 0 to GNU Backgammon to World Class, as above. Set Settings, Analysis 
to World Class and the Hint Level to use the same as analysis.

[cid:image005.jpg@01DA4A12.A1F9CB60]



The alternative is to look in gnubgautorc and ensure the settings are as you 
wish, or edit the settings you want in another file of commands that you load.



It’s interesting that you think the cube decision can be improved upon. Have 
you reviewed the changes that Philippe has just announced to 0-and 1-ply cubes? 
I haven’t, but I’m wondering what changes you have planned compared to the 
originals or to his.

What’s your algorithm?



Regards,

Ian



-Original Message-
From: MK 
Sent: Wednesday, January 17, 2024 5:34 PM
To: Ian Shaw ; bug-gnubg@gnu.org
Subject: Re: Problems with auto-roll and auto-play functions



On 1/17/2024 2:52 AM, Ian Shaw wrote:



> Hi Murat,



Hi Ian,



Thanks for trying to help with such detailed suggestions, which I don't get too 
often. So, I appreciate it. I will respond to your ideas and also explain what 
I want to do, so that you or others may offer further/better ideas.



> I would expect the auto-roll and auto-play functions to only apply to

> the human player. The bot makes it's own decisions on whether to roll

> or move.



I understand. Bot can still make its own cube and checker decisions with or 
without auto-roll or auto-move. The code should not waste additional logic to 
make an exception for the bot. The flags should work the same for human and bot.

What's wrong with that? It will take five minute to take out the addition "if" 
in the code. Very simple with huge flexibility and benefits to experimenters.



> If you have a script that makes moves, perhaps you could approach it

> in another way. Set the player to human. Get a hint. Parse the first

> hint and make that move.

> In the CLI, “hint 1” shows the best move. But if you have a script,

> perhaps can extract the output of hint.



Parsing the bot's cube and checker hints and then making the human player 
execute these would take excessive and unnecessary effort and even then it may 
not work if the hints don't exactly match how the bot actually plays at the 
same ply settings.



> What are you trying to achieve?



Okay, let me explain. I want to experiment with alternative double/take points, 
etc. using the CLI. Both players will be the bot set at, let's say, 3-ply cube 
and 3-ply checker.



When Player-1 is on roll, the script simply will say "Play"

and the bot will make its cube and/or checker move as usual.



When Player-2 is on roll, if it doesn't have access to the cube, the script 
simply will say "Play" and the bot will make its checker move as usual.



If it has access to the cube or has to respond to a cube action from Player-1, 
the script will get its winning chances from 

RE: Problems with auto-roll and auto-play functions

[Bug reports for and general discussion about GNU Backgammon.]

Hi Murat,



I would expect the auto-roll and auto-play functions to only apply to the human 
player. The bot makes it's own decisions on whether to roll or move.



If you have a script that makes moves, perhaps you could approach it in another 
way.



Set the player to human.

Get a hint.

Parse the first hint and make that move. On the GUI you can select the 1st move 
and press the Move button.

Or, simply press Enter while the Hint Windows is displayed to make the first 
move on the list. (This seems only to work for chequer plays, not cube 
decisions).



In the CLI, “hint 1” shows the best move.

I haven’t found a way of passing this to the move command. I’ve tried move hint 
1, hint 1 | move, move 1 > hint, move < hint 1 etc.

But if you have a script, perhaps can extract the output of hint.





What are you trying to achieve?





While experimenting, I've found that you can also type directly onto the Hint 
window and a command line appears on it. This seems to be an undocumented 
feature/anomaly, and I’m not sure it does anything in reality.
[cid:image001.png@01DA4928.CFF57360]



Cheers,

Ian Shaw



-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of MK
Sent: Tuesday, January 16, 2024 7:33 PM
To: bug-gnubg@gnu.org
Subject: Problems with auto-roll and auto-play functions



Unchecking these in the Game tab under General Options has no effect when GnuBG 
is made to play against itself in neither GUI nor CLI mode.



This makes it impossible to run scripts that let the bot make some decisions 
and let the script make some others, (perhaps among other problems in other 
situations).



This most likely very simple to fix bug was discussed in RGB probably more than 
once over the past years but I'm not sure if it was ever reported here. So, I'm 
doing it now and hoping that it will be fixed soon.



MK

RE: GNU backgammon - random starting point?

[Bug reports for and general discussion about GNU Backgammon.]

I thought we used to be able to paste a position ID without it resetting the 
match score, so we could play it repeatedly. 

This came up quite independently for me today when I wanted to practice 
64S-55K-F-DT.
4HPhQUAzTvABMA:QQkE is the position and match ID.
It works splendidly when I paste this in. I then play out the game and start a 
Game 2. 

When I paste in only the position QQkE into game , boths games 1 get 
wiped and it starts again at game 1.

In my mind, this is new behaviour. I think I used to set up several interesting 
related positions by pasting them into one game and then rolling them out. 

Version GNU Backgammon 1.05.000-dev1-mingw 32-Bit 20150120

The interactive rollout is a nice idea. Would it be too hard to add the human 
player into the skill settings for both players.

The other option would be to add a position ID option, either on
Options Game Variations
Or probably more intuitive would to add it to the
New... menu, with options to select who is on roll and whether it's the 1st 
roll of the game. 

That would allow you to practice a position such as the blitz above, or play 
one of Simborg's weird variations. 

-- Ian 



Cheers,
Ian Shaw

-Original Message-
From: bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org 
 On Behalf Of Philippe 
Michel
Sent: Thursday, November 30, 2023 9:07 PM
To: Flurn Zero One 
Cc: bug-gnubg@gnu.org
Subject: Re: GNU backgammon - random starting point?

On Wed, Nov 29, 2023 at 02:15:27PM -0500, Flurn Zero One wrote:

>     Is there a way to start a game in GNU backgammon at a random 
> starting point, instead of starting from the beginning?  I'm using 
> Windows, if that makes any difference.

Do you mean a randomly generated position, or an arbitrary one you set up 
(presumably to play it out multiple times) ?

In the first case this doesn't seem very easy.

In the second case editing the starting position you want, saving it in a sgf 
file and opening the file again and again might be adequate, although this will 
be slightly different from a real game, for instance the same player will be on 
roll every time.

What would be interesting and provide this feature in a much cleaner way would 
be to implement something similar to Jellyfish's interactive rollouts. It may 
not be that easy to modify the current rollout code to have the human player 
handling one side (or both), though.

New rule request: No "hit-and-run" in the player's home board.

[Bug reports for and general discussion about GNU Backgammon.]

Hello!
I want request a new rule ( "no-home-hit-and-run" ) for gnubg if possible.

The Player may not make additional moves with a checker that has hit an 
opponent’s checker in the Player’s home board.
There are two exceptions to this rule.
Player doesn’t have any other legal moves.
Player hits with a pair of checkers and replays both checkers.
 

RE: GNU Backgammon

[Bug reports for and general discussion about GNU Backgammon.]

Yes!

 

Øystein’s logic reminds me of an anecdote from years ago. A friend took a 
double in a non-skill position that was a clear drop. The dice bailed him out, 
but he redoubled way too early. He explained, “you’re the better player so I 
have to do things with the cube.” I explained that the reason I’m a better 
player is I don’t make silly cube errors. 

 

Best,

 

David 

 

PS – he won the match, so what do I know?

 

 

 

From: Øystein Schønning-Johansen  
Sent: Tuesday, August 23, 2022 11:29 AM
To: Joseph Heled 
Cc: Ian Shaw ; pub...@booksongaming.com; Ezequiel 
Galarce ; bug-gnubg 
Subject: Re: GNU Backgammon

 

Yes!

 

I am also very skeptical of the effect of skewed match equity tables. Why 
should this work?

If the best player is better he has a higher probability of winning, so his/her 
doubling point is appearing earlier.

 

However in a position type where skill is not really dominant, say no contact 
position, the doubling from the strongest player should rather be delayed to 
avoid the underdog being lucky.

 

I strongly believe that cube handling in matches of uneven players should 
rather consider the skill needed to play the specific position on the board. 
Just making a skewed MET is in my opinion not the solution.

 

As a serious besserwisser, I am (in this case) not willing to make any effort 
to do any type of experiments to prove me right. (I'm just using the same logic 
as flat-earthers and ani-vaxxers etc.) :-)

 

-Øystein

 

tir. 23. aug. 2022 kl. 19:56 skrev Joseph Heled mailto:jhe...@gmail.com> >:

 

A personal note, if I may.

 

Back in the day I dabbled with rating adjusted equity tables, i.e. having the 
stronger player use an adjusted equity table based on the rating difference.

 

I was never able to make it work. If anything, it ended up with the higher 
rated "player" doing worse. It's possible I implemented it wrong, but I would 
like to see some evidence first ...

 

Also, using different equity tables rarely makes a difference in actual play. 
Again I struggled to prove that one equity table is much better in practice 
than others.  

With todays computing power it should be much easier to set up experiments. 
Anyone up to the task?

 

(Ian might remember how I distributed the rollouts for the net training. I 
could not have done it without you or the others!!!)

 

-Joseph

 

 

On Wed, 24 Aug 2022 at 05:12, Ian Shaw mailto:ian.s...@riverauto.co.uk> > wrote:

Thanks David.

 

That T-12 is very interesting. I see that the subsequent tables are based on an 
increasing cubeless win % by 1% per 50 rating points. 

 

The Elo formula gives a higher win rate for a given rating (in a 1-point match) 
than the equivalent Jacobs Table. 

 


Table #

Page

Rating point difference

Jacobs Table cpw

Elo cpw


T-13

32

0 (even)

50.0

50.0


T-15

34

100

52.0

52.9


T-17

36

200

54.0

55.7


T-19

38

300

56.0

58.6

 

I’ll try to construct the xml files for the tables over the next few days. 

 

-- Ian 

 

 

 

From: pub...@booksongaming.com   
mailto:pub...@booksongaming.com> > 
Sent: 23 August 2022 17:33
To: Ian Shaw mailto:ian.s...@riverauto.co.uk> >; 
'Øystein Schønning-Johansen' mailto:oyste...@gmail.com> >; 
'Ezequiel Galarce' mailto:egala...@gmail.com> >; 
'bug-gnubg' mailto:bug-gnubg@gnu.org> >
Subject: RE: GNU Backgammon

 

Ian et al,

 

I also included T-12 which gives the parameters for subsequent tables. Let me 
know if you want more. 

 

I’m also not sure how happy the list-serv is with 5MB of attachments. I can 
find other ways to send them if need be.

 

Best,

 

David

 

From: Ian Shaw mailto:ian.s...@riverauto.co.uk> > 
Sent: Tuesday, August 23, 2022 12:59 AM
To: public@booksongamingcom  ; 'Øystein 
Schønning-Johansen' mailto:oyste...@gmail.com> >; 
'Ezequiel Galarce' mailto:egala...@gmail.com> >; 
'bug-gnubg' mailto:bug-gnubg@gnu.org> >
Subject: RE: GNU Backgammon

 

Hi David, 

 

>From 
>https://bkgm.com/articles/Sengoku/GraphicalMatchEquity/FishEffects/index.html 
>I understand that these are the tables used for compiling the METs.

 

Since we have a jac50, I assume that one would be T-14. 

If you could send a picture of T-17 and T-19, that would be great.

 


Table #

Page

Rating point difference


T-13

32

0 (even)


T-15

34

100


T-17

36

200


T-19

38

300

 

Thanks, 

Ian Shaw

 

 

From: pub...@booksongaming.com   
mailto:pub...@booksongaming.com> > 
Sent: 23 August 2022 00:29
To: Ian Shaw mailto:ian.s...@riverauto.co.uk> >; 
'Øystein Schønning-Johansen' mailto:oyste...@gmail.com> >; 
'Ezequiel Galarce' mailto:egala...@gmail.com> >; 
'bug-gnubg' mailto:bug-gnubg@gnu.org> >
Subject: RE: GNU Backgammon

 

I have a copy of the book. There are more than 60 tables in it, but if anyone 
knows which one(s) you’re looking for, I’m happy to send along photos.

 

Best,

 

David Levy

 

From: Bug-gnubg 

RE: GNU Backgammon

[Bug reports for and general discussion about GNU Backgammon.]

I have a copy of the book. There are more than 60 tables in it, but if
anyone knows which one(s) you’re looking for, I’m happy to send along
photos.

 

Best,

 

David Levy

 

From: Bug-gnubg  On
Behalf Of Ian Shaw
Sent: Monday, August 22, 2022 1:34 PM
To: Øystein Schønning-Johansen ; Ezequiel Galarce
; bug-gnubg 
Subject: Re: GNU Backgammon

 

There was a table in the book. Tom Keith refers to it in one of his articles
on bkgm.com.

 

If I can resurrect an old hard drive, I'll have a look. 

 

It ought to be possible to generate fish tables from first principles,
assuming a win rate and gammon rate per player. 

 

I think Jacobs used 24% gammon rate, which is higher than most. 

 

Regards,

Ian Shaw



 

  _  

From: Bug-gnubg mailto:bug-gnubg-bounces+ian.shaw=riverauto.co...@gnu.org> > on behalf of
Øystein Schønning-Johansen mailto:oyste...@gmail.com> >
Sent: Monday, August 22, 2022 5:08:30 PM
To: Ezequiel Galarce mailto:egala...@gmail.com> >;
bug-gnubg mailto:bug-gnubg@gnu.org> >
Subject: Re: GNU Backgammon 

 

Hmmm 

 

If my archive remembers correctly there never was a jac200 table. I don't
have a copy of "Can a Fish Taste Twice as Good?", is it even a table in that
book? I find no file called jac200.xml in the CVS attic either. So if there
was a file called jac200,xml it must have been a local contribution that
never was checked in.

 

The guy who contributed this was named Craig Campbell. (Must be 20 years ago
or so) Is it possible to get hold of him?

 

-Øystein

 

man. 22. aug. 2022 kl. 17:27 skrev Ezequiel Galarce mailto:egala...@gmail.com> >:

I don't know, I'm asking the creator of the equity table, maybe he has it

 

El lun., 22 ago. 2022 16:06, Ian Shaw mailto:ian.s...@riverauto.co.uk> > escribió:

H Ezequiel, 

 

Now that you mention it, I think you’re right. I wonder why it’s been
omitted from the installation. 

 

Does anyone here have a copy of the jac200 MET?

 

-- Ian 

 

From: Ezequiel Galarce mailto:egala...@gmail.com> > 
Sent: 22 August 2022 15:01
To: Ian Shaw mailto:ian.s...@riverauto.co.uk> >
Subject: Re: GNU Backgammon

 

Hello, I have contacted the creator of "jac050" and "jac100" and he told me
that he thinks he remembers that he had made a "jac200", I don't have any
data.

 

El lun., 22 ago. 2022 12:51, Ian Shaw mailto:ian.s...@riverauto.co.uk> > escribió:

Hi Ezequiel,

 

I don’t think the jac200 table is available on line. 

 

If you have the raw data, it’s easy to make a MET that gnubg can use. I
could create one if you can find the data

 

Regards,

Ian

 

 

From: Ezequiel Galarce mailto:egala...@gmail.com> > 
Sent: 19 August 2022 22:19
To: Ian Shaw mailto:ian.s...@riverauto.co.uk> >
Subject: Re: GNU Backgammon

 

Hello good evening, can you get the equity table "jac200.xml"?

 

El vie., 19 ago. 2022 14:54, Ian Shaw mailto:ian.s...@riverauto.co.uk> > escribió: