Pinochle Probability (again)

Okay, so I was reviewing this thread from before: http://www.vbforums.com/showthread.p...light=pinochle and was trying to apply it to a new situation (and also the question asked there).

If I use Jemidiah's method in post 11, I'm not sure I'm getting the same numbers as he did.
I'm trying to figure out odds for Aces around and double Aces around.

I started with quadruple aces around (4,4) ^ 4 from each suit * (64,4) = 635376
Then I went to triple aces (4,3) ^ 4 * (68,8) - 4x Aces from above = 1,892,353,865,232
Then I went to double aces (4,2) ^ 4 * (72,12) - 3x Aces and 4x Aces from above = 19,908,924,100,186,400
Then I got single aces (4,1)^4 * (76,16) - 2x/3x/4x Aces from above = 2,752,579,046,460,370,000

With (80,20) hands = 3,535,316,142,212,180,000

With these numbers dividing the total number of hands by the Number of Aces around hands, I'm getting a result of 1 in 1.28 hands, and double aces as 1 in 177.57 hands.
I've calculated hands through Excel and Python programs that I've written, and python and perl programs that my sister has written and I'm getting numbers of 1 in 4.84 and 1 in 466.04.

Can someone help me determine where I'm going wrong? The reason I'm trying to figure this out is I'm comparing numbers from 4 player, double deck pinochle with 6 player triple deck pinochle (i.e. 6 of each card of each rank).

My numbers are showing me that it's easier to get anything around once, when using 2 decks, but it's easier to get things around 2 or more times when you're playing with 3 decks). I find it odd that you can get Aces around once, fewer times with 3 decks, but double/triple aces around more times with 3 decks. (I have over 400 million simulated hands with programs... and the program results all line up...)

Edit: I'm also trying to calculate the probability of a run. I saw this thread http://www.vbforums.com/showthread.p...un-in-pinochle, but it looks like the OP didn't finish clarifying the questions asked of him. I'm also basing it off of a double deck of pinochle cards (i.e. 4 of each card of each rank from Jack through Ace (tens are included, but they're ranked below Aces, above Kings), double deck Pinochle doesn't use the 9's).

So I'm thinking it should be:
Random suit (4,1)
Random ace of that suit (4,1)^5 (^5 does Ace, Ten, King, Queen, Jack).

Then there are 75 cards left, and you still need 15 in your hand, so that should be (75, 15)

so if I take (4,1) ^6 (Suit + 5 ranks) * (75,15), I'm getting a number of 9.33 E+18, yet (80,20) says there should only be 3.53E+18 total combinations.... so I'm off somewhere.

In regards to previous unanswered questions, yes having both other face cards is still a run. The only point at which it quits being a run is if you end up with 2 of every card... then it's a double run. I was thinking I'd figure out the number of ways to get a quad run (should only be 1...make that 4, since it could happen in any suit...), then the number of ways to get a triple run (minus the one(make that four) for the quad run), then the ways of getting a double run (minus the ways of getting a triple/quad run), and then the ways of getting a single run (minus the double/triple/quadruple runs). But even ignoring double/triple/quadruple runs when looking for a single run, my numbers still seem way off...

First of all, as a lifelong Pinochle player, I'm tempted to ignore this post entirely on the principle that you are playing it wrong. Double deck? That's like eating tofurkey on Thanksgiving!

However, I can see the problem pretty easily, but I'll have to leave the solution to you (which I don't have the time to figure out at the moment anyway):

Your basic problem is that you are over-counting things. For example, given:

Quote:

---

Originally Posted by Fizziii

Then I got single aces (4,1)^4 * (76,16) - 2x/3x/4x Aces from above = 2,752,579,046,460,370,000

---

Consider the hand sA1, sA2, hA1, cA1, dA1 plus 15 non-ace cards. This hand (and thus all (76,15) possible hands like this) are being counted at least twice by the above formula. This is because it is being counted once as...

sA1, hA1, cA1, dA1 plus 16 cards, which include sA2

... and also once as ...

sA2, hA1, cA1, dA1 plus 16 cards, which include sA1

In order to get around this, you need to account for this. And then account for this with every other suit (plus when it happens to more than one suit at a time).

Good luck, ya double deck heathen!

Edit: Almost forgot, I wrote a little routine that I *believe* calculates the number of hands that do NOT include a set of aces: 2,796,602,307,719,350,464. That should leave a total of 738,713,834,492,823,856 hands that do contain a set of some sort, or roughly 1 hand in 4.7858 deals, which is very close to your experimental results.

