Texas Hold’em is bloodsport, primarily because of its computational complexity which requires you to guess probabilities that are not easy to estimate. The “blood” part comes from the consequences of making uninformed bets, which can get you into big trouble – if you don’t know which guy at the table is the mark, then its always you. Poker is not meant to be kind to the beginner.

I used to write pokerbots. For the flop, turn and river rounds the ease of calculating hand odds by computer in real time is pretty straightforward with a bit of pre-calculation. The hard part was dealing with bluffing and adjusting the hand odds accordingly. The University of Alberta’s pokerbot program did a really good job figuring that out – I usually wrote my bots to combat theirs.

The hardest part – and the most computationally intensive – was figuring out proper bets during the ante. You had your 2 cards, you faced a table holding their cards – and you had to properly guess the odds. I saw lots of opening round strategies but didn’t see anyone making a simple table with the probabilities of winning or losing. So – I wrote a quick program to figure that out.

The first step is to show the “base” probabilities. This is the chance of a win or a draw if you go right to the river card – it’s not odds as we would need to know the size of the pot etc, but you can use this info to figure out the odds pretty easily from there. I simplified things (for reasons that will be clear later) by reducing openning cards to suited or not suited for me versus my opponent. Here’s the table showing that result:

You use it by looking at your hand and reading off the table. Let’s say I was dealt 10-H and A-D. That’s an offsuit pair, so I’m looking at the upper part of the triangle (note that all pairs are necessarily offsuit), specifically at the cell for TAd (T=10, A=Ace, d=offsuit portion of the grid). In this case, it gives me a probability of 65%. That means playing against every other hand combination and assuming that all those hand combinations appear equally, I would have a 65% chance of winning. That means against 22d (pair of 2’s), AAd (pair of Aces), 27s (2,7 same suit) etc. – all 169 combinations (13 x 13).

This grid would be good for figuring out your chances against the blinds if no one raised during the ante – but not good for much else.

Things get more complicated if you are figuring out the probability of a win against other players who have to bet money in order to stay in the game (or if the blinds raised or called to a raise). In that case, the likelihood of your TDd playing against an opponents 27d is zero: that’s literally the worst hand and no one is going to bet money on that. So, we need to weight the hands of your opponents in order to come up with a more realistic estimate of what your winning odds are. In this case, I used the odds from the base table to help me figure it out – anything with less than a 50% base chance of winning isn’t going to get played by an opponent, while anything with 70% or over base chance will get play 100%. All numbers in between are simply copied. When I use this weighting, I come up with a new table:

For the record, here’s the probabilities I use to calculate table 3:

I’m trying to put this into a spreadsheet so that you can make your own probabilities based on your own estimates. The code used to calculate this was a separate program I wrote that did a couple of days of calculations to come up with the base cases I use to calculate the estimates – I need to clean it up before releasing it to the world, so I’ll probably post that later. I originally did this years ago in C but for simplicity I just wrote this version in Java – oddly enough, running highly optimized C code on a machine from 10 years ago versus unoptimized Java code on a modern laptop (and not even the fastest one out there – I probably could have multithreaded it to take advantage of the multiple cores on my i5) took about the same length of time.

Finally, for the record, even this is a simplification. Given, TAd, there are actually twelve combinations of cards which would match that pattern (10 hearts – Ace diamonds, 10 spades – Ace hearts etc.). The issue lies in the base program I use to calculate the odds of various match ups like TAd versus 27s. If the 10 in TA is a hearts and both of the 27s are hearts, then the chance of a flush resulting in a tie is greater than if the two sets of cards have different suits. Still, flushes are relatively rare and don’t change the percentages by much – you can get a sense of the effect by looking at the relative win percentages for, say, TAs versus TAd – it’s a delta of 1-2%. I figured that was a fine margin of error if it meant I could fit everything into a 13×13 table.