I have sent a savefile to following adresses:

- stoxpoker_ev @ hotmail.com
- crevflopzilla_spam @ hotmail.com
- contact @ cardrunnersev.com

Thanks for the help.

Scylla, probably the question was asked before but I would love to know if you have ever compared GTO+ simulation results to other solvers like Piosolver? I started to use GTO+ and thought the best way to start with, would be to simulate and compare results to some pots from RIO training videos where coaches used Piosolver. I ofc used identical ranges for this purpose.

But there is a quite difference between my results and the results of the RIO coaches (which would result in different strategies for the same spot). Since the tree builing editors are very similiar, I expect to have at least very similar trees but maybe not 100% identical (used same bet sizings, check raise freq., etc).

It would be really nice if you could provide a benchmark for a certain spot, so that people like me who are GTO+ newbies would now how to start to work with the software. The reason for that is that I can imagine a lot of people start to work with GTO+ by watching some training videos (where coaches mostly use Piosolver) and tying to replicate the simulations in GTO+ and get identical strategies.

I have simulated so far 4 spots from a RIO training video with GTO+ and the simulations show in some spots larger discrepancies, which results in different strategies than the coaches for RIO suggest.

Here is an example:

The Pio results are from a RIO training video from Mark Lammers:

Pio Tree

https://gyazo.com/a8aff3198711e3f568a8703c68938d2f

Pio result for Flop

https://gyazo.com/cde0f94edf7d1c04903fb720efe25270

My GTO+ tree for same spot

https://gyazo.com/2b80fe8951a23f9e287422409c2af5b5

My GTO+ result for same spot

https://gyazo.com/c7e736b1c54ac0194824150644edddf8

Please notice the significant discepancy OTF for the bet sizings and freq. between Mark Lammers and mine results. For me this looks like:

a) It is not that easy to replicate Piosolver trees in GTO+ and therefore maybe an instuctional video how to do this would be nice

b) or GTO+ leads to different results than Piosolver which would it make very difficult to study with

The results between the softwares will be the same if the trees are identical. This can easily be checked with GTO+'s "Basic" tree builder, which will build the exact same tree as pio's "Version 1.0 style" tab. When using the same tree you will get the same solution. Any differences in results will be due to the differences between the trees. You may want to check if all of the lines actually match to a decent extent though. For example, I notice that in your screenshot that for IP's river play in pio "Don't 3bet" has been checked. That means that on the river check-bet-raise will only result in a call from IP, even if he holds the nuts (I'm no expert on pio, but I'm fairly certain that's what it means). Another difference may be in the donk bet settings, which I unfortunately can not fully see in the screenshot. If you can send the GTO+ savefile to support, then I can check if there's a difference there. One more thing to consider is that when using multiple bet sizes, the difference in EVs in different bets are often very small, even if the bets are very differently sized. You can probably see this when comparing the EVs for several hands for the different sizes. A slightly different tree can easily cause a different configuration of hands being assigned to certain actions, at no significant loss in EV.

Yeah I see this. But nevertheless GTO+ uses quite often bet sizes with high freq. in some standard spots which should not be used even if the EV´s are "close". And deviates therefore in some cases stongly from nowadays theory teached by coaches, training sites, other solvers. The above example demonstrates this very well. A very standard spot were IP should check definetely more than just 20% and when he bets than 99% using a small sizing. Your solver is suggesting something completely different.

Without knowing which exact settings are used for both programs I unfortunately do not have enough information. If there are differences in the results, then I suspect that the trees are different, however I can not tell from just the screenshots. If at all possible, please include savefiles. Doing so rules out any chance of miscommunication.

Syclla, the nodelock funtion seems to doesn´t work properly for me. I have performed the following simulation:




The simulation results are fine. After that I´ve nodelocked OOP as following:




I decreased the check-raise freq. of OOP, so that he can only check-raise AK, A2 and 88.

After that I performed a simulation with the nodelocked OOP and got following results:




