I don't know, that's what I was using it for when it was my hobby project in 2014. It seems like the most natural thing to me: looks at interesting HHs from the session, solve, compare your play with the optimal one, explore some more branches to see "what if" scenarios.
While it was a bit of a pain back then when it was only text interface and scripts it's now quite easy to do: you construct 10-15 templates for common situation from your game and all is needed is to change the board and solve. Maybe sometimes adjust ranges a bit according to your reads.

If you are doing it this way it's important that you can have solutions fast and that you can browe them fast.
The other way to work with it is to schedule interesting spots and solve them during the night or when you are otherwise not at your computer and review them later.
In 2nd case the speed of solving is not that important, it's true. The speed of browsing is still something you want though.

People build their personal libraries - yes. Scripting is very popular feature and it seems a lot of poker players' first programming language is UPI interface from PioSOLVER

As to real play/botting - my views on this are as follows:
-you could use the solver to build AI
-it would be terribly inefficient comparing to just writing your own AI
-95% of the challenge with botting is infrastucture, stealth and willingness to break the rules; for people capable of doing those things improvements they could make using the solver are relatively minor; it's not like we discovered some miraculous algorithms here, you can read publicly available code of CFR+ from Alberta and you will know all the important ideas; we are faster and we have good interface to analyze hands/export data/make spreadsheets etc. etc. but those things are useless for botters

I think datamining and real time play assistance tools are way bigger threats to online poker than GTO solvers are.
If it comes to that you can always move to more complicated game (6max instead of HU, PLO instead of Holdem), there is no such way out from programs analyzing opponent tendencies in real time.

Clearly 2 vs 5 minutes per hand is significant. Yes you could do something else while you wait, but most people who dedicate time for study would probably prefer to do it efficiently.

Personal opinions (for now) after following this thread.

I can get the best of two worlds (out of 3?).

--Seems like GTORBdotcom is perfect for getting a good "game theory for poker" education. Learning concepts, how to reason from calculated results and what it means. This for a pretty low price of 20/month and quite cheap solution packs to go with it. Asuth seems to be an expert both at game theory and education from my google results.

--Since the GTORB calculator wont let me solve flops on my own i think my money for the software is better spent on either piosolver or simple postflop. Right now i am leaning towards piosolver but from the trials i have used i like simple's slightly more intuitive UI for selecting ranges. I think the customers would benefit greatly if there could be some actual "showdown" between the two to get all the claims undisputed.

This is just my own ideas based on my own needs (I'm sure a midstakes or highstakes player would think different. Smallstake players with limited funds but enthusiastic about GT have to be picky even if the price for the softwares undoubtedly is peanuts compared to its potential impact)

Thanks for the reply.

I agree with real time play assistance tools being a threat. The potential with solvers seem scary, but perhaps a little resource hungry right now? I don't know. And for how long?

Why do you think datamining is a threat? I've never really understood that. Data on fish helps them lose a little faster sure, but often they wouldn't have data and they're going to lose fast anyway. And against a thinking opponent, data from that player against his player pool is often more detrimental than helpful to most players I'd argue. So it really only hurts regs who have very significant leaks.

PLO sure, for now. Bust as for 6max vs HU nl. About 90% (depending on player pool) of flops in midstakes games are heads up. So ignoring preflop, there really isn't a lot of difference.

Well... Alberta solved limit holdem using 4800 cores for 67 days. Claudico team attempted NLHE AI better than humans using similar resources and years of computations.
I think unbeatable (by humans but not by other computers) AI for NLHE HU playing on Macbook pro will be there in 2016. I don't know who delivers it but there are some competent people in this race.
That is HU though, it's long way for 6 max or any other multi player game. It's also a longer way to solve NLHE with proven upper bound on exploitability although that is way more "in play" than academics would like you to believe.

It's easy to make a bot which wins vs recs. It's not that easy to make a bot which wins vs regs. Datamining reduces the need for the latter.

The thing is you can't just ignore preflop because ranges change depending on who sits on blinds, how loose the opener is. It's many more situations, many more sizings and way bigger game overall.


It would and it will happen. It's just still very early and it's not easy to find unbiased party. The best way for now is for all sides to present their products and to make verifiable claims and showing off features.
GTORB did the best job here and despite this thread going sour my opinion about them didn't change. They have legit product, Alex Sutherland did everything he could do to verify his results (including ridiculously inefficient manual copy pasting strategies to CREV but there isn't any other way to use CREV for that) and you get what is advertised.

