Probability of a higher pocket pair

[R Gibert]

Apparently, computing the probability of your opponents being dealt a higher pair than you in Hold'em is not so easy to calculate. See:

http://en.wikipedia.org/wiki/Poker_p...9#Pocket_pairs

for an explanation of how to do it exactly.

I decided I would try to come up with an approximation that would be suitable for calculation over the table that would be accurate to within about a percent. What I came up with is a bit more complicated than I hoped, but it seems to be accurate to within 0.5%:

P = n*t/2 - [.15*n²]*(t²/100)

where t = 14 - pocket_pair_rank
and [x] is the greatest integer < x

Using Python, I produced the following table:
<font class="small">Code:</font><hr /><pre>
1 2 3 4 5 6 7 8 9
KK 0.5 1.0 1.5 2.0 2.5 3.0 3.4 3.9 4.4
QQ 1.0 2.0 3.0 3.9 4.9 5.8 6.7 7.6 8.5
JJ 1.5 3.0 4.4 5.8 7.2 8.6 9.9 11.2 12.4
TT 2.0 4.0 5.8 7.7 9.5 11.2 12.9 14.6 16.1
99 2.5 5.0 7.3 9.5 11.8 13.8 15.8 17.8 19.5
88 3.0 6.0 8.6 11.3 13.9 16.2 18.5 20.8 22.7
77 3.5 7.0 10.0 13.0 16.0 18.6 21.1 23.6 25.6
66 4.0 8.0 11.4 14.7 18.1 20.8 23.5 26.2 28.3
55 4.5 9.0 12.7 16.4 20.1 22.9 25.8 28.7 30.8
44 5.0 10.0 14.0 18.0 22.0 25.0 28.0 31.0 33.0
33 5.5 11.0 15.3 19.6 23.9 26.9 30.0 33.1 35.0
22 6.0 12.0 16.6 21.1 25.7 28.8 31.9 35.0 36.7
</pre><hr />
You can compare this approximated table with the more accurate one at the above link (sorry if the table appears a bit mangled, but I don't know how to avoid it at this forum).

I had originally planned to come up with an approximation for ICM calculations, but discovered that some of the information around the web on it to be unreliable. I decided on the above project as a of kind practice before sorting out how I'm going to resolve how I'm going to tackle the ICM approximation. I'm sure the above has virtually no practical value. FYI

[R Gibert]

correction:

[x] is the greatest integer &lt;= x

[AaronBrown]

That's a good approximation, but I use something simpler. I start with n*t/200 (working in decimals instead of percentages), then subtract half of that number squared. So for pocket 5's (t = 9) and 6 players (n = 6), I start with 6*9/200 = 0.27. 0.3 squared is 0.09, so I need to subtract 0.04 to get 0.23 (I round up the 0.27 to 0.3, but then round down the 0.045 to 0.04, the exact answer is 0.2324).

My way works within 0.01, except for very low pocket pairs with lots of other players, where it's not relevant anyway.

The reason I like my approach is not that it's a simpler calculation, it's that it works more generally. Given my two cards, there are 1,225 possible hands one other player can have. I'm afraid of a certain number, higher pocket pairs (each pair can be made 6 ways) if I have a pair, hands that match one of my cards and have a higher second card (12 times the sum of the number of ranks that beat each of my cards, minus one, so if I have K9 that's 12 times (1 + 5), or 72, minus 1, for 71) if I don't, suited cards of the same suit as mine with a higher top card if I've got suited cards; and so on. Once I know the number of hands that I'm afraid of, I divide by 1,225. 6/1,225 is about 6/1,200 = 0.05, I often round like this.

Whatever result I get I multiply by the number of players I'm worried about. Then subtract half of the square of that number. That's roughly the probability that two or more players have hands I'm afraid of, which I'm double counting in the initial calculation.

Especially in no-limit poker, the important thing is to avoid being dominated. You can survive lots of hands with 35% or 40% equity, but those 5% and 10% equity hands kill you. So if there's a significant probability of someone being dealt one of them, and they're hands people are very likely to play, you either fold immediately or at least play very carefully.

Of course, you balance the theoretical probability with your reads and deductions from people's actions, but knowing the probabilities is important in the long run.

[jay_shark]

Anyone else spot the error on the wikepedia page ?

According to the source , if you hold pocket 2's against 9 other opponents , then there is a 36.33% chance that someone holds a higher pair . This is wrong .

[AaronBrown]

Why do you think this is wrong?

[jay_shark]

It's not consistent with the numbers from this page

http://www.math.sfu.ca/~alspach/comp35/

[Some9]

http://sports.espn.go.com/espn/poker...amp;id=2665855

[R Gibert]

I wrote a Monte Carlo program in Python that produced the following results:

13: 0.0440
12: 0.0860
11: 0.1263
10: 0.1649
9: 0.2011
8: 0.2372
7: 0.2703
6: 0.3029
5: 0.3346
4: 0.3643
3: 0.3916
2: 0.4187

I used 1 million iterations apiece. This is in very close agreement (&lt; 1% difference) to the sum of each row in the last table from the link you gave "and yet not" . As you move down the table there is a definite pattern where the results from the link you gave are generally a bit larger than the results produced by my program:

13: 0.0439
12: 0.085983
11: 0.1271218
10: 0.1659144
9: 0.2030309
8: 0.238537
7: 0.27248
6: 0.304978
5: 0.33591
4: 0.36546
3: 0.393731
2: 0.42062

I suspect a subtle error on my part or possibly on the part of the article. I will look at it some more. Seems like a quibble due to the smallness of the difference, but the pattern is there and so it seems something is wrong somewhere. It's probably me.

In any case, it is clear that the Wikipedia article is definitely unreliable. This is the same sort of thing I noticed with ICM calcs on the web not agreeing with one another.

It is very hard to find trustworthy information on this sort of thing. Errors in this type of thing are very easy to do.

For example, Paul Erdos, a renowned mathematician got the Monty Hall problem wrong, but was finally convinced by a Monte Carlo program, that illustrated what was really going on. Evidently, such programs can be quite useful.

BTW, if someone could write their own Monte Carlo program to help clarify this, it would definitely help. It's easy to do. Mine is only 18 lines long, so it is a trivial "project." In this way, my possible mistakes won't likely be repeated. It's a good independent way to test.

[im a model]

why are you guys off by so much? isnt this easily solvable by just running a simulation a few million times? i realize you guys are trying to solve it by using different methods, but im interested in the actual odds and im confused by which table to follow. i take it that this one is the most correct: http://www.math.sfu.ca/~alspach/comp35/. right? if so, phil gordon and others are off by a large amount on the lower pairs full ring--compare 54% to 33%.

[binions]

[ QUOTE ]
I wrote a Monte Carlo program in Python that produced the following results:

13: 0.0440
12: 0.0860
11: 0.1263
10: 0.1649
9: 0.2011
8: 0.2372
7: 0.2703
6: 0.3029
5: 0.3346
4: 0.3643
3: 0.3916
2: 0.4187

I used 1 million iterations apiece. This is in very close agreement (&lt; 1% difference) to the sum of each row in the last table from the link you gave "and yet not":

13: 0.0439
12: 0.085983
11: 0.1271218
10: 0.1659144
9: 0.2030309
8: 0.238537
7: 0.27248
6: 0.304978
5: 0.33591
4: 0.36546
3: 0.393731
2: 0.42062


[/ QUOTE ]

Looks like another rule of 4, or more precisely, 4% for 1-6 possible overpairs, and then 3% for the 7th-12th possible overpairs.