Oh, so basically the difference in solving times is a few %?
That's to be expected, given that Windows will need resources for other programs as well.
So there's a random element in the solving times.
The path that the solver will take will be exactly the same throughout each solve though.
This is one of the advantages of v132.
So, in your screenshots, all solves are finalized at the exact same solution at a dEV of 0.205.
This is very advantageous, given that in case of issues, we will be able to exactly reproduce a solve.

Ah, yeah. That makes sense. And yep, this a very good feature add. The difference is always +/- 5% tops, so it's basically nothing.

On this note, there's one other thing that I had a doubt about that I hope you can clear up:

I ran a database solve, BTN vs BB 100bb SRP. I forced OOP to check on the flop and gave IP two bet sizes: 33% and 67%, or a check. What I wanted to do was see which flops were the ones where I could simplify to have IP betting his entire range for 33% pot with an EV loss of <1% of the pot.

My question is this: I had initially solved all flops in the database to 0.5%. Since I'm looking to compare the EV of betting range with the optimal solution, the differences often times are pretty low, many times <0.5% of the pot. Is it logically correct to just solve down to 0.5% dEV even in the nodelock, or should we choose a lower dEV, say, 0.1%?

For example: In the database, solving down to 0.5% on A83r, IP bet 68.5% for 33% pot, and checked the remaining 31.5%, never betting with the 67% sizing. I got an IP EV of 36.76 in a pot of 59.

I re-ran the spot again, now solving down to 0.1%. IP bets 69.9% for 33% pot and checks the rest of the time, never betting with the 67% sizing. Got an IP EV of 36.77.

I then ran a nodelock on this flop, having IP bet range for 33% pot. Solved down to 0.1% and got an IP EV of 36.43.

Since measuring EV loss is in comparison to the EV in the optimal solution, should we want to do so with both solutions at the same dEV and preferably a low dEV? Or does that not matter much at all? I just need to solve the nodelock to a low dEV?

EV is one of the first properties to converge.
So it will make almost no difference which dEV is used.

Hey Scylla,

A question about the default flop subsets.

In the 163 flop subset, If I sort by rainbow unpaired flops, it gives me 50 flops. If we look at the 1755 strategically different flops possible in Holdem, only 286 are rainbow unpaired. Which is ~16.3%. In the 163 flop subset, 50 being rainbow unpaired means they add up to ~30.7%. I have to assume that the internal weights attached to each flop will make sure that the overall frequency/percentage of occurrence will closely resemble that of the full game?

I actually went ahead and checked this in the other default subsets provided down to the 33 flop subset, and these were the numbers I got:

163 - 50/163 = 30.7%
141 - 42/141 = 29.8%
129 - 40/129 = 31%
111 - 34/111 = 30.6%
89 - 28/89 = 31.5%
80 - 24/80 = 30%
66 - 20/66 = 30.3%
55 - 16/55 = 29.1%
44 - 14/44 = 31.8%
37 - 12/37 = 32.4%
33 - 10/33 = 30.3%

The numbers are all pretty close, which means that something about how I'm thinking about this is wrong. What is it?

I just did a manual calculation using combinatorics to see what are the odds of being dealt a rainbow unpaired flop, and it's 31.06%, which is the number that you're trying to approximate in your subsets. This means that the weights for individual flops have nothing to do with this.

Is it just that even though only 286/1755 strategically different flops are rainbow unpaired, in the whole game that is 22100 flops, rainbow unpaired happen far more frequently?

One other question:

On the GTO+ site in the subsets section (https://www.gtoplus.com/subsets/), there are 2 graphs that compare the average errors between GTO+'s subsets and Pio's.

In the 2nd graph, the error is compared between overall EV. But in the first one, it simply says error, but not what the unit/statistic it is that we're measuring the error of. What is this?

I seem to remember that it's the square root of the sum of squared deviations in EV.

The internal weights in the subsets have been designed to correct for certain types of boards being over/under-represented.

Hey Scylla,

Can you add the 'RIGHT-CLICK TO FILTER FOR THIS STATISTIC' option when viewing ranges of specific actions, too? Right now I can use it when looking at the entire decision, but if I'm looking at just the calling range vs a c-bet, and I wanna filter for all hands that are 2 card BDFDs, I can't. I'm a little surprised that this option isn't available for all options since it's useful, pretty commonly used I'd say, and implementation seems trivial. Were there any specific developmental/interface reasons for why this wasn't implemented?

I believe that there was a reason, although I don't immediately recall it.

Would be nice be able to make a subtree solve. Like chop a tree from a certain point and have the ranges and stacksizes board cards and remaining tree as the starting point so we can quickly add or remove turn and river bets and nodelock stuff.

I often want to do stuff like nodelock a situation like c/r in srp maintaining villains cbet range and my c/r range but editing villains response one way or the other. I know his response will change my strategy otf, but It's too hard/computationally expensive for me to do this for each villain type.

So like instead of solving for a max exploit in this case im just trying to see what my strat is after I play ''correctly'' and villain makes a mistake.

Also if we nodelock flop would be nice to be able to click solve from there

Subtree solves are actually possible right now.

Just make sure you don't overwrite the nodelocked solution on the original solve, or you'll lose it. So it's best to create a new savefile with a different name and then proceed with nodelocking.

If you want to nodelock on the turn, just do whatever nodelocking you want, and then to recalculate, click the small circle shown below:



And if you want to edit the tree from the turn onwards, like add or remove certain actions, then use the edit tree option shown below:



Basically, at any point, if you want to solve with changes made to turn and river but have the flop solution intact, use the small circle. It's also available on the river just as it is on the turn.

In the gif below, I show how to add an extra turn c-bet sizing for IP after a flop c-bet and call. IP only had 67% and 150% turn c-bet sizings after a flop c-bet of 33%.



<< Also if we nodelock flop would be nice to be able to click solve from there >>

Not sure what this means. Are you trying to say that you'd like to the solver continue solving instead of starting from scratch with the nodelock? I don't think that's possible. If you lock certain decisions, then solver needs to be able to figure optimal from scratch again with the given constraints.

Is there a way to save an edited tree to use it with different ranges (obviously stack size/pot would have to be the same)? If I build a tree, then use the edit tree feature to make changes to it, how can I go about using the edited tree elsewhere?

There isn't a direct way to save an edited tree as a profile. But what you can do is create a savefile with the edited tree, and then whenever you want to solve with different ranges, just open up the file and make whatever changes you see fit. For saving stack size/pot and rake settings, there's a store option as shown in the screenshot below:

Would you consider adding this for future releases, or maybe give some more information as to why not? Thanks.

One other thing: How exactly do people go about getting benchmarks for GTO+ solving speed on their systems? Up until now, I've tested by manually solving a given tree with different versions of GTO+. But is there a standard benchmark tool or something?

And a feature request: Can you implement hotkeys to navigate turns and rivers? Something like Pio has - Ctrl + up, down to change ranks; Ctrl + left, right to change suits. And similarly, Ctrl + Shift + up, down to change ranks for the card on the previous street (so for turn when we're on the river), and Ctrl + Shift + left, right to change suits for the card on the previous street.

I think this is something that doesn't clutter the interface at all and actually makes browsing solutions and learning strategy patterns a lot more intuitive and easier. As of now, we need a lot of clicks for every change in turn/river card, so this would be a big boost.

Let me know what you think about it.

For the moment, you can use the editor to make changes to the turn/river and use the "Resolve" icon to only solve that turn/river line again. Using the editor to make changes to the bets on the turn/river will maintain the flop solution after clicking "ACCEPT CHANGES".

For this:
1) Load the edited tree
2) Make any changes to the ranges/board/etc that you like
3) Go to "Build tree"
4) Go to the tab "Rebuild"
5) Click on "Rebuild with current settings"

I think that the easiest way is to just recalc the same tree with different versions. And possible use a number of different types of trees (deep stacks, shallow stacks, with rake, without rake, cash game, SitAndGo, etc). Any benchmark measurements will have a ramdon element to them; there's probably not much to be gained from formalizing the process.

This can be tricky, given that if "Basic" storage is used, a recalc is required for every line switch.

Yeah, I wanted to say that this feature would only be available for solves that were stored using extensive storage, because like you said, it would otherwise need a recalc for every line switch.

You can implement it for basic storage as well, but users having to wait for recalc. And this shouldn't really be an issue since on basic storage, viewing different turns and rivers already requires the user to wait for recalc anyway. So it's not like it's taking any extra time. Instead of manually going and changing the runout and waiting for recalc, you give users an option to directly switch and wait for recalc.

Is the implementation of such a feature code/time intensive? It seems trivial enough to me, but I don't know how the back-end stuff works and if this would be a challenge to implement.

Another question: When we solve to a certain dEV that is low enough (say, 0.5%), where does most of the exploitability lie? My intuition say it would be on the river.

In other words, say I solve a BTN vs BB 100bb SRP to 0.5%, and then manually resolve every river to a very low dEV, say, 0.01% (I know this isn't practical, but it's just a thought experiment) - would I see an decent enough change in the overall exploitability?

That actually reminds of something I wanted to ask. Say we make some changes to one of the players' ranges at different points within the tree, while keeping the other player's ranges intact for all decision points - is there any way to see how exploitable this would be?

This is actually a useful feature because it would allow us to see how exploitable a certain deviation would be vs a max-exploit. This is something that's available in CREV, AFAIK. Would it be difficult to add this to GTO+? I don't want to see what the max exploit strategy looks like; just how exploitable the deviation would be in % of the pot.

This feature is something to consider, but, once again, in certain spots it might work clunky.

I've never looked into this, however, it's most likely on the river.

This would require storing the entire GTO solution in memory, which would in turn require a lot of RAM.
In GTO+ only the flop and possibly turn solution are stored.
So it's not possible to quickly check this.

Hi Scylla,

In the data distribution mode in some cases (I recognised it with 163 flop subsets) after filtering the flop to a top card, the avarage values at the bottom are off. (It seems that in some cases only one, or not every board gets counted in the average values)

The averages below the table include card removal and internal database weights.
So they are more accurate than the average that excel will give you.

No, it isn't about that!
The case was the following: there were a couple of AXX boards with different frequencies but the average values were exactly the same as for the first board (for every line (check, different betsizes ans so on) as if only the first board would have been considered in the averaging process. So it seem like a calculation error to me.