I just wish SP were held to similar standards.

We didn't do good job advertising/showing off yet because we divide our time to programming and support (and I am working 10-14 hours days on it with very rare breaks)
There aren't any videos with all the features and you need to dig the blog to see update announcements. The reason for all that is that we had so much success in first 3 months that it was overwhelming to implement the most urgent feature requests and supporting everyone. People trusted us buying the product which you couldn't find any information on the Internet other than my claims in the 2p2 thread. I felt we owned those users the support and a lot of features for giving us that much benefit of doubt when we started.
I think we delivered and maybe now it's time to advertise it a bit more although I am always thinking "one more feature before we start it"

do any of these programs provide GTO preflop charts. for example, if UTG open raises 15% and opens to 2.5bb and it is folded to me in BB... what % of hands should i defend? thx

No, they are postflop solvers, and currently you won't find preflop functionality. I know that at least Pio and SP have plans for preflop solving, but nothing on that front has been released yet.

The thing with preflop is that you need some way to make your results believable and measurable.

If we were to code kinda/sorta correct sampling on kinda/sorta decent abstractions on kinda/sorta decent subset of flops we would get not very exploitable preflop strategy.
What good is that for though? You can already see some approximations made by programs like Snowie or top AIs from Alberta competition (someone even posted preflop charts for those in poker theory forum).
Those are probably quite decent because preflop converges decently fast the same way flop strategies converge fast (and almost all of the exploitability comes from turn/rivers being imperfect still).
You can also buy a big database and see what top players are doing.
Another thing is that even if you had such a solver producing decent preflop charts someone would calculate it once for HU/common 6max spots/CAP/HUSNGs, publish it and that would be it. We would all be back to solving flops because that's where interesting analysis happen.

A solver producing just preflop approximation today wouldn't be very valuable. What would be valuable is either full solving (so being able to show exploitability upper bound and have quick way to access the solutions from flop onwards).
It will happen but from my perspective it makes more sense to invest more time in postflop optimizations first (and there is a lot to do there, memory could easily by 1/3 of what it is today and speed can be improved in many ways as well) because that will make w/e is done from preflop in the future just much more useful.

Is your software and others really useful for a human player, or just for a bot? If I see the percentages for GTO turn plays and see that checking QTo is the right play on this turn it doesn't help me to remember that unless I also remember all the other hands and how to play them on this turn as well - infinite combinations. So it seems like a GTO engine's main function is for AI, for botting/non human play.

I know you have played NLHE for a quite awhile. Remember you back in the day. Did you go back and learn programming, is all your programming out sourced or did you have a programming background pre-online poker?

So what seems to being said in this topics on GTO tools is that I should just play my standard preflop and flop game and then use these programs to study turn/river?

I had this as hobby project for myself and my customers are human as well

There is no way to remember even small part of the solutions. There are still a lot of ways you can use the solutions to understand the game better:

1)you can see EVs of actions and see which are close and which are not
2)you can understand the ranges better; we went out of our way to make this possible; you can see how many strong/weak hands are there in a range, what equity they have against opponent range at given time, what % of the range is say top pair; you can also see it refreshing while browsing the tree, like here: http://imgur.com/vRLeZun
You can learn a lot about frequencies and how to construct ranges this way.
3)you can understand what cards are good or bad for your range because it's easy to pull data from the whole tree, for example here is a sample report:
http://i.imgur.com/X6fKGyQ.png (sorted by 2nd barrel frequency)

You can also pull such information for flops from multiple trees.

If you were to construct AI you would take many shortcuts. For example it doesn't matter if you have turns/rivers solved - it matters to have good flop approximation fast, make a play, worry later. For learning/understanding the game that's close to useless though as you wuldn't be able to compare various spots in reasonable time and thus unable to find interesting patterns.
I think GTO solver is way more useful for humans than it would be for making a bot. Making a bot is a different challenge.