What happened to 88, A2 hands ? They are not part of OOP´s range (neither of calling, folding, check-raising) anymore. Not sure what GTO+ is here doing. I have send the files to the support mail.

Thank you for the savefiles. In the first file A2 and 88 were checked in OOP's first decision. In the second file, OOP now bets them. This means that they are no longer present in the check-raise line (you can't check-raise hands that you've already bet). If you want OOP to continue checking A2 and 88 then please lock his first decision as well.

Scylla

Thanks a lot, scylla. Did not see that OOP has a leading range. Makes sense ofc.

BTN open 3.5bb

BB 3-bet

BTN call







used 'with only two bets left, get the money in smoothly' option in turn and river, not in flop.

is there anything to fix?

thx for your advice

after get rid of the option - 'with only two bets left, get the money in smothly'

required qunatity of memory increased drastically, up to 5.71G

and took so much time to calculate, wow.

I had to stop calculating after 1387.95 sec.


[IMG]
[/IMG]

[IMG][/IMG]

my computer's cpu is 1230 v3, which has 8 threads.

If I want to study with GTO+ efficiently, should I buy 1950X or something??

Is there any way to directly import hands from DriveHUD into CREV for analysis? If not yet, can you try to work this into future versions? A lot of us are using DH on some US facing networks now and it would help us out a ton. Thanks.

Ok, I'll take it under consideration.

I don't see the problem.
Can you please tell me what I should be looking at?

It's not really necessary to use multiple bet sizes on the turn and river. All that we're trying to do here is estimate the EV performance for both players on all possible runouts of the board. Their overall performance will typically drop by only as little as 1% if you use single bet sizes instead of multiple bet sizes. Similarly, if stacks are somewhat deep, then the "Get the money in smoothly" option is a pretty safe selection. The money rarely goes in, and it's not necessary to spend a lot of CPU on all sorts of permutations of that scenario. If you can send the savefile to support for the 5.71G tree then I'll run some simulations with different settings for you. I don't expect to see much difference when using a simplified version of turn/river play instead of complex play.

As always: Most appreciated

with this option, there's only one bet size that i can choose in turn and river.

that was weird for me.

So, I tried again without those options for more accurate suggestion.

Then I could get all the betting option but it took very long time.

Is there no big difference between, the option's on/off??

In real game, we use multiple bet size in turn and river, don't we?

Thx for answer

That's very kind of you.

I sent the savefile through the adress 'support@cardrunners-ev-calculator.com'

Hasegi!!!

After calculating a GTO strategy, there is the combo tab with the entire decision tab that shows the pot, stack, how much to call, and the odds. Can you add a minimum defense frequency after a bet or raise? Yes, I know it's easy to calculate but I'd just like to see it instantly so I can compare it to what the GTO strategy suggests as I'm clicking through each bet and raise.

Minimum defense frequency it is not gto concept,particularly not on a flop I think.It is what part of your range has to defend .It could be lower,it could be higher than MDF.

Doesn't MDF also depend on villain's bet sizing and range?

Ok, thank you for sending the savefile.
See here for a link for both your own savefile, and simplified versions of it that are solved far more easily:
www.crevfiles.com/crev/forum/1/processed.rar

How to measure performance
In order to compare the different files, we'll first need to know how to measure performance, so that we can see how much of a disadvantage is involved in using only single bet sizes on the turn/river as opposed to complex play. Measuring performance for the entire tree is actually very straightforward. For this, just go to the very first decision in the tree for OOP and check his EV. That's how much his entire strategy is worth. See below for the performance for OOP in the complex tree that you sent (3BPot BTN 3.5 vs BB Ts9s6x.gto), that needed about 6GB of memory to solve. Apparently, this value is 11.20.



3BPot BTN 3.5 vs BB Ts9s6x_OOPs.gto
Now, what would happen if instead of complex turn/river play, we were to replace OOP's turn/river strategy with strongly simplified play. For this, I will go as far as giving him a single bet size of 65% for the turn/river, with the option "Get the money in smoothly" ON:



If we solve this tree, we see the following.
This is rather surprising, given that by any logic we would expect OOP to be at a huge disadvantage versus IPs complex turn/river play.



So, apparently OOP's EV has only dropped by as little as 12 cents.
This is only a drop of about 1% in the overall performance.

3BPot BTN 3.5 vs BB Ts9s6x_IPs.gto
Similarly, if instead of simplifying OOPs play, we simplify IP instead we only see an increase to 11.37, or in other words if IP were to give up his complex play for the favour of simplified betting, he only loses about 1.5% in performance.



3BPot BTN 3.5 vs BB Ts9s6x_IPs_OOPs.gto
For the _IPs_OOPs savefile, I have created a version of your tree where both IP and OOP use simplified play on the turn/river. The flop play, which is what we're interested in, is kept the same. This tree will only require 500MB to solve, which can be done within a few minutes. Below we see the frequencies for OOP (left for complex, right for simplified), which apparently are not strongly affected.



And here are the two matrices for OOP.
On the left is the one for complex play, requiring about 6GB, and on the right simplified play, requiring only 500MB:



So although using multiple bet sizes does indeed accomplish a very small increase in the quality of play, even strongly simplified turn/river play will lead to almost the exact same results. If in the simplified tree either IP or OOP were to use complex follow-up play instead, their increase in EV would be marginal at best.

The importance of bet sizing
For the simplified play so far I have used 65%, which is generally a fine default bet sizing to go with in the case of single bet play. A question that might arise though is how important this sizing actually is. For this, I have created the file multiple.gto. This is a database file, similar to 3BPot BTN 3.5 vs BB Ts9s6x_OOPs.gto. The difference being that it tries out different default bet sizes for OOP, namely 50%,60%,70%,80%,90%,100%. If in the database report we compare the EV performance for OOP for the different sizes, we see the following result:



So, apparently, bet sizing barely has any influence at all on the performance for a player. You can get away with betting anywhere from 50% to 100% without any significant loss in performance. It appears that it's more important how you play, as opposed to which bet sizes you use. Also, using multiple bet sizes does not seem to give a significant advantage in GTO play (of course, in practical play exploiting your opponent's weaknesses with different bet sizes is a different story).


For the purposes of the simulation it's not necessary to simulate every part of the tree with the same level of attention. It's somewhat like the graphics in a computer game. When standing 3 feet away, you can see individual leaves of grass and an insect walking across a leaf. But this is only for things that are close to you. Objects at a large distance don't require the same detail. So high complexity is only required for the parts that you're looking at. Similarly, if you're interested in flop play, and are only using the turn/river play for finishing up the tree, then using basic play is sufficient for this remaining play. Also, if stacks are deep, the option "Get the money in smoothly" will save a lot of memory and time as well. In deep stacked play, the money only very rarely goes in (about 1% of the scenarios). That particular scenario does not require as much simulation time as parts of the tree that are reached far more often.

really awsome!!

So, if I want to study flop play in detail, that's a very terrffic option for saving time and resources, without any significant difference, right?

I think it's a huge advantage against other solvers(ex piosolver).

We don't need a high-end cpu, we spend much less time, as well as less money!!!

Thank you for all the researches for me, really appreciated.

Problem is do we know villain's range like 100%?As Scylla explains bet sizing doesn't improve our overall EV if villain plays optimal.

Hello, I try to use CREV for obtaining info about profitability of my push in spins BBvsBTN (when SB folds). So basically, I try to do with crev what icmizer does. However, when I setup tree and perform EV run, my results are different each time. When I use icmizer results are always the same. Can you please explain why is not the same when using crev? I remarked that this situation happens only when I preform 3 handed tree EV calculation. For HU push/fold situation the results are always the same (similarly like in icmizer).