Some Meld Statistics

[mickmackusa]

I am still thinking about My Theoretical Bidding System.
I wanted to look into what bids realistically occur and which ones I don't need to worry about.

Check this out:

After 100000 Hands with no trump selected @ Yahoo.com:
Less Than 15 Meld Hand occurred 64547 times or 64.547% of the time
16 to 24 Meld Hand occurred 24708 times or 24.708% of the time
26 to 34 Meld Hand occurred 5652 times or 5.652% of the time
36 to 44 Meld Hand occurred 3342 times or 3.342% of the time
46 to 54 Meld Hand occurred 958 times or 0.958% of the time
56 to 64 Meld Hand occurred 162 times or 0.162% of the time
66 to 74 Meld Hand occurred 175 times or 0.175% of the time
76 to 84 Meld Hand occurred 93 times or 0.093% of the time
86 to 94 Meld Hand occurred 125 times or 0.125% of the time
96 to 104 Meld Hand occurred 153 times or 0.153% of the time
More Than 105 Meld Hand occurred 85 times or 0.085% of the time

I'm not sure how I am going to incorporate these figures into my thinking, but I'll be honest the results did surprise me.

Things that make you go hmmm.

[ToreadorElder]

Without knowing how you built the hands, I can't say whether you've got some kind of systemic bias such that double X's around might be more likely than it should, but the high-meld results are at least fairly internally consistent. The root for anything over 40 is double X's or triple pinochle, whereas 40 includes just the double pinochle with some extras.

But this largely correlates with my experience: 40 meld is uncommon, and anything more is getting fairly rare. Thus, it's not all that necessary to worry about bids that show more than 40, *if doing so would be a problem*. The exception is double aces...admittedly rare, but being able to bid them lets you show massive meld AND massive tricks. Figure that this is why, when the auction is no higher than, say, 54 or 55, that 58 becomes unlimited meld, and 59 shows double aces, in CABS. Say the auction's gone 52-55 to you. Say you have:

--30 meld: 58 is spot-on.
--40 meld: 58 gets most of it across
--50 meld: 58 first. MOST of the time, you should have room to make a 2-step bid to show this. For example:

North 52
East 55
South 58
West 70
North 75
East pass
South 85

If North can bid 75 on South's presumed 30, South knows that 90 is OK. South has an extra 20, but he's only pushing the bidding up 15.

The advantage is, on South's first turn, his bids of 60 *or higher* become control bids/semi-shutout bids...don't let West give meld, don't let East compete easily. The key here is that North offered captaincy by giving meld. If South can take it, then North-South have the information advantages.

[mickmackusa]

(09-11-2013, 01:00 PM)ToreadorElder Wrote:  Without knowing how you built the hands, I can't say whether you've got some kind of systemic bias such that double X's around might be more likely than it should, but the high-meld results are at least fairly internally consistent.

How I produced the data:
I create an 80-card array.
The order of the cards is randomized using PHP's shuffle() function.
Then cards 1-20 are sent through the meldcalculating program.
Then cards 21-40 are sent through the meldcalculating program.
Then cards 41-60 are sent through the meldcalculating program.
Then cards 61-80 are sent through the meldcalculating program.
Then the shuffled 80-card array is reshuffled and the four new hands are looped through the meldcalculating program.
This entire process repeats until the number of hands is reached.

[ToreadorElder]

PHP's shuffle() uses its rand(), from what I can see...and it's a POS linear congruential. Among other things, it repeats itself rather quickly. And it has certain bad behaviors. I'd take the probabilities with a grain of salt, but I wouldn't expect your numbers to be *really* off.

[mickmackusa]

(09-12-2013, 06:12 PM)ToreadorElder Wrote:  PHP's shuffle() uses its rand(), from what I can see...and it's a POS linear congruential. Among other things, it repeats itself rather quickly. And it has certain bad behaviors. I'd take the probabilities with a grain of salt, but I wouldn't expect your numbers to be *really* off.

I expected this response as I've seen it several times before.

If something is useful enough, I can tolerate "certain bad behaviors."

[FLACKprb]

Mickmackusa's PHP implementation is adequate as I obtained results that are close to his as shown in Figure 1.

   

Figure 1 Binned Meld Probabilities