I didn't have programming background but I had strong math/comp-sci background. I've learnt programming later in life doing hobby projects connected to bridge, chess and just fooling around with other stuff. I did commercial poker related projects before but either I wasn't a programmer (Pokerazor) or it wasn't a public project.
I was very lucky to meet all the right people who know more about poker programming than is publicly available. I've learnt a lot from them.
The solver is not outsourced. I've written all of it myself in 2014 and to this day ~97% of the solver code is written by me. The viewer is written by my friend.

Standard as in estimated from a database, yes. You can try seeing how good standard preflop ranges do but that requires some scripting. Some of my customers did a lot of work in this respect but I can't share results because it's their work. It requires running hundred of flops for given spot and summing up results, seeing what is +/- EV, adjust preflop assumptions, repeat.
It is very inefficient process comparing to what real preflop solving would be but it is what it is for now.

Feel free to ask any other questions. There is very little I am not willing to answer (that very little is about some low-level implementation details).

why does saved pios tree take 5GB of disk space, while its only 50kB for simple postflop?

Yeah, this is another nonsense you can find googling or hear coming from SP camp. One of many which prompted my somewhat harsh reaction here.
It is true that in our first release we only gave an option to save the whole tree and those saves were huge. It was promptly corrected and now we give the following options for saves:

1)save the full tree as it appears in RAM
2)save flops + turns which is about 50x-100x smaller than the whole tree
3)save flops only which is more than 1000x smaller than full save (usually around 1MB or smaller)
4)save just tree configuration - this is several kbs but you need to recalc the whole tree

What 1) gives you is 0 delay when browsing, ability to resume solving, ability to access river stats from various branches fast.

What 2) gives you is very fast load/save times (loading usually around 1 second) while still giving very fast browsing (typical delay on the river is about 200 miliseconds for recalculation) and the delay for turns is 0 (as there are saved).

What 3) gives you is even smaller saves but significant delay when browsing because turns need to be recalculated.

What 4) gives you is ability to copy-paste tree config on chat or forum and for other people using it with simple copy-paste as well

Now, Simple Postflop gives you only option 3) (out of first 3, I don't know about 4 but this is not an important point here) which brings following disadvantages:

a)you can't resume solving (at least not without recalculating all the forgotten info first which defeats the purpose)
b)big delays when browsing as you need to recalc every single turn/river you access
c)inability to access the information from various branches as it was calculated so no verification of given EVs is possible

We recommend option 2) for most cases as it's good combination of speed of browsing with reasonable storage amount but you can choose. Small saves mean less information stored and additional recalculation cost. It's only natural that when you claim "we have smaller saves" you explain what the cost of this is.

In this case flop saves make it impossible to compare ranges/strategies of various branches in reasonable time. Flop + turn saves reduce that cost very significantly but you need more storage space (still, it's usually 40-100MB per save so not the end of the world).

I mean, it's not like we are saving porn movies along with those saves to make them blow up to several GB, be honest and say what disadvantages of small save approach are and why your competitor might have chosen other path - even back then when full tree saves were the only available option in PioSOLVER.
Or I don't know, at least say that you can't save nor browse the whole solution because you decided storage space is more important thing.

Hello!
I would like to answer the quiestions which were adressed to me.

Theoretically speaking, adding this feature shouldn’t present any difficulties. Yet I fear this might make sharing results more complicated. I see the following benefits:

1) We couldn’t have implemented SaaS solution without taking this approach.
2) This makes sharing results relatively easy. You just send me a file which is only a few hundred kilobytes, and we’ll have the same strategies even for the river branches.
3) You don’t have to worry about having enough free disk space to store your results. You can schedule 100 flop jobs overnight and the results folder will grow up only 10Mb by the morning.
4) In theory, this approach provides better general convergence for the solution, because if we select a specific branch we can make more effective calculations. Yet there’s a flip side to it.

So we’ve talked about the benefits, let’s mention the drawbacks.

