My Null hypothesis was that this strategy has an expected net score of
zero against GNU Backgammon. However, while after 1000 games the
results were close to allowing me to reject this hypothesis,
continuing the session did not result in the mutant leaving the 2
sigma confidence interval.
Histogram after 3000 games
| Frequency | Points |
|-----------+--------|
| 152 | 1 |
| 453 | 2 |
| 283 | 4 |
| 10 | 6 |
| 1105 | 8 |
| 4 | 12 |
| 632 | 16 |
| 17 | 24 |
| 199 | 32 |
| 3 | 48 |
| 36 | 64 |
| 3 | 96 |
| 63 | 128 |
| 24 | 256 |
| 1 | 384 |
| 6 | 512 |
| 5 | 1024 |
| 1 | 2048 |
| 3 | 4096 |
Average: 2.18933
Variance: 21576.6
Maximum allowed lead: 16091
Actual lead: 6568
So the Jury was still out.
Now, since the cube got very high indeed (around 100 of the 3000 games resulted in more than 128 points, and I even got more than 1000 points
each in 9 games), this reminded me on the famous "eternal redouble"
position, see:
https://bkgm.com/rgb/rgb.cgi?view+366
After reading "Under-doubling dice",
https://bkgm.com/rgb/rgb.cgi?view+429
as well, I thought that maybe scenarios 4, 5 (and even 3) jack up the
cube so quickly that we suffer from the problem of not having equities
any more and get to a Peterburg Paradoxon.
I think that these scenarios could be analyzed using Markov chains,
The question I would really like to answer is: How can a money session
be protected against "abuse" by maniac gambling/doubling strategies to prevent a Peterburg Paradoxon from occurring? Is it sufficient to just eliminate Beavers? Or does the cube need to be capped (say at 64,
which would be the most natural solution)?
you haven't specified anything about the probability distribution
there's an unknown probability distribution and you're trying to
figure out something about it by sampling
keep collecting more statistics to see if you can get the frequencies
of the high cube values to "settle down."
I'd suggest forgetting about the mathematics of Markov chains, at
least at first
How often do you think GNU will offer a redouble in the course of a
game? How often does the mutant offer a redouble?
I don't know why one would want to protect against such "abuse."
But if you have someone like that in your chouette then you have a
problem that simple rule changes aren't going to fix.
Timothy Chow <tchow12000@yahoo.com> writes:
keep collecting more statistics to see if you can get the frequencies
of the high cube values to "settle down."
I intended to do so, but there is a small problem: GNU Backgammon does
not allow a cube value higher than 4096. And depending on the mutant
strategy this will be reached occasionally (more easily with raccoons, obviously).
I'd suggest forgetting about the mathematics of Markov chains, at
least at first
I had the idea of pursuing this path because it might avoid the capped
cube: Neither the mutant nor GNU Backgammon care about the absolute
value of the cube when redoubling/beavering/raccooning. So if I get a
rough estimate about how likely transitions from "mutant holds the cube
at x" to "gnubg holds the cube at 8x" are, I could work around the 4096 limit.
I don't know why one would want to protect against such "abuse."
To avoid both accusations of gambling and attraction of gamblers.
On 11/5/2021 1:20 PM, Axel Reichert wrote:
To avoid both accusations of gambling and attraction of gamblers.
Oh, well, in that case, don't play money games. Just play matches.
On 11/5/2021 1:20 PM, Axel Reichert wrote:
I intended to do so, but there is a small problem: GNU Backgammon does
not allow a cube value higher than 4096. And depending on the mutant
strategy this will be reached occasionally (more easily with raccoons,
obviously).
Ah, yes, that would be a problem. How hard is it to modify the code
to raise this ceiling?
But my point is that if you aren't very fluent with the mathematics of
Markov chains, don't let that stop you. The crux of the matter is
spelling out in detail some scenario where the cube gets very high.
Figuring out this part doesn't require technical knowledge so much as
clear thinking. Once you get this far, the Markov chain math should
be relatively straightforward.
I doubt that the strategy you outlined will run into St. Petersburg problems. After all, one side is standard GNU, so it's probably not
going to be jacking up the cube all that much.
Have you manually examined the 4096-cube games to see if the positions
are so wild that standard GNU has no idea what is going on, and is
beavering when it's losing?
Oh, well, in that case, don't play money games. Just play matches.
Timothy Chow <tchow12000@yahoo.com> writes:
I doubt that the strategy you outlined will run into St. Petersburg
problems. After all, one side is standard GNU, so it's probably not
going to be jacking up the cube all that much.
Yes, GNU Backgammon has a "times 2" cube (it will almost never be
beavered when playing against its own take/pass decisions), but if its opponent essentially wields a "times 8" cube and a symmetric "times 3"
cube already gives rise to a Petersburg Paradoxon, then I am not so
sure.
Oh, well, in that case, don't play money games. Just play matches.
Which is possible, but from a logistics point of view less flexible in a chouette setting.
Timothy Chow <tchow12000@yahoo.com> writes:
Ah, yes, that would be a problem. How hard is it to modify the code
to raise this ceiling?
I don't write C, but tried to read it. Maybe Philippe Michel can comment whether a re-compile with
#define MAX_CUBE ( 1 << 15 )
instead of 12 in backgammon.h might work (there are only 4 bits in the match-id for log2 of the cube value, so going still higher would likely
be too large a surgery). This would give leeway for another raccoon,
perhaps sufficient to get a "converged" histogram.
On 11/6/2021 6:26 AM, Axel Reichert wrote:
Yes, GNU Backgammon has a "times 2" cube (it will almost never be
beavered when playing against its own take/pass decisions), but if
its opponent essentially wields a "times 8" cube and a symmetric
"times 3" cube already gives rise to a Petersburg Paradoxon, then I
am not so sure.
The size of the cube doesn't have anything to do with it. It's all
about the frequency with which the "paradoxical" positions occur.
the cube won't get arbitrarily high unless standard GNU is redoubling
with sufficiently high probability.
If you're worried about getting a reputation for gambling then don't
play in a chouette.
Offhand, what I would try instead is to add something like:
if (ms.nCube > 64)
ms.nCube = ms.nCube / 64;
at the beginning of the ComputerTurn() function in play.c, and find the
final cube value in another way, for instance by counting the doubles in
the game log.
If this works, as a bonus, it would remove any limit to the cube level.
I am not necessarily talking about positions like "perpetual recube",
but about the usual swings in a "normal" game, with several moves in
between. If these swings occur frequently enough and at least one player
is rather cube-happy, then scenarios like
https://bkgm.com/rgb/rgb.cgi?view+429
seem plausible to me, at least with raccoons.
In the meantime, my little Markov chain program was ready and was fed
the probability data from two mutant sessions: I have run 10000 games
(0 beavers, no Jacoby) and then another session (1 beaver, no
Jacoby).
Suppose two players behave as follows. They play D/T every single
turn. They move the checkers the way a bot such as GNU does at DMP.
For simplicity let us say that gammons and backgammons don't count.
Does it make sense to talk about "expected payoff" in such a
situation? Of course, by symmetry, if the expected payoff exists
then it must be zero. But it is not immediately obvious that the
expected value exists. If the probability that a game lasts n rolls
drops off slower than 1/2^n then I think the expected payoff does
not exist.
It still seems to me that if only one side is doubling this
aggressively then we're not going to get undefined expected values,
but I see now what you're suggesting.
can you post a description of your Markov chain?
... Since I consider this case to be settled, I have not listed
them here, let me know if you want/need them.
The transition probabilities come from my "real" games
between the mutant and gnubg, 10000 without beavers,
10000 with 1 beaver, all below the cube limit of 4096.
The mutant doubled with cubeless GWC 0.5 and took all
beavers. Other take decisions (2-ply) and checker play
(0-ply) like gnubg.
Please let me know if you need something else.
Timothy Chow <tchow12000@yahoo.com> writes:
Suppose two players behave as follows. They play D/T every single
turn. They move the checkers the way a bot such as GNU does at DMP.
For simplicity let us say that gammons and backgammons don't count.
Does it make sense to talk about "expected payoff" in such a
situation? Of course, by symmetry, if the expected payoff exists
then it must be zero. But it is not immediately obvious that the
expected value exists. If the probability that a game lasts n rolls
drops off slower than 1/2^n then I think the expected payoff does
not exist.
Fully agree. And I am very sure that this ends up in Peterburg.
Without beavers, the expectation has settled, and by now I think that
1 beaver does not cause a Petersburg paradoxon either. But for 2
beavers my results are still far away from stability or there is no expectation any more. My gut feeling says the latter.
can you post a description of your Markov chain?
Sure. The states and transition probabilities (for 1 beaver) are as
follows:
On November 11, 2021 at 12:53:01 PM UTC-7, Axel Reichert wrote:
Why is the need for substituting fantasy for fact? Lack of needed CPU
time?
The mutant doubled with cubeless GWC 0.5 and took all beavers. Other
take decisions (2-ply) and checker play (0-ply) like gnubg.
The mutant should take also at a lower GWC
how can I download the text file of those 20,000 "real" games?
plot a histogram that shows how frequently a game lasts n rolls
Does the histogram coming from real games look close to the histogram
you get from the Markov chain?
That would provide a sanity check
Any other ideas that I could check? Or would you be able to provide
estimates for how many "games" I should run the Markov chains? Or any
hints on how to fit my session histogram to a (geometric) distribution
in order to further pursue the analytical path?
MK <mu...@compuplus.net> writes:
Why is the need for substituting fantasy for fact? Lack of needed
CPU time?
This is not fantasy, but a rock-solid mathematical technique. And
yes, CPU time is the reason.
The mutant should take also at a lower GWC
I know, we have discussed this. The session with
"Take if GWC > 0" is still running.
how can I download the text file of those 20,000 "real" games?
Sorry, I will not provide 2.5 GB of ASCII text.
Your 2.5Gb works out to 125K per game which doesn't sound real. What
am I missing?
When I say something like, you should diagonalize the transition
matrix in order to compute stationary probabilities, do you know what
I mean?
What histogram exactly are you trying to fit to a geometric
distribution?
In any case, one approach to fitting a geometric distribution is to
take the logarithms of the values, since these should lie on a
straight line, which you can estimate by doing a least-squares fit.
Timothy Chow <tchow12000@yahoo.com> writes:
When I say something like, you should diagonalize the transition
matrix in order to compute stationary probabilities, do you know what
I mean?
Not quite, since my 6 states do not all have 6 transitions and I believe
that the transition matrix should be a square one. I have no idea, e.g.,
how to cope with the difference in my state 5 (mutant owns cube) and the
two transitions for a simple take versus a take with beaver and how to
ensure that the cube value is carried through the process. So yes, I
would be very happy if you could walk me through, especially since I
guess it is the stationary probabilities that we are after.
For each of your 6 states, you need to create a bunch of states, each
with a different cube value. (There is a slight annoyance here in
that to keep things finite, you'll have to put a cap on the cube
value.)
If you don't have access to such software then I can probably do the computation for you if you send me the matrix.
MK <mu...@compuplus.net> writes:
Your 2.5Gb works out to 125K per game which doesn't
sound real. What am I missing?
Run
gnubg -t
from the command line and play one game. Multiplied by
10000, this gives my session file.
it sounds like the text files you are talking about contain ascii representations of all positions
can you export them as game/match files made of only the dice rolls
and moves in text?
MK <mu...@compuplus.net> writes:
it sounds like the text files you are talking about contain ascii
representations of all positions
Yes.
can you export them as game/match files made of only the
dice rolls and moves in text?
No, not any more, the sessions have been closed.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 17:10:48 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,190 |
Messages: | 5,327,170 |