The significant NPA differences are due to their giving a single Pinochle 15 points vice 4 points as in the other organizations.

Data was collected via a Matlab Monte Carlo Simulation from 1 Million samples (4 hands dealt then each evaluated from 250,000 deals). Matlab's random number generator uses the Mersenne Twister algorithm developed by M. Matsumoto and T. Nishimura which has a (2^19937)-1 run length.

Details on the Mersenne Twister algorithm may be found at:

Link to --> Mersenne Twister Home Page

If the link above doesn't work try pasting the following into your browser:
http://www.math.sci.hiroshima-u.ac.jp/~m...T/emt.html

Details on Matlab may be found at:

Link to --> MathWorks Website

If the link above doesn't work go to MathWorks.com.

(09-12-2013, 06:12 PM)ToreadorElder Wrote:  PHP's shuffle() uses its rand(), from what I can see...and it's a POS linear congruential. Among other things, it repeats itself rather quickly. And it has certain bad behaviors. I'd take the probabilities with a grain of salt, but I wouldn't expect your numbers to be *really* off.

I did an internet search looking for "POS Linear Congruential". I found many references to "Linear Congruential" in reputable academic sources. I did not find any reference to a "POS Linear Congruential". Constructive criticism based on logical arguments backed by facts advance the discussion. Negative opinions without supporting data raises the noise level thereby decreasing the signal-to-noise ratio making it harder to recover the information content from the signal being sent.

Rock on Mick, I'm very interested to see where your path leads!

[ToreadorElder]

http://www.mathcom.com/corpdir/techinfo....tml#q210.1

Quote:Linear Congruential Generators (LCG)

Linear congruential generators are of the form
x(n) = a * x(n-1) + b mod M

A good discussion of this type is in the text by Press et al. These are by far the most common form in use, and have periods in the range 10^6 to 10^9 when using 32 bit words. Unfortunately, they have some unpleasant properties. When taken in pairs, triplets, or n-tuples, the random values often fall on only a few planes in n-space. Using a shuffle box can break up this uniformity. For more information on the problems associated with linear congruential generators, see Marsaglia 1968, Marsaglia 1993 and Sullivan 1993. See also Marsaglia's web site, described under Tests for Randomness .

Also look here:
http://www.ics.uci.edu/~smyth/courses/ic...rticle.pdf

The generator being discussed (clarified in sections 4 and 5) is an LCG.

Another issue with the PHP algorithm:

http://php.net/manual/en/function.rand.php

Quote:Note: On some platforms (such as Windows), getrandmax() is only 32767. If you require a range larger than 32767, specifying min and max will allow you to create a range larger than this, or consider using mt_rand() instead.

PHP's shuffle() uses rand(). If getrandmax() is 32767, the period of the RNG is no more than 32767. That means mick's repeating his random draws every 410 or so hands he deals.

LCGs simply are not very good. They're simple, and they're fast, but they're not statistically reliable. They fail most simple statistical tests. LCGs are almost never mentioned in serious discussions about RNGs because their bad behaviors are well known in the numerical computation community.

[mickmackusa]

(09-17-2013, 12:52 PM)ToreadorElder Wrote:  Another issue with the PHP algorithm:

http://php.net/manual/en/function.rand.php

Quote:Note: On some platforms (such as Windows), getrandmax() is only 32767. If you require a range larger than 32767, specifying min and max will allow you to create a range larger than this, or consider using mt_rand() instead.

PHP's shuffle() uses rand(). If getrandmax() is 32767, the period of the RNG is no more than 32767. That means mick's repeating his random draws every 410 or so hands he deals.

I was curious to see just how much duplication there was, so I ran a few tests on the array of hands.

Hands Original Count = 100000
Hands Unique Counts = as low as 99988, as high as 99998.
This shows that the hands are not simply repeated every 410 or 1640 hands; rather all hands are unique with the exception of 2 to 12 in 100,000.
I don't know if this is because I am shuffling the already shuffled deck, but the hands seem to be more random than you are suggesting.

In reality, if I played 100,000 games, isn't it possible that I would be dealt some hands that I had already had?

If they all need to be different, I could pre-filter the hands to be unique before counting the meld, but wouldn't that interfere with what could possibly occur in a natural setting?

