Do you mean the basic tree builder?
It will figure out the smoothest way to get the money in with X bets.

For example in the pic below the starting pot is 40 and the effective stacks are 444. If you select "4th bet", then the basic tree builder will calculate that it will take 4 bets/raises of each 60% of the pot to get all the money in.

An important thing to realize here is that in GTO bet sizing isn't really that important. When playing GTO, for any bet size the GTO strategy will perform almost exactly the same as the GTO strategy for any other bet size. So there isn't really a preferred size. You may as well pick bet sizes that you like and focus on the GTO strategies for those. As a consequence, your approach will work perfectly fine, given that even if it were to lead you to a "wrong" bet size, it will still lead to nearly the same overall EV.

You can test this for yourself by building different trees for different bet sizes and looking at the overall performance for OOP. This overall performance is the EV below the table for OOP's very first decision. See the pic below. As you will find, no matter which bet sizes you choose for OOP, his overall performance will barely be affected. Even letting him use multiple bet sizes in the tree will not lead to any significant increase in his overall EV.

Ok, I have sent you a PM with a temporary update that I expect will resolve your issue. Please let me know if the issue still persists. Otherwise I'll include the fix in the next update. Thank you for reporting the storage of files to AppData/Local. That might have been a tricky one to figure out otherwise.

what if I select no bet though? As in, when you first go to set up the tree and adjust the starting pot and stack sizes it selects how many bets to get the money in automatically, like 3 bets or 4 bets or whatever.

I'm just wondering, is there any logic to the amount of bets the program chooses? Because sometimes it will make it like 50% pot and get the money in within 3 bets for example, but I can change it to different amounts of bets manually, and I don't know which betting structure for my strategy is best?

Does the program choose what bet size it thinks is best, or do we just manually mess around with it to find the best betting structure with the highest EV?

Thanks

I know that. The goal of my question was more to optimize the time it takes to solve a tree on my slow computer If I pick the bet sizes I like, in some spots it can take hours to solve a tree.

An example I ran today, I had 3 bets sizes on the flop (33%, 70% and 130%), and after solving I realized that the 130% was only used 0.3% of the time. If I had been able to know that before, I wouldn't have put it as an option in the first place, and it would have solved a lot quicker (removing 1/3 of the tree). Which leads me back to my original question: how low does the dEV need to be before I can be confident that the frequencies won't change drastically?

Another way to phrase the question would be: If I only want to look at the overall frequencies used for each bet sizing without looking in detail at every combo, do I still need to solve to a dEV <0.5% or would 5% be enough to get the overall picture?

hello is there a way to compare EVs in multiple databases? example: i solved 3x 33 flop subset with same ranges, same pot and effective stacks but with different postflop criteria: only potbet on flop, only third pot on flop, multiple sizings on flop, now i can open all three in GTO plus and check overall EV of strategy, but i would like to compare what flops are bad to play specific strategy on i would like to compare it fast like in this screenshot
https://gyazo.com/55d3fa734e51f4f1f4cb89e57900cd0f

At the moment the requirement is that all the trees are identical when it comes to bet sizes and the number of bets. We can consider adding exceptions in later releases, although this may turn out to be difficult, given that each deviation from the general approach may require its own unique configuration.

It will choose whichever number of bets leads to a bet % closest to 75%. If you prefer using more bets with a lower % or less bets with a higher percentage then you can just select whichever number of bets you'd prefer for getting the money in.


It will choose a betting configuration that will get the money in as smoothly as possible (smoothly means that each bet/raise is the same % of the pot). It will test all possible number of bets for this (1 through 5) and use the one where the % is closest to 75%.

The EV will be roughly the same for any betting configuration that you can think of. You can just test this for yourself by varying configurations and checking OOP's overall EV. To get this overall EV, check for his EV below the table in his very first decision (see screenshot below). When playing GTO, bet sizes are not really that important; any bet size will perform roughly the same as any other bet size, so you may as well just use a bet size that you feel comfortable with.

