2021 Public Beta: HRC Goes Postflop
Since our launch in 2012 HRC has been a tool focused on Preflop strategies when stacks are shallow, shining especially in those push-or-fold phases late into tournaments or sit-and-goes. In this beta cycle we branch out into deeper stacked play where flat calling and Postflop equity realization are important factors.
Our goal is to provide a complete Preflop/Postflop solver combination by the end of this beta cycle, fully integrated with our existing tournament features.
- Save/load support for Monte Carlo calculations.
- Monte Carlo calculations with Postflop equity realization.
- General performance improvements for the Monte Carlo engine.
- New Range editor with the option to bookmark/save custom ranges.
- New display modes for the Range Viewer component.
Planned for the near future:
- Simplified/improved handling of saved hands.
- Rewrite of the bet sizing UI to allow better customization of the game tree.
- Support for BB antes.
Expected later in the cycle:
- Graphical hand replayer with Quiz / Play Against the Solution capabilities.
- Extended Quick Analyze functionality.
- Dedicated Postflop solver and full interaction with Postflop strategies.
This version is for subscribers only. The beta version only accepts regular HRC licenses, trial users will not be able to participate.
The latest HRC beta can be downloaded here:
Only download this version if you are comfortable with testing beta features. This version may introduce stability issues and other bugs. Once the new features are sufficiently tested, they will be integrated to the stable version. You can run the stable and beta versions on the same system, simply use different install locations.
Postflop Equity Realization
This feature is the main addition of the initial beta version. In previous HRC versions any pots that weren't all-in Preflop were assumed to be checked down after the flop. Previously we advised against using limps/flatting lines, except for setting up previous actions. This new version introduces Postflop betting for Monte Carlo calculations. Calculations can now accurately model Postflop equity realization, even taking the various ICM/KO factors and full card bunching into account. This feature does not apply a static equity realization approximation but actually builds a Postflop game tree.
This means HRC can now calculate useful general purpose Preflop ranges for deep stacked play.
This feature can be found at the bottom of the betting setup dialog when selecting the Advanced Monte Carlo Mode. Explanations of these new settings are displayed as tooltips. Make sure to run additional sampling after the initial calculation completes by using the green Run Nash Calculation button in the toolbar, Postflop calculations require considerably larger sample sizes than a Preflop calculation.
The structure of the Postflop tree can be browsed in the regular strategy table. The table also shows the frequency of various Postflop lines being taken as an average over all boards. Board specific EVs or hand strategies can not be displayed at this time.
A note on Postflop positions: Hands calculated with exactly two players use HU positions by default: The SB is on the button and the BB is first to act after the Flop. Hands with more than 2 players use standard positions where the SB is first to act after the Flop.
How does this work?
Users familiar with Postflop solvers will be aware that solving Postflop trees requires an extensive amount of memory, especially when working with dozens or hundreds of different Postflop spots between the various players and Preflop sequences. HRC uses imperfect recall abstractions to make these calculations feasible with regular consumer hardware.
Instead of learning the Postflop strategies for each individual board run-out, HRC uses abstractions that place the various board/hand combinations into a number of buckets that contain similar situations. The solver no longer works out the strategies for specific hands on specific boards, but for groups of similar situations across a variety of boards. Conceptually the solver learns to play entire categories of hands e.g. "mid pair strong kicker on a low two-suited board", unaware of the specific hand/board combination that is currently sampled.
The number of buckets controls how nuanced these categories are. A lower number of buckets means more hand/board combinations are placed into each bucket. As more combinations are added, the combinations within a bucket become less similar to each other and details of the situations are lost. For example, reducing the number of buckets we may go from "mid pair strong kicker on a low two-suited board" to a more general bucket like "mid pair on a two-suited board". Eventually this sacrifices the ability to play individual hands correctly if the buckets become too general.
The main benefit of this approach are vastly reduced memory requirements and faster convergence. Strategies converge faster because the solver is generalizing over the various hand/board combinations within the buckets. Even if a particular hand/board combination shows up in sampling for the very first time, a sensible strategy may have already been derived from seeing similar hand/board combinations of the same bucket earlier. It's no longer necessary to process a large number of samples for each individual hand/board run-out.
In the initial version we provide abstractions ranging from as few as 64 buckets all the way up to 16k buckets. The first instinct of users may be to pick abstractions as large as possible within the available memory. We strongly recommend giving the smaller abstractions a try first, especially when only interested in the Preflop EVs and ranges.
Larger abstractions do have a higher accuracy ceiling: Given enough training time, the additional detail of the abstraction will allow for more accurate strategies. On the other hand larger abstractions generalize less aggressively, which means more training is required before reaching even a decent level of accuracy. When running quick calculations with limited sampling, large abstractions typically perform considerably worse than small ones.
It's important to mention that the raw number of buckets isn't the only factor for abstraction quality. Since hands within each bucket need to be played the same way, it's essential that only hand/board combinations that are strategically similar are grouped together in a bucket. Finding a metric that captures the strategic similarity of hands is actually fairly complex.
For example: When using the equity against a random hand as similarity metric, underpairs and weak draws can be almost indistinguishable on some boards. These hands would then be grouped together in the same bucket even though they are not actually strategically similar at all. Increasing the number of buckets wouldn't fix this general problem, this metric simply does not consider all important factors.
The abstractions used in HRC not only compare the equity of hands, but also how these hands realize their equity on future streets. We'll leave the details for another blog post, but interested readers can check the excellent 2013 paper by Johanson et al from the University of Alberta linked below for more information.
It is now possible to open saved hands in a quick read-only mode. Saved hands can be loaded almost instantly and only require very modest amounts of RAM. Hands opened in viewer mode will be marked as read-only [ro] in the hand tab.
This mode only transfers data that is required for display purposes and should typically need no more than a few MB, regardless of the total tree size. The process works transparently from remote locations, e.g. hands stored on a NAS, remote server or cloud storage. To load hands from a remote location, simply mount them into your local file system first. In Windows this can be done using the "Map network drive" option or by using various cloud storage clients.
When working with local files there should only be minimal delays when branches are expanded in the UI. For remote locations this can become more noticeable, depending on the connection speed and latency.
This mode is still highly experimental, please let us know if you experience any problems.
The range edit dialog now includes a new bookmark sidebar that can be shown via the collapse button in the bottom right area. This provides a way to manage ranges within the program, including full support for weighted strategies and options for importing / exporting of saved ranges.
The hand grid component now has two additional display modes to better visualize nodes with multiple actions. The strategies can be displayed as pie/bar charts using the new buttons above the hand grid. The color scheme is still temporary.
Increasing HRC's memory limit
By default the beta version of HRC uses a memory limit of 4GB, this also limits the size of trees that can be calculated. If you see error messages about "Insufficient heap space" or "Out of memory exceptions" then either simplify your tree or increase the memory limit.
To increase this limit, open the hrc.ini file from the installation directory in a text editor and look for the line starting with "-Xmx", the default should be "-Xmx4G" (4GB). Increase this setting to a higher value, e.g. "-Xmx8G" (8GB), save the file and restart HRC. The effective memory limit is displayed in the Postflop section of the hand setup.
Important: The -Xmx parameter tells the Java runtime how much memory it is allowed to allocate if necessary. Java will not check if other processes have enough spare memory. If you use -Xmx16G on a machine with 16GB physical RAM then you may experience severe performance drop-offs or crashes. Your overall requirements may exceed the installed physical RAM if Java tries to allocate the full 16GB, so the OS will be forced to either start swapping (slow) or killing programs ("crashes").
The suitable -Xmx value depends on the operating system and other programs running, but we'd recommend keeping at least 4-8GB of memory reserved for the OS and other tools. There's no significant performance benefit to allocating excessive spare memory, e.g. an 8GB tree will generally run at roughly the same sampling speed with -Xmx16G or -Xmx32G. Some rough guidelines for the maximum recommended Xmx values can be found below, you probably shouldn't go any higher than that.
|Physical RAM||Max. Xmx|
|8GB||4G - 6G|
You can monitor the live heap usage in the program by enabling Window: Preferences: General Performance: Show heap status. Make sure to restart HRC after changing this setting.
Upcoming: Subscription Changes
Some of the planned features go way beyond the feature set of classical ICM tools and cross over into the area of Preflop/Postflop GTO solvers. We intend to transition the Preflop functionality into a basic subscription tier and make some of the new features exclusive to a premium tier. Content that has already been available in the current stable version will NOT be moved into a premium tier, this is strictly for some of the new content.
For the duration of this public beta test all new features will be accessible for users with a regular HRC license (no trials). We currently expect the beta phase to run at least until Q4/2021, so there will be plenty of time to explore these features at no additional cost. But we'd like to make it clear from the start that some of the new content will require a subscription upgrade after the beta concludes.
We also haven't updated our pricing structure since the HRC launch way back in 2012 and some minor changes are overdue. We will be restructuring the subscriptions to be more in line with other products in this space. We intend to grandfather any existing subscriptions into the basic tier at their current pricing.
Please leave feedback and ask questions if anything is unclear! Any general feedback on the current and planned changes is appreciated. We are especially interested about your experiences with the new Postflop mode, e.g. unexpected deviations from other solvers, your favorite abstraction settings, etc.
Also make sure to report any stability issues or user interface glitches! We need to know about them before we can fix them :)
The HRC Support Thread on 2+2 is the best option for general questions, feedback and discussions of new features. Preferably contact firstname.lastname@example.org with bug reports or issues that may be related to your specific hardware setup. In these cases please try to include the steps necessary to reproduce the problem and ideally mention any special properties of your computer setup that might affect the issue.
We will also add a Discord server for the beta in the near future to make it easier to get in touch directly.
- 2021-04-22: Updated for Range Viewer changes.
- 2021-09-07: Added instructions for changing the memory limit.
- 2021-09-09: Added section for Viewer mode.