1) The theoretical inability to verify the results. Yet, even if the interface allowed us to view the complete decision tree in full, in reality this is unlikely to help us with verifying.
2) Transitioning from flop to turn might incur a few seconds delay. This might negatively impact usability, but again, it all depends on how the person conducts their analysis and how much time the transition will take.
3) The theoretical possibility to relearn and inability to restore strategies for degenerate cases with 0% upon exiting the flop. I believe this can be a serious problem in some cases.

1) I’m claiming that it was a significant error, it was just a display error which didn’t affect strategies themselves and Nash dist., and it only persisted on turns and rivers.
2) I still don’t see any significant error in that case.

1) But I couldn’t find the option in your program to export the results in CREV format, is it possible? As far as I understand, that’s the only option for the regular user to verify the results.
2) I disagree, but I’ll describe it later so as not to repeat myself.

I maintain this is about the program usability, not about the flop strategies calculation performance.

1) I haven’t verified the accuracy of your Nash dist. either, but according to the results I have no reason to believe there are any significant errors.
2) It seems I’m repeating it for the third time in this post, but this doesn’t affect the performance. But even if we multiply by some factor, there will be no fundamental changes for narrow ranges.

We have it explicitly stated on our site that we don’t use abstractions. I’ve also stated in my last message that we keep all strategies and make all calculations for the game in RAM. That leaves the ignorance out, and the only possibility left is that we’re being dishonest, not just making a mistake, but deliberately lying to you. That’s a serious accusation that shouldn’t be made lightly.

But if you’re able to speed the calculation up by a magnitude (10 times), why aren’t you doing it? You would’ve killed off any competition we are able to offer with this GUI. And using this technique for turns would remove the need to store tree, as the performance delays would be negligible with this speed up. Even if you’d be producing the complete tree as it is now, you’d easily be able to increase performance by a factor of 3.

Yes.
I don’t think our programs would differ significantly when performing on huge input ranges. I won’t speculate on what the acceptable accuracy should be and am willing to concede that performance results might be different for that accuracy. I’ve been only waiting for the higher accuracy in order to be able to tell if there are errors if EV differs by a lot.
Calculations on narrow ranges use a different factor and it’s not related to the required accuracy.

I only wanted to show with these tests that there’s almost no difference for the EV result, and the cases were chosen purely to emphasize this angle.
If a flop strategy exists that allows for the turn and river strategies to produce an epsilon of 0.05% combined, then it’s obvious that turn and river strategies exist that produce an epsilon of 0.5%, 5% or 50%. But if we have a flop strategy that allows for the turn and river strategies to produce an epsilon of 50%, that wouldn’t imply that there exist turn and river strategies that would give 0.05%.

When our program outputs flop strategies and Nash dist., it asserts in general case that turn and river strategies exist for this flop that produce an exploitability equal to Nash dist. We’re not making epsilon up, we’re displaying a value that corresponds to turn and river strategies that we’ve found and which are stored in RAM on standalone version. I see no other reliable way to solve the problem I’ve described but to find turn and river strategies, as it would be difficult to claim that they exist if we don’t find them. I’m making a conclusion based on this reasoning that the problem of finding a complete tree is equal to the problem that the user sees us solving.

If we’re discussing a problem that requires a 100% correct answer, and not a probabilistic one, then the time spent on verifying doesn’t affect the performance of solving the problem.
From the user’s perspective given equal performance we will output a necessary solution in equal time. The time spent by the user on reviewing might negatively impact the usability, but it doesn’t affect the performance of solving the problem.
I don’t claim that I’ve achieved a 3 times better performance for 100% ranges on flops. I’ve just shown the results that I’ve obtained. I don’t make any claims about my performance on 100% of the ranges just on their basis. And I don’t deny that it might be a poor sampling. But I insist that SimplePostflop indeed runs significantly faster on narrow ranges.

That's what I meant when I first claimed misinformation and dishonest claims and I still stand by that.
I don’t want any agressive competition on the forum. Please forgive me if my last message was overly promotional. I’m only trying to get my point across that PioSolver and SimplePostflop are both doing the same job, and I believe that in the nearest future performance won’t differ significantly, although we’ll continue to race against each other. And I’m displeased to read claims like "we are already way ahead of the rest of the market in performance". It’s even more unpleasant that we’re being discredited and accused of dishonesty when we only claim it’s not like that.

