Notifications
Clear all
Please mail me at support@holdemresources.net and let me know what name / email you used to order. If you can, you should probably edit out the payment info above, not ideal to have this posted in a public forum.
Hi plexiq. I have been doing some work with the ICM multitable feature and I have come across some surprising results (at least to me).
For a standard structure with roughly 1000 entrants, where 128 get paid, I find that the calling ranges for the short stacks are extremely wide.
For instance, I have a 10bb on the BB calling 24.6% vs a BU 30bb 53% shove.
I would guess that in reality, assuming that there are many similar 10bb on average left on other tables, and the fact that doubling up when we are still so far from the FT is not worth that much more $EV than a mincash, that we would want to be way tighter and let someone else burst first.
This fact, combined with the fact of how fast the multitable calculation is performed, has led me to believe that this feature is not taking into account the probabilities of other players colliding at the remaining tables (I would assume taking into account all of the % of every possible player combination at every single table would take way more computation time).
Could you elaborate a bit on what exactly is taken as input information from the other tables to come up with the ICM multitable solution?
Thanks a lot in advance.
As far as I understand, HRC assumes that there's no play at all at the other tables while the current hand is taking place at our table, as if they were stalling, waiting for our hand to finish. So it underestimates shortstacks' chance of cashing after folding at our table. An emulation of hand-for-hand play would be indeed much slower, as it would require calculation of ranges at the other tables.
As mentioned by tonypmm, HRC treats the stacks from other tables as static for the course of the calculation. Note that ICM itself will still model collisions of stacks from other tables that occur *after* the current hand is played out, just not ones that occur during the hand. If you believe that the difference might be significant then simply enter the stacks from other tables as they would be at the END of the current hand, this would give you the correct results. In most cases the difference is probably negligible, unless e.g. the bubble is expected to burst on a different table while you make your decision.
As a side note: The MTT ICM mode in the beta version has much higher accuracy, it calculates ICM (Malmuth-Harville) values for the full prize structure and field. The old MTT mode in the stable version only runs an approximation on a compressed structure / field and is considerably less accurate because of that.
You can find more information about the difference in accuracy here:
https://www.holdemresources.net/blog/high-accuracy-mtt-icm/
In any case, if you are concerned about MTT calculation accuracy: Definitely use the latest beta! 
Thank you for your quick replies.
If you believe that the difference might be significant then simply enter the stacks from other tables as they would be at the END of the current hand, this would give you the correct results.
While I believe that changing the stack sizes in the way you suggested should make a tiny difference, the main component of the difference between the calling range given by the HRC result and the "ideal" calling range (the calling range that maximizes our $EV), should come from future game considerations that actually take into account all possible collision scenarios at all tables. While this is probably not feasible in a numerical way at the moment (at least for any reasonable length of time and processing power), it is not hard to arrive at the conclusion that the difference I just mentioned should be quite substantial.
I have no formal argument to prove my claim analytically, but I think the following example illustrates my point quite easily:
- Let's say the probability of someone else busting out of 130 players in the current hand (first bubble hand) is 50%. We probably don't need to go that many hands into the future to reach 99.9%, definitely under 10, probably even under 5 hands. If this fact is true, then the impact this should have in our calling ranges would be gigantic.
Now, how big is this impact, I have no idea.
Do you fellas agree with my assumptions? Do you have any idea on how to even begin to quantify all these factors?
What you describe is already modeled as part of standard ICM, this is included in the calculations.
Originally posted by plexiq
What you describe is already modeled as part of standard ICM, this is included in the calculations.
Do you mean the collisions at the other tables, the future game considerations or both?
It is also possible that I am confusing myself by loosely using the term "future game considerations". If I understood your last reply, you mean that since ICM is intrinsically assigning each stack a finish distribution based on it's value relative to the prizepool and the other players' stacks, in a way, the "fate" of that stack is already set, since assigning a probability of finishing first to the stack, entails that ICM is already "looking into the deepest future" of each stack.
Is that a correct way to put it?
I meant the collisions, right. ICM already assigns the probabilities for e.g. finishing last by looking at all stacks in the tournament, not just the ones on your active table. The chances that players are busting on other tables before anyone on the active table is eliminated are already taken into account by ICM.
(Note that this does not mean that FGS wouldn't be useful for MTT calculations to get better estimates for those probabilities. FGS would still be useful, like it is useful for regular single table calculations. Just not in the drastic way that you outlined.)
So if I got all this right, FGS only expands the ICM algorithm to include the extra factor of future interactions between each player's stack and the blinds, it has nothing to do with future interactions between players (although it will have an impact on the decisions), since this was already calculated by the standard ICM model.
For a long time I had the misconception that FGS was the responsible for including not only the effects the blinds will have on the stacks on future hands, but also for the future collisions among players in the following hands. If this is correct, does that mean that we should only worry about FGS when dealing with very shallow stacks?
Correct, FGS is indeed most useful for calculations with shallow stacks. The positions relative to the blinds play a big factor when stacks are short and positional information is not taken into account by ICM.
For other scenarios the difference between vanilla ICM and FGS is usually relatively small.
Ok, cool.
Also, is there an adequate Simulation Depth for every situation, or should we try to go as many hands into the future as we can afford?
I noticed that for SD = 1, if we have a shortstack on UTG 6 handed, it's recommended push ranges are drastically different between regular ICM and FGS1, since he is on the BB next hand. However, as we keep increasing the SD by 1 or 2, the shortstack range tightens up again, since he is relatively far away from the imminent BB danger. If we keep increasing the SD, will we get a cyclical result depending on the relative position of the shorstack to the BB or will it somewhat converge?
You should generally go as deep as possible within acceptable runtime. Results somewhat converge with deeper calculations. You will still see minor swings but they get smaller as the depth increases.
Please check settings at Window/Preferences/Tracker Database
как решить проблему? !
In the program menu, go to Window: Preferences: Tracker Database and check the settings there. Click the test config button to make sure everything is correct.
Originally posted by plexiq
In the program menu, go to Window: Preferences: Tracker Database and check the settings there. Click the test config button to make sure everything is correct.
Please select a database name first
Click on the button on the right side of "Database Name" and select a database. I'm wondering if i need to make the error messages more clear.
I'm having some trouble getting to analyzing hands 'from hand-history files'. Whenever I go into the option and press 'select files' the program crashes.
This seems like a really valuable tool to analyze a number of hands filtered out in PT4, so I would very much appreciate if there were a solution to this!
For the record I'm running HRC Sierra on Mac.
EDIT: nevermind, I can do it in the beta version.
After Little break i renew my License of HRC, now i try to Import my Hands from PT4 as usual ( paste raw @ pt4 --> paste to clipboard @hrc ) and it says, "No valid Hand history…"when pasteing from clipboard…
& when i import whole hand histories the programm imports somth invisible.... nothing Shows up..
please help. thanks.
Hand history Looks like this: "PokerStars Hand #204622220996: Hold'em No Limit ($0.01/$0.02 USD) - 2019/09/26 14:37:19 CET [2019/09/26 8:37:19 ET]
Table 'Regulus II' 9-max Seat #5 is the button
Seat 1: Feffermintee ($3.80 in chips)
Seat 2: StaNiUA ($3.45 in chips)
Seat 3: GuJane ($1.56 in chips)
Seat 4: flipber ($1.23 in chips)
Seat 5: effkay23 ($1.15 in chips)
Seat 6: Mangoop ($0.54 in chips)
Seat 7: Tamamne ($1.37 in chips)
Seat 9: dboogaart ($2.37 in chips)
Mangoop: posts small blind $0.01
Tamamne: posts big blind $0.02
dbromain666: sits out
HOLE CARDS
Dealt to Tamamne [9c Tc]
dboogaart: fo"
add: i reinstalled HRC once, checked for updates and didnt change anything else.
Can you paste the full history please, or send it to support@holdemresources.net, so we can check it. Partial histories are not supported.