4

Sorry I'm just starting this project and don't have any ideas or code, I'm asking more of a theoretical question than a programming one.

It seems that every google search provides the same responses and it's very hard to find an answer to this question:

Is there a way to calculate win percentages for texas holdem poker (the same way they do on poker after dark or other televised poker events) without using the monte carlo/exhaustive enumeration methods. Assuming all cards are face up and we know every card in the deck.

Every response on other forums just seems to be "use pokerstove" or something similar, I'm looking for the theory to write the code.

Thanks.

Ben Thomson
  • 41
  • 2

2 Answers2

0

The answer is no.

There is no closed form computation that you can do to compute poker equities. Using combinatorics, you can identify and solve many subproblems, which speeds up computation.

For example, if you are considering all five card hands, there are 52 choose 5 = 2,598,960 different hands. But knowing that suits are equivalent and using combinatorial methods (either analytic or computational), you can reduce the space of all hands to 134,459 classes each weighted according to the number of different hands in each equivalent class.

There are also various ways of using exhaustive evaluations tailored to your application. If you need to perform some subset of evaluations repeatedly, you can use caches or precomputed lookup tables targeted to your specific needs.

Andrew Prock
  • 6,900
  • 6
  • 40
  • 60
  • Why do you say that there are 134,459 equivalence classes? I'm only aware of [7,462](http://www.suffecool.net/poker/7462.html). – gdejohn Jan 06 '14 at 20:18
  • 1
    There are 7462 evaluations, but that begs the question. The equivalence classes don't map hands to evaluations, but hands to equivalent hands. For example AcAd maps to the same evaluation as AhAs. If you were going to create a lookup table which mapped cards to evaluations, you could use this sort of suit equivalence to reduce the lookup table size by 19 or so. – Andrew Prock Jan 07 '14 at 19:26
  • 1
    You can do better than that. A set of five cards can be collapsed directly to its equivalence class by determining if it's a flush and counting the frequency of each distinct rank. Just map each equivalence class to its respective score, and you have exactly 7,462 key-value pairs. – gdejohn Jan 07 '14 at 19:50
  • The suit independent equivalences are independent of texas hold'em evaluations. Your approach requires "collapsing" 2.6 million hands. The one I discussed requires "collapsing" 134k hands. – Andrew Prock Jan 07 '14 at 23:01
0

Is there a way to calculate win percentages for texas holdem poker (the same way they do on poker after dark or other televised poker events) without using the monte carlo/exhaustive enumeration methods.

In specific instances it is possible...

You can use a perfect lookup table preflop for two players heads-up preflop matchups: note that the "typical" 169 vs 169 approximation ain't good enough (say Jh Th vs 9h 8h ain't really "JTs vs 98s": I mean, that would quite a gross approximation).

Besides that if you have a lot of memory and if you can live with gigantic cache misses, you technically could precompute gigantic lookup tables (say on the server side) and do lookups for other cases (e.g. for every possible three players all-in matchups preflop), but you'd really need a lot of memory : )

Note that "full enumeration" at flop and turn ain't an issue: at flop there's only 2 more cards to come, so there are typically only C(45,2) [two players all-in at flop, we know 2*2 holecards + 3 community cards -- hence leaving 990 possibilities] or C(43,2) [three players all-in at at flop, we know 3*2 holecards + 3 community cards].

So an actual evaluator would not use one but several methods. For example:

  • lookup table for two players all-in preflop (the fastest)
  • full enum for any number of players all-in at flop or turn because it's tiny (max 990 possibilities) -- very fast
  • monte-carlo or full enum for three players or more all-in preflop -- incredibly slower

It is interesting to see here that in the most typical cases you'll get the result very, very fast: most actual all-ins involve two players, not three or more.

So you're either looking up in a "1 vs 1 preflop" lookup table or doing full C(45,2) or C(46,1) full enum (which are, in both case, amazingly fast).

It's really only the "three players or more all-in preflop" case which do take time.

TacticalCoder
  • 6,275
  • 3
  • 31
  • 39
  • The 3+ players or more preflop case can be done very quickly if you can identify the combinatorial subproblems. But you still have to enumerate through the space of all equivalent combinations. – Andrew Prock Jun 05 '12 at 20:29
  • @Andrew P.: as far as I know even when suit-normalizing the 3+ players matchups preflop the combinatorial explosion is way too gigantic to create lookup tables. There are still no known closed formula. Without normalization there are, what, about one billion (!) possible 3 players preflop matchups. Normalizing the suits helps but the combinatorial explosion is so big that you won't have enough memory. Even PokerStove, which is still the fastest out there, cannot do these cases fastly. Let's not even mention 4+ preflop. – TacticalCoder Jun 06 '12 at 12:05
  • PokerStove does 3 handed preflop matchups instantly without using lookup tables. There are only 1.37 million cases to enumerate. – Andrew Prock Jun 06 '12 at 19:53
  • @AndrewP.: I should point out I wrote both a tracker/HUD which can parse several thousands of online poker hands per second (it's not a typo), including all-in equity computation. Computing 1370754 cases is not anywhere near "instant" compared to a table lookup, which was my point. If PokerStove was "instantaneous" to compute that, then it would be able to instantly compute: *"AJs+, AJo+ vs ATo+,ATs+ vs 22+"*, but it cannot. Because that's 198 **billion** computation. You cannot say that doing something 1370754 times is "instantaneous" compared to a lookup table, which was my point ; ) – TacticalCoder Jun 06 '12 at 20:58
  • @AndrewP.: my point was that C(52,2) * C(50,2) * C(48,2) is huge (without normalization). If you want to do really fast, say, *"AJs+,AJo vs ATo+,ATs+ vs 22+"* then without lookup tables it's very slow. If you tried to create a C(52,2) * C(50,2) * C(48,2) table it would be, even after suit-normalization and whatnots, quite a gigantic memory drain. When I mentioned one billion case I of course wasn't talking about the C(46,5) / 1370754 cases you'd need to (painfully slowly I'd add, compared to a lookup table) evaluate using a full enumeration : ) – TacticalCoder Jun 06 '12 at 21:04
  • @AndrewP.: the only way to get something really near instantaneous 3-players preflop would be to either find a (magic?) closed-formula or to precompute a gigantic table in which you could easily pick any of the C(52,2) * C(50,2) * C(48,2) possibilities. Funnily enough it *is* doable on the server-side. But on the client-side there's no way as of now to realistically store / compute / query / ship that a big an amount of data. Been there, done that ; ) – TacticalCoder Jun 06 '12 at 21:08
  • On my machine, PokerStove does 3+ players preflop in under 5 milliseconds. Not sure why you'd ever compute equities of three ranges, but the first two ranges vs 2c2s only takes 6 seconds, which is 3 billion games. – Andrew Prock Jun 06 '12 at 22:54