Finally, 2 to 12 hands in 100,000 are not going to disrupt the figures that much.

That said, when providing statistical data on the WWW, it is paramount that the facts be scrutinized and verified for absolute correctness. I will never again provide statistical data using my php functions. Instead, I will defer to the membership to derive the correct data, as they have both better knowledge and better means.

Thanks to TE for explaining why and where the inaccuracies are in my data.

I should also reveal that:
1. My data was collected without any nomination of trump.
2. My meld calculating program includes "assumed" meld:

like a bonus 2 points for an assumed royal marriage when using a scorechart that doesn't recognize the Roundhouse:

http://www.powerpinochle.com/forum/meld....p=&chart=0

or an assumed run (this is the only case where the meld can be an odd number):

http://www.powerpinochle.com/forum/meld....p=&chart=0

Thanks to FLACK for taking the ball and running with it.
His representation not only uses better technology to create the data, but is also more comprehensive in displaying data across multiple scorecharts.
(and the graph is visually appealing) *p.s. a couple of the red Yahoo bars seem to be a pixel higher than its competitors even when the %'s are the same (<15 & 26..35). Are my eyes deceiving?

***
I'll end this post with some new questions.
If necessary, please respond via a new thread with an appropriate title for search-ability.
How many different variations of cards are there for a 20-card double-deck pinochle hand?
My data arbitrarily used 100,000 hands, but how many should be used?
Seems to me, that this magic number should be the backbone of all future computations.
I am not suggesting that all future computations iterate through every possible hand, because that doesn't seem realistic/natural.
I just want to identify the absolute best, most accurate procedure to garner statistical data.
Please speak amongst yourselves.

[ToreadorElder]

I'd tend to doubt you'd see the exact same hand. VERY similar, yes...but not card-for-card the same. If you started from the same 'clean' deck (with all the cards in whatever order)...you'd see them when the cycle length and the number of cycles played out together. But when you're retaining the prior order each time, it'll be hard to see that the random number cycle is repeating.

The problem of the pairwise (and especially triplet) associations is still there, tho, no matter what. The solution's fairly straightforward...don't use the default RNG. shuffle() does, but all that means is you write your own version that uses MT. MT's built into PHP. Poking around the shuffle() documentation on the PHP site, I found this function:

<?php
function seoShuffle(&$items,$string) {
mt_srand(strlen($string));
for ($i = count($items) - 1; $i > 0; $i--){
$j = @mt_rand(0, $i);
$tmp = $items[$i];
$items[$i] = $items[$j];
$items[$j] = $tmp;
}
}

This should work, but feels perhaps off, with a pinochle deck. Maybe not. Another option is to simply deal the cards as you go:

// draw a hand of 20 from a deck
hands = array of 4(array of 20 cards)

