Texas Hold'Em Poker Analyzer

This graphical interface computes the winning frequency of any given hand in a poker game of Texas Hold'em. This is similar to the percentages they show on the poker games on TV.

Most poker analyzers require that you specify what cards your opponent is holding. Then, the program will determine your hand's chances of winning versus your opponent's specified hand.

An advantage of this Texas Hold'em analyzer is that it determines the win frequency of a hand without knowing what the opponent is holding. It will determine your hand's chances of winning versus any arbitrary hand your opponent(s) might hold. This is similar to the situation when you are sitting at a table in a real game.

Which pocket hand is better, A,K suited or 2,2? Consider a head-to-head match up (two players) with A,K suited versus 2,2. Simulating this with the analyzer, we find the win percentage to be about 50/50. However, which hand is stronger versus any arbitrary hand? We find that 2,2 versus any arbitrary hand remains about 50/50. However, A,K versus any arbitrary hand is better at about 66/34. Therefore, a head-to-head match up does not indicate how strong one hand is versus another arbitrary hand.

Now add another arbitrary hand to the game. We find this reduces the win percentage of the A,K suited to about 51%, but we find it increases the expected return from 1.33 to 1.5. Therefore, we see that although we'll win fewer hands, we expect to win more money.

The expected return of 2,2 versus another hand is about 1.0. The expected return versus three other hands decreases to about 0.88. However, using nine other hands increases it to about 1.18. Therefore, increasing the number of hands does not result in a monotonically increasing or decreasing expected return.

If you have an interest in looking at the code, note that this program originated as a programming exercise in vectorizing operation. Very few FOR-loops are used. Although there was a great benefit to vectorizing operations in versions prior to MATLAB 6.5 (R13), this is not the case in more recent versions. The JIT accelerator now speeds FOR-loops so that they are often as fast, if not faster, than vectorized operations. Therefore, this code is not as fast as it can be, and uses more memory than it needs to.