On 3/16/2024 6:15 PM, Ian Shaw via "Bug reports for and general discussion
about GNU Backgammon. wrote:
You wrote "Not the "equity" but the "equity difference"
between the "from" position and the "to" position."
I said that because you had written: "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."
I don't know if the bot's not having an input is critical
because it can and indeed does seem to handle it later as
a special condition.
Each position has an average equity, which belongs to the
position itself, regardless of specific dice rolls, except
the starting position that can have two different equities
based when during the game it occurs.
What I had said applies to when the starting position is
the "previous position" not when it is the "next position".
Actually there is more to "maximizing equity" than this. I
will explain it further down.
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.
There is a philosophical question here, aside from how the
bot is programmed. When you land on a "next position" from
any other "previous position", it may not matter but when
the "previous position" is the stating position, it does
matter, in that the equity gain may not come solely from
the dice roll and how it is played.
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.
Thanks for the effort that allows one to see the net luck of
rolls (as played as the bot plays) without having to calculate
them individually.
Your first table is exactly the same as GnuBG's temperature
map. The second table show the net luck after subtracting the
average luck but I fail to understand the use of the last two
tables...?
The equity of 31 after returning to the opening position is
+0.219. The equity after an opening 31 is also +0.219.
I can't believe that you are saying this. How can it not be?
The luck of a roll is its deviance from the average equity of
the position, which is different between the initial and later
occurrences of the starting roll. At the expense of insulting
you, I must say I just felt that I may be too stupid to waste
may time here... :(
> I conclude that there is no problem with the equity calculation
> that would affect how gnubg plays.
Based on what? I had mentioned the bug in GnuBG code not to
dwell on the obvious small error which may hardly ever happen
in real life, (I personally don't remember ever seeing a game
recycled to the starting position in my entire life), but to
indicate that GnuBG does treat the initial and recycled cases
of the starting position differently. The question is whether
it does it correctly.
Here is the section of code for you all's convenience:
272if (is_init_board && n0 != n1) /* FIXME: this fails
if we return to the initial
position after a few moves */
273 return LuckFirst(anBoard, n0, n1, , );
274 else
275 return LuckNormal(anBoard, n0, n1, , );
The visible evidence such as the tempreature map and the eval
screen prove that GnuBG isn't doing it right at least partially.
I'm just not going to waste my time inspecting the rest of the
code, (which we used to call "spaghetti code" in the old days
and in the case of GnuBG I'm tempted to call it "macaroni and
cheese" code), in order to see if it does correctly internally
in other function. Perhaps someone from the GnuBG team, with a
mastery of its code, can tell us.
The temp map was a later addition to gnubg, so I don't think
it's used in the luck calculation.
Do you know when was it added? (BTW: To be fair, I know but I
am asking to see if you know what you are talking about).
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.
It's not just the temperature map. I had also attached the eval
screen. I agree that there won't be a ripple effect as far as
bot playing against itself but even so the final luck and skill
figures will reflect the calculation error.
The> luck calculation is based on the actual roll compared to
the> other 21 (14 in the opening) possible rolls.
Exactly. Because of another gamblegammon fallacy that luck+skill=1,
the error you will make playing the same dice roll at the initial
occurrence of the starting roll will be different than the error if
you do the same play at a recycled occurrence of the starting roll.
The luck of 31 after returning to
