06-30-2016, 06:05 PM
OK, so I've written a few things for analytic purposes, one of which is a random hand dealer. One of the analytic tools checks the hand shape...what are the suit lengths? So, 5-5-5-5, 6-5-5-4, etc. I then ran 2.5 million deals, or 10M total hands, and checked the hand shapes.
On the dealing methodology: I dealt the first hand as the first 20 cards, next hand was next 20, etc. If the dealing is truly random, then it doesn't matter if you do it like this, or 1, 4, or 5 cards per hand at a time. Note that this DOES matter when dealing by hand, because it's not completely random. The RNG is a fast Mersenne Twister implementation:
* <h3>MersenneTwister and MersenneTwisterFast</h3>
* <p><b>Version 13</b>, based on version MT199937(99/10/29)
* of the Mersenne Twister algorithm found at
* <a href="http://www.math.keio.ac.jp/matumoto/emt.html">
* The Mersenne Twister Home Page</a>, with the initialization
* improved using the new 2002/1/26 initialization algorithm
* By Sean Luke, October 2004.
* <h3>About the Mersenne Twister</h3>
* <p>This is a Java version of the C-program for MT19937: Integer version.
* The MT19937 algorithm was created by Makoto Matsumoto and Takuji Nishimura,
* who ask: "When you use this, send an email to: matumoto@math.keio.ac.jp
* with an appropriate reference to your work". Indicate that this
* is a translation of their algorithm into Java.
In the table below, the first column is the shape; the 4 numbers add up to 20. Those are *hexadecimal* numbers, so a=10, b=11, etc. The second column is the percentage that pattern is dealt. to 2 digits. I cut this report off at 0.1%; it *did* report a single 15 card suit, and one 11-9 hand (!).
6554 15.33
7643 11.28
7544 9.57
6653 9.01
8543 7.32
7553 7.20
7652 6.01
6644 5.98
8642 3.06
8633 2.15
8552 1.94
7742 1.87
5555 1.65
9542 1.63
8444 1.62
9443 1.52
8732 1.43
7733 1.33
6662 1.25
9533 1.15
8651 1.02
9632 0.96
7661 0.79
8741 0.64
7751 0.64
9641 0.43
a532 0.42
a433 0.40
a442 0.28
9551 0.27
9731 0.20
a541 0.19
9722 0.16
8831 0.12
b432 0.12
a631 0.11
8750 0.10
8822 0.10
These look correct. 5-5-5-5 is actually unlikely because there's only 1 way it can happen; 6-5-5-4 is much more likely because there are 12 separate ways to deal 6-5-5-4 (6S 4H, 6S 4D, 6S 4C, 6H 4S, 6H 4D, etc.), and each specific 6-5-5-4 is only a little less likely than 5-5-5-5. And the numbers bear that out.
So I think these numbers are good...at least within statistical error, and with the sample size, that should be minimal. (Plus I'm not reporting down to the very low-frequency cases like that 11-9.) And on one very *simple* case, the 5-5-5-5 case, it is correct. The test run generated 1.645%; the theoretical is 1.634%. The difference is sampling error, and that's a perfectly acceptable sample error. (5-5-5-5 is 20c5 ^4 / 80c20. This one's easy.
)
But if anyone sees a possible error, let me know. I'm gonna go through a couple more combinatorial checks with some of these shapes, to check the predicted versus the sampled, and therefore, the randomness of the dealing. (That's ONE check, not the last one.)
On the dealing methodology: I dealt the first hand as the first 20 cards, next hand was next 20, etc. If the dealing is truly random, then it doesn't matter if you do it like this, or 1, 4, or 5 cards per hand at a time. Note that this DOES matter when dealing by hand, because it's not completely random. The RNG is a fast Mersenne Twister implementation:
* <h3>MersenneTwister and MersenneTwisterFast</h3>
* <p><b>Version 13</b>, based on version MT199937(99/10/29)
* of the Mersenne Twister algorithm found at
* <a href="http://www.math.keio.ac.jp/matumoto/emt.html">
* The Mersenne Twister Home Page</a>, with the initialization
* improved using the new 2002/1/26 initialization algorithm
* By Sean Luke, October 2004.
* <h3>About the Mersenne Twister</h3>
* <p>This is a Java version of the C-program for MT19937: Integer version.
* The MT19937 algorithm was created by Makoto Matsumoto and Takuji Nishimura,
* who ask: "When you use this, send an email to: matumoto@math.keio.ac.jp
* with an appropriate reference to your work". Indicate that this
* is a translation of their algorithm into Java.
In the table below, the first column is the shape; the 4 numbers add up to 20. Those are *hexadecimal* numbers, so a=10, b=11, etc. The second column is the percentage that pattern is dealt. to 2 digits. I cut this report off at 0.1%; it *did* report a single 15 card suit, and one 11-9 hand (!).
6554 15.33
7643 11.28
7544 9.57
6653 9.01
8543 7.32
7553 7.20
7652 6.01
6644 5.98
8642 3.06
8633 2.15
8552 1.94
7742 1.87
5555 1.65
9542 1.63
8444 1.62
9443 1.52
8732 1.43
7733 1.33
6662 1.25
9533 1.15
8651 1.02
9632 0.96
7661 0.79
8741 0.64
7751 0.64
9641 0.43
a532 0.42
a433 0.40
a442 0.28
9551 0.27
9731 0.20
a541 0.19
9722 0.16
8831 0.12
b432 0.12
a631 0.11
8750 0.10
8822 0.10
These look correct. 5-5-5-5 is actually unlikely because there's only 1 way it can happen; 6-5-5-4 is much more likely because there are 12 separate ways to deal 6-5-5-4 (6S 4H, 6S 4D, 6S 4C, 6H 4S, 6H 4D, etc.), and each specific 6-5-5-4 is only a little less likely than 5-5-5-5. And the numbers bear that out.
So I think these numbers are good...at least within statistical error, and with the sample size, that should be minimal. (Plus I'm not reporting down to the very low-frequency cases like that 11-9.) And on one very *simple* case, the 5-5-5-5 case, it is correct. The test run generated 1.645%; the theoretical is 1.634%. The difference is sampling error, and that's a perfectly acceptable sample error. (5-5-5-5 is 20c5 ^4 / 80c20. This one's easy.

But if anyone sees a possible error, let me know. I'm gonna go through a couple more combinatorial checks with some of these shapes, to check the predicted versus the sampled, and therefore, the randomness of the dealing. (That's ONE check, not the last one.)