VASL Dicebot silliness

[syfaulk]

I know, I know, not a full AAR, but it is something that happened while playing ASL, and this is the place to share it...

Playing Jim "Gunny" Thompson is ASL69 "Today We Attack". Japanese knee mortar spots a stack of Chinese lurking in the jungle a few hexes away. First shot misses, but rate keeps the 9-1, 2x447, 2xMMG stack in danger. Shell loaded, ring pulled and.....

Omigosh..... :shock:

Later,
Scott

 

[Toedwy]

Your first instance of 3, 3s in a row were 1:216 chance.. probable.


Your second instance of 4 , 2s in a row were 1:1296 chance... probable.


But, I would classify this as skeptical. I personally cannot count the times I have had similar instances as this. But, hey.. there must be NOTHING wrong with the non-seeded rnd() java function that VASL uses...

Naaaaaaaaa.


Here is the Java Junk below that VASL3 Scenario.jad uses.. Ok, we are going to use this same bit of code to then test the results.

if("DR".equals(s))
{
int i = (int)(ran.nextFloat() * 6F + 1.0F);
int j = (int)(ran.nextFloat() * 6F + 1.0F);
String s1 = "";
if(map != null ? map.isShowing() : false)
if(i + j == info.axisSAN)
s1 = info.axisSAN != info.alliedSAN ? " Axis SAN " : " Axis/Allied SAN";
else
if(i + j == info.alliedSAN)
s1 = " Allied SAN";
sendMessage("CHAT *** DR = " + i + "," + j + " *** <" + Pref.getPrefs().me + ">" + s1);
return;
}
if("dr".equals(s))
{
sendMessage("CHAT *** dr = " + (int)(ran.nextFloat() * 6F + 1.0F) + " *** <" + Pref.getPrefs().me + ">");
return;
}




Stand by for geekum.

 

[Toedwy]

After further research......


I then decompiled VASL4 and found within the DiceButton.class the following code snip....



protected void DR()
{
String s = getReportPrefix();
int i = 0;
for(int j = 0; j < nDice; j++)
{
int k = (int)(ran.nextFloat() * (float)nSides + 1.0F) + plus;
if(reportTotal)
{
i += k;
} else
{
s = s + k;
if(j < nDice - 1)
s = s + ",";
}
}

if(reportTotal)
s = s + i;
s = s + getReportSuffix();
GameModule.getGameModule().getChatter().send(s);



it looks amazingly similar. So VASL3 and VASL4 uses the same java rand import, same call, same math.

So it comes down to how well the random function within java really creates randoms.

Next step. going to use the same java code to create an output file for results for futher analysis.

 

[FuraxVZ]

I've been bitching about this in the General forum, but nobody believes me.

You're right; the problem is with the java.util.Random.

For those of us without degrees in math, here's a picture:
http://alife.co.uk/nonrandom/

See the pattern?

 

[apbills]

I don't know of anyone who plays VASL that doesn't believe you.

Now that you have shown you have skills and you have an interest in this problem, PLEASE write a real random number generator for inclusion in the VASL program. Just submit the thing to Rodney and let him plug it in.

The ASL world will rejoice!

 

[Anonymous]

Well, the work-around seems pretty simple.
That very cool website that shows the problem graphically stated that Integer randomness is only half as seriously inflicted, so just get VASL to use integers instead of floats for the die-rolls. I program games in Java as well and I always do it with ints.

p.

 

[Nat Mallet]

I apologize for not catching this thread earlier, but this really isn't an AAR.


Nat

 

[spb]

Silliness is right.

The graphical widget referenced earlier is compelling. It is also irrelevent. I don't believe
anyone has argued that the output of java's native PRNG is truly random---what
we're interested in is if the dicebot is `fair'. These are two different propositions.
Would I rely on the PRNG implementation in question as a source of cryptographic
randomness? No. But it isn't clear that it is inadequate for what it does---i.e.,
simulate die rolls in a game between honest players.

The author of the web page in question is quite correct in pointing out problems in
the distribution of the low-order bits in Sun's java PRNG. I have no arguments with
his position, and in fact whole-heartedly concur with it. And, all else being equal,
I'd suggest that the dicebot -should- use a better PRNG (and, for that matter,
a better seeding technique).

