Hey guys, I'm trying to build my own version of ICMizer for my poker lib for a few reasons (mainly they incorrectly analyse shove spots for stack size <0.5BB but I digress)

I'm working my way through the mammoth challenge part by part and I'm currently stuck on:

How do we get the equities of four way all ins?

Essentially to update the over calling strategy for a fourth player using a Fictitious/Regret minimisation algorithm we need to calculate the EV of the over call. So we need to know the four way equities for all hands for the strategy.

This is problematic because despite having a lightening quick hand elevator (like the one open sourced by members of 2+2 using lookup tables) you cant really calculate these equities on the fly in any reasonable amount of time. I can definitely see it viable to calculate a three way equity lookup table for 3 way all in's then solve three way shoves like done in this paper:

https://www.cs.cmu.edu/~sandholm/3-p...ld.AAMAS08.pdf

Also done by the guy from Holdem Manager I think but I'm stuck trying to figure out how it could be done for four ways+, a 4(+)D matrix is infeasible (is it not?) calculating the equities on the fly is infeasible (is it not?) but ICMizer and Holdem Manager both manage to do these 9 way NE Calculations which I don't understand. I'm sure there is likely some like pruning done because the probabilities of four way all in's occurring are so so small that I could probably get away with discounting them somehow.

But it's not really ideal and going to derive incorrect results which is unappealing especially because I know both ICMizer and Holdem Resources have solved it without doing so (or have they just used some simplification/pruning trickery?).

Any thoughts?

Cheers

As far as I know all the ICM programs on the market restrict action to a maximum of 3 active players in the pot - all remaining players are folded once that limit is reached. That way you never deal with 4-way equities.

Hey thanks for your reply. That makes sense I think. Still trying to wrap my head around some aspects of how to frame the problem correctly but it's great to know this going forward.

Your probably the best person to ask this if you don't mind taking some time to answer:

I'm a little inexperienced programming wise, just about 4 years of my undergrad and a few personal projects. How feasible is this to tackle by myself? I have absolutely no sense to the scale of difficulty of going from a 2 person solution that I have now to full ring spots with re shoving and all that jazz.

Just don't want to waste month(s?) doing something that I have not a real chance of completing if you get where I'm coming from, like how hard was it to get it to run quick enough to actually be use-able? Hard to really answer that without knowing my ability or anything but:

Say if solving a 2 person heads up shove game was an hour walking on the treadmill at a 10 degrees incline, is the 3+player solution like another hour or two at the gym or is it like climbing K2 ?

I had roughly your experience level when I started with poker programming.

For me it was basically these steps:
1) Basic 2-player push-or-fold solution/charts. I don't remember exactly, but i think this took me maybe a weekend from scratch with no previous poker coding at all. You can probably re-write this in a couple of hours if you have programming experience with poker.

2) Full ring push/fold with linear ranges. This is a simplified version of the game where ranges are restricted by a hand-ranking, ie without mixed strats you are limited to 170 possible ranges instead of 169^2. This is what the free web-calculator does on my site, and i believe ICMizer calculates its Nash ranges like that. I'm pretty sure SNGWiz 1 also worked like this internally for all its calculations. To get this working fast you need the range equity matrix similar to the paper you linked, the rest is relatively straightforward. It's still a bunch of work though, like 1-2 magnitudes more complex than the 2-player case.

3) Full push/fold without the hand-ranking restriction mentioned above, which is what you are trying to do. Doing this fast enough to be usable is very challenging. For a long time (years) after writing the hand-ranking restricted version I still used to think an unrestricted Nash calculator would not be feasible. It's certainly easier when you already have other implementations around as a reference, but it's tricky.

I'm really confused by this part of your reply if you don't mind elaborating?

When solving the scenario for P1 of 3 players my understand leads me to think we are solving the strategy "profiles?" of:

P1: 169 hands to shove
P2: 169 hands to call
P3: 169 hands to call given P2 folds + 169 hands to overcall given P2 calls

So we have just 2 ranges to solve for P3? Feel like I'm missing some complexity here and I don't get what you mean about hand ranking?

Also for calculating the equity matrix the paper said a month of processing on 16 processors . Think its worth looking at doing some sort of MapReduce job for this? Think I might be a little over my head , but it's fun and a learning process so I'm pot commited, thanks for your help

Yup, for the case where P1 pushes there are only 4 ranges. For the normal game, ignoring mixed strategies, there are 2^169 possible profiles for each of these ranges. (That's 169 hands, each being a shove or fold.)

In the "linear" version of the game you restrict the possible profiles by a hand ranking, e.g. only allow profiles that are consistent with the Sklansky/Chubukov numbers. The Sklansky/Chubukuv ranking goes like AA>KK>AKs>QQ>etc.

You get 170 profiles that are consistent with that ranking:
{}, {AA}, {AA, KK}, {AA, KK, AKs},...

Something like {AA, KK, QQ} would not be allowed because AKs>QQ, so AKs needs to be played if QQ is played.

This restricted game is much easier to calculate because you can pre-compute all possible 3-way range matchups.