I purchased CREV sometime prior to 2010 and re-purchased it very recently to gain access to GTO-plus. Great software! I had purchased PioSolver for $500 and the products are very comparable. CREV will only get better.

Is it possible to add a feature that allows you to edit the GTO tree to force one player to take certain actions with certain hands?

For example, on a specific Turn branch perhaps he will only call a bet with TP or better.

PLEASE make it easier to have predefined preflop ranges in GTO+

This would enhances the software so much better.

Would anyone be interested in starting a GTO+ skype chat (same as PIOsolver and Monkersolver)

We haven't gone so far as to display the turn here. The problem is that the further you get away from the root, the less relevant the information becomes. The first 70.4% value is still relevant, given that player 2 always reaches that decision 100% of the time, and his betting frequencies can simply be added.

The 17.1% for player 1 after that is already substantially less interesting. Let's says that you have 10 flops, where player 2 has bet the following frequencies: 54%, 60%, 65%, 75%, 80%, 82%, 84%, 88%, 90%, 92%. The 17.1% number has been obtained by adding the frequencies for player 1 for each scenario for player 2's bet. And each scenario is for a different frequency, and therefore a different range. It comes down to adding apples and pears. Although mathematically speaking a value does indeed roll out, the number itself has reduced meaning.

Doing the same thing for the turn is even substantially less useful. A number will indeed come out of the calculation, but it consists out of values that have been obtained under vastly different conditions. By the time you get to the turn the information is so diluted that these numbers don't actually mean much anymore.

It's already possible to edit decisions, lock them and re-run the solver. For a demonstration, watch the first video here: http://www.cardrunnersev.com/gtoplus.html

This has already been written, but due to me having the flu recently, and us currently working on some other things, we haven't had a chance yet to release it. I expect to get to it next Sunday.

But if you think how those frequencies can be compared to opponent/pool HUD stats to gain insight into where people play differently than solver, you'll realize how valuable that info can be and why this feature was requested a few times already.

I realize that you can easily edit Flop decisions by locking them in this manner, but (correct me if I'm wrong) to edit Turn decisions, you need to edit each Turn card individually (and the same with Rivers...which would take hours).

If there was a way to edit all Turn (and/or River) cards simultaneously this would allow a quick method of modelling opponents' Turn and River play.

While this method wouldn't result in ideal opponent modelling for every Flop, it would be more practical than setting each Turn/River card individually. Perhaps a rules-based system could be used to break Flops down by type so that different absolute hand strengths would be played on the Turn/River for different board textures.

This was just a thought...I know that it would be a massive amount of work (especially the latter half).

Hello, could you answer some questions please? Thanks in advance.

1) My number of threads is on maximum but CPU usage is never over 30%. How I can increase it?
https://gyazo.com/b5bac05f371eb3ee29f076c9e738d573

2) Could you please take a look and explain (from the side of your program of course), why does CREV provide (or may provide, if we're talking about algorithm in general) different results from HRC? Here is a simple push-fold situation:
https://gyazo.com/8d3b8e0b7009be9f4ec3a4de826ee262
And here is the results: https://gyazo.com/c3ccfbb778881b12200b6ad620426ca5
I've made a lot of attempts with different numbers of simulations in both programs (including very big ones) and the results are always noticeably different (in the same time HRC and ICMIZER provide identical results).
Any help (explanation, links...) would be welcome.

The monte carlo engine isn't multithreaded. The math engine and the GTO solver áre multi-threaded though. We can consider multi-threading the monte carlo engine as well, but at the moment this is not available.

CREV offers an enumeration-based math engine for heads-up spots and even as much as a GTO solver for postflop play. For multiway spots or play on unknow boards it offers a monte carlo engine that bases its results on performing a large number of simulations. The great advantage of the monte carlo engine is that it always works and can be applied in any spot. So, for example, it can figure out the effect of card removal of 8 players folding prior to a SB vs BB spot. Or for complex spots with play on unknown flops. Basically, the great thing about the monte carlo engine is that it's general purpose and can always be applied to any spot. A disadvantage is that it may take some effort in interpreting the results, due to these results having been based on simulations as opposed to enumeration. In the pic that you've posted the ranges seem to actually match when it comes to hands being +EV or -EV. However, the values for individual hands will be slightly different due to them having been based on monte carlo. This is simply the nature of basing results on simulations. The great advantage on the other hand is that due to the open-ended nature of CREV, it can be applied to a much wider variety of spots than just basic push-or-fold ones. In the end, CREV is different software from the products that you've mentioned, and it has a different purpose.

Oh, I see. The thing is that you said "For example, on a specific Turn branch perhaps he will only call a bet with TP or better.". So, I assumed that you meant for a specific turn coming off.

This is already available in CREV, where you can enter specific conditions and lock them. We can consider adding this for GTO+ at some point as well. The thing is though that this would take some time to develop, and we need some starting point for GTO+ to begin with. The alternative of adding all possible features prior to release would push back the release date considerably.

Thank you very much for the response, scylla.

Yeah, actually push-or-fold spots with the effect of card removal for 9max are that reason why I'm looking into CREV now instead of the products I've mentioned.

Yeah, I understand what you mean. Although in the posted pic the ranges do not completely match unfortunately even when it comes to hands being +EV or -EV (98o, J6s, T6s on the pic). And as you said yourself it's just a basic push-or-fold spot. Very simple indeed, only 3 players. There would be a lot more differences if I construct the spots which I'm interested in.

So I'm confused what I am supposed to do in that way. I mean how accurate would be such monte carlo results with the effect of card removal and how much I can count on them if there are noticeable differences even without the effect and in a situation with only 3 players involved?

Yes, I realize this would require a massive amount of work. If you could keep this in mind for later upgrades, that would be great.

Perhaps (when you get to it), you could allow importing the tree into CREV. I'm not sure of the inner workings of your software and how different that would be. ThanX!

When using the monte carlo engine to look at the effects of bunching, the borderline hands will never completely match up, precisely because they are so close to 0. So the error that is inherent to monte carlo simulations can always switch a borderline +EV hand to -EV, or the other way around. Interpreting results derived from monte carlo can be a bit tricky, and in some cases there can be too much scattering to do so effectively. However, you really don't need every single hand to match exactly in order to tell to a decent degree of accuracy what a range should be. The thing about borderline hands is that, precisely because they're so close to 0 EV, they have no significant influence on the winrate. If you're looking at the effect of bunching in multiway hands, then you should usually be able to tell if the range should be tighter, looser or approximately the same as without bunching. However, you are correct that when it comes to bunching in multiway spots, the results will not be absolutely crystal clear and some effort may be required in interpreting the results. If it's important to you that every single hand matches, then this is something that we can not offer you.

We can always keep it in mind. However, one of the great things about GTO is precisely that it can take care of the play on unknown turns/rivers for you. Play on the roughly ~2500 possible river runouts in particular can be very difficult to define manually, with defining play on the 49 possible turns also being quite a challenge in itself. The errors that some users will make in this input will likely outweigh any benefit that can be gained from it.

There's some significant differences in the storage of data between the programs. For a start, GTO+ does not store rivers (there's no need; they can be recalculated on the fly). This reduces savefile size considerably, as well as the software's memory requirements, however, CREV does require this info, so this alone would already create challenges in exporting trees to CREV.

