I just bought a month and am concerned by the outputs that ICMIZER is giving me. For a standard 20BB SB rejam versus BTN open it's saying I can reshove any two cards. But the concerning part is the edge value it is giving me for different hands. In the provided example below pocket 22 is 0.00 edge but pocket AA is only 0.02 edge. I've used your product before and this just seems wrong to me.

https://www.icmizer.com/icmizerapp/#EStvDZ

This is an MTT hand early enough in the tournament that it should be close to chip EV. I selected a similar tournament from the list and filled out the MTT Mode information.

Hey stinbag,

I am not sure what exactly was entered that led to 100% reshove range, I entered your raising range for BTN and locked it and kept everything else unlocked.
Here is the result I got:
https://www.icmizer.com/screenshot/IqHoGd/
The range makes much more sense now.

In order to end up with 100% reshove range you usually need to limit the calling frequency of the raiser so they simply don't call enough.

Note that regarding 0.00% EV - with 900 players remaining it is hard to gain much in a given hand because we are talking about % of the total prize pool.
For MTTs I generally recommend using ICM $EV mode. In $EV mode you can see how much $ your gaining or missing and it can be easily compared to the tournament which in turn makes choosing the right threshold easier.

Best ways to use ICMizer?

Currently I run my completed one-table tournaments through ICMizer Auto Hand Analysis (making sure to select the correct tournament type) and get feedback on push/fold decisions. I also use MTT coach to train those same structures. It's all helpful and I've learned a lot, but I'm not feeling grounded in my progress. Perhaps because I don't have a good foundation in ChipEV push/fold decisions to adjust from?

Do you recommend spending time learning ChipEV push/fold decisions first? Any recommended resources? Short-stack Push/Fold charts starting on page 206 of Modern Poker Theory are helpful, but only cover 10BB or less.

Has anyone worked on a regression model for ChipEV or ICM EV decisions? The inputs could be positions and stack sizes and the output could be push %. Simple cases (single raise from EP with stack X vs hero on BB with stack Y, etc) seem they might bear fruit.

All thoughts appreciated, thanks.

Fortuitous

Mystery Bounty Royale support added to ICMIZER and MTT Coach.

These special tournaments required update to our KO tournament logic since knockouts are paid only for busting players on positions from 2 to 9 with 18 players total.

The strategy changes in interesting ways as you move from the initial two table format to the final table where mystery bounties begin!

The strategy is the same on all 4 types regardless of stakes, so we've only added one in ICMIZER & MTT Coach.

New to the software but enjoying my study journey with this great tool.
https://www.icmpoker.com/screenshot/uxDQsC/



3 players left; 2 are paid.
Btn has 2bb; Hero on SB has 20 and BB has 16.
Btn shoves with 49%, and Hero re-shoves with 25%.

But isn't the likely outcome that both Hero and BB will call, maximizing chance of busting Btn and cashing?

So is Hero's 25% call correct when the only options are Shove / Fold? Would the real distribution be more like 90% call and 10% shove?

I recognize ICMizer only offers Push / Fold and is not a solver. Just trying to understand that limitation in this context and how to interpret this result or others like it. Thanks.

Hi guys. I'm new to the software (and pretty new to poker) so apologies that these are noob questions. Any replies appreciated.
Here's an Ignition Single Table Double Up 6-Max (top 3 are paid equally) -- a mini-satellite. Down to final 4 and I'm short stack but we're all close.
CO and Btn fold, SB limps to me in BB.

https://www.icmizer.com/icmizerapp/#OceiuO



I've not seen this shape of range before. Can anyone help me understand it?


Here is SBs 51% range (click on his 51%):


Conventionally linear, but what is this exactly? Is this a limping range? Does ICMizer do that? I'm confused.
And if it is indeed a limping range, why is my push range (above) so odd?



If I set SB to a push and re-analyze:


I see that SB can push with any two and I have a 3.2% calling range. This makes sense to me. But I'm lost regarding the above.
Help? Thanks much.

Similar to last post in that I don't understand how ICMizer deals with reply to pre-flop limp:



Ignition 6-max Hyper, two are paid. Three left.
I'm short stack on BB. Btn limps, SB folds. I can call or push.
ICMzer tells me to push with only 4.6% which seems quite wrong (but I am not confident of this).


If I set Btn to push, then I can call with 14% which seems reasonable:


Why should I be more willing to call here (with no fold equity) than I am to shove after the limp (with some fold equity)?
Ok, I guess part of the reason is that after the limp I can choose play the hand without going all-in.

Another way to ask the question:
What exactly does the Btn 11% range mean in the top image? Is that his 11% limping range? I thought ICMizer doesn't calculate limping ranges, so what does it mean?

Thanks -- very appreciative of any reply.

Bug report. I think. Hard to tell what expected behavior should be without documentation . . . but seems like a bug to me:

https://www.icmizer.com/icmizerapp/#StvzMa

6-max SNG Hyper. Three left, two get paid.
I'm on BB with middle stack. Btn folds, SB completes (limps) to 1 BB.

So yes, this is another question about how ICMizer handles limps. But with a bug report payoff to come . . .


ICMized at recommended FGS=5.

