Pseudo-Random Number Generators - why bother?
Karlheinz Agsteiner
"Ian Shaw" <ian....@riverauto.co.uk> writes:
> Please, please, tell me that using the system clock does not produce an even
> distribution of numbers due to the relativistic nature of time and the
> factorability of the occult number 36, or something else highly technical.
> I'm not happy with the concept of using a lesser solution just because you
> can prove exactly how less good it is.
For a purely interactive application a random generator based
on a timer (a very fast one, though, seconds won't do) will
work well. But whenever a program contains the sequence
1. get a random number from the generator
2. perform stuff without user interaction (ie. something that
involves waiting for the user)
3. get another random number
the program will be in deep trouble. For example the trivial
solution in backgammon:
1. user makes his move
2. first die = a random number
3. second die = another random number
will fail miserably because step two will always take precisely
the same amount of time so the second die will always be the value
of the first time plus a constant, mod 6. So even in a trivial
case as computing two dices you'll have to work around an unnecessary
problem with eg.
1. user makes his move
2. both dices = random number 0..35
3. first die = both / 6; second die = bodh mod 6.
And of course chances are that any kind of demo, auto play,
auto bear-off, rollout will run into major problems.
Because all of this nobody is using timed random numbers for anything
- it's far too dangerous they might be completely non-random.
Karlheinz
--
Karlheinz Agsteiner | http://www.tu-chemnitz.de/~kag
Institute of Computer Systems | "I've done everything you can do
Department of Computer Science | on computers. I'm 31."
Chemnitz University of Technology | (Douglas Coupland: Microserfs)
Murat Kalinyaprak
>I've just had the "JellyFish cheats, it must cheat, it
>gets too many lucky rolls" discussion with someone at work.
>I quickly satisfied him with a demonstration that the seed
>and counter alone governed the roll produced.
So you were able to sell the same baloney to another
poor soul who fell for it...?
For the umpteenth time: JF's seed counter scheme is
not enough to prove that it's not cheating. Offering
that scheme as proof is short-logic, false-logic,
smoke-and-mirrors, snow-job, hocus-pocus, hogwash,
horse-shit (sorry for the language but I thought I
should use whatever words I could to make sure that
this points gets accross)...
Seed and counter only shows that JF rolls the same
dice again and again, but they don't prove anything
about where the dice rolls come from, how they are
generated, etc...
It's possible that JF doesn't "cheat" with the dice
but the seed and counter scheme is no proof for it.
If anybody, including the author of JF, want to show
that JF doesn't cheat, then they should do it right
by offering *proof* not "pooff"...
>His next question was, "Why do all that when you could just
>take the value of the system clock and take mod 36? The
>instant that the user clicks to roll and move is unpredictable
>and therefore genuinely random."
In that case, if JF gets 66 just when it needs it,
then people would say that it rolled what it needed
on the fly... Predetermined dice rolls prevent this
argument but this is only one of many possible ways
of cheating (about which there has been been many
speculations made and some of them could very well
be implemented to whatever extent they may succeed).
>My only answer was that by having a predictable Pseudo-Random
>Number Generator, one could confound cynics like him!
>This seems illogical. This amounts to arguing that it is better
>to have a completely predictable but well distributed series
>rather than a completly unpedictable and random one.
"Completely random" rolls may produce extremes that
would take very large number of rolls to even out.
Pseudo-random/predetermined rolls can "create" that
evenness much faster and would, in my opinion, be
just as good (if not better). But they lead to the
possibility that they may also be manipulated for
whatever other purposes...
Of course, there are other ways to implement better
schemes than JF's seed/counter, in order to dispel
suspicions about predetermined rolls but I'm not
going to openly volunteer such ideas which could
benefit bg software developers in a newsgroup where
some developers ignore/avoid my questions...
>Please, please, tell me that using the system clock does not
>produce an even distribution of numbers due to the relativistic
>nature of time and the factorability of the occult number 36,
>or something else highly technical.
I think that "good" enough random dice rolls can
be produced using the system clock very easily.
Overly simplistic algorithms may get caught in
cycles, depending on the pace of the players for
example. But more than one layer of "randomness"
could be used to avoid such deficiencies. Also,
certain types of mild "filtering" can be used to
eliminate harsh extremes of "complete randomness".
For example, you can put a limit on how many times
in a row the same roll may be allowed or you can
roll-ahead and adjust the numbers to stay close to
"theorical average roll value". As long as such
manipulations are done in ways unbiased for either
player, they would be fair and still random enough
for all practical purposes. I don't know "complex"
of an algorithm is needed to generate pseudo-random
rolls like JF's, but an algorithm incorporating all
of the above (and then some more) would hardly be
considered "complex" by any decent programmer.
MK
MJR
>
> It's possible that JF doesn't "cheat" with the dice
> but the seed and counter scheme is no proof for it.
> If anybody, including the author of JF, want to show
> that JF doesn't cheat, then they should do it right
> by offering *proof* not "pooff"...
>
http://www.bkgm.com/rgb/rgb.cgi?menu+fibsdice,softwaredoesitcheat
(in particular:) http://www.bkgm.com/rgb/rgb.cgi?view+528
Karlheinz Agsteiner
mu...@cyberport.net (Murat Kalinyaprak) writes:
> For the umpteenth time: JF's seed counter scheme is
> not enough to prove that it's not cheating. Offering
In addition to the various things you can try to "statistically prove"
that JF doesn't cheat there's one I found particularly nice to test if
JF selects only those initial seed/counter values that eg. give it
higher numbers than you.
Do the following: First start a new game. Note the random seed and
counter. Make the first roll of dices. Note the dice values. Now start
a new game. For the first roll select "manual dice", enter the dice
values you noted but change who's the first to move. Now set the seed
to the one you noted, the counter to the one you noted + 1.
After this little procedure you're getting the dice JF would
have got in the original game and JF gets yours. Play a lot
of games this way and with the non-reversed dice and check
if there's a difference (I didn't find any).
> It's possible that JF doesn't "cheat" with the dice
> but the seed and counter scheme is no proof for it.
> If anybody, including the author of JF, want to show
> that JF doesn't cheat, then they should do it right
> by offering *proof* not "pooff"...
After all the "JF cheats" postings I've read I think that maybe the
developers should split the random generator off the game and have the
two programs communicate by a publicly known protocol (for example
via sockets or whatever similar concept Windows knows). This way
you could use a public random generator, write your own or whatever.
This would make absolutely obvious that JF doesn't cheat or know the
dice values ahead without being as tedious as manual rolls.
On the other side - why bother? I'm getting stomped by JF
regardless of if I play normal, with switched sides, or
with manual dice.
Herb & Lee Kanner
k...@informatik.tu-chemnitz.de (Karlheinz Agsteiner) wrote:
Chapter 3 (Volume 2) of Donald Knuth's The Art Of Computer
Programming--Semi-Numerical Algorithms deals with pseudo-random number
generation and testint. Pages 54 through 97 specifically discuss
testint. Applying some of the better tests to the generated sequence
should settle the argument as to whether the generated sequence is a
satisfactory immitation of a truly random sequence.
Herb
>
>
> Because all of this nobody is using timed random numbers for anything
> - it's far too dangerous they might be completely non-random.
>
> Karlheinz
>
> --
> Karlheinz Agsteiner | http://www.tu-chemnitz.de/~kag
> Institute of Computer Systems | "I've done everything you can do
> Department of Computer Science | on computers. I'm 31."
> Chemnitz University of Technology | (Douglas Coupland: Microserfs)
--
Herb and/or Lee Kanner
Julian
Murat Kalinyaprak wrote in message <6s0ds6$2i7$1...@news.chatlink.com>...
<snip>
>I think that "good" enough random dice rolls can
>be produced using the system clock very easily.
>Overly simplistic algorithms may get caught in
>cycles, depending on the pace of the players for
>example. But more than one layer of "randomness"
>could be used to avoid such deficiencies. Also,
>certain types of mild "filtering" can be used to
>eliminate harsh extremes of "complete randomness".
>
>For example, you can put a limit on how many times
>in a row the same roll may be allowed or you can
>roll-ahead and adjust the numbers to stay close to
>"theorical average roll value".
<snip)
>MK
You have got to be kidding. You would eliminate a 1 in a million roll series
because it does fit the "theorectic average roll value"?
Just because rolling 6-6 in 7 consecutive rolls is likely never to happen,
it doesn't mean you should eliminate the chance of it ever happening.
By introducing your proposed "filter" you are introducing non randomness
into the rolls...which contradicts your previous arguments.
by introducing another factor into the random number generation in
conjunction with the system clock...such as the screen co-ordiates of a
specific pixel of the mouse arrow (apologies to all text based users) the
chances of eliminating a system clock cyclical error would be greatly
reduced without a "rules based" filtering scheme
julian
Murat Kalinyaprak
>Murat Kalinyaprak writes:
>> For the umpteenth time: JF's seed counter scheme is
>> not enough to prove that it's not cheating. Offering
>In addition to the various things you can try to
>"statistically prove" that JF doesn't cheat
Could you please expand on what "things" do
"statistically prove" JF doesn't cheat...?
>there's one I found particularly nice to test if JF
>selects only those initial seed/counter values that
>eg. give it higher numbers than you. .....
>..... Now set the seed to the one you noted, the
>counter to the one you noted + 1.
I was aware of this from almost the beginning
and in fact used/mentioned it while reporting
JF's dice bug and in other instances. But it's
good that you pointed it out again, as it may
help any new readers of the newsgroup.
There are "possibilities" that this test doesn't
eliminate. The issue of possible patterns in
JF's dice has been hashed over many times, so I
won't repeat them. If there are indeed patterns
that can be decisive enough to games' outcomes
(regardless of at what stage they occur), this
could mean that either "JF wins-human wins-JF
wins-human wins" or "human wins-JF wins-human
wins-JF wins"... With a few skips in between,
they may win/loose in a different order but
neither one might win by a large margin (i.e.
even the backgammon gods couldn't win any more
than 50+another few games out of 100 against JF).
As I developed a habit of doing by now, let me
clarify once more that I'm not making claims on
"what is" but only speculating on "what may be".
If a debate on a given subject gets to the level
of "proofs" and if that debate is expected to be
conducted based on logical arguments, then every
possible question may be raised and needs to be
answered until what's offered by either side can
be called "proof".
>After all the "JF cheats" postings I've read I think
>that maybe the developers should split the random
>generator off the game and have the two programs
>communicate by a publicly known protocol (for example
>via sockets or whatever similar concept Windows knows).
Yes and I think similar suggestions may have been
made before also. However, as far as the question
here is concerned, whatever future changes will
accomplish nothing more than turning it from "IS
JF cheating" to "WAS JF cheating" and 100 years
from now it will still be the same question unless
answered by then...
JF's dice rolls has been trivialized and segregated
from its playing abilities by its developer's and
supporter's own arguments. They should have never
gone as far to offer schemes like seed/counter as
"proof" for its not cheating with the dice, and
instead (or in addition) they could have made the
dice rolling algorithm public. I have never heard
anybody say they downloaded JF player to use it
as a dice roller while playing monoply. I just
don't see what big value can there be in its dice
rolling algorithm to keep it secret. If anybody
does, I would appreciate if they would point it
out to me.
It's almost silly that this discussion is still
going on but I just can't let go of it, because
every now and then some new user makes a comment
about JF's "cheating" and the regulars of the
group are still referring them to some old old
articles archived at some web site. Come on guys,
make some effort to be a little more creative and
try to answer some of the new questions raised...
MK
Murat Kalinyaprak
>Murat Kalinyaprak wrote:
>>For example, you can put a limit on how many times
>>in a row the same roll may be allowed or you can
>>roll-ahead and adjust the numbers to stay close to
>>"theorical average roll value".
>You have got to be kidding. You would eliminate a 1 in a
>million roll series because it does fit the "theorectic
>average roll value"?
You were talking about "better distribution" of
pseudo-random rolls (and as though that was an
advantage over "purely random" rolls, if I had
understood correctly), so I was just giving some
examples of how "more random" (i.e. not completely
predetermined) rolls may be manipulated on-the-go
to artificially expedite better distribution.
>Just because rolling 6-6 in 7 consecutive rolls is likely
>never to happen, it doesn't mean you should eliminate the
>chance of it ever happening.
I wasn't arguing about what/how things should be
done but just proposing that relatively simple
algorithms based on system clock could produce
similar results to other (perhaps more complex)
pseudo-random generators.
>By introducing your proposed "filter" you are introducing
>non randomness into the rolls...which contradicts your
>previous arguments.
I think the concept of "random" is very relative
with not a single definition that I'm aware of.
As long as the numbers rolled are not related to
the current position and/or favoring one of the
players, they are random enough for me. I don't
have the slightest intention of arguing what it
should mean to you and I respect your opinion on
what you would consider "random".
>by introducing another factor into the random number generation
>in conjunction with the system clock...such as the screen
>co-ordiates of a specific pixel of the mouse arrow (apologies
>to all text based users) the chances of eliminating a system
>clock cyclical error would be greatly reduced without a "rules
>based" filtering scheme
In case it was misunderstood, I was approaching
the two separately. Without specifying, I had
proposed that multiple-layers of randomness like
your pixel coordinate example could be used to
break cycles, except that the multiple-layers I
had in mind would still rely on the system clock
and nothing else.
Even after breaking problematic cycles, you can
still get pretty harsh extremes of randomness.
The filters, etc. that I proposed were additional
manipulations on top of this, with no claim that
they are obligatory, necessary or even better...
MK
Karlheinz Agsteiner
mu...@cyberport.net (Murat Kalinyaprak) writes:
> Karlheinz Agsteiner wrote:
>>In addition to the various things you can try to
>>"statistically prove" that JF doesn't cheat
>
> Could you please expand on what "things" do
> "statistically prove" JF doesn't cheat...?
I mean the "play n games under varying conditions" kind of methods. I
mean all the stuff mentioned in the URL someone else posted in one of
the "JF cheats" threads that point to a long and very interesting
posting of somebody a while ago. For example: play a number of games
with manual and non-manual dice, compare your results. If you're
playing maybe two 50 point matchs it should suffice to prove/disprove
a hypothesis like "JF doesn't win a different percentage" with maybe
5% error. The more the better (just making the numbers up from my
vast (haha) statistical experience) :)
> I was aware of this from almost the beginning
> and in fact used/mentioned it while reporting
> JF's dice bug and in other instances. But it's
> good that you pointed it out again, as it may
> help any new readers of the newsgroup.
Oops, sorry.
> As I developed a habit of doing by now, let me
> clarify once more that I'm not making claims on
> "what is" but only speculating on "what may be".
> If a debate on a given subject gets to the level
> of "proofs" and if that debate is expected to be
> conducted based on logical arguments, then every
> possible question may be raised and needs to be
> answered until what's offered by either side can
> be called "proof".
Oh, in that case ignore my point above. You can never statistically
disprove something like "jellyfish cheats every >10th move" without a
_huge_ number of games played. I was just trying to point out that for
the average player there's no difference between the amount of games
he wins with manual or automatic dice. Whatever statistical results I
might show you, you can always counter with some kind of cheating that
would just fall below that border. For example instead of the normal
"seed generation" there might be one that gives you only those seeds
that contain no four 6+6 rolls in 50 rolls for the opponent. The
probability of this is so little that you can play forever with
manual/auto dice, you'll never be able to disprove it with eg. 99%
certainty.
> Yes and I think similar suggestions may have been
> made before also. However, as far as the question
Damn, always those newbies (me) posting the same stuff over and
over. :) Sorry (but I just can't read everything that's ever posted
concerning jellyfish).
> here is concerned, whatever future changes will
> accomplish nothing more than turning it from "IS
> JF cheating" to "WAS JF cheating" and 100 years
> from now it will still be the same question unless
> answered by then...
:)
> JF's dice rolls has been trivialized and segregated
> from its playing abilities by its developer's and
> supporter's own arguments. They should have never
> gone as far to offer schemes like seed/counter as
> "proof" for its not cheating with the dice, and
> instead (or in addition) they could have made the
> dice rolling algorithm public. I have never heard
Even if they'd do this there would be numerous cheats
possible (all the "knows the next roll" things).
> It's almost silly that this discussion is still
> going on but I just can't let go of it, because
> every now and then some new user makes a comment
> about JF's "cheating" and the regulars of the
> group are still referring them to some old old
> articles archived at some web site. Come on guys,
> make some effort to be a little more creative and
> try to answer some of the new questions raised...
Hm, I've read in this newsgroup that
1. you can show that the dice are fixed, ie. are deterministic
for a given seed and counter.
2. you can show that the play depends deterministic in a given
situation (board x roll) by playing a position with different
seeds.
Furthermore (and probably posted here, too :) ) it's the case that
3. Jellyfish doesn't seem to store anything on my harddisk
apart from stuff I want it to store. Particularly, it doesn't
store all its previous rolls (which would be necessary to
fake random seeds without running into contradictions). I'm
not sure if somebody has already covered this, but a lot of
the "jf cheats" postings I've read base on simulating a
random cube. Of course when JF would try to make me believe
that eg. the 4th roll of seed 1, counter 2 has _always_
been a 6+6 it has to store that somewhere.
I conclude from 1. and 3. that there are only two numbers available to
JF that influence the roll, therefore there's a fixed algorithm that
computes a roll _solely depending on these two numbers_. Any
"override" of this algorithm's result (depending on the situation)
would have to be stored somewhere or at a later run the same numbers
would result in a different roll for the same seed/counter (which
obviously isn't the case). This could be disproved by playing a game
where JF has been particularly lucky, noting the original
seed/counter, rebooting the computer and playing the same seed/counter
values from another position (maybe the "I get JF's roll and the other
way round" method)
And I conclude from 2. that this roll and nothing but this roll is
used to determine JF's move. Sure, JF can look ahead 20 rolls but it
can't use this information or it would show with the "change seed,
play same position" method.
If I'm not missing anything the only possible ways to
cheat left after this are
a) the algorithm that generates random numbers from the
seed/counter doesn't generate true random numbers, ie.
it could generate sequences of "slightly more than 7
pips (?)/move", "slightly less then 7 pips/move".
b) the initial seed/counters are selected in a way that
it has an advantage. For example, only those are used
where the sum of the next 50 rolls JF will get exceeds
those the player will get by a certain amount.
I don't think there's a way other than statistics to
prove/disprove a) or b). But simply noting maybe a
thousand consecutive rolls both players get and comparing
should do the trick.
Of course I'm way to lazy to actually test all that but
then I do believe that JF plays fair :)
Looking forward to your reply (I'm sure I'm missing
something somewhere :) ).
Murat Kalinyaprak
>> It's possible that JF doesn't "cheat" with the dice
>> but the seed and counter scheme is no proof for it.
>> If anybody, including the author of JF, want to show
>> that JF doesn't cheat, then they should do it right
>> by offering *proof* not "pooff"...
>http://www.bkgm.com/rgb/rgb.cgi?menu+fibsdice,softwaredoesitcheat
>(in particular:) http://www.bkgm.com/rgb/rgb.cgi?view+528
I had read all those just before or shortly after I
started writing in this newsgroup. There is nothing
in them that can be called "proof". They eliminate
some possibilities, but not all. For the past many
weeks/months, I/we have been speculating about other
possibilities and also offered some data on limited
experiments. It's sad to see that there have been so
many people (including the ones offering them) for
whom "pooff" was enough to be convinced with. But I
hope that this will be the last time anyone will be
referred to those articles at that web site...
MK
Murat Kalinyaprak
>Murat Kalinyaprak writes:
>> Could you please expand on what "things" do
>> "statistically prove" JF doesn't cheat...?
>..... For example: play a number of games with manual
>and non-manual dice, compare your results. If you're
>playing maybe two 50 point matchs it should suffice
>to prove/disprove a hypothesis like "JF doesn't win a
>different percentage" with maybe 5% error. The more
>the better (just making the numbers up from my vast
>(haha) statistical experience) :)
I'm not sure if such results could be called
"proof", yet I would accept them at least as
very strong indications in either direction.
But I haven't seen anyone offer such data. I
myself offered some data about JF's average
dice values, game lengths, etc. but nobody
elaborated or offered counter arguments on
those either. It seems to me that games played
with JF's dice go faster than real-life. Each
set of 100 games I played against it were over
in about 5500 rolls total. Before I started
writing these, I just made JF play 100 games
against itself and they took about 5300 rolls.
That's about 26.5-27.5 average rolls per game
per player. I don't have data accumulated based
on games played with manual dice to compare but
these just seem a little too close to 21 roll
minimum-average needed to finish a non-contact
game with perfect-bearoff...
>> As I developed a habit of doing by now, let me
>> clarify once more that I'm not making claims on
>> "what is" but only speculating on "what may be".
>> If a debate on a given subject gets to the level
>> of "proofs" and if that debate is expected to be
>> conducted based on logical arguments, then every
>> possible question may be raised and needs to be
>> answered until what's offered by either side can
>> be called "proof".
>Oh, in that case ignore my point above. You can never
>statistically disprove something like "jellyfish cheats
>every >10th move" without a _huge_ number of games played.
>..... For example instead of the normal "seed generation"
>there might be one that gives you only those seeds that
>contain no four 6+6 rolls in 50 rolls for the opponent.
>The probability of this is so little that you can play
>forever with manual/auto dice, you'll never be able to
>disprove it with eg. 99% certainty.
You are right but the proof doesn't need to be
limited to statistical conclusions. This isn't
a Easter egg-hunt either, where the users would
be challenged and rewarded for finding "proof"
for JF's cheating. If it's ok for some people
to assert that "JF doesn't cheat" without proof,
then it should be ok for others to say that "JF
cheats" without proof also. This is my point in
initiating and/or participating in threads on
this subject. Otherwise, I really don't care if
JF cheats or not.
What I find further unfair in all this is that
not only that the people who can't offer proof
keep asking it from others, but the people who
argue that JF doesn't cheat have better means
of offering proof than what the other side has.
Granted some people may never be satisfied, but
at least more could have been and still could be
done, such as the author's publishing JF's dice
rolling algorithm, which could satisfy more/most
people. Not only this is not done but *none* of
the people who argue that JF doesn't cheat even
care to try offering a reason why it's not done.
>> Yes and I think similar suggestions may have been
>> made before also. However, as far as the question
>Damn, always those newbies (me) posting the same stuff
>over and over. :) Sorry (but I just can't read
>everything that's ever posted concerning jellyfish).
No problem. This is very easy to understand as
there are nearly 19,000 articles in Deja-News'
rgb archive and I myself only read maybe a few
hundred of them selectively. I'm just pointing
out things so that you can quicky catch up on
the past issues/arguments (at least about the
ones since I joined this newsgroup).
>> here is concerned, whatever future changes will
>> accomplish nothing more than turning it from "IS
>> JF cheating" to "WAS JF cheating" and 100 years
>> from now it will still be the same question unless
>> answered by then...
>:)
If there are people who are curiously waiting
for the next revision of JF, I must be one of
them... :)
>> JF's dice rolls has been trivialized and segregated
>> from its playing abilities by its developer's and
>> supporter's own arguments. They should have never
>> gone as far to offer schemes like seed/counter as
>> "proof" for its not cheating with the dice, and
>> instead (or in addition) they could have made the
>> dice rolling algorithm public. I have never heard
>Even if they'd do this there would be numerous cheats
>possible (all the "knows the next roll" things).
I think JF's making the same moves with any given
position/dice combinations, regardless of how the
dice is rolled, would be enough to refute this.
>> It's almost silly that this discussion is still
>> going on but I just can't let go of it, because
>> every now and then some new user makes a comment
>> about JF's "cheating" and the regulars of the
>> group are still referring them to some old old
>> articles archived at some web site. Come on guys,
>> make some effort to be a little more creative and
>> try to answer some of the new questions raised...
>If I'm not missing anything the only possible ways to
>cheat left after this are
>a) the algorithm that generates random numbers from the
> seed/counter doesn't generate true random numbers, ie.
> it could generate sequences of "slightly more than 7
> pips (?)/move", "slightly less then 7 pips/move".
Considering the doubles are played 4 times, I
think the magical number is 8.16. For the 24
games lasting 21 rolls or less (out of the 100
that I had played), this average was higher
for all but one (for which it was 8.05) and it
was as high as 10.83 (which is 1.33 times 8.16).
I had calculated and posted the overall average
for the 24 games also but I don't remember what
it was, except that it was "considerably" higher
in my opinion. On the other hand, I have never
seen anybody post similar data showing JF's dice
rolls averaging below 8.16 in X number of games.
I had made/posted other observations like the
above mentioned game with 8.05 average lasting
only 21 moves and total value of the dice rolls
adding up to 169 (2 more than the minimum 167).
I think for this to happen, those 21 rolls must
have almost perfectly fallen in place. Here are
some more details that may be interesting (just
considering games that took about 2x8.16 more
pips than 167):
Game Winner Pips Rolls Avg.
---- ------ ---- ----- ----
#08 MK 184 21 8.76
#11 JF 185 21 8.81
#13 MK 177 20 8.85
#29 MK 187 21 8.90 - winner takes 1 hit!
#35 MK 169 21 8.05
#43 MK 184 20 9.20 - winner takes 1 hit!
#47 MK 177 *18* 9.83 - winner takes 1 hit!
#52 JF 175 *18* 9.72
#63 JF 179 20 8.95 - winner takes *2* hits!
#78 MK 187 20 9.35
#90 JF 184 21 8.76 - winner takes 1 hit!
#99 JF 181 21 8.62 - winner takes *2* hits!
What is interesting about these is not necessarily
the higher average roll values but that some games
could end in 20 rolls and only 12 pips above the
minimum 167 required even after winner takes 2 hits.
Can anyone explain these by anything other than the
dice rolls falling neatly in place...? How about the
fact that all these occurred in only 100 games...?
>b) the initial seed/counters are selected in a way that
> it has an advantage. For example, only those are used
> where the sum of the next 50 rolls JF will get exceeds
> those the player will get by a certain amount.
This is possible but I think it could only apply to
first games and its effect wouldn't add up to much.
>I don't think there's a way other than statistics to
>prove/disprove a) or b). But simply noting maybe a
>thousand consecutive rolls both players get and comparing
>should do the trick.
I had actually offered that I would be willing to
spend some time doing such analyses if there was
a convenient way to produce large numbers of JF's
dice rolls and store them for later processing (by
importing into databases/spreadsheets or by simple
programs). Not with the exclusive intention/claim
to prove that JF cheats but just to see and accept
whatever results may emerge out of them...
>Looking forward to your reply (I'm sure I'm missing
>something somewhere :) ).
I can't claim that I have an imagination wild
enough to cover all possibilities, but I have
tried to contribute my share to show that what
had been offered thus far as proof of JF's not
cheating were not enough to be called proof. I
hope what I wrote (repeated:) in this article
was of some interest to you other readers...
MK
MJR
> >(in particular:) http://www.bkgm.com/rgb/rgb.cgi?view+528
>
> I had read all those just before or shortly after I
> started writing in this newsgroup. There is nothing
> in them that can be called "proof". They eliminate
> some possibilities, but not all. For the past many
What type of proof are you looking for? One of the first things stated
in second article is that it is impossible to prove that JF *never*
manipulates the dice. So that sorta limits what can be proven. The
article continues to show how you can *satisfy* yourself that JF doesn't
cheat while you are watching for cheating. The method presented seems
like enough proof to me.
If you are really interested in this debate, then why don't you offer
some statements which can be either proven or disproven. Instead of
being vague and general in rejecting the methods in the article, how
about being more explicit and specifying which arguments are invalid,
and why they are invalid. Just like you dont believe people who think
JF doesn't cheat without proof, people who think JF doesn't cheat wont
believe you without proof.
I am not going to say that JF never cheats, because how do I know. But
I will say that I am personally convinced that it doesn't So far no one
has been able to show any method which proves that JF cheats with the
dice. Many have shown methods for proving that JF doesn't cheat with
the dice in a large number of situations. If you can prove that JF
cheats, then I too will believe that JF cheats, but until then I will
remain convinced that it doesn't.
Remember, if you want absolute proof, people are already pointing out
that it is impossible to prove absolutely. Which JF are we talking
about anyway? How do we know the copy on my machine is the same as on
yours? The program could be distributed with secret cheater versions in
the mix. And its not just the copy that matters...what about the
machine its running on, the particular hardware and software it has
installed...or even the manufacturers of the chips used on the boards.
All of these can affect how the program runs if there are conspirators
involved.
So if there is no absolute proof, why I am so convinced? Well, consider
that I also have no proof that the sun will rise tomorrow, but I am
pretty convinced of that too. (Still, I'm sure there are a number
people convinced that the world will end tomorrow..they might be right
too)
Karlheinz Agsteiner
mu...@cyberport.net (Murat Kalinyaprak) writes:
>>a) the algorithm that generates random numbers from the
>> seed/counter doesn't generate true random numbers, ie.
>> it could generate sequences of "slightly more than 7
>> pips (?)/move", "slightly less then 7 pips/move".
>
> Considering the doubles are played 4 times, I
> think the magical number is 8.16. For the 24
> games lasting 21 rolls or less (out of the 100
> that I had played), this average was higher
> for all but one (for which it was 8.05) and it
> was as high as 10.83 (which is 1.33 times 8.16).
That doesn't match my experience (and 100 games are not that many). So
here we go (drum roll) my big JF "demo mode" cube test.
After a few frustrating moments against JF last week I decided to take
a closer look at its random generator to find out if there are
differences between the rolls of player 1 (JF in non-demo games) and
player two (user in non-demo games). Here's my results.
(beware: long and boring stuff full of numbers ahead :) )
The first thing I did was write a little Java application that reads
JF's match files, adds up all rolls for both players, saves the sums
for further invocations, and produces some statistics. You can take
a look at the source code and/or download the class file (you need a
java vm to run it) at
http://herkules.informatik.tu-chemnitz.de/kag/bg/JFTest.java
http://herkules.informatik.tu-chemnitz.de/kag/bg/JFTest.class
To check how random the results are I've produced the same statistics
from random rolls. The program:
http://herkules.informatik.tu-chemnitz.de/kag/bg/JFCheck.java
http://herkules.informatik.tu-chemnitz.de/kag/bg/JFCheck.class
(usage: You call JFTest by java JFTest <file> where <file> is
a .mat file. JFTest will read its private file "jf_rolls.dat",
<file>, update jf_rolls.dat and produce statistics like below.
Specify a non-existing file and you'll only see statistics.
You call JFCheck by java JFCheck <number> where <number> is
the number of random rolls to do. No file is produced, only
statistics are written).
My first tests were, of course, feeding my saved games into it. And
strangely the results were quite un-random: my rolls were significantly
higher than JF's. The explanation is simple: I've saved mostly games
that I've won and in order to beat the superior player JF is compared
to me you obviously have to have a higher average roll (and luck). So much
for the difficulty of gaining unbiased results :)
Since I don't have any access to a lot of matches using JF's dice
I used the demo mode for my "real" test. Of course you might argue
now that if JF cheats it may well use different random generators
for demo and normal play. This has to be taken a look at later (has
anybody a huge number of games using JF's normal rolls?).
What I actually did was play 100-game demo matches and feed the
resulting .mat files (that are limited to 500 lines in JF Player)
into my program. This way I did 3 tests of about 55000 rolls
each. The results can be seen at the bottom of this text.
Here's what I've gained: The "average roll" seems to be even:
Pl1 average number of pips is 8.14, 18.16, 8.17, Pl2's
average number 8.12, 8,15, 8.19. Given that 8.16 (?) seems
to be the average number of pips that's pretty well in the
random area.
Now let's take a look at all the rolls. I'm tabulating the
ones that are more different from the expected number than
the average difference, and especially those that are even
more different than two times the average difference.
Test < 2 std.dev < 1 std.dev > 1 std.dev > 2 std.dev
-------------------------------------------------------------------
1 JF 33 11,52 43,64 51
2 JF 21,43,44,53 31,32,52,54
3 JF 32 41 21 65
1 Pl 31,55 32,53,63,66 54,61,62
2 Pl 66 21,22,32 61
3 Pl 22 51 42,62,64,65
The foremost candidate for a cheating random generator would be
the 66, of course. And strangely player 2 rolled 66 less than
he should. In test 1 he rolled 744 instead of 771, in test 2
even 714 instead of 770. Only in test 3 he rolled 759 of 761.
Player 1 (JF) didn't have this problem. He rolled 770 of 782,
768 of 781, and 763 of 773. On the other side JF got very
poor rolls more than average: 21, 32, 51. Player 2 got nothing
like this. Actually, 21 and 32 is listed as less than average
two times. (BTW. since the standard deviation is the average
difference from the expected value it is normal that there
are a lot of rolls above/below the limits of avg+/-std.dev).
IMHO the most important facts are that
* in the three tests there was no "pattern", no number that
occured always too often or not often enough.
* the maximum difference to the average was not bigger than
in the randomly rolled test cases.
All in all I don't see any significant difference between JF's
and Player 2's rolls (at least in demo mode). Like I expected,
JF seems to roll as fair as it plays. Of course it would
be more interesting to take a look at actual matches rolled by
JF but it will take a while until I've got enough... Another
interesting test I'm planning is looking at consecutive rolls,
maybe there's a pattern there.
--------------------
Here's the full test results. A few explanations: The first four lines show
the variance and standard deviation of doubles and normal rolls for both
players.
Then the all the rolls are shown in a table that contains
a) Number / number divided by total JF
b) Expected number for JF plus a number of stars. 0 stars means that
the actual number is closer to the expected number than the standard
deviation, 1 means less than 2*std.dev., 2 more than 2*std.dev.
c) a) for the player
d) b) for the player
e) "should be" probability for the number/totals.
The end of a test shows the total number of rolls of both players
(JF's rolls are more because of a bug in the formatting of demo
output - after a drop of JF the first roll of the next game is
not correctly formatted. Unless JF specifically cheats in roll
1 - I'm not suspecting that - that doesn't matter), the average
number of pips rolled for both players, and the average sum of both
dice.
============== Test 1 ==============
JF's Var/stddev XX: 760.8449074074074/27.583417253984457
JF's Var/stddev XY: 1478.2129629629628/38.44753520010045
Player's Var/stddev XX: 750.1774691358024/27.389367811904723
Player's Var/stddev XY: 1457.4876543209875/38.17705664821461
JF E(JF) Player E(Pl) should
Roll: 11: 739/0.0262 782* 774/0.0278 771 0.0277
Roll: 21: 1557/0.0552 1565 1573/0.0566 1543 0.0555
Roll: 22: 768/0.0272 782 768/0.0276 771 0.0277
Roll: 31: 1575/0.0559 1565 1454/0.0523 1543** 0.0555
Roll: 32: 1603/0.0568 1565 1505/0.0541 1543* 0.0555
Roll: 33: 720/0.0255 782** 782/0.0281 771 0.0277
Roll: 41: 1598/0.0567 1565 1541/0.0554 1543 0.0555
Roll: 42: 1534/0.0544 1565 1561/0.0561 1543 0.0555
Roll: 43: 1629/0.0578 1565* 1568/0.0564 1543 0.0555
Roll: 44: 795/0.0282 782 749/0.0269 771 0.0277
Roll: 51: 1662/0.0589 1565** 1626/0.0585 1543** 0.0555
Roll: 52: 1504/0.0533 1565* 1550/0.0557 1543 0.0555
Roll: 53: 1560/0.0553 1565 1505/0.0541 1543* 0.0555
Roll: 54: 1538/0.0545 1565 1594/0.0573 1543* 0.0555
Roll: 55: 765/0.0271 782 715/0.0257 771** 0.0277
Roll: 61: 1549/0.0549 1565 1608/0.0578 1543* 0.0555
Roll: 62: 1599/0.0567 1565 1583/0.0569 1543* 0.0555
Roll: 63: 1556/0.0552 1565 1504/0.0541 1543* 0.0555
Roll: 64: 1625/0.0576 1565* 1552/0.0558 1543 0.0555
Roll: 65: 1527/0.0542 1565 1522/0.0547 1543 0.0555
Roll: 66: 770/0.0273 782 744/0.0267 771* 0.0277
Total rolls JF :28173
Total rolls Player:27778
Total pip JF :229331
Total pip Player :225581
Pips/roll JF :8.14009867603734
Pips/roll Player :8.120851033191734
Avg. sum JF :7.0
Avg. sum Player :6.9911080711354305
============== Test 2 ==============
JF's Var/stddev XX: 759.6836419753085/27.56235915111964
JF's Var/stddev XY: 1475.9567901234568/38.41818306640043
Player's Var/stddev XX: 748.8541666666666/27.365199920093158
Player's Var/stddev XY: 1454.9166666666665/38.143369891327985
JF E(JF) Player E(Pl) should
Roll: 11: 788/0.0280 781 779/0.0280 770 0.0277
Roll: 21: 1494/0.0531 1562* 1490/0.0537 1540* 0.0555
Roll: 22: 752/0.0267 781* 742/0.0267 770* 0.0277
Roll: 31: 1607/0.0571 1562* 1529/0.0551 1540 0.0555
Roll: 32: 1614/0.0573 1562* 1494/0.0538 1540* 0.0555
Roll: 33: 781/0.0277 781 761/0.0274 770 0.0277
Roll: 41: 1569/0.0557 1562 1561/0.0562 1540 0.0555
Roll: 42: 1579/0.0561 1562 1538/0.0554 1540 0.0555
Roll: 43: 1491/0.0530 1562* 1562/0.0563 1540 0.0555
Roll: 44: 731/0.0259 781* 769/0.0277 770 0.0277
Roll: 51: 1573/0.0559 1562 1505/0.0542 1540 0.0555
Roll: 52: 1636/0.0581 1562* 1536/0.0553 1540 0.0555
Roll: 53: 1515/0.0538 1562* 1568/0.0565 1540 0.0555
Roll: 54: 1631/0.0579 1562* 1547/0.0557 1540 0.0555
Roll: 55: 808/0.0287 781 781/0.0281 770 0.0277
Roll: 61: 1540/0.0547 1562 1630/0.0587 1540** 0.0555
Roll: 62: 1533/0.0544 1562 1511/0.0544 1540 0.0555
Roll: 63: 1578/0.0560 1562 1563/0.0563 1540 0.0555
Roll: 64: 1547/0.0549 1562 1571/0.0566 1540 0.0555
Roll: 65: 1595/0.0567 1562 1578/0.0569 1540 0.0555
Roll: 66: 768/0.0273 781 714/0.0257 770** 0.0277
Total rolls JF :28130
Total rolls Player:27729
Total pip JF :229514
Total pip Player :226149
Pips/roll JF :8.15904728048347
Pips/roll Player :8.155685383533484
Avg. sum JF :7.006754354781372
Avg. sum Player :7.015290850733889
============== Test 3 ==============
JF's Var/stddev XX: 752.3919753086419/27.429764404905885
JF's Var/stddev XY: 1461.79012345679/38.23336400915815
Player's Var/stddev XX: 740.8063271604938/27.217757570389477
Player's Var/stddev XY: 1439.2808641975307/37.9378552925377
JF E(JF) Player E(Pl) should
Roll: 11: 765/0.0274 773 773/0.0281 761 0.0277
Roll: 21: 1587/0.0569 1547* 1539/0.0561 1523 0.0555
Roll: 22: 795/0.0285 773 702/0.0255 761** 0.0277
Roll: 31: 1585/0.0568 1547 1487/0.0542 1523 0.0555
Roll: 32: 1468/0.0526 1547** 1490/0.0543 1523 0.0555
Roll: 33: 769/0.0276 773 763/0.0278 761 0.0277
Roll: 41: 1507/0.0540 1547* 1513/0.0551 1523 0.0555
Roll: 42: 1530/0.0549 1547 1569/0.0571 1523* 0.0555
Roll: 43: 1528/0.0548 1547 1500/0.0546 1523 0.0555
Roll: 44: 768/0.0275 773 779/0.0283 761 0.0277
Roll: 51: 1532/0.0549 1547 1452/0.0529 1523* 0.0555
Roll: 52: 1529/0.0548 1547 1539/0.0561 1523 0.0555
Roll: 53: 1549/0.0555 1547 1551/0.0565 1523 0.0555
Roll: 54: 1554/0.0557 1547 1532/0.0558 1523 0.0555
Roll: 55: 780/0.0279 773 764/0.0278 761 0.0277
Roll: 61: 1536/0.0551 1547 1487/0.0542 1523 0.0555
Roll: 62: 1554/0.0557 1547 1594/0.0581 1523* 0.0555
Roll: 63: 1549/0.0555 1547 1503/0.0547 1523 0.0555
Roll: 64: 1582/0.0567 1547 1573/0.0573 1523* 0.0555
Roll: 65: 1630/0.0585 1547** 1562/0.0569 1523* 0.0555
Roll: 66: 763/0.0273 773 759/0.0276 761 0.0277
Total rolls JF :27860
Total rolls Player:27431
Total pip JF :227848
Total pip Player :224599
Pips/roll JF :8.178320172290022
Pips/roll Player :8.18778024862382
Avg. sum JF :7.014501076812635
Avg. sum Player :7.024424920710145
Murat Kalinyaprak
>>>http://www.bkgm.com/rgb/rgb.cgi?menu+fibsdice,softwaredoesitcheat
>>>(in particular:) http://www.bkgm.com/rgb/rgb.cgi?view+528
>> I had read all those just before or shortly after I
>> started writing in this newsgroup. There is nothing
>> in them that can be called "proof". They eliminate
>> some possibilities, but not all. For the past many
> What type of proof are you looking for?
Let me first "repeat" one more time that I'm not
looking for proof for any specific reason other
than to make the point that the people who request
proof from others have to provide proof for their
own arguments also...
Then let me "repeat" again, as an example, that
seeing the source code of JF's roll generator would
be more proof for me than all what had been offered
so far...
> One of the first things stated in second article is
> that it is impossible to prove that JF *never*
> manipulates the dice.
I don't find such arguments neither sincere nor
sufficient. Before making such arguments, one
should at least try to exhaust all possible ways
of accomplishing it. Whoever made that argument,
I would like to know what he had in mind to still
leave a door open and say that it's impossible to
to prove JF never manipulates the dice? What if,
for example, JF's dice rolling algorithm was put
in front of that person? Would he still argue that
even that wouldn't be "proof" enough? (It would be
proof enough even for me). So, why don't they take
the next step(s) and then reconsider their claims
based on whether there can be any possibilities
left for JF to manipulate the dice beyond/outside
of the dice rolling algorithm (which would sound
impossible to me)...
> So that sorta limits what can be proven. The article
> continues to show how you can *satisfy* yourself that
> JF doesn't cheat while you are watching for cheating.
> The method presented seems like enough proof to me.
That's fine. Whatever satisfies you/them is your/their
business. But you/they shouldn't try to impose that as
"proof" on other people...!
> If you are really interested in this debate, then why
> don't you offer some statements which can be either
> proven or disproven. Instead of being vague and general
> in rejecting the methods in the article, how about being
> more explicit and specifying which arguments are invalid,
> and why they are invalid.
I think I have done just that, in fact to the point
of getting tired of repeating them...
> Just like you dont believe people who think JF doesn't
> cheat without proof, people who think JF doesn't cheat
> wont believe you without proof.
The important difference is that I or other people
who expressed their opinions about JF's "cheating"
didn't go as far to try convincing other people by
offering so-called "proofs"... The most I have seen
anyone do was to speculate on the possibilities and
only after being *pushed* to do so by "loud" JF
groupies/defenders who thought they had "proof" to
the contrary. If anybody still doesn't understand
this argument, there is nothing more I can say...
> Remember, if you want absolute proof, people are already
> pointing out that it is impossible to prove absolutely.
Fine, then if some people get an impression that JF
cheats and express their opinions here, they should
be left alone or at the most offered counter-opinions
without bashing them with "accusasions of accusing",
sarcasm, name callings, false/insufficient "proofs",
etc.
MK
Murat Kalinyaprak
>Murat Kalinyaprak writes:
>> Considering the doubles are played 4 times, I
>> think the magical number is 8.16. For the 24
>> games lasting 21 rolls or less (out of the 100
>> that I had played), this average was higher
>> for all but one (for which it was 8.05) and it
>> was as high as 10.83 (which is 1.33 times 8.16).
>That doesn't match my experience (and 100 games are not
>that many). So here we go (drum roll) my big JF "demo
>mode" cube test.
Thanks for your going through the trouble of doing
more extensive analisys of rolls. Let me also make
a few corrections/clarification about the data I
had offered.
The above average dice values were based on only
24 specific games (i.e. lasting 21 rolls or less)
not even the entire 100. So, I knew they would be
skewed but considering that average length of all
100 games was still only about 26.5 rolls, I had
assumed that the overall average dice value being
higher than normal would hold true for all of the
100 games (though being lower compared to those 24).
If I find time, I may recalculate an average for
all 100 games.
>Since I don't have any access to a lot of matches using
>JF's dice I used the demo mode for my "real" test. Of
>course you might argue now that if JF cheats it may well
>use different random generators for demo and normal play.
I haven't used the demo mode myself, but I had made
JF autoplay (for other reasons) some games we had
played starting at the same seed/counter values and
the rolls looked to be the same. I would feel pretty
safe in assuming that it's the case with demo mode
rolls as well.
> * in the three tests there was no "pattern", no number that
> occured always too often or not often enough.
This is good to know. The issues about "patterns"
were a little different though (i.e. not directly
related to the distribution of individual numbers).
> * the maximum difference to the average was not bigger than
> in the randomly rolled test cases.
This is good to know also.
>All in all I don't see any significant difference between JF's
>and Player 2's rolls (at least in demo mode).
Since anybody learns from very early on that players
can swap sides, I don't think player 1 and 2 getting
biased rolls has been an issue and/or was insisted on.
>... Another interesting test I'm planning is looking at
>consecutive rolls, maybe there's a pattern there.
This is one analysis I wish I could do. So, I would
be very interested to hear what results you come up
with if you get to do this test.
MK
Ian Shaw
Murat Kalinyaprak wrote in message <35ECDC...@cyberport.net>...
>MJR wrote:
>
>Then let me "repeat" again, as an example, that
>seeing the source code of JF's roll generator would
>be more proof for me than all what had been offered
>so far...
[snip]
>MK
>
How would you know that what you were shown was the genuine source code?
Would you require the developer to give you the entire source code for all 3
versions of JF, and the compiler so that you could verify that it compiled
to an executable (.exe)identical to the one you are using. Anything less
would surely require some measure of trust on your part that Fredrick was
not lying, and would therefore not be "proof", merely evidence.
I must confess I've lost track of this thread somewhat. Murat, do you mind
if I pose a few questions, phrased so that I hope your answers will clarify
things for me?
Do you currently suspect that JF deliberatly uses its knowledge of the dice
algorithm IN ANY WAY whilst choosing its moves?
Do you suspect that JF's dice rolling algorithm is imperfect, and that
during the training/development phase JF somehow (perhaps inadvertantly)
recognised this flaw and thus makes moves which enable it to take advantage
of said flaw?
Do you suspect that JF does not ALWAYS make the same play for a given
combination of;
board position, dice roll (manual or JF generated), match score, level
setting.
(I am aware that this can not be proven without trying every combination, or
checking the source code ;ลน) . I am fairly sure that if somebody had found a
single example they would have posted it.)
Regards,
Ian Shaw