Is there a way of locking subsets of hand types when looking at ranges? So for example, I know I can right click on 'no made hand' to lock it and then hover over 'non flush draw hands' etc to look at that subset. What I'd like to do though is also be able to lock the 'non flush draw hands' as well so the grid etc is locked to non made hands that don't have a flush draw.

Just realised I can lock a subset on the table of cards on the left by pressing F9 while I highlight one but I can't lock the grid for it.

Basically I'd like to check things out by looking at the card grid and also be able to tell, for example, what % of hands are bets that are non made hands with no draws (flush draw, oesd or gutshot)

Hey, I want to buy crev but I have a 32 bit system, do you have a link for 32 bit?

You can right-click a stat to fix it.
After that, you can mouse over any other stat to see the overlap.

Here is a link: https://s3-us-west-2.amazonaws.com/c...v334_32bit.msi

Please do note though that a 64bit system is highly recommended. The problem with 32bit systems is that they can only assign at most 1.5GB of memory to any program. Beyond that it will crash. So, if possible, please upgrade to a 64bit system.

The same will apply to GTO+. However, GTO+ has been specifically written to be far more memory efficient, and you should be able to run just about any reasonable tree with it, even with the 1.5GB memory limitation. For a 32bit version of GTO+ please go here: http://www.cardrunnersev.com/gtoplusdownload.html

Yeah I've got that but I want to fix the overlap as well

I'm having some trouble interpreting displayed EV.

I ran a CO vs. BTN scenario in GTO+ on Ts4s3h.

The Pot size is $6.50 with 5% rake, bringing possible winnings down to $6.175.

Prior to the first decision point, EV is displayed as "2.76". This is OOP EV for the entire hand, correct?

If OOP checks (he does so 89.7%), then the next node displays an EV of "3.04". This is for the IP player, correct? And this would be the best possible EV line (to this point in the tree) for IP.

Here is my problem: OOP checking range is weaker than his betting range (when OOP bets, IP has EV of "2.09"). Yet, if we add together OOP's EV for the entire hand and IP EV when OOP has checked (which is his best possible EV), we get 2.76 + 3.04 = 5.80, which is less than the pot size.

I'm a novice at this, so I'm sure my thought process is incorrect somewhere. But after OOP checks, his EV will be LESS than the first node's EV (since his range is weaker), so at this point, IP ought to have at LEAST an EV of $6.17 - $2.76 = $3.14. And this is if OOP EV remains the same at this node (after OOP checks).

Ok, I'll see what I can do.

Yes, if I understand you correctly, then this is indeed the case.


This is actually calculated differently.
See the example below.


IP's performance in the entire hand will be the weighed average of all lines taken by OOP. See the pic below for an example. Here OOP bets 25% of the time and checks 75% of the time. IP will have an EV of 9.82 in the "Bet" line and 16.16 in the "Check" line. That makes IP's total EV 25%*9.82+75%*16.16=14.575.

So OOP's total EV is 15.42, and IP's total EV is 14.575.
The sum of these EVs is 15.42+14.575=30.
This is exactly the pot, which is what the two players were playing for.

You should find a similar result in your tree, only with the sum being a bit less than the pot due to rake. I would expect it to be a bit less than the 6.175 that you predicted due to money going into the pot in some scenarios.

Awesome. Thanks!