Here's the source code of the algorithm (in c#), it should point you towards an algorithm that could help you solve your over-counting problem:

Code:

---

        private void ComputeNoAces()
        {
            long i;
            long j;
            long k;
            long n;
            long total;

            // no aces Choose(64,20) = 19619725782651120
            total = Choose(64, 20);

            //ace in one suite
            n = 0;
            for (i = 1; i <= 4; i++)
                n += Choose(4, i) * Choose(64, 20 - i);
            total += Choose(4, 1) * n;

            //ace in two suites
            n = 0;
            for (i = 1; i <= 4; i++)
                for (j = 1; j <= 4; j++)
                    n += Choose(4, i) * Choose(4, j) * Choose(64, 20 - i - j);
            total += Choose(4, 2) * n;

            //ace in three suites
            n = 0;
            for (i = 1; i <= 4; i++)
                for (j = 1; j <= 4; j++)
                    for (k = 1; k <= 4; k++)
                        n += Choose(4, i) * Choose(4, j) * Choose(4, k) * Choose(64, 20 - i - j - k);
            total += Choose(4, 3) * n;

            MessageBox.Show(total.ToString());
        }

        private long Choose(long n, long r)
        {
            //need to compute n choose r = n!/r!(n-r)!
            if((n < r)||(r < 0))
                throw new Exception("n or r out of bounds");

            if((r==n)||(r==0))
                return 1;

            long r1 = r;
            long r2 = n - r;
            if (r2 > r1)
            {
                r1 = r2;
                r2 = r;
            }

            long y = 1;
            List<long> div = new List<long>();
           
            for (long i = 2; i <= r2; i++)
                div.Add(i);

            for (long i = r1 + 1; i <= n; i++)
            {
                y *= i;
                List<long> div2 = new List<long>();
                foreach (long j in div)
                {
                    if (y % j == 0)
                    {
                        y /= j;
                    }
                    else
                    {
                        div2.Add(j);
                    }
                }
                div = div2;
            }

            return y;
        }

---

I'll see what I can do... statistics are a bit beyond me, but I'll evaluate what you said and see if I can get it to work.

Regarding the double deck... what can I say, I play the way I learned... I do use single deck for 3 player though. And if it helps, what brought this up was comparing probabilities to triple deck... (From what I'm seeing, with 6 hands and triple decks, you are less likely to get anything around (or a run) once, but more likely to get anything around (or a run) two or more times (when compared with double deck).

If I'm understanding what *you're* saying, I'll need to add the combinations of:
4441, 4431, 4421, 4411, 4331, 4321, 4311, 4211, 4111, 3331, 3321, 3311, 3221, 3211, 3111, 2221, 2211, 2111, and 1111 and separately, and then add them together to find out the total number of cominations of single aces (kings, etc.)... and then divide the total number of hands by that number to get the 1 in xx number?

*Edit: Fixed "I'm" to "you're"

Basically, yes. As it turns out, this is much easier than I expected. In c#, again (and using the same Choose() function in my earlier post:

Code:

---

private long[] CalculateAll()
{
    long[] total = new long[5];

    for(long i=0; i<=4;i++)
        for(long j=0; j<=4;j++)
            for(long k=0; k<=4;k++)
                for(long l=0; l<=4;l++)
                    total[Math.Min(Math.Min(i,j),Math.Min(k,l))]+= Choose(4,i) * Choose(4,j) * Choose(4,k) * Choose(4,l) * Choose(64, 20 - (i+j+k+l));

    return total;
}

---

That's it! This nets you:
[4] = 635,376
[3] = 1,299,449,210,880
[2] = 7,576,701,736,868,160
[1] = 731,135,833,306,109,440
[0] = 2,796,602,307,719,350,464
[T] = 3,535,316,142,212,174,320

([T] is the sum of [0] - [4], and, as verification, equals (80,20))

If I'm understanding that right, it's adding 4441, 4414, 4144, and 1444 separately?

So it seems. It's a interesting mix of combinatorics, but the proof is in the pudding:
- both algorithms I've shown produced the same answer for number of hands without aces around
- that answer is within a reasonable amount of your experimental results
- the second algorithm produces a total count equal to (80,20)

As an FYI, it should be very easy to extend the algorithm to make the calculations for the single (aka correct) or triple (blah) decks, although in the case of the triple you'll probably need to replace the longs with BigIntegers or something similar

How would I apply this to Runs and Aces in triple decks.

I know Aces in a single (aka correct) deck would be 0-2 each for i/j/k/l)... but with triple deck and 20 card hand sizes... there are 24 aces total (4 * 6). So would I construct the i/j/k/l loops for 0 to 6, and have an if clause that says if i+j+k+l >20, ignore it?)