You can just use single bet sizes. Not only do bet sizes not really matter in GTO, even using multiple sizes as opposed to just a single size will not lead to any significant increase in EV. Using single sizes will make your trees smaller, solve faster, while making the solution far easier to interpret. For the size you can just use anything that you like; there's really no penalties for selecting a very slightly sub-optimal size. If deciding where to focus your analysis efforts, I really would put it more into interpreting the meaning of solutions as opposed to trying to gain some minimal edge with a bet sizing.

I've never looked into this, but I can tell you that the fastest thing to converge is EV. Frequencies are the second fastest thing. So solving to 5% will probably give a decent impression of the frequencies. I've just run a quick test and 5% already gives a very decent idea of the final frequencies. And, once again, even if you were to make a "mistake" and choose a wrong bet size, then the loss in EV will be absolutely minimal. In GTO, bet sizing will have almost no effect on the overall EV.

first of all, big thanks for creating gto+ as well as for the great support you offer. you are a rare exception to how customer service usually handles customers (i.e. https://www.youtube.com/watch?v=p85xwZ_OLX0)

anyways, i ran into a small problem: i was quite shocked to hear that bet sizing should only have a insignificant effect on EV, so i built quite a big tree with lots of different betsizings to test this. after building the tree, gto+ told me that it required 10gb of ram, while in the bottom left of the screen (over the language flag), it showed, if i understand that correctly, that i had 11gb of ram available. i started running the sim and after a while a blue msg showed up telling me that ~9gb more ram might be required and only ~4gb was available (my PC has 16gb total). taskmanager shows that gto+ is already using 9gb ram.

i did this once before already and after a while the solver just stopped at ~1% dev, instead of the targeted 0.5% and after stopping, it basically just showed completely evenly distributed hands for every node. so i assume it did not include any results from the calculations up to the point where it stopped because it ran out of memory?
btw that blue msg directs me to https://www.gtoplus.com/memory for further information but that page does not seem to exist.

thanks again.

where can i find saved preflop ranges when i want to move them to other computer so i dont have to create them again?

GTO+ will estimate the amount needed for the solution based on flop you are viewing currently. For example if you have an AAA flop on the window and it says 2gb required for solve then by the time the solver gets to a 246r flop u will need like 13gb for it a good way to make sure you have enough space for all the flops in the database is to go to a low dynamic rainbow flop and check that flops requirements. Also these days the windows os has so many secret ram hogs and extra ram used by each program not shown in the task manager. E.G currently my task manager says I'm using 11gb of ram of which 5gb are completely unaccounted for.

As far as sizings not making a difference to EV, this is only true on a street by street basis pertaining mostly to the flop.

Sizings will also matter more if you restrict the opponents sizings as well making them have no counterplay to your lack of sizings.

Flop sizing only makes 0 difference if you are still able to get the money in on future streets. So if in doubt and want to save computation time always minimize the amount of sizings and raises OTF. Not having an overbet size OTF on AK2r bu vs bb will lose you like 0.01bb/100 but then not having it on the turn on some turns can lose you up to 15bb/100

What you should take away from this is that you should use a minimum amount of sizings that allows you to bet nutted hands and make the pot big/get all in, but also bet other hands for thin value/protection. Also like scylla said it is way easier to interpret solutions as the tree gets smaller, which means even if you have the computer power to do 10 sizes per street it will make your solution so complicated it will be less useful than one with 2 per street.

programfiles/gto/config

it will be the newdefs3 I believe. also the folder has some backups incase some of your ranges disappear or are not included in that file

thanks for your reply.
i am not currently solving databases but just a simple, pretty dry flop. since i posted my problem, i cut down in betsizes and started the solver again. the estimation on required ram was way below what was available, but now it has been shooting up again. i wonder if i am making mistakes setting up the solver or if my RAM might be defect.
i think this time it estimated to be needing around 9gb of ram, it is currently using 9 and now telling me it needs ~8 more with only ~4 more available.

I just bumped this thread to 5 star

That's not true. Scylla posted proof that using multiple bet sizes on every street doesn't improve EV by a significant amount.
If you found a spot where this is not true, please post proof here.

are you referring to the screen posted on this very site, or is there proof way deeper into the thread?

one thing that bothers me about the screenshot above is how OOP and IP have almost completely identical ranges. i would imagine once ranges differ more, as would be more realistic, one range would start the flop by having an equity and/or nut advantage and then betsizes could play a much bigger role?

In most cases the stated amount of memory will be all that will be needed. However, in rare cases, particularly when ranges are tight, the solver will need additional memory to converge to the given dEV. This should rarely be an issue, given that tight ranges will usually mean that memory use is low as well. However, it's possible to add multiple bet sizes up to point where the tree both has tight ranges and a very large memory requirement. In those cases, with the required additional memory not being present, the solver won't be able to converge. The only way around this would be to create a smaller tree, or to add more RAM. As long as enough RAM is present, the solver will always converge.


Ah, I think that we overlooked writing that page.
Thank you for pointing that out.

Up until this point I have not found any cases where bet sizing makes a significant difference in performance. That being said, I'm happy to be proven wrong; it would be interesting to see if situations exist that are an exception.

Those are stored in newdefs3.txt.
This file is stored in the subdirectory /config.

Hi,

I found that on flop & turn, all lines when I see in individual hands appear to have similar EVs. While in total EV , it is the huge differences between different lines (Bet & check)

For example as below:

so should I consider as both line (bet or check) for KJs is indentical here or there is big difference in EV as total EV shown below?

Thank you,

got it to work by simplifying the tree, thanks!

If a hand has a mix of bet and check, then this will mean that the solver considers them as having the same EV, and it does not consider there to be a difference between them. Now, in practice you may see a difference in EV between two lines for the same hand, even if there's a mix. This is however only because the solution has not fully converged yet to a dEV of 0. If you take a turn or river line, and let the solver run until dEV is 0, then you'll find that all mixed hands have the exact same EV for all of the actions that are in their mix. Lines that are not in the mix will have a lower EV.

For example, in the screenshot below IP has a choice between raise, call and fold. With his AJo he chooses a mix between raise and call. The EV for raise and call will be nearly identical, given that in a GTO mix, mixed actions will perform identically from an EV perspective. It's only the fold action with a substantially lower EV (which is why it's not included in the mix).