So, I would like to stop this agressive discussion and I urge to treat each other in a peaceful way.

Well, there is NaN in there... but what I meant is that it's not clear (at least to me) if you round the strategies in the whole tree or just on one street.
Just to clarify: my understanding right now is that you round them on one street and send the results before forgetting turns/rivers. Would that be correct?

I don't think CREV is too reliable an option because they have montecarlo engine unlike us and unlike Simple Postflop (in a sense that we can both do full exact calculation as long as numeric accuracy allows).
I believe you can verify without it though. For example looking at equties/frequencies to see if everything on rivers add-up. Then go back to turns and see again. It's true though that serious verification requires exporting the results and adding stuff up programmatically as it's just too many numbers for a human.

Just to make it clear: I have 0 reasons to believe Simple Postflop gives incorrect results as well as everything I've seen adds up and I tested some very sneaky blocker heavy river situations.

What I meant is that if we were to add several seconds forced recalculation period on the turn and say 200-300ms on the river the resulting tree would have way better accuracy than claimed.
From user perspective they would be able to browse way more accurate tree for the cost of spending additional time. So when the tree is at 0.5% I could claim 0.2% and that what the user would see as the program would "catch-up" by recalculating turns/rivers when needed.
I see that you are not doing it as you are forced to recalculate from scratch though so I don't have reasons to doubt your exploitability number.

I admit I went on big tilt hearing some claims I found not being fair. I probably overstated a lot of SP disadvantages in my response and should be more civil about it. I was being sincere but not objective at the time of making my first posts in this thread.
I think getting those problems right is hard and before us there was no-one in the world (at least with public projects) who were close to performance of those solvers. While I am not happy that you got it right at the same time as I did I have a lot of respect for you for doing so

may we all solve in peace

How long does Pio take to solve flops? On the website it says 3-5 minutes, is this correct? When I tried SPF it took about 20-45 mins.

This is impossible to answer without knowing what hardware, what exact tree and what accuracy.
It's always possible to build bigger tree so you can always make it take longer.
For example in SRP it makes significant diffrence if raise size is small enough to produce bet-raise-raise-raise-call line (without being all-in) or if donkbet OOP is allowed.

The benchmarks I posted on the website (here) are not very up-to-date (it's faster in current version and way way faster in 1.4).

If you describe the tree I can tell you how much it takes to solve on i7-3770 (run out of a mill 3 years old i7 quad).

I was just looking for some rough estimations. Say a 3b pot with one bet size v a sb bb with 2 bet sizes for sb.

Whilst you are here I was also wondering what the differences were between the different products. From what I can tell Pro is faster than Basic and can do multiple betsizes however is the only benefit of Edge that you get better support and early access to new version? Is there anywhere with more info on the differences?

Thanks!

p.s. I have an i7-4790k @4ghz with 8gb ram (pretty decent I think pc is about 6 months old).

I am not sure what "v a sb bb" means. So let's run a few pots. This is with release candidate of 1.4 which is for now available for edge customers only but will be there in every version once some things (save format, updater etc.) are finalized. Previous version was significantly slower for smaller ranges.

All pots assuming 5/10 blinds, 100bb; I run all of them until 0.2% of the pot accuracy is reached.

1)HU ranges, SB vs BB, starting pot 180, stacks 910; like here

Button: AA:0.25,99,88,77,66,55,44,33,22,AQo,AJ,AT,A9,A8,A7 s,A6s,A5s,A4s,A3s,A2s,KQ,KJ,KT,K9,K8s,K7s,K6s,K5s, K4s,K3s,K2s,QJ,QT,Q9,Q8s,Q7s,Q6s,Q5s,Q4s,Q3s,Q2s,J T,J9,J8s,J7s,J6s,T9,T8s,T7s,T6s,98,97s,96s,95s:0.5 ,87s,86s,85s:0.5,76s,75s,74s:0.5,65s,64s,63s:0.5,5 4s,53s:0.5,43s