That being said, what we're really interested in here is whether or not the problems
in the underlying PRNG have any statistically significant effect on the `fairness' of the
dicebot. As I have (repeatedly) pointed out, the data do not suggest any such effect.

If you want to look at numbers, I'll again refer any and all to my analysis on the ASLML,
two salient examples of which can be found at:

http://www.meshuggeneh.net/dicebot.txt
http://www.meshuggeneh.net/dicebot2.txt

But if you find dancing dots more beguiling than numbers, I can give you dancing
dots. I grabbed a copy of the .java file from the web page referenced earlier in this
thread. I added a line that re-seeds the PRNG every `generation' (refresh of the
grid), which is what VASL does (it re-seeds every game turn, I believe...which will
actually almost certainly re-seed the PRNG more frequently than we're re-seeding
here). Also, I copied the dr code from the dicebot into the widget. The difference
here is that instead of testing (int)rnd.nextLong() (which is what the java widget
did by default), it tests (int)(rnd.nextFloat()*(float)6 + 1.0F) (which is what the
dicebot does).

You can take a gander at the result at:

http://www.meshuggeneh.net/rnd/rand.html

and you can grab the source .java file at

http://www.meshuggeneh.net/rnd/nonrandom.java

Again...I'd be more than receptive to data which actually supports the contention
that the dicebot is unfair. But so far none has been offered, and indeed all the data
which actually have been collected and analysed would lead us to reject the hypothesis
that the dicebot behaves `unfairly' in any statistically significant way.

 

[GazMarsh]

For notes on the Java RNG have a look at:

http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html

Also bear in mind that for some linear congruential generators, certain seeds can generate some really crappy sequences...

 

[spb]

For notes on the Java RNG have a look at:
http://java.sun.com/j2se/1.3/docs/api/java/util/Random.html
Also bear in mind that for some linear congruential generators, certain seeds can generate some really crappy sequences...

For more notes, check the source code. You'll discover that they're using the standard,
vanilla Lehmer LCG with the Lewis, Goodman and Miller constants. The LCG itself
dates back to 1948 (when Lehmer first described it), and this version of it was
suggested by Lewis, Goodman and Miller in 1969. It is, in fact, one of the most
well-explored PRNGs in current use. The algorithm is sometimes referred to as
MINSTD, or the `minimum standard' for PRNGs.

It is the case that there are a number of known problems in the output of this PRNG.
These problems are of great concern if you are using it as a source of numbers (or bits)
for use in conjunction with cryptography. This is because your threat model includes
evildoers analysing the raw output of the PRNG (or being able to recover it from
observation), and use information gained from analysing portions of the PRNG
output to predict future output bits/numbers, to recover seed values, and so on.

None of this has any immediate bearing on the suitability of the LCG in question for
the task at hand...namely simulating die rolls in a game between honest players. In
other words, the problems that have been described in the java Random class
are not sufficient to describe the problems people are attributing to it.

If you are miffed because you rolled three 12s in a row or your opponent got four 2s
in a row, this just plain cannot be described in terms of the (very, very well explored)
behaviour of the LCG. Further, if strings of 12s or 2s happened a disproportionate
number of times, then this is something that would show up extremely clearly in
the sorts of testing that I've done on the dicebot (and have referenced earlier in
this thread). No such occurances appear.

If you really think that the dicebot is biased in such a way that it is just -obvious- to
you that it's broken---which seems to be a popular belief---then there must be SOME
way of testing for it, right? Well...I'd love to hear about it. Gimme a reproducable
test that demonstrates this unfairness. I mean, if it's so obvious that you can pick up
on it without even trying, then it must be easy to demonstrate the problem, right?

Or is this an obvious yet untestable hypothesis? If it is, then we need to move this
discussion into a thread about magic. If your computer is haunted by evil
spirits, I can't help ya.