We gave him a test file pulled from the same data source (random.org), made in the same way, and of the same size (500,000 rolls) as our dice file. This means gave him a statistically significant number of rolls, without repetition or aberration common in user-submitted tests.

600MB of data, perhaps a hundred spreadsheets and 9 pretty graphs later; looking at distribution, attack/loss percentages and streakiness, he has come up with the following analysis:

I've completed my analysis of the dice. No problems have been found.

The 'Dice Sucks' guy wrote:LIES! LIES, DAMN LIES!

That's right "Dice Sucks" guy - "no problems have been found".

The 'Dice Sucks' guy wrote:Noooooooo! My Losses MUST be the fault of the dice!

Sure...but in reality, maybe not...Lets take a look at some fancy graph thingys that will explain everything....

First off, lets start with the most common complaint: Streaks

e_i_pi's analysis:

The following images have CC's actual as the lighter colour next to their expected result (i.e. what perfectly distributed, non-random, dice statistically SHOULD be) as the darker colour and are sorted as Win/Draw/Loss or Win/Loss streaks. They are then sorted by runs of 1 through 30 (so the tall columns are runs of 1 while the small columns are runs of 30)

Statistically perfect columns should match up evenly next to eachother.

3v2:

Yes, those little tiny columns at the lower end actually mean CC's dice are less streaky than statistically perfect dice

3v1

2v2

2v1

1v2

1v1

So, while there are minute differences, they are well within the range of statistical error caused by actually random dice. If the dice were abnormally sticky or streaky, you'd see large differences between the Actual and Expected columns.

The 'Dice Sucks' guy wrote:Damn! We can't blame our losses on streaks any more!

But maybe we can blame it on the distribution of dice! Surely the defense has only double 6's!!!

Surely you can:

Woops, maybe not...no major abnormalities there, all within less than 0.08%. That's right, less than 1 tenth of 1 percent. That means the dice are random, but not too random to be anomalous.

The 'Dice Sucks' guy wrote:But haha! I see those bumps on the 6 in there! BROKEN!!!! BROOOOOOKEEEEEEEN!!!!

Lets take a look at what those bumps do to the win/loss stats then, shall we?

Looks pretty evenly spread to me....again, most combinations fall within less than 0.04% difference from the expected.

The 'Dice Sucks' guy wrote:

In total, we average 0.026% difference from what we would expect if we had hand picked the dice to be perfectly distributed. 0.026% means that you will see a non-perfectly distributed (i.e. random) roll twice in every ten thousand rolls.

The 'Dice Sucks' guy wrote:So, your dice are screwing me over every ten thousand rolls then!

Not quite. Our dice are just random. Random means that you're going to see odd rolls - In any random set of throws you're going to see anomolies from a perfect case scenario. Go and throw a die 6 times, I bet you that you wont get each number only once. This is what's happening here and is whats "screwing you over".

If CC's dice were 0.00% different, then it would mean they were "fixed" and not random. If CC's dice were 2% different, then it means there is a serious problem.

Right now, CC's dice are "not to hot, not too cold, but juuuuuuuust right"

Or, as e_i_pi says:

I've completed my analysis of the dice. No problems have been found.

So, now, not only does the CC dice data pass the following tests:

* Frequency Test: Monobit

* Frequency Test: Block

* Runs Test

* Test for the Longest Runs of Ones in a Block

* Binary Matrix Rank Test

* Discrete Fourier Transform (Spectral Test)

* Non-Overlapping Template Matching Test

* Overlapping Template Matching Test

* Maurer's Universal Statistical Test

* Linear Complexity Test

* Serial Test

* Approximate Entropy Test

* Cumulative Sums Test

* Random Excursions Test

* Random Excursions Variant Test

* A chi-square test

* A test of runs above and below the median

* A reverse arrangements test

* An overlapping sums test

* A binary rank test for 32×32 matrices

They also pass the ever more important Yeti_c, DIM, and e_i_pi's approval tests.

Thanks very much to e_i_pi for putting in the hours to do this, great work!

Please use e_i_pi's other thread for discussion of these results or the venting (but not flaming) thread if you want to continue to cry foul.

If you can find real, legitimate and systematic errors in this data, please PM me and we will actually fix them. Right now, we can't find anything to "fix".

Twill

p.s. for the record, e_i_pi was trained as a data miner, so he knows what he's doing