BB:
AA,KK,QQ,JJ,TT,99,88,AK,AQ,AJ,ATs,ATo:0.75,A9s,A8s ,A5s:0.5,A4s:0.5,A3s:0.5,A2s:0.5,KQ,KJs,KJo:0.75,K Ts,KTo:0.25,K9s,QJs,QJo:0.5,QTs,Q9s,JTs,JTo:0.25,J 9s,J8s,T9s,T8s,T7s:0.45,98s,97s,96s:0.45,87s,86s:0 .75,85s:0.45,76s:0.75,75s:0.75,74s:0.45,65s:0.75,6 4s:0.5,63s:0.45,54s:0.75,53s:0.5,52s:0.45,43s:0.5, 42s:0.45,32s:0.45

-0.42% after 95 seconds
-0.34% after 110 seconds
-0.236% after 157 seconds
-0.196% after 189 seconds

Memory: 850MB
Screen: http://i.imgur.com/LmzkGMI.png

2)Single raised pot, BTN vs BB, 6max ranges, no donkbet on the flop (it's chosen with 0% frequency anyway in those spots)
Bet sizes are a bit unfortunate becuse with 55 starting pot and 975 effective stack there is bet-raise-raise-raise-raise line on the flop; if it was capped at 4 the tree would take faster to solve;

BTN:
AA,KK,QQ,JJ,TT,99,88,77,66,55,44,33,22,AK,AQ,AJ,AT ,A9,A8,A7,A6,A5,A4,A3s,A3o:0.5,A2s,A2o:0.5,KQ,KJ,K T,K9,K8,K7s,K7o:0.3,K6s,K5s,K4s,K3s,K2s,QJ,QT,Q9,Q 8s,Q7s,Q6s,Q5s,Q4s,Q3s,Q2s:0.5,JT,J9,J8s,J7s,J6s,J 5s:0.3,J4s:0.3,T9,T8,T7s,T6s:0.3,98,97s,96s,95s:0. 3,87s,87o:0.3,86s,85s,84s:0.3,76s,75s,74s:0.5,65s, 64s,63s:0.5,54s,53s,43s

BB:

AA:0.1,KK:0.1,QQ:0.1,JJ:0.1,TT:0.3,99:0.5,88:0.5,7 7:0.9,66,55,44,33,22:0.9,AK:0.1,AQs:0.1,AQo:0.5,AJ s:0.5,AJo:0.8,ATs:0.8,ATo,A9,A8,A7,A6,A5,A4,A3,A2, KQs:0.5,KQo:0.8,KJs:0.5,KJo,KTs:0.8,KTo,K9,K8,K7s, K6s,K5s,K4s,K3s,K2s,QJs:0.8,QJo,QTs:0.8,QTo,Q9s:0. 9,Q9o,Q8,Q7s,Q6s,Q5s,Q4s,Q3s,Q2s:0.9,JTs:0.8,JTo,J 9s:0.8,J9o,J8s:0.9,J7s,J6s,J5s,J4s:0.9,J3s:0.9,T9s :0.8,T9o,T8s:0.8,T8o,T7s:0.9,T6s,T5s:0.9,98s:0.8,9 8o,97s:0.8,97o,96s:0.9,95s:0.9,87s:0.8,87o,86s:0.8 ,85s:0.8,84s:0.9,76s:0.8,75s:0.8,74s:0.8,65s:0.8,6 4s:0.8,63s:0.8,54s:0.8,53s:0.8,43s:0.8

-0.438% after 165 seconds
-0.313% after 219 seconds
-0.247% after 274 seconds
-0.202% after 328 seconds

Memory: 1.5GB
Screen: http://i.imgur.com/wCRNtIy.png

3)SB vs BB in 6max; 60 starting pot, 975 stacks; again 5 bets may go in on the flop which makes the tree bigger. All lines are allowed although in practice it's save to disable say check-call/donk turn one. This is one of the worst cases for Pio because on of the ranges is huge (in number of combos included) while the other is significantly smaller.