Would runs be 5 loops (representing each A/10/K/Q/J in the specific suit) and ignore the suit? (or multiply by 4 at the end for a total of 4 suits?)

I did rewrite your code into Python and got it to work and come up with the correct values for aces, so now I'm trying to expand on what you taught me...

Quote:

---

Originally Posted by Fizziii

How would I apply this to Runs and Aces in triple decks.

I know Aces in a single (aka correct) deck would be 0-2 each for i/j/k/l)... but with triple deck and 20 card hand sizes... there are 24 aces total (4 * 6). So would I construct the i/j/k/l loops for 0 to 6, and have an if clause that says if i+j+k+l >20, ignore it?)

---

Exactly, except for two things:
- instead of (64,20-(i+j+k+l)), you'd use (96,20-(i+j+k+l)), where 96 = 120 cards - 24 aces
- You'dd definitely need to use a larger numeric datatype. A long is only 64 bits, which won't even hold (120, 20). If you are using .net, I'd just go with BigInteger. Alternatively, a 128bit integer type should suffice for triple deck considerations

Quote:

---

Originally Posted by Fizziii

Would runs be 5 loops (representing each A/10/K/Q/J in the specific suit) and ignore the suit? (or multiply by 4 at the end for a total of 4 suits?)

---

Not exactly, that would still overcount things because you are not taking into account hands with runs in more than one suit. The five loops should indeed count the number of hands that produce runs in, say, spades, but you can't just multiply that by four, since you would then be double counting hands with runs in both spades and any other suit (triple counting runs in spades and 2 other suits, and quadruple counting the hand with a run in all four suits). Also, since a run in one suit is not an independent event as a run in another suit, you can't just add their probabilities and then subtract the product of their probabilities for a shortcut. At present, I think your best bet may be to use 20 nested loops (a, b,..., t) where SUM(a, b,..., t)=20 to compute (4,a)*(4,b)*...*(4,t) , and organize those counts based on whether how many runs are in the hand (aka, examine max(min(a-e), min(f-j), min(k-o), min(p-t)), which will tell you if there is no run, single, double, tripe, or quad).

Quote:

---

Originally Posted by Fizziii

I did rewrite your code into Python and got it to work and come up with the correct values for aces, so now I'm trying to expand on what you taught me...

---

I'm not that familiar with Python, but make sure you are not using a non-integer type like a double, as you'll hit significant rounding errors (I noticed that your numbers in your OP were off due to lack of precision, so I thought you might be using doubles)

20 loops is too much. I named my variables A1/T1/K1/Q1/J1 (1-4 for each) to go through by suit. The second 2 suits (the 3's and 4's) can complete a cycle every 20 seconds. So K2 increments every 8 minutes. so that's about every 40 minutes per T2, and every 3+ hours for A2... let alone the first suit.

Quote:

---

Originally Posted by Fizziii

20 loops is too much.

---

It's only too much if you don't want the correct answer. With some smart pruning (aka, not entering branches if you can determine that no useful work can be done there), the algorithm can be optimized significantly. Mine ran in about three hours and produced these counts & probabilities:

[0] = 1844614576453356700
[1] = 1686335758985681856
[2] = 4365781817350608
[3] = 24955785152
[4] = 4
[T] = 3535316142212174320 = (80,20)

P[0] = 0.521767927464364
P[1] = 0.47699715984395136
P[2] = 0.0012349056326879954 = 1.2349056326879954E-3
P[3] = 0.0000000070589967482750409 = 7.0589967482750409E-9
P[4] = 0.0000000000000000011314405385813831 = 1.1314405385813831E-18
P[T] = 1.0

Bear in mind that [1] is probably smaller than your calculation, because it does not include hands which have both a run and a double or triple run, because if you have a double or triple run in one suit, who the heck cares if you have a single run in another suit?

The numbers I have in my simulation are:
1x Run: 1 in 2.10 hands (Dead on out to 2 decimal places)
2x Run: 1 in 809.27 hands (A hair lower than your calculated numbers)
3x run: 1 in 202,827,360 hands. (This one is obviously off because I haven't simulated enough hands.)

I'll have to think about how and where you did your pruning. It's not coming to me right now.