So the display total EV of 2 lines is not accurate ? since all single hands have identical EV. The total EV should be similar too ? But I always see big difference as the screen shot above.

No, the display of EV is accurate; it's the exact EV of each line.

For example, in the screenshot above the bottom hand (AdJs) has a mix of raise versus call. Folding is not part of the mix. This can also be seen in the table, where the EV for both raising and calling is roughly $96.11. The EV of folding is much less, namely $0 (which is why it's not part of the solution). The solver doesn't really care whether you raise or call; when in a perfect equilibrium, the EV for each line in the mix will be exactly the same, and the solver will be indifferent between them.

However, GTO solvers do not converge to 0, because this would take forever. Instead we tend to stop running the solver at a point where we feel we're close enough to the solution. As a consequence, a true equilibrium will not have been reached yet, and small differences between the EVs in the mix will occur. So in AdJs above there's still a 2 cent difference between raising and calling. This does however not mean that one of the actions is preferred above the other. The mix in the second column of the table for this hand is the recommended play; mixing your play will guard you against villain exploiting your mistakes.

If instead, when playing, if you were to always choose the hand with the highest EV for each line, then your EV would turn out to be dEV above the stated overall EV for the player. This is what dEV (or Nash distance) means. So dEV is the maximum amount you could gain as opposed to the GTO solution if you were playing max exploit. A disadvantage of playing max exploit would be that if you were to ignore the solution, and always play the action with the highest EV, then you will become exploitable yourself. So recommended play is to always use the distribution that is indicated in the table, even if it means sometimes playing one of the actions with a slightly lower EV.