hey!
i often see in minrase calculations that raiser has more offsuited hands in his range than suited ones. how can it be so?
example
here we see k9o kts. quite often i also see like a2o a8s. cant understand how is that, it doesnot make sense
These are hands that exclusively play raise/fold and never see a showdown, so the equity advantage of suited hands does not make a difference.
So it comes down purely to card removal against the re-shoving ranges. Offsuit hands have a very slight edge over their suited counterparts if the re-shoving ranges include the suited hand but not the offsuit one.
e.g.:
Minraise/folding K9o/K9s when the re-shoving ranges contain K9s but not K9o.
K9o and K9s have exactly the same card removal against all hands except against K9 hands.
K9o blocks 2/4 combinations of K9s.
K9s blocks 1/4 combinations of K9s.
K9o blocks 5/12 combinations of K9o.
K9s blocks 6/12 combinations of K9o.
This means K9s is slightly more likely to get re-shoved on, and K9o takes down the blinds a bit more often.
cool stuff thank you 
about card removal in push /fold nash and fgs calculation
1) when calculating equity prog knows that when i push ax opps after me will have less aces right?
2) if 3 opps before me folds and im on BU does prog knows opps on blinds are more likely to have good hands (since 3 folds mean they had bad ones overall)
1) Yes, this is correctly considered.
2) No, program still assumes "normal" distributions for the remaining players. Card removal due to folded ranges is ignored. (I don't think any tool doing full enumerations is considering the "card bunching" effect, it is extremely hard to do this efficiently.)
hey again
i dont understand calculations of cold call spots and limps, here is an example
hand
Grabbed by Holdem Manager
NL Holdem $20(BB) Replayer
Hero ($476)
BB ($496)
UTG ($538)
UTG+1 ($538)
CO ($486)
BTN ($466)
Dealt to Hero A♠ 4♠
fold, fold, CO raises to $40, BTN calls $40, fold, BB raises to $494 (AI), fold, BTN calls $424 (AI)
FLOP ($990) 6♠ 7♥ T♦
TURN ($990) 6♠ 7♥ T♦ 8♦
RIVER ($990) 6♠ 7♥ T♦ 8♦ K♠
BTN shows K♦ K♥
(Pre 71%, Flop 84.8%, Turn 84.1%)
BB shows J♠ A♦
(Pre 29%, Flop 15.2%, Turn 15.9%)
BTN wins $990
calculation
1) half of hands has more +ev diff then some of recommended hands
2) why so many hands are +ev here its very unlikely
3) why after my 3b shove there is no BB action (BB overcall) in action tree
As you probably know, postflop play is calculated as forced check-downs, so flat calling tends to be over-evaluated in the calculations. Always keep that in mind when having this option enabled.
1) In equilibrium hands are played with whatever action has the highest EV. Some of the +EV hands displayed in the 3-betting range have an even higher EV for flat calling, so they are played as calls.
2) Somewhat connected to 1). Since many of the +EV 3-betting hands end up as being played as flats anyway, the actually played 3-beting range is still fairly tight/strong.
You can simply lock the flat-calling range of the 3-bettor to 0% and re-calculate using Fictitious Play. This will probably leave you with a wider 3-betting range (>14.1%), but fewer +EV 3-betting hands.
---
3) All calculations are restricted to a maximum of 3 active players. After raise, flat and the 3-bet, this limit is reached and all remaining players are automatically folded.
As you probably know
i dont think postflop matters that much because this type of hands occures on first blind level t20 with 5-6 players still in game so my equity doesnot depend to much on stacksizes of others, its just too far to prizes.
1) In equilibrium hands are played with whatever action has the highest EV. Some of the +EV hands displayed in the 3-betting range have an even higher EV for flat calling, so they are played as calls.
thats was my first thought but after checking calling range diffs i dissmissed it. next time will check more carefully)
You can simply lock the flat-calling range of the 3-bettor to 0% and re-calculate using Fictitious Play. This will probably leave you with a wider 3-betting range (>14.1%), but fewer +EV 3-betting hands.
ye ok. but i still dont understand why cant you make this programm to understand hands) like if in hand CO raises and BU flats and im on SB why cant it just calculate this situation instead of calculating everything? =\ ye i know i can click "next" and make whoever i want to fold or raise or call, but why not automatically? 
3) All calculations are restricted to a maximum of 3 active players. After raise, flat and the 3-bet, this limit is reached and all remaining players are automatically folded.
ye ok but why? fourth player complicates calculation in geometric progression or what O_O i have no idea for example how much influence on the diffs my running into cooler on BB has
i dont think postflop matters that much because this type of hands occures on first blind level t20 with 5-6 players still in game so my equity doesnot depend to much on stacksizes of others, its just too far to prizes.
It matters for the evaluation of your flat-calling range though. The flats will likely be over-evaluated, which means less hands will end up in your actual 3-betting range.
ye ok. but i still dont understand why cant you make this programm to understand hands) like if in hand CO raises and BU flats and im on SB why cant it just calculate this situation instead of calculating everything? =\ ye i know i can click "next" and make whoever i want to fold or raise or call, but why not automatically?
Well, i suppose the played line could be pre-selected in the dialogs, but you will still need to assign the earlier ranges manually. (This would require some major changes to the parsers though, i currently don't have bet sizings available.)
The actual problem in this particular example is your flatting range though, you'll basically always need to set that manually. No way to automatically detect whether or not you are playing with a flatting range there.
ye ok but why? fourth player complicates calculation in geometric progression or what O_O i have no idea for example how much influence on the diffs my running into cooler on BB has
The calculations rely on pre-calculated results for all hand matchups. This data needs to stay in RAM and takes (very) roughly 0.25MB for 2-way, 50MB for 3-way and 10GB for 4-way. That's just too big for a typical client machine. And even with the lookups, unrestricted 4-way evaluations would still be a 1-2 orders slower than 3-way.
As far as i am aware, none of the ICM tools on the market offer full enumerations for 4-way pots.
i also wanted to ask about speed of calculation
when using fgs the calculation time is not too longer then just icm. its because fgs hands are calculated in restricted nash and the hand itself in unrestricted?
also i used simple nash calculator for two weeks the calculations there are really faster, like instant compared to several seconds in hrc. why is it so? sn support tells they also use unrestricted ranges =\
The difference between ICM and FGS-1 runtime is usually just barely noticable, but if you set the FGS depth higher you will definitely notice a difference. (All future hands are calculated restricted, right. Restricted vs unrestricted barely matters regarding overall equity changes, and we don't care about the specific hand selection for the future hands.)
Regarding the other calculator, what actions are you talking about in particular? The initial Nash calculation, or editing ranges?
If you need faster initial calculation you can try the linear/restricted initialization. (Note that this only affects initial ranges, the equity calculations are always at full accuracy anyway.) The last time i tested the unrestricted Nash calcs were of comparable speed in the two tools, but maybe you mean something different.
You can also try the latest beta update, it further reduces the runtime by ~35%.
i mean usual nash equilibrium without fgs and minrases and so on. it rakes several seconds in hrc but in simple nash all such hands were calculated instantly. ye i know i can set restricted, but simple nash support says they use unrestricted for this type of hands o_O
Can you give some more details please?
*) Rough details of CPU / RAM / Java version
*) Can you give some examples of hands you were testing, along with approximate runtimes?
Testing unrestricted Nash for 10-handed, 10bb deep with 50/30/20 payouts takes about:
*) 1.5 seconds on a 8 x 4.0GHz recent desktop
*) 10 seconds on a 2 x 1.4GHz old laptop (2008)
I'd expect your system to be much closer to the desktop, so we are probably talking about max ~3-4 secs for 10-handed, and much faster for shorthanded?
ohhh i ll make tests just for intrest but right now is a bad timing, im trying to play over992357829356 tournaments to get out of downswing faster 
i also dont have simle nash anymore so icant compare, probably smth is wrong with my system that was ok when i was using simple nash.
PC i5-2300 2.8 \ 8gb ram \win7 (about java not sure cause dunno whats that, there is some java 7 update 17 in program list)
hands all in 6max only. icant say exact time for exact hand without testing but it feels like 2sec+ at least which is much slower than instantly obviously)))
Hello,
I just noticed ranges in HU depend on payout structure. Can you explain why is that?
Thanks in advance.
heads-up of 18man
Blinds 600/1200 a75
sb 9595
bb 17405
for 40/30/20/10 structure it shows call with T8o -0.07 and for 50/30/20 -0.15
Oh. The diffs change of course, because they are relative the the total prize pool. But the ranges should stay the same regardless of the structure.
In 40/30/20/10 you are only playing for 10% of the total prize pool HU, at 50/30/20 you are playing for 20%. So all diffs will be 2x higher for 50/30/20, which seems to work out in your example.
i am unable to paste from clipboard hands from merge in my pt4 to resources calculator
Replied via mail already but as a reference for other users:
HRC only supports the original Merge XML histories, not the "human readable" versions that PT4 & co produce. I believe all trackers have the option to copy the raw history instead of the human readable one, this option should work with HRC.
For PT3/PT4/HM1 users the SQL import option is highly recommended instead of manual copy/paste though.