So same initial question as my post above -- what does the 97% mean regarding SBs limp to 100?
Is it: If SB is limited to Limp / Fold, he should limp with 97%?
Is it: If SB is limited to Raise / Limp / Fold he should limp with 97%?
Is it something else?

Anyway, SB limps and my push range is the odd-looking 25%. Cool. Odd that 52o is better than A5s, but strange things happen, I guess.
Is there a way to explore this kind of range in more detail? Yes -- the nifty Dynamic Hand Strength-based Rankings!

https://support.icmpoker.com/en/arti...based-rankings

"The dynamic hand strength-based rankings significantly improve the range editing experience. The range editing slider now takes hands based on their situational strength. So hands that are better for push go in first for push ranges, and hands that are better for the call go in first for calling ranges, for example."

Cool, so I 'll edit my 25% range by clicking right mouse button over it:



Cool, that's the same range as before, but now with different color-coding. Great, so let's slide the slider down to 0 to see which hands are taken out first. Wait, what? As soon as I move the slider at all, the range changes to one with a much more conventional linear shape:



In fact, if I just go back to the prior image (reset locks, ICMize, right-mouse click on my 25% range) . . .



. . . and now where it says 24.9% in the text box next to the bottom slider I click and enter 24.9 . . .



. . . I instantly get this conventional linear range.


Am I misusing this feature? The edit range table seems to "know" I have this unusual, non-linear range to start with . . . but then doesn't "know" how to build up to that range or beyond it and instead builds a linear range. Something seems off.

Would love to hear your thoughts, Q.

Hey, sorry for the late response.
You're pretty much everywhere. We've checked the specification, apparently it doesn't support dynamic ranges for VPIP ranges or sub ranges. Dynamic ranges work with unrestricted push/fold ranges only. It makes sense, because subranges are so special that it often makes sense to manually adjust them and make fewer assumptions.

Hey, we're using simplified and limited support for such situations with limps because these a significant problem to push/fold raise/fold calculator like ICMIZER because the options is not push fold but push/check. In this case it assumes that checking is better than pushing with the hands that we're not pushing.

Realistically though I would be taking these GTO results with a grain of salt. Once we can offer better support for limps, we will announce an update. This also answers your second question regarding limp, all these results given the limitations should be taken not at face value but with some understanding of the math behind these results. You can learn more in Detailed report like this:

https://www.icmpoker.com/screenshot/zHYFXG/

However, if you are the limper and you are facing a push, then this spot can be calculated in ICMIZER precisely. If you put your opponent on a pushing range and enter your limping range, the calling range will be calculated.

Limp is rarely a part of optimal strategy and in most cases when you face a limper you can't make general assumptions about the range, you need to use your reads to assess what your opponent is trying to achieve with a limp and edit it accordingly.

Hi,

It is hard to say what is the likely outcome here. The bigger stack may push to keep the advantageous situation and squeeze the medium stack.

I can see you're using FGS5 which is good for this spot.

As for interpreting how ICMIZER works, C in this case stands for second push, not mere call of 160. So ICMIZER is looking at binary push/fold tree here and finds GTO for this binary tree, the 3rd option of calling the push of 160 (not pushing) is not considered here.

Hi Q,

Thanks for taking the time to answer my questions above.

I get the general notion that limps and replies to limps aren't in the ICMizer wheelhouse, and that you have to do something imperfect to analyze hands with limps. I understand taking such results with a grain of salt. Gotcha.

Still, I'm left with an unanswered question and some comments:



In the SB row, after the Limp 150 text, you show a range bar with 51%. What does this 51% mean?
* Does it mean that ICMizer estimates 51% limps when SB is forced between limping and folding?
* Does it mean that ICMizer estimates 51% limps when SB is forced between limping and all-in?
* Does it mean that ICMizer estimates 51% limps among the hands that are not pushed?
* Does it mean anything at all?

I'm getting the feeling that it means nothing at all - that it's a UI artifact left over from the standard non-limp case, where the range percentage has a clear meaning. If it does have some imperfect interpretation in this case, I'd really like to hear it. And, regardless of what meaning it has . . . I think you really should label it somehow. For example, when reporting on a limp you could:
* Include an on-screen note that limps are not the primary use-case for ICMizer and all results should be taken provisionally.
* Hide the range bar entirely. Why present some meaningful-looking data if it is meaningless? You don't analyze limps, so you don't know how often someone should limp. All you know is someone did limp. Just show that and omit the range bar after the limp. (Maybe still include the on-screen note saying that replies to limps should be taken provisionally.)


Oh, also when you replied above you wrote "You're pretty much everywhere." What was it that you meant?

Hope the feedback is useful. Love the program, thanks.

Hey, I meant "You're pretty much correct everywhere."

Regarding the result that you're looking at, it is not just some artifact. It is the result of calculation where we compared the limp and fold alternatives given the BB has check and push alternatives & our way to assess postflop EV.

The range next to Limp shows limp range if calculated given limp/fold alternative. You can always use detailed result button to see the math behind the numbers on the 13x13 square.

The data is not meaningless if you know the way the engine works with it (Get details button provides a way to learn that). However, the limp case is not a default go to case for ICMIZER as I say.

Glad to help!