Wrath of God. Twice.

[Tiburon Silverflame]

I really want to do a RNG test where I take about 10 million rolls from 1-100 and measure both the probability of each number showing up (it'll probably be close enough to 1%) and the probability of each number showing up based on what the previous number is. It's pretty trivial to code...if I knew how to easily.

As in, you know the algorithm, but don't know C? The algorithm is trivial...the simplest approach is just create a 2D array, and increment the [prev,current] bucket.

But that isn't necessarily the only flaw. There are other forms of cyclic behavior. A very brief look at the RNG gives me pause; the root RNG is a linear congruential, which is an awful basis, but there's manipulation going on that may improve it. How good is it? Not sure. It claims a basis in Berkeley's random.c...but as of when? The web shows the 1995 Berkeley code in /dev/random.c, and suffice it to say, it looks NOTHING like the code in z-rand.c. Personally, I'd rather see something with proven-good performance...a fast version of Mersenne Twister, which can readily be found as freeware, or some of the more recent members of the same family such as WELL:

http://www.iro.umontreal.ca/~panneton/WELLRNG.html

WELL's a tiny lil guy...

I've definitely noticed too many cases of cluster behavior for me to think there isn't some memory in the RNG.

[zaimoni]

Well, the fact the RNG state is saved allows studying the RNG distribution by savescumming.

A particularly easy case, is low-probability enchantments. Recall the basic approximation from the first two weeks of a 700-level real analysis course,

(1-1/n)^(n-1) < 1/e < (1-1/n)^n .

The convergence of the upper and lower bounds is fairly rapid.

In particular, e^(-3) is approximately 0.0498 so for an event with probability 1/n, a run of 3n failures should be pretty close to a 5% probability event. e^(-4) is approximately 0.0183, so a run of 4n failures should be pretty close to a 2% probability event.

Empirically (my own testing, V3.0.9), the critical value appears to be near n=27. Runs of 3n failures suddenly become far more common than 5% of the time then.

[Protocol: save-load so that all copies of the game start from the same internal time. For each instance k, walk k-1 steps before reading the enchant scroll. A 1/26 enchant doesn't have a naked-eye discernible difference from a 5% chance to fail all 78 times; a 1/27 enchant empirically fails all 81 times about 1 in 3.]

[Magnate]

Well, the fact the RNG state is saved allows studying the RNG distribution by savescumming.

A particularly easy case, is low-probability enchantments. Recall the basic approximation from the first two weeks of a 700-level real analysis course,

(1-1/n)^(n-1) < 1/e < (1-1/n)^n .

The convergence of the upper and lower bounds is fairly rapid.

In particular, e^(-3) is approximately 0.0498 so for an event with probability 1/n, a run of 3n failures should be pretty close to a 5% probability event. e^(-4) is approximately 0.0183, so a run of 4n failures should be pretty close to a 2% probability event.

Empirically (my own testing, V3.0.9), the critical value appears to be near n=27. Runs of 3n failures suddenly become far more common than 5% of the time then.

[Protocol: save-load so that all copies of the game start from the same internal time. For each instance k, walk k-1 steps before reading the enchant scroll. A 1/26 enchant doesn't have a naked-eye discernible difference from a 5% chance to fail all 78 times; a 1/27 enchant empirically fails all 81 times about 1 in 3.]

I'm impressed - that's a brilliant piece of analysis. Bagsy not be the one to tell Takkaria that we have this problem!

[zaimoni]

I'm impressed - that's a brilliant piece of analysis. Bagsy not be the one to tell Takkaria that we have this problem!

Well, I'm not sure that it's a "problem". (This particular deviation plays well with untrained intuition about probability.)

[Pete Mack]

@Zaimoni--
It plays well, so long as there aren't any 1/27 chances. (Rod activation comes to mind.)

[Tiburon Silverflame]

http://www.lavarnd.org/what/nist-test.html

This page suggests that the Linux/BSD generators are probably OK for our very relaxed purposes, *in their current versions.* z-rand.c doesn't provide a point of reference for the version used as its basis, beyond the general copyright date. And the one time I did manage to find the code for one of the current versions, it didn't look methodologically similar.

http://www.iro.umontreal.ca/~simardr/indexe.html

has links to a number of tests and generators, including C code.