for count = 1 to 3
for i = 1 to 20
j = mt_rand(0, sizeof(deck)
hands(count).add(deck.get(j))
nextdeck.add(deck.get(j))
deck.remove(j)
next i

hands(4).add all cards in deck
nextdeck.add all cards in deck
deck = nextdeck

Either way, doing your own shuffling lets you use any RNG you can find, or code up (altho I don't know how many you could find for PHP, but MT is widely considered Good Enough for serious simulation work), with just drop-in replacement. The rest of your code wouldn't have to be touched.

As far as the number of hands needed...it depends on what you're trying to do, and how much you want to chase down the slim chances. There's a certain amount of trial and error. I'll start with some reasonable, probably small number like 1000, just to test the code. Once I think it's right, I'd probably jump to 100,000, for execution time checking, and this is enough to (hopefully) let me figure how many I really need.

The answer, tho, depends on the questions. Here, we're asking: how do we design a system for showing meld intelligently, based on the frequency of meld-range occurence? Well, how much meld CAN we show? Let's start with what has to be the simplest case: we're first to bid. What would an opening bid of 60 or 65 show? We need something for shutout bids, and these sure *sound* like shutout bids. By extension, then, opening 70 or 75 or even higher, should remain shutout bids. Therefore, the last possible bid to show meld here, has to be 59. I completely understand that double aces is rare, but it tells your partner SO much, that I need it in the system...at least here. (I sympathize, mick, with the ambiguities that arise about 59 bids, in other auctions.) So, now, the highest meld-showing bid I've got, is 58.

So now we go back to proposing a bidding system. The first cut...NOT the only one, but the first one...is the jump bids show meld == 10x the steps jumped. It's simple and it's natural; these are good things. That suggests, max meld we ever have to worry about, is 80; it's the most we can show with 1 bid (not counting double aces).

Another point: we can consider double aces as a special case. We will reserve bids to show double aces. I strongly suspect that most cases with >100 meld are based on double aces...double kings with a double pinochle, requires defining 12 of the 20 cards. That's got to be significantly less likely than double aces. The other case is a double run...and I for one am never showing meld. It's my hand!

(This poses a modeling question. When I have >100 meld, what's the frequency of NOT having double aces, or a double run?)

If that is correct, it also strongly argues for making sure we have special bids to show double aces...because it caps the meld we believe we'll ever need to show.

Have to get going...will try to finish this later today...

[ToreadorElder]

Starting up again...

A comment to make. This is something of an iterative process. We're building and testing hypotheses. We can start with a coarse case, then use the information gained to build up to a larger set of test cases.

So...our working hypothesis is, we will handle double aces separately, and we don't have to deal with a double run. More than 80 meld is only about 0.5% to start with, and if we handle the double aces and double runs, the leftover frequency is very, very small.

So...how many runs to make? From flack's test, we can pretty much say the lowest frequency we need to resolve, is about 0.1%, or 1 in 1000. The more runs you can make, assuming they're independent, the better, but having them show up 1000 times is going to be plenty. So I'd say, 1M total trials should be fine.

Note that this applies to THIS question. There's a couple other ones that would be interesting.

1. I said, in expectations, that if you haven't heard partner give meld, you can assume 15 total points from him between meld and play. How reasonable is this? To test this, we need to restrict the hands, and to count a bit differently.

a) Using adjusted meld, partner has no more than 19 (e.g. 16 meld and 3 aces). If you deal a hand with 20+ adjusted, skip it.
b) We need some way to identify 'total contribution.' Meld's obvious and we have that. How many tricks, and how many points from tricks? Count the number of aces (we have that from adjusted meld) then perhaps give 2 values...2 points per ace (conservative, and caters to the potential that not all aces will cash) and 2.5 points (more average...caters to the potential of tricks other than aces).
c) Reporting bands might be 0-6, 7-12, 13-18, and 19+.

2. We see from the results we have, that >50 meld is uncommon. That suggests we downplay them. THAT means we can consider different bidding. Again, we'll restrict ourselves to first seat; we'll worry if this approach doesn't work in other situations later.

pass: nothing to say
50: asking for meld, showing 35-7-6
51: shows aces AND <18 total meld*
52: shows 20
53: shows aces AND 19-28 meld*
54: shows 30
55: shows aces AND 29-38 meld*
56: shows 40
57: shows aces AND 39-48 meld*
58: shows 50+ (unlimited)
59: shows aces AND 49+ meld (unlimited)*

* -- meld adjustment here is different. Count the raw meld, then adjust by each ace beyond the aces around you're showing. So aces around and queens around, with no extra aces, is still 16 adjusted. Aces around and kings around with 1 extra ace is 19 adjusted.

This is such a huge departure from CABS that I feel justified in dropping 59 as double aces, and use 100 instead.

The even bids, 52, 54, 56, and 58 now DENY having aces around. This approach lets us get 2 pieces of key information across with 1 bid, within the key meld ranges that show up most of the time. The first cost is, we lose the ability to explicitly show 60 or more...but that's rather uncommon, and if we can show 50 meld, that's very likely to be enough for partner to outbid the opponents if he wishes to.

So...the question we ask is, is this worthwhile from a frequency standpoint?

a) The hand must have aces around OR 20+ adjusted meld (here, using the normal method of counting adjusted meld...meld plus number of aces.) If it doesn't, skip it.
b) We want to report how often each bid would occur, AND how often we'll have problems. So our categories are defined by the 9 bids we can make (51-59).

Note that we'll probably have to shuffle a lot more decks, if we want, let's say, 1,000,000 *qualifying* hands. A first mid-sized test might be to shuffle/deal 100,000 decks and see how many results we get.