SB:
AA,KK,QQ,JJ,TT,99,88,77,66,55,44,33,22,AK,AQ,AJ,AT ,A9,A8,A7,A6,A5,A4,A3,A2s,KQ,KJ,KT,K9,K8s,K7s,K6s, K5s,K4s,K3s,K2s,QJ,QT,Q9,Q8s,Q7s,Q6s,Q5s,Q4s,JT,J9 s,J8s,J7s,T9,T8s,T7s,T6s,98,97s,96s,87s,86s,85s,76 s,75s,65s,64s,54s

BB:
AA:0.05,KK:0.05,QQ:0.05,JJ:0.05,TT:0.05,99:0.25,88 :0.5,77:0.85,66:0.9,55:0.9,44:0.95,33:0.95,22:0.95 ,AK:0.05,AQs:0.05,AQo:0.1,AJ:0.15,ATs:0.3,ATo:0.5, A9s:0.3,A9o,A8,A7,A6,A5,A4:0.85,A3:0.85,A2:0.85,KQ :0.3,KJs:0.3,KJo:0.5,KTs:0.5,KTo,K9s:0.85,K9o,K8,K 7,K6,K5,K4s:0.75,K4o,K3s:0.75,K3o:0.85,K2s:0.75,QJ s:0.5,QJo,QTs:0.95,QTo,Q9s:0.95,Q9o,Q8s:0.95,Q8o,Q 7s:0.85,Q7o,Q6s:0.85,Q6o,Q5s:0.85,Q5o,Q4s:0.85,Q4o ,Q3s:0.75,Q2s:0.75,JTs:0.95,JTo,J9s:0.95,J9o,J8s:0 .95,J8o,J7s:0.85,J7o,J6s:0.85,J6o,J5s:0.85,J4s:0.8 5,J3s:0.85,J2s:0.75,T9:0.95,T8s:0.95,T8o,T7s:0.85, T7o,T6s:0.85,T6o,T5s:0.85,T4s:0.85,T3s:0.85,T2s:0. 85,98:0.95,97s:0.85,97o,96s:0.85,96o,95s:0.85,94s: 0.85,93s:0.85,92s:0.85,87s:0.85,87o:0.95,86s:0.85, 86o,85s:0.85,85o,84s:0.85,83s:0.85,82s:0.85,76s:0. 85,76o:0.95,75s:0.85,75o,74s:0.85,74o,73s:0.85,72s :0.85,65s:0.85,65o,64s:0.85,64o,63s:0.85,62s:0.85, 54s:0.85,54o,53s:0.85,52s:0.85,43s:0.85,42s:0.85,3 2s:0.85

0.435% - 352 seconds
0.328% - 452 seconds
0.265% - 552 seconds
0.206% - 703 seconds

Memory: 2.8GB
Screen: http://i.imgur.com/aatRM2x.png

As to accuracy I don't think anything lower than say 0.25% is practical. If you wanted more precise rivers (where most of the missing exploitability is) you can recalc them on the fly to w/e accuracy you wish (if you make a small save in Pio, say flops+turns you can choose what accuracy forgotten streets are calculated to and it happens automatically when browsing). I consider something like 0.45% very good overview and something like 0.35% the most practical accuracy for normal analysis.

