VASL dice bot...

[zgrose]

VASSAL is open source software. If you feel the dice bot doesn't have a sufficient random number generator, just code another one and submit it. Problem solved. End of story. Everyone can move on.

My DR guess:
dicebot 1,2,4,5
real 3

 

[UXB]

Design note and trend suggestion

One problem in implementing a die roll for two players in a single game
is treating them as separate entities.

It leads to unfortunate results if you declare (pseudocode)
Random player1dr = new Random( System.currentTimeInMilliseconds() );
Random player2dr = new Random( System.currentTimeInMilliseconds() );
...
int cdr1 = player1dr.nextInt(6) + 1;
int cdr2 = player2dr.nextInt(6) + 1;

a better way is to declare only one Random and apply sequential
results for each player
Random dr = new Random( System.currentTimeInMilliseconds() );
...

int p1result = dr.nextInt(6) + 1;
int p2result = dr.nextInt(6) + 1;

since currentTimeInMilliseconds will most likely be the same for both
in the inital example.

Without a sufficent sample size say 1X10^6 results noting which player
gets what, an empirical analysis of the raw function won't help to
settle the math, I contend.

For a true evaluation you've got to set confidence intervals for
trends and identify a trend for example
roll N > 10 followed by roll N+1 < 4

if the count of such events is outside the confidence interval then
boom you can make a case for a problem.

the observed complaint is say 12 followed by 2. the probabality of
this event is 1/1296 so in a million runs of DR pairs there should
be about 772 (FRU) such results. The variance from this should be what?

So we need a statistic based on the Event 12 followed by 2 in a sample
of a million DR pairs generated from the bot. Then count the number of
Events, determine a confidence interval voila.

Clear as mud

 

[zgrose]

I'm not sure I'm following your point, UXB. But the likelihood of you and I starting VASSAL at the exact same millisecond seem fairly unlikely.

For the record, here the functional bit of the dice bot class

[code:1:4b6d2c3267]

public class DiceButton extends AbstractConfigurable {
protected java.util.Random ran;

...snip...

/**
* Forwards the result of the roll to the {@link Chatter#send}
* method of the {@link Chatter} of the {@link GameModule}. Format is
* prefix+[comma-separated roll list]+suffix */
protected void DR() {
String val = getReportPrefix();
int total = 0;
for (int i = 0; i < nDice; ++i) {
int roll = (int) (ran.nextFloat() * nSides + 1) + plus;
if (reportTotal) {
total += roll;
}
else {
val += roll;
if (i < nDice - 1)
val += ",";
}
}

if (reportTotal)
val += total;

val += getReportSuffix();
GameModule.getGameModule().getChatter().send(val);
}

...snip...

}
[/code:1:4b6d2c3267]

 

[UXB]

Thanks for the clarification

Thanks for the clarification on the currentTime issue, and for the code
fragment.

There is an interesting analysys of a similar technique to

int roll = (int) (ran.nextFloat() * nSides + 1) + plus;

at
http://java.sun.com/docs/books/effective/excursion-random.html

which uses a modulus rather than a scaling to achieve the
interval.

But the artcle suggests to me that a the cast above is discarding low order
bits which may lead to a result which is not uniformly distributed.

So maybe there is a case to be made for a biased result. But without
a statistic, there's not a good way to disprove the assertion.

maybe a side by side analysis of the

int roll = (int) (ran.nextFloat() * nSides + 1) + plus;

and the

int roll = ran.nextInt(6) + 1;

techniques is in order.

I may be misapplying the cited article, but if I understand correctly the
Dice Roller code snipped seems to have the same issues cited.

Thanks for the interesting discussion.

 

[Victor]

I love this link!! For the dicebot doubters donate your system to some live dice cam time 24/7. Be sure that the dice roller is a hottie please :shock:

hehe
Victor

 

[zgrose]

Re: Thanks for the clarification

But the artcle suggests to me that a the cast above is discarding low order
bits which may lead to a result which is not uniformly distributed.

This may have been dealt with in later versions of Java. See this note in nextFloat().

In early versions of Java, the result was incorrectly calculated as:
return next(30) / ((float)(1 << 30));
This might seem to be equivalent, if not better, but in fact it introduced a slight nonuniformity because of the bias in the rounding of floating-point numbers: it was slightly more likely that the low-order bit of the significand would be 0 than that it would be 1.

maybe a side by side analysis of the

int roll = (int) (ran.nextFloat() * nSides + 1) + plus;

and the

int roll = ran.nextInt(6) + 1;

techniques is in order.

that would be int roll = ran.nextInt(nSides) + 1 + plus of course.

 

[UXB]

only if plus is modified

The variable plus is initially set to 0. I suspect this is a cast artifact.
If the plus is modified elsewhere in the code then that skews the
result so you don't get a uniform distribution, but one weighted
by the value of the plus variable.

I suspect the statistics are
Chi squared
a run count over several expected values of runs.

The Chi squared is set up
with one degree of freedom one event is 12 followed by <4 and the other
is anything else.

the run counts should be probablility of 2, 3, 4 and 5 runs of DR == n

Initial results of 100 runs of one million pairs of Dice Rolls seem to
fit into the 99% confidence interval I need to do some more checking.
In fact some results showed that the nextFloat cast method deviated less
from the expected value than the nextInt method. I need a better
Chi squared table.

 

[UXB]

However note that ASL is not a zero sum game

Even with an analysis of the DR method, ASL is not a zero sum game.

Some event are much more important than others. Rolling a 12 on a
24 FP down 2 shot is much more harmful then rolling a 12 on a 8 up 1.

People tend to remember the "unusual" events, say 3 snakes in a row,
than a less "unusual event" say of 64 rolls with no 7s appearing.
(3 snakes 2.14x10^-5, 64 no sevens 8.56x10^-8)

Anecdotal evidence may seem compelling evidence of a flaw but the statistics may say it's not flawed.

 

[Andreas Ludwig]

"Unusual" results regarding DR is certainly dependent on personal definition I'd say. In my last FTF game I had 16 Snakes, not in a row of course, but 16 is still "unusual" in a game. But it happens, even with real dice...

Andreas

 

[zgrose]

Re: only if plus is modified

The variable plus is initially set to 0. I suspect this is a cast artifact.
If the plus is modified elsewhere in the code then that skews the
result so you don't get a uniform distribution, but one weighted
by the value of the plus variable.

Not an artifact. VASSAL dice buttons allow one to roll X N sided dice with constant C added to the each die.

 

[Baktru]

I think REAL dice are flawed as well

In one of the cardboard games I actually played, which are few, I had two StuG IIIGs and two AT Guns facing a multitude of British tanks, including two of those tiny hard to hit carriers...

My AT shots hardly ever missed, up to a point where we started to predict dice rolls based on what SuperStuG needed to roll to score a hit...

Basically, it was a carnage with the StuGs taking out Churchill after Churchill, hardly getting hit themselves and if they did get hit, the TK always failed.

I admit, I was playing well that game, but the dice gods definitely favoured me as well. Heck hitting a moving carrier in Smoke with a PF from one hex range, firing from a building... That's low odds and even that hit on the first attempt...

My most slanted game EVER was with real dice. And I never saw Dice Bot grant me such a good streak of rolls as the real dice there...

Real dice are flawed

B.

 

[PT109]

Dice Bot

Try pressing the dicebot key 10 times before you begin an important dice roll... Call those rolls just "Non Random Event Multipliers" Let your opponent do the same....then just make a note on the log file. :twisted:

I know, silly responce but I couldn't help it!

PT109

 

[zgrose]

Re: Dice Bot

Try pressing the dicebot key 10 times before you begin an important dice roll... Call those rolls just "Non Random Event Multipliers" Let your opponent do the same....then just make a note on the log file. :twisted:

I know, silly responce but I couldn't help it!

PT109

be careful though, you may burn out all your 1s. :shock:

 

[Hubbs5]

I am getting ready to play a VASL game and my opponent suggested that in order to circumvent the dicebot inconsistencies that we should make double rolls for everything and ignore the first roll. That works for me if it makes him happy.

I personally am not concerned about the dicebot, I have had both good and bad luck with it and I can't see any difference between it and regular dice. I really don't care if you roll the dice standing on your head just make sure you clarify things beforehand so I know what to expect. ASL is a game where luck is factored in to represent fate, you got to learn to live with both the good and the bad.

 

[J P]

I recently kept track of every DR in a game of PB and, quite honestly the dice bot prescribed the bellcurve that it should have. We were "burning off" 10 DR's before each fire/rally phase so i had quite a large sample of DR's (over 700) and, in fact, the average Dr for myself, my opponent, and the burn off DR's were all around the "7" mark (give or take .5 ) so, as much as i still want to blame the dice-bot, i cant!!!

(the results are in an article at the "warfare HQ" asl site.)

 

[Centurion]

Law of Small Numbers

Discussion of the randomness of the VASL dicebot reminds me of the so-called "Law of Small Numbers". This "Law" was first discussed by A. Tversky and Nobel Prize winner D. Kahneman in an article published in the Psychological Bulletin, 1971, Vol. 76, No. 2. 105-110. Here is a quote from the article:

"We submit that people view a sample randomly drawn from a population as highly representative, that is, similar to the population in all essential characteristics. Consequently, they expect any two samples drawn from a particular population to be more similar to one another and to the population than sampling theory predicts, at least for small samples."

In the context of this discussion, the mistake is to expect small samples of dice throws to reflect the underlying statistical properties of the population distribution. Unfortunately, presenting small samples of "funny looking" results proves nothing. The distribution of outcomes in a small sample commonly deviates from the underlying distribution of outcomes in the population. In addition, individuals commonly infer the presence of non-random sequences or "runs" in what is actually entirely random data. This is termed the "Hot Hand Fallacy."

Here is a link to the original work:
http://law-of-small-numbers.behaviouralfinance.net/TvKa.html

For a disuccsion of the "Hot Hand" see
http://skepdic.com/clustering.html