You are having problems with the PKR parser too? Did you update to the latest Beta version already?
Beta activation:
http://www.holdemresources.net/h/products/hrc/beta-repository.html
You are having problems with the PKR parser too? Did you update to the latest Beta version already?
Beta activation:
http://www.holdemresources.net/h/products/hrc/beta-repository.html
I'm having the same problem with all sites. I click the paste button and nothing happens.
What site, and how do you copy them? Directly from the HH or within HM/PT? There appear to be some changes to the copied format in PT4 lately, please try to copy directly from the HH.
Also, is there no message at all, or a "not supported" error?
If you are using PT4, i'd recommend using the SQL import for now. You can mark the hands in PT4 and then import in HRC using the "marked hands only" filter.
Please also send me a few of the histories via mail to helmuth@holdemresources.net.
Hello,
Feature request:
Would it be possible to define range in such a way to exclude certain hands from it? We edit range by removing some hands and range goes half-locked (hands removed), half-flexible (algorithm finds best hands with max EV for hands untouched).
Definitely an interesting suggestion, i can see how that feature could be very useful for some calculations.
I'll have to think about a way to integrate this without complicating the basic use cases.
Hi there,
I am playing 2.50$ sng's and i am trying to evaluate my hands with the resources calculator.
I'm able to import my hands from the pokertracker 3 database but when i try to analyse, the software needs a payout structure.
I am able to insert a structure for example from the 1st place to the 10th place, but how can i insert a range like 10th - 18th place : 3.89$?
Also, does the software know how many people are still in the tournament ? Or does it assume the hand is played on the final table ?
Also, does the software know how many people are still in the tournament ? Or does it assume the hand is played on the final table ?
It assumes the hand is played on the final table. This also means you don't need to enter 11th-18th place at all, the only difference this makes is that the EQDiffs will be displayed as % of the final table prizepool, instead of % of the total pool. But all the ranges etc will be exactly the same.
If you want to calculate hands before the final table, you can use an artificial payout structure to approximate the bubble factor.
For an example, see:
http://forumserver.twoplustwo.com/showpost.php?p=43587168&postcount=889
Full thread with more info:
http://forumserver.twoplustwo.com/168/free-software/holdemresources-net-beta-feedback-832260/
I have another feature request - additional raise size. I think it would be very useful in situations with high bubble factor (on the final tables).
Currently players can only do a min-raise or shove all-in but there is need for 3rd raise size where player moves almost all-in (for half stack) and have the option to make a fold if there is severe action behind him.
Originally posted by plexiq
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.)
There is SimpleNash calculator which does card removal for last 3 players. They implemented also simulation option (monte carlo?) to look for EV.
Currently players can only do a min-raise or shove all-in but there is need for 3rd raise size where player moves almost all-in (for half stack) and have the option to make a fold if there is severe action behind him.
This will be added, was already mentioned a few times itt i think.
There is SimpleNash calculator which does card removal for last 3 players. They implemented also simulation option (monte carlo?) to look for EV.
Yeah, i can see how it's definitely possible for the last 3 players. Does not strike me as very interesting though, in reality this just accounts for a single folded range, right? ie BU folds and then you have the modified SB vs BB play.
Especially with relatively wide BU Ranges, it would surprise me a lot if this has much effect on the results. Monte Carlo mode is more interesting imo.
Originally posted by plexiq
ie BU folds and then you have the modified SB vs BB play.
actually BU push range is also modified (BB will contain more Ax in his distribution when SB has folded?)
Please implement simulation mode, it may be cool feature for raise/3bet game for 9 handed tables !
True, i forgot about the BU push / SB fold scenario. My point still stands though, a single folded range is generally not going to alter the results much. It's when you consider a full table folding to the BU when things get more interesting, but that's simply not feasible to do fully enumerated.
(Supporting folded removals for the 3 last players is a bit of a special case, itcan make use of the existing lookup tables for 3-way allins. But that approach doesn't easily extend to 4+ players.)
Simulation mode will be interesting for quite a few scenarios, i completely agree! Multiple raise sizes mentioned in the last post will likely be first though, i actually wanted to add these a few months back.
What do you think to implement simpler version of calculation with card-removal effect. Instead of th whole tree (which indeed is super tough) calculate equilibrium only for one position with folded ranges defined by user (or inherited from normal nash ranges).
For example:
9-handed game where UTG to CO folded and their's pushing ranges are defined.
Then equilibrium is found for BU to BB (for skewed range of BB when BU pushes and SB folds?)
Using simulation mode, calculating Nash for the whole tree is perfectly possible. I do have this prototyped already, it's mostly a matter of adding the simulation mode to the user interface.
I don't think full enumerations are feasible, even if it's just BU-BB with locked folding ranges ahead.
Hi,
Our goal in poker is always to maximize hourly win rate. In HU cash games usually it means maximizing stack size and playing every hand as profitably as possible (cEV). Hovewer, in the tournaments we should maximize chance of winning (winning percentage).
In tournaments if we expect to win more often than our opponents it becomes correct to pass up small edges. But if neither player has a skill adv. over the other then win-rate play is to maximize $EV (in particular cEV when there is no ICM involved). Along with exisiting indicators (gain of the prize pool, gain in BBs) HRC could adopt another one called 'Expected Win-rate Gain' for hand H (EWG) for particular action (shove, call, 3-bet shove, min-raise).
Let's consider HU push/fold match with 10bb for each player as the easiest example. We are in the SB deciding whether to push or fold. First we have to make assumption how our winning percentage over the opponent differ (edge, E) than is simple result from stacks and payouts (ICM equity). E is given when stacks of all players are equal. For HU game formula for calculating EWG is:
EWG = 'Expected Winrate when hand shoved' - 'Expected Winrate when hand folded'
EWG = EWS - EWF
When SB folded EWF is the winrate at new stack size and equals 2*(50% + E) * (9.5/20). For the final tables with more than 2 players other than WTA this will be ICM equity at new stack size + E'.
EWS = (1 - C) * EWSf + C * (W * Ww + L * Wl + T * Wt)
C- calling frequency of BB (depends on hand H)
EWSf - winrate at new stack size when SB shoved and BB folded
Ww - winrate at new stack size when SB scooped the pot
Wl - winrate at new stack size when SB lost the pot
Wt - winrate at new stack size when SB tied the pot
W, L, T - win, loose, tie freqeuncy
Calculating this for E = 0 we can see that SB win-rate maximizing actions follow chipEV.
Idea here has been taken from Will Tipton's book HUNLH2.
Hm, i'll have to look into this in more detail. It sounds interesting and is probably not very hard to implement (apart from the user interface aspect).
Hello,
A few days ago PKR released a new upgrade to their site and because of this programs like HM2 stopped importing the Hand-histories which has been solved already. The problem is now that when I am trying to copy from my HM2 to HRC it says that no valid hand-history is found. I do not know if PKR have changed Hand-history formats(at least I cannot really see the difference now) but that seems to be the case since I cannot 'copy from clipboard' neither when I copy from HM2 or directly from Hand-history files.
Every HH older than 28th of July does not import.
Please send me a few of the new HH's to helmuth@holdemresources.net, it's most likely just a minor change that they made to the format. I'll try to get a fix for it asap.