GTO GTO+/CardRunnersEV? - Page 301 - Poker Software -- Two Plus Two Poker Forums

Hey!

I have a question about the lock+node function:
if I have a solution, and lets say AK is a check, but I want to change the action to "bet".
I changed it into bet, so I have the original GTO range but I added "AK" combo there.
Then I solve it again.

Will the new solution contain "original GTO range + AK" or it will be "AK" and a new "GTO" range?
So basically, if I nodelock AK, then will the solver balance that range out?

Basically what I want to do is change a few combos in to "bet" instead of check, but I want the solver to balance it out the best he can.

I hope you will understand my question

Cheers!

Quote

12-02-2018 , 03:16 PM

#7502

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by jancsigyerek

If you edit a decision and lock it, then all combos in that decision will be locked. So the solver will figure out GTO play in the tree under the restriction that it's forced to play the entire edited+locked decision as it was instructed by the user.

Quote

12-02-2018 , 03:43 PM

#7503

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by mojo6911

It won't show various bet sizing options though, or am I missing it?

The problem with multiple bet sizes is that there's almost no added value in using them. When forcing a user to only use single bet sizes as opposed to multiple bet sizes his overall EV will typically only drop by as little as 1% or 2%. Multiple bet sizes offer basically no advantage over single bet sizes, and it's for this reason that we're not really that focussed on offering extensive analysis features for them. It's basically just a waste of time. Just to be clear, our solver can handle multiple bet sizes, and our tree builder offers them, but it just means that the solution is 100x more difficult to analyse, with almost no potential payoff.

Another problem with focussing on frequencies for multiple bet sizes is that, due to different bet sizes performing as closely to each other as they do (when playing perfectly, any bet size will perform just as well as any other bet size), even the slightest change in the tree or ranges will completely change the frequencies between the different bets in the solution. So an extensive feature for visualizing turn frequencies (and there's many different lines for reaching the turn from the flop) has no real added value; the different bets are so close to each other in performance that the frequencies of individual bets basically mean nothing. Just to be clear, the bet vs check ratio is relevant, and will remain consistent if small changes are made. The ratio over bet X vs bet Y vs bet Z however is very unstable because when playing perfectly all bets have approximately the same EV.

Last edited by scylla; 12-02-2018 at 03:51 PM.

Quote

12-02-2018 , 03:59 PM

#7504

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by mojo6911

Also, it doesn't appear that it works for Player 2

If player 1 has multiple actions, then for player 2 there will be multiple spots where he gets to act. It's not possible to display frequencies for multiple spots in a single table.

Quote

12-02-2018 , 04:07 PM

#7505

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by AuMind

Can you add an option to go all-in if player bets X% of his stack on the advanced tree builder? I know there's a "go all-in if push is less than X% of pot" filter but there are a few flaws with this. For example, in one spot on the tree, a player has $75 left with $50 in the pot and bets 75% ($37) on the turn leaving himself with $38.

This option is already available in v115, which can be downloaded here: www.gtoplus.com/download. Should you already have v115 and be referring to something else, then please send a savefile to support so that I can take a closer look at why certain actions are taken.

Quote:

Originally Posted by AuMind

Also, I'm wondering if you can have the "With only 2 bets left, get the money in smoothly" option to somehow include the other bets as well since it always takes out my overbet option. I know this one might be pretty tricky or not even possible.

This option is meant for deeper stacks. In these cases, the money only rarely goes in (only in roughly 1% of the cases); it's not really necessary to spend a lot of computation time on these scenarios. Other than that, it will guarantee that the final play applies to the stack-to-pot ratio, whereas without it the final play will often have bet sizes that for example commit a player by overbetting. If however you'd prefer not to use it, then the best thing to do would probably be to just turn it OFF.

Last edited by scylla; 12-02-2018 at 04:14 PM.

Quote

12-02-2018 , 04:09 PM

#7506

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by realtimer

Unfortunately, it seems like it deleted the naming adjustments I made, like Player 1 - OOP and so on.

Will that happen with every update?

Ah, I see.
The updater will currently indeed overwrite the edited file.
I will fix this for later releases.

Thank you for pointing this out,

Scylla

Quote

12-03-2018 , 01:51 AM

#7507

mojo6911

veteran

Join Date: Feb 2008 Posts: 2,979

Quote:

Originally Posted by scylla

Maybe I am approaching this the wrong way. I would like to have maybe 3 sizes on the turn: small, medium, overbet. There are some spots where when given 3 options, the solver will prefer a size an overwhelming amount over the other. Other times, it is mixed pretty closely. If I had access to a tool like what I posted above, it will help me identify spots where betting small or overbetting are preferred to a standard sized bet.

Quote

12-03-2018 , 06:16 AM

#7508

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by mojo6911

When using this approach, there may appear to be a preference for a certain bet size, but, as it turns out, it doesn't actually seem to mean much. When playing perfectly, any bet size will perform almost exactly the same as any other bet size.

You can try this for yourself. Simply take the same tree and build it a few times for different bet sizes. Solve the different trees and then compare their overall EV. It will be almost exactly the same for any bet size.

The most important factor in winrate is the quality of play; when playing perfectly, any bet size appears to work; reasonable bet sizes work, but even ones that are unreasonably large or small still seem to have surprisingly decent performance.

Even moreso, using multiple bet sizes does not seem to offer much of an advantage either. Using only a single size only leads to a very small drop in performance as compared to very complex strategies with multiple bet sizes.

To measure the overall EV of a strategy, go to the very first decision for OOP and look for the EV below the table. This value is the only number that you need to look at when you want to know the performance of a certain strategy.

Quote

12-03-2018 , 04:58 PM

#7509

AuMind

journeyman

Join Date: Dec 2009 Posts: 354

Quote:

Originally Posted by scylla

Where is this option? I'll explain in case I made it confusing. I'd like an option to go all-in if I bet a certain % of my own STACK and not in relation to the pot. For example:

Pot: 30
Stack: 100
Bet size: 200% (or 60 in this case)

Instead of betting 60, I'd like the tree to just force an all-in at this point since I'm putting in 60% of my stack.

Quote

12-04-2018 , 05:45 AM

#7510

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by AuMind

The situation that you describe, with a 200% pot bet being made, is rather exotic. The current tree builder assumes regular sized bets being made. In these cases the "With only 2 bets left get the money in smoothly" and "Add/Go all-in if push less than X%" should nicely take care of all the final play scenarios in a tree without too much effort from the user. I can consider some sort of adaptation to account for extreme overbets in later releases, but right at this moment the builder is focussed on regular play.

Last edited by scylla; 12-04-2018 at 05:58 AM.

Quote

12-04-2018 , 02:11 PM

#7511

numberonedonk

veteran

Join Date: Oct 2014 Posts: 2,181

My current CPU is an i5-4590 (3.30GHz - 4 cores/4 threads) It's fine for my day to day use and it will still run GTO+ at a decent speed.

I was thinking of upgrading to an AMD Ryzen 5 2600 (3.90GHz - 6 cores/12 threads). Will I see a drastic improvement in speed or will it pretty much be not worth the upgrade?

Thanks

Quote

12-04-2018 , 04:26 PM

#7512

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by numberonedonk

The processing speed is mostly determined by the processor speed multiplied by the number of cores. So on the old system it would be 3.3*4=13.2gHz and on the new processor it would be 3.9*6=23.4gHz. There would be an additional speedup if indeed the previous processor has only 4 threads instead of 8. I can of course not offer guarantees, but from what I've seen so far, I would indeed expect the solver to run faster here.

Last edited by scylla; 12-04-2018 at 04:34 PM.

Quote

12-05-2018 , 08:47 AM

#7513

numberonedonk

veteran

Join Date: Oct 2014 Posts: 2,181

Thank you for the information.

Quote

12-07-2018 , 05:13 PM

#7514

bra1nSturgeon

stranger

Join Date: Apr 2017 Posts: 4

Hello, I've been using database mode a lot recently, I use the table with tab-seperated values to create different spreadsheets and I would like to suggest adding more options to these tables. Besides Equity, EV and (for OOP player) action frequencies I would love to be able to export action EV as well as IP action frequencies/EVs given a certain OOP action. The problem is for 50+ flops database it becomes very tedious to get those values manually for each flop/action. A customizable table there would be a dream come true!

Obviously I would also love this functionality for turn and river reports.

Last edited by bra1nSturgeon; 12-07-2018 at 05:25 PM.

Quote

12-08-2018 , 03:15 AM

#7515

opgf

newbie

Join Date: Nov 2016 Posts: 17

Hello, is it possible to sort by the ip frequency in database mode? I understand someone has asked this before and different oop action results in different ip reaction, but I still feel like it could be handy especially in cases like flop cbet when oop is checking very frequently(or we can make oop check 100%)

Thank you

Quote

12-09-2018 , 05:13 AM

#7516

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by opgf

I can see your reasoning, however, I have some concerns though about adding features that only work under very specific circumstances.

Last edited by scylla; 12-09-2018 at 05:39 AM.

Quote

12-09-2018 , 05:36 AM

#7517

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by bra1nSturgeon

There's a few problems with this. First of all, OOP will have multiple actions. So such a feature would need to be available for each individual action by OOP separately. Secondly, and more importantly, for each possible flop, OOP will take his action with an entirely different range and frequency. This will mean that for each flop, IP's reaction to OOP will be measured under completely different circumstances. As a consequence, this data is not suitable to be plotted in a graph/table (for this, you need to vary only a single variable and measure the outcome; not multiple ones). We can consider plotting it anyhow for later releases, but for the moment, it has been left out for this reason.

Quote

12-09-2018 , 11:28 AM

#7518

Hector1

stranger

Join Date: Nov 2018 Posts: 8

It seems like the tree builder is using an incorrect bet size.

I built a tree using default bet size of 75%. I did not use any custom settings for flop turn or river.

On flop the bet size is 75%, but then on turn and river bet size is 58.7%. Stacks are large enough for 75%.

I also noticed that if there is a check on the flop, then on turn bet size is 75% but then on river bet size is 58.7%. Stacks are large enough for 75%.

Why is it not using 75% bet size all the time?

Quote

12-09-2018 , 11:43 AM

#7519

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by Hector1

Can you please send a savefile to support so that I can take a closer look?

Thank you in advance,

Scylla

Quote

12-09-2018 , 12:18 PM

#7520

Hector1

stranger

Join Date: Nov 2018 Posts: 8

Quote:

Originally Posted by scylla

Can you please send a savefile to support so that I can take a closer look?

Thank you in advance,

Scylla

I just now figured it out. Everything seems to be working correctly.

I was using the option "With only 2 bets left, get the money in smoothly".

Even though stacks are large enough for a 75% pot bet, stacks are not large enough for two of them.

Quote

12-10-2018 , 05:55 PM

#7521

opgf

newbie

Join Date: Nov 2016 Posts: 17

Hello, I was trying to use the nodelock function. Is there a way to lock only specific combo's of a certain player in a decision point instead of locking the strategy of their entire range?

For example if OOP player is always checking all his sets, but not so sure about how OOP plays other hands, can I let the solver solve for the optimal strategy for both players given that OOP always checks sets?

Quote

12-11-2018 , 05:36 AM

#7522

scylla

GTO+ Representative

Join Date: Mar 2008 Posts: 7,353

Quote:

Originally Posted by opgf

When writing GTO+ we originally tested this feature. As it turned out, the interface became really difficult to use and editing+locking individual hands was quite a chore. Personally I was constantly losing track of which hands were edited and at which value they were locked. Even moreso, there's wasn't really much to be learned from it that I could see. In some tests, locking a partial range could make a strategy switch from 10% check to 80% check. It wasn't clear to me what there was to be learned from results like that. The idea itself is great, and we have spent about a month testing it, but as it turned out, we felt that the software would benefit more from having only a single method for locking that required only a few buttons and was easy to work with.

Quote

12-11-2018 , 11:58 AM

#7523

opgf

newbie

Join Date: Nov 2016 Posts: 17

Quote:

Originally Posted by scylla

Quote:

Originally Posted by opgf

Quote:

Originally Posted by scylla

I can see your reasoning, however, I have some concerns though about adding features that only work under very specific circumstances.

Thank you for your reply!
Just want to let you know I realized when I actually set OOP to check 100%(which I should've actually tried before asking in the thread), the report will be able to sort by IP frequency

Quote

12-11-2018 , 03:53 PM

#7524

mojo6911

veteran

Join Date: Feb 2008 Posts: 2,979

Hello,

When pasting this range from PIO:

Code:

99:0.14,88:0.58,77:0.73,66:0.84,55:0.98,44,33,22,AQo:0.16,AJo:0.54,ATs:0.47,ATo:0.9,A9s:0.87,A9o:0.94,A8s:0.7,A8o:0.96,A7s:0.37,A7o:0.99,A6s:0.64,A6o:0.71,A5o:0.91,A4s:0.23,A4o:0.77,A3s:0.88,A3o:0.09,A2s,KQo:0.56,KJs:0.29,KJo:0.63,KTs:0.46,KTo:0.72,K9s:0.22,K9o:0.96,K8s:0.55,K8o:0.8,K7s:0.73,K7o:0.17,K6s:0.74,K5s:0.86,K4s,K3s,K2s,QJs:0.17,QJo:0.92,QTs:0.04,QTo:0.91,Q9s:0.23,Q9o,Q8s:0.92,Q7s,Q6s,Q5s:0.96,Q4s:0.97,Q3s,Q2s,JTo:0.85,J9o:0.96,J8s:0.53,J8o:0.2,J7s:0.58,J6s:0.94,J5s:0.78,J4s:0.95,J3s,J2s,T9o:0.88,T8s:0.01,T8o:0.59,T7s:0.62,T6s:0.65,T5s:0.97,T4s:0.58,T3s:0.29,T2s:0.04,98s:0.25,98o:0.53,97s:0.8,96s:0.81,95s:0.78,87:0.41,86s:0.93,85s:0.89,84s:0.02,76s:0.51,76o:0.26,75s:0.81,74s,73s:0.15,65s:0.71,64s:0.86,63s,54s:0.6,53s:0.95,52s,43s,42s:0.99,32s:0.5

PIO says it is 430.3 combos, but GTO+ only takes 394.94 combos. Here is the output from GTO+

Code:

[14%]99[/14.00%],[58%]88[/58.00%],[73%]77[/73.00%],[84%]66[/84.00%],[98%]55[/98.00%],[16%]44,33,22,AQo[/16.00%],[54%]AJo[/54.00%],[47%]ATs[/47.00%],[90%]ATo[/90.00%],[87%]A9s[/87.00%],[94%]A9o[/94.00%],[70%]A8s[/70.00%],[96%]A8o[/96.00%],[37%]A7s[/37.00%],[99%]A7o[/99.00%],[64%]A6s[/64.00%],[71%]A6o[/71.00%],[91%]A5o[/91.00%],[23%]A4s[/23.00%],[77%]A4o[/77.00%],[88%]A3s[/88.00%],[9%]A3o[/9.000%],[56%]A2s,KQo[/56.00%],[29%]KJs[/29.00%],[63%]KJo[/63.00%],[46%]KTs[/46.00%],[72%]KTo[/72.00%],[22%]K9s[/22.00%],[96%]K9o[/96.00%],[55%]K8s[/55.00%],[80%]K8o[/80.00%],[73%]K7s[/73.00%],[17%]K7o[/17.00%],[74%]K6s[/74.00%],[86%]K5s[/86.00%],[17%]K4s,K3s,K2s,QJs[/17.00%],[92%]QJo[/92.00%],[4%]QTs[/4.000%],[91%]QTo[/91.00%],[23%]Q9s[/23.00%],[92%]Q9o,Q8s[/92.00%],[96%]Q7s,Q6s,Q5s[/96.00%],[97%]Q4s[/97.00%],[85%]Q3s,Q2s,JTo[/85.00%],[96%]J9o[/96.00%],[53%]J8s[/53.00%],[20%]J8o[/20.00%],[58%]J7s[/58.00%],[94%]J6s[/94.00%],[78%]J5s[/78.00%],[95%]J4s[/95.00%],[88%]J3s,J2s,T9o[/88.00%],[1%]T8s[/1.000%],[59%]T8o[/59.00%],[62%]T7s[/62.00%],[65%]T6s[/65.00%],[97%]T5s[/97.00%],[58%]T4s[/58.00%],[29%]T3s[/29.00%],[4%]T2s[/4.000%],[25%]98s[/25.00%],[53%]98o[/53.00%],[80%]97s[/80.00%],[81%]96s[/81.00%],[78%]95s[/78.00%],[41%]87[/41.00%],[93%]86s[/93.00%],[89%]85s[/89.00%],[2%]84s[/2.000%],[51%]76s[/51.00%],[26%]76o[/26.00%],[81%]75s[/81.00%],[15%]74s,73s[/15.00%],[71%]65s[/71.00%],[86%]64s[/86.00%],[60%]63s,54s[/60.00%],[95%]53s[/95.00%],[99%]52s,43s,42s[/99.00%],[50%]32s[/50.00%]

I believe something isn't getting sorted out correctly in the formatting. I have also tried using the rangeconverter.com formatter, and there are issues, as well.

Quote

12-12-2018 , 03:57 AM

#7525

ionutd

Carpal \'Tunnel

Join Date: Apr 2010 Posts: 13,624

Good day, Scylla

A couple of questions for you regarding GTO+

1.Can I import ranges from Equilab? If not directly, is there a workaround to it? I would hate to have to manually input everything.

2.Where are the different flops you can pick stored? How can I edit that file to put in my own 25-30 types of flops instead of having to use the random flop generator?

Thanks a bunch, have a nice day.

Quote

Page 301 of 568

First

101 201 251 281 291 296 297 298 299 300 301 302 303 304 305 306 311 321 351 401 501

Last

Post Reply Subscribe

...

Page 301 of 568

First

101 201 251 281 291 296 297 298 299 300 301 302 303 304 305 306 311 321 351 401 501

Last