Again, those numbers are produced by 1.4 version. You can find ones made by one of the ancient versions (I think 1.1) in the link in my previous post. I didn't test very small ranges (like MP vs BB) because it's very very fast now and not very interesting but if you want to know, just describe the case.
I would run spots with more bet sizes for you but I didn't understand what you mean in the description.
I consider cases above not very lucky for the solver (cause one more raise fits and makes tree bigger) but also not very unlucky (it's very bad if there are long chains of small bet/small raise/small raise 6-7 times on the flop).


Pro is faster (can use more than 4 threads) than basic and is scriptable.
Edge gets developer versions, is a bit faster (because I make hardware specific compiles which ends up being about 15% faster for new CPUs). We give 3 activations to edge as well as priority support. If you want to run it in the cloud or need something specific which isn't available yet you would probably need to buy edge as well.

This may change in the future. For now we were concentrating on adding basic functionality to all versions. If there is even additional functionality in edge version you would need you can always upgrade.

The benchmarks above are run on i7-3770 @ 3.4GHz with 1.4 release candidate which is at this point unlikely to change (in performance department at least).

Why do you need to specify hand ranges of you and your opponent when GTO shouldnt require that?

Hi,

I believe you asked this on my youtube channel, my email and this thread all in the last few hours so I will just answer this here

Equilibrium solving programs currently focus on solving subsets of the entire game tree rather than all of NLHE. This is particularly appropriate for games like 6-max where the full game is not 2-player but you often end up in 2-player situations postflop.

A full solution to NLHE would require determining optimal preflop ranges and you would not enter "starting ranges". Instead your "starting range" at the beginning of a preflop game tree would be determined by a random deal of the deck and would put equal weight on every 2-card hand combo.

At the moment it is not computationally practical to completely solve the game of hold'em from preflop, particularly with multiple bet sizes in the game tree and/or when stacks are deep.

As a result what programs like GTORB/Piosolver/Simple Postflop offer is the alternative where you use your poker experience / beliefs to make assumptions about preflop play (if the solution starts on the flop, if the solution starts on the turn then assumptions on how people played up until the turn are required), and an equilibrium strategy is calculated given those assumptions. A flop solution from GTORB is a solution to an theoretical sub-game (I'm using that term informally, there is a technical definition of sub-game that doesn't quite match the usage here) where you and your opponent are required to play according to a pre-determined (likely non-GTO) preflop strategy that you input as one of the defining parameters of the flop scenario that you wish to solve. The starting ranges must be input but at ever other point in the game tree after the starting point, the computationally GTO solution strategy is independent of your opponents range. The GTO strategy that solves that theoretical postflop subgame has the following properties:

1. If you and your opponent both play according to your preflop assumptions and you then following the postflop strategy specified in the solution, then when the given flop that you selected comes you are guaranteed to maintain at least the EV shown in the solution no matter what your opponent does postflop, and in general if your opponent does not play according to the GTO strategy postflop but plays as assumed preflop then your EV will increase.

2. If your assumed preflop strategy were to be GTO then the postflop component that the program shows as its solution would be part of a GTO strategy of the full game tree of poker.

3. If you and your opponent play preflop according to the assumed ranges that you use as the starting condition of your postflop scenario, and those preflop ranges are not GTO, then your postflop EV will actually be higher against your opponent using the postflop solution strategy than it would be using the GTO solution to the full game of NLHE. This is because in essence what programs like GTORB/Pio/Simple Postflop actually compute are minimally exploitative strategies based on locked preflop play and a specific flop. I have a free youtube video on minimally exploitative play here if you are not familiar with the concept: https://www.youtube.com/my_videos?o=U

If you want a deeper understanding of game trees, sub games, how GTO solutions to subsets of the game tree relate to GTO solutions to a full game tree etc, then I recommend you check out my Theory of Winning video series on cardrunners as it goes through all these technical elements of game theory in depth in a way that poker players (non-game theorists) can easily understand.

I hope this helps,

-swc

This was brilliant, I will check out the vids now. Lastly can this be opaquely applied to 6max games despite you saying GTO deteriorates past 3handed, as most situations end up with only 2 players in the interaction? - if so, when in situations where applying GTO isnt mathematically possible, is there any information/videos on how to minimize chokepoints in your game where exploitability is achievable for opponents allowing you to get into GTO environments after losing as little EV as possible when NOT in a situation where GTO can be applied?

Glad to help! Regarding 6-max, as long as you and your opponent reach a point where there are only two players left in the hand with specific hand ranges, you can solve the remainder of the game tree (from the point where it went down to 2 players onwards) using your assumed ranges and all the properties I mentioned above hold. As soon as there are only 2 people left in the hand you can solve the theoretical 2 player game with starting conditions that were determined by the previous action (even if it was multiway).

Unfortunately I don't think there is any content (certainly none made by me) analyzing how to play the 3+way portions of a hand so as to minimize your exploitability when the hand reaches a 2-player state.