Dice
EdmondT
I'm no computer programmer, but I have to believe that creating a program where
the dice "cheat" effectively would be one mean feat. You would need to teach
it to know when you need to cheat, what roll you would want to cheat, and then
teach it to back off on the cheating so you don't win every game and make it
obvious.
To me, this would be a Herculean programming task.
I think we now need an addendum to the old saying that pooerer players always
think better players are lucky. The new one should be Human players always
think computers cheat with dice.
William C. Jenkins
It seems to me that programming a good backgammon player is a "can't
win" situation.
If players beat the program consistantly, it "must not be any good."
If the program is effective enough to consistantly win, "it must be
cheating."
It's got to be tough being a programmer.
Gary Wong
I'm afraid I haven't been following this newsgroup (or playing backgammon)
as much as I would like to over the last few months, I've been busy with
other things. But recently I've noticed a large number of complaints
about all kinds of backgammon software -- I believe it could save us all a
significant amount of time if posters could in future please use the:
Official rec.games.backgammon Software Complaint Form
-----------------------------------------------------
I want to make as much noise as possible and let the world know about
a gross miscarriage of justice concerning the following software (check
all that apply):
[ ] FIBS
[ ] Games Grid
[ ] Jellyfish
[ ] Netgammon
[ ] Snowie
[ ] TD-Gammon
[ ] other (specify) ______________________
in the following manner (check all that apply):
[ ] it has a biased random dice generator
[ ] intentionally coded by the author to give "better" rolls to the
computer to create the illusion of an superior backgammon program;
[ ] unintentionally coded by the author because he/she is too
incompetent to program one, even though satisfactory algorithms
for generating psuedo-random sequences have been published for
decades;
[ ] a conspiracy between the (specify) ___________ backgammon server(s)
and (specify) _____________ bot operator(s) that gives the bot(s)
"better" dice than me (I'm sure Elvis and the Kennedy assassination
are involved here somewhere too, but I haven't discovered how yet);
[ ] a conspiracy between the (specify) ___________ backgammon server(s)
and (insert names of players who beat you) ________________ which
gives them "better" dice than me;
[ ] deliberately coded by the author to give weaker players higher
rankings to encourage them to continue paying to play there;
[ ] it maximises my duplication and minimises its own self-duplication to
give the impression it rolls more "lucky" numbers than I do (this must
be cheating, right?);
[ ] it is horribly overpriced (I KNOW this because my 8th grade teacher
once gave us a lesson on economics, it's all about the law of supply
and something else, and the distributor(s) would sell lots more copies
and the users would all be happy and we'd achieve world peace if it
was cheaper, and I don't want to pay that much for it anyway);
[ ] and it cheats too;
(Accusations of cheating only) I have the following proof (check all that
apply):
[ ] I'm really good at backgammon, I can beat my grandmother and my little
brother but the computer keeps winning against me, therefore it MUST
be cheating;
[ ] it rolled double-7 and escaped my 6-point prime;
[ ] it rolled a miracle 4-3 which was one of only 6 rolls that allowed it
to simultaneously complete its prime and hit the blot I left subject
to only 3 direct shots; THEN I rolled 6-4 and 5-5 and danced twice in a
row on a 3-point board -- there's no way that would happen with real
dice, so it MUST be cheating;
[ ] (the software in question) rolled 3 doubles in a row while bearing
off -- this is clearly impossible, so it MUST be cheating;
[ ] I've been playing for (specify) ___ years and never seen this before,
therefore it MUST be cheating;
I haven't formalised my suspicions, presented a falsifiable hypothesis,
designed an experiment, gathered data and made reasonable conculsions
because I (check all that apply):
[ ] don't know how;
[ ] can't be bothered;
[ ] already KNOW I'm right so there's no point doing any of that stuff;
In conclusion, I demand the following (check all that apply):
[ ] The author publish the source code;
[ ] The distributors reduce the price to (specify) $_.__; (commercial
software only);
[ ] I pirated the software in the first place, but it still cheats so
it isn't worth what I paid for it, so SOMEBODY owes me (specify)
$___,___.__ (commercial software only);
[ ] Since the software is already free, the distributors should pay ME
(insert amount) $___,___.__ to continue using their @!^$(* cheating
software (free software only);
[ ] I be compensated to the tune of (insert amount) $___,___,___.__
for damages resulting from the above complaints;
[ ] I don't really want anything except to stir up the same old
arguments in rec.games.backgammon. Has anybody else noticed this?
Signed,
(insert psuedonym) __________________
PS: What's the registration code for (specify software) _________________?
Cheers,
Gary. (formerly ga...@cs.auckland.ac.nz)
--
Gary Wong, Department of Computer Science, University of Arizona
ga...@cs.arizona.edu http://www.cs.arizona.edu/~gary/
e r g y @best.com Paul Ferguson
In article <199806241142...@ladder03.news.aol.com> EdmondT,
edm...@aol.com writes:
>I'm no computer programmer, but I have to believe that creating a program where
>the dice "cheat" effectively would be one mean feat. You would need to teach
>it to know when you need to cheat, what roll you would want to cheat, and then
>teach it to back off on the cheating so you don't win every game and make it
>obvious.
>
>To me, this would be a Herculean programming task.
>
>
Actually, it can be pretty easy. You don't have to guarantee that you will
win a given game, you just have to make it more favorable to you (and as you
said, you definitely don't want to win every game).
Here's one way to do this.
First write down a list of simple cheating ideas. Manipulating the dice can
be quite flagrant, since there is no one there to "see" you do it.
(1) If you roll a 1/2, roll again until you dice total > 9.
Only do this once per game.
(2) If your opponent is on the bar, give him a roll that
keeps him there. Only do this twice per game, maximum.
(3) Give yourself double sixes every 50-73rd roll.
(4) Give yourself double fours every 34-37th roll.
(5) Once every fifteen minutes, change the higher of
your opponent's dice to a one.
(6) Once every eleven minutes, change the lower of
your dice to a five or a six.
(7) Once every ninth time your opponent rolls doubles
or 6/5's, roll again until his dice total is < 6.
(8) etc, etc, etc...
None of these "Little Cheats" (tm) happen very often, but each contributes to
a definite home court advantage. Dozens of different Little Cheats can be
mixed and matched randomly (the mix can even be changed in the middle of a
game), making it very difficult to detect by analyzing the dice history.
Programming a Little Cheats system would be pretty straightforward (it might
make an interesting C++ class project). Individual Little Cheats are simple
to define and implement; they require no knowledge of backgammon strategy, and
little or no knowledge of backgammon mechanics.
The only hard part is finding a way to wire this into a server, I leave that
as an exercise for the interested reader... ;-)
//fergy
Phill Skelton
Gary Wong wrote:
>
> I'm afraid I haven't been following this newsgroup (or playing
> backgammon) as much as I would like to over the last few months,
> I've been busy with other things. But recently I've noticed a large
> number of complaints about all kinds of backgammon software -- I
> believe it could save us all a significant amount of time if
> posters could in future please use the:
>
> Official rec.games.backgammon Software Complaint Form
> -----------------------------------------------------
LOL! Excellent idea, and it could be used in 75% of posts here. As
long as it had a standard subject header most people could
then kill file it and save themselves a lot of pointless reading.
A generic 'How do you play this position/double' form should take
care of most of the other 25% of posts - the ones that are worth
reading.
Phill
Rodrigo Andrade
> The only hard part is finding a way to wire this into a server
Not at all. Netgammon guys probably know that already, but they'll not
publicize that for obvious reasons...
Sell your Little Cheats to the guy who makes Jellyfish (if he doesn't use
them already, that is), so he'll make a fortune of the next release.
Rodrigo
Rodrigo Andrade
*LOL* *LOL* *LOL* *LOL*
When read the word Dice on the subject I thought "Oh, no, not again!!!!!!
NO!!! They're resurrecting the beast to beat it to death again..." but your
post definitely made my day!!!
Rodrigo
Harold Evenson
Paul Ferguson > wrote in message <6mr8uf$82s$1...@nntp2.ba.best.com>...
You wouldn't notice on a game by game basis, however, such cheats would
change the distribution of the dice. If you were to analyse a hundred
thousand rolls, you would certainly notice that distribution was not
correct. You could statistically prove that the dice are not fair.
Of course, someone could argue that the program could simply substitute the
original roll at a later time in the game when it didnt matter, and the dice
would still meet statistical tests for fairness. This would mean that the
programmer would have to code not only the cheats, but also code to hide the
cheats. The program would have to determine at what point of the game to
stop cheating, and start adjusting rolls to hide the cheating. A bit more
difficult to program.
In some games the cheats might have caused the opponent to resign the point,
rather than play out the game. In these cases, the program would have no
opportunity to "hide" the cheating. This will leave the dice distribution
skewed, unless the program is able to 'remember' across games and matches.
A lot more difficult to program (and hide).
Programming 'little cheats' might be a straightforward exercise, but
programming a system to hide the cheats is hardly a simple feat.
e r g y @best.com Paul Ferguson
In article <6n10mk$gm...@crash.videotron.ab.ca> Harold Evenson,
Harold....@v-wave.com writes:
>Programming 'little cheats' might be a straightforward exercise, but
>programming a system to hide the cheats is hardly a simple feat.
>
Well, I haven't given this a great deal of thought, but I think that some
little cheats would be nearly impossible to detect, while others (such as
giving yourself double sixes every third roll) would be very obvious.
While most little cheats you think of (like my examples) might tend to give
you higher dice and your opponent lower dice, but this doesn't necessarily
need to be the case. For example, you could have little cheats that give your
opponent higher dice when it has no possibility of affecting the outcome of
the game. Or, if your opponent is on the bar, you could give him double sixes
once or twice (secure that he can't come in). If you're on the bar, and the
one point is open, a little cheat that gives you 1/2 or 1/3 would also work.
Creating a little cheats system that is resistant to sophisticated analysis
probably is a pretty involved, but not impossible. My statistics knowledge
(which was never very sophisticated to begin with) is far too rusty to ponder
this much further.
//fergy
Harold Evenson
Paul Ferguson > wrote in message <6n1vl5$cba$1...@nntp2.ba.best.com>...
>In article <6n10mk$gm...@crash.videotron.ab.ca> Harold Evenson,
>Harold....@v-wave.com writes:
>>Programming 'little cheats' might be a straightforward exercise, but
>>programming a system to hide the cheats is hardly a simple feat.
>>
>
>Well, I haven't given this a great deal of thought, but I think that some
>little cheats would be nearly impossible to detect, while others (such as
>giving yourself double sixes every third roll) would be very obvious.
Some cheats would be harder to spot then others, certainly.
>
>While most little cheats you think of (like my examples) might tend to give
>you higher dice and your opponent lower dice, but this doesn't necessarily
>need to be the case. For example, you could have little cheats that give
your
>opponent higher dice when it has no possibility of affecting the outcome of
>the game. Or, if your opponent is on the bar, you could give him double
sixes
>once or twice (secure that he can't come in). If you're on the bar, and
the
>one point is open, a little cheat that gives you 1/2 or 1/3 would also
work.
Well, if the cheat tends to give smaller rolls early in the game, and larger
ones when it is too late to effect the outcome, a number of the games will
have ended with a double/drop. So the cheat won't be able to correct the
distribution.
You can test whether the dice have a different distribution when you are on
the bar as opposed to when you are able to move. You can also test if you
are staying on the bar for longer than you should.
>
>Creating a little cheats system that is resistant to sophisticated analysis
>probably is a pretty involved, but not impossible. My statistics knowledge
>(which was never very sophisticated to begin with) is far too rusty to
ponder
>this much further.
For every way that you could cheat, you could come up with a statistical
test which would detect the cheat. Of course, if you don't know how the
program is cheating, it would be hard to come up with a hypothesis to test.
But I think a few standard tests would be able to detect the vast majority
of cheats.
You could collect data for
a) all dice rolls
b) when you are on the bar
c) when you are not on the bar
d) when you are trailing in pipcount
e) when you are leading in pipcount, etc
If the dice deviate from statistical norms in any of these cases, you could
prove cheating.
The hardest part would be to collect enough data to prove the program is
cheating. Sample sizes would have to be tens of thousands of observations
to have any statisical value.
Rodrigo Andrade
>the program could simply substitute the
>original roll at a later time in the game when it didnt matter, and the
dice
>would still meet statistical tests for fairness.
That's what this cheating thing is all about, isn't it??? The so called dice
statistics on Netgammon don't prove a damn thing!!!
RODRIGO
Harold Evenson
Rodrigo Andrade wrote in message <6n3gho$cd8$1...@news4.wt.net>...
Since the rest of my note after what you quoted (completely out of context)
dealt with why such a scheme would be difficult to implement, I'm not going
to repeat it here.
Of course the statistics on Netgammon don't prove a thing. It would be
impossible to prove that any program doesn't cheat by using statistics.
(Very hard to prove a negative.)
However, if a program is cheating, it would be possible to prove that it is
cheating by using statistics. You need to form a hypothesis about how a
program is cheating, and then collect data which would support or refute the
hypothesis.
Of course, if you don't have the initiative to do that, you can always fall
back to using paranoia, suspicion and innuendo to support your conclusions.
This really doesn't prove anything, but it probably makes you feel better.
