I really like this suggestion. I often find the sizes are too big in my 3bp/4bp if I'm only using one size post, which often means it's trying to get stacks in over two bets. That skews the pf ranges. Agreed that 1 small, 1 geo and all in are a good representation of the NLHE postflop space.

A simple implementation would be to allow users to enter a code like "e3" to indicate 3-street geometric sizing in the postflop bet sizing hints. Then if you want a block-bet you can just enter something like e7 or 25% in the 2ndary postflop sizing.

The sizings are already geometric, your bet sizing hint just determines how many bets are used to get all-in. If you enter 75% pot as hint then it will select the geometric sizing with the number of bets such that the resulting bet size is closest to 75%. Wouldn't using constant 3 bets to get all-in result in some absurdly large (or small) bets in some cases? This is actually much more important in tournament calcs, where we'll have drastically different stack-to-pot ratios depending on the active players. A limped pot could have SPR=50 or SPR=5, depending on which players are in the pot.

I don't think there's that much difference between "1 fixed small + 1 geo" vs "1 small geo + 1 larger geo" (which is what you can do already). In the scenario you mentioned, this would result in one sizing being geo2 and the smaller sizing being geo3. (A benefit of using two geos is that you won't ever have awkward overlaps. e.g. your fixed sizing could end up to be almost identical to your geo sizing for some SPRs or leave some awkward leftover amounts. That won't happen when using 2 geos.)

Anyway, allowing different sizing input options is actually really easy to add, we can definitely do fixed sizings and/or geo-with-fixed-#bets in addition to the current option. I think we'll keep the current one as default though.

This is a feature that's a pretty big deal for effective tree building.

Didn't mean to imply that this wouldn't be added later, could be as part of the tree editing or in some other way. But the Preflop building has priority for now.

Hello, I am using the trial version and I'm on the fence about buying it. Is there a tutorial that shows a complete newbie how to use it ? Newest version?

The main advantage would be that it would keep bet sizing appropriate for the SPR, avoiding situations where for example it solves with 75% bets in 4bet pots. For very small SPRs bet sizing is supposed to be absurdly small + allin.

For 100bb single raise pot situation you can refer to this image:



We have two very clear clusters round 3 street geometric and around ~33%. Thus why I said that block bet + 3 street geometric is a fine abstraction to use. The only other thing to note is that the raise size vs block should be something like pot to avoid the tree getting too large.

I'm happy to support fixed street geo, that's a fairly trivial thing to add and I'm sure it has its practical use. Not convinced that it's a good default for a wide range of SPRs though, I'll look into that.

In isolation that plot you posted really doesn't allow too many conclusions. Any chance you could post a similar graphic for varying SPRs? (Or maybe link the thread if it was discussed on here.) Thanks!

thank you, if i see it again, I'll screen shot it to you. If it doesn't affect the calculations I'm not sweating it.

The latest update provides a first work-around for this. You are now able to change the abstraction size after the initial calculation. Start out with a minimal abstraction (i.e. 64 buckets), prune, and then adjust to a larger abstraction as needed. Still not ideal, but it should help a bit until we have advanced tree editing ready.

---

Regarding general progress on the betsizing / tree building options:
There's been a lot of new requests in that regard and we are making sure to pick a flexible approach to tree creation. We are currently evaluating several options, including support for scripted building.

Really enjoying the Beta version so far.

Have a question regarding the betsizing setup:
When is it necessary to add a 2nd (smaller or allin) geometric betsizing? And when is it sufficient to just keep the default sizing of 75%?

In other words, how much difference does it make to add multiple geometric sizings?

Hey, I know that graph! Those are flop cbet sizing preferences for BTN vs BB SRP, 100bb deep, solved over a complete 1755 flop subset by GTO Wizard. That bimodal shape is very common in IP vs BB 100bb SRP spots.

https://forumserver.twoplustwo.com/1...lysis-1792863/

Great update! I like to solve with low abstraction and a complex tree first to get a sense for optimal sizes, then prune and resolve with better abstraction. So this helps a lot.

For those wondering, it's under the "hand" dropdown at the top.

I would like if the allow flatting of 3bets & 4bets option only applied to the initial raiser. I don't want any cold calls.

Adding all-in is generally not very costly in terms of tree size, you can probably have this on by default.

As for a second geometric sizing, this really depends on your requirements and the type of hand you are calculating. Having a single ~75% geo sizing will generally give you a decent approximation of Postflop equity realization.

Adding a second (smaller) geo sizing, e.g. ~33%, will make the equity realization more accurate, but that comes at the cost of a much larger tree and longer calculation times before you get usable results. Small sizings are especially expensive because they can result in very deep action sequences!

I'd recommend to experiment with a few hand setups to see if the 1 geo sizing solution is sufficient for your requirements or if the added accuracy of the 2 geo setup is actually worth it for you.

With all the feature requests coming in, I don't think we can realistically cover everything with a "simple" UI.

So, the current plan is:
*) Offer scripted tree building where users can define the available actions in some accessible script language. You should be able to fully customize the tree build that way.
*) Possibly scripted editing, where you can prune trees after creation via user defined filters / scripts.
*) Above should cover most requirements of advanced users. We'll keep the non-scripted betsizing UI relatively simple and accessible for new users.

Thanks for your reply.

If the results take too long to converge with 2 geo sizings, do you think it makes sense to use one single geo sizing that's the average of the two sizings? So instead of 70% + 30%, is it better to use 50%? (because right now the standard sizing is 75% which seems rather large since most hands played in MTTs have rather low SPRs)

The default 75% leans towards the larger side because this results in smaller/quicker calculations. If this seems too large for your games and you have sufficient memory then feel free to adjust it.

Maybe try a small setup (e.g. HU) with 2 geo sizings (75% + 33% for instance) and compare the ranges to calculations using a single geo of 50% / 75% to get an idea how much difference this makes.

IMO geometric works well for the initial bet, not so much for the raise. In general there is an inverse relationship between bet size and raise size. The bigger the bet the smaller the raise and vice versa. This also works out quite nicely for abstraction purposes as it avoids the huge trees that 33% geometric raise creates.

I could see some sort of algorithm where the first bet is geometric and the raises are larger or smaller depending on the size of the first bet. Benefits would be trees being more accurate to optimal play and keeping the abstraction size in check while using block bet.

Does the strategy converges to 1 certain strategy, as sampling goes to infinity or will it always fluctuate? And does more sampling necessarily imply more accurate (closer to GTO) strategy?

If you disable decay then strategies/EVs will eventually fully converge/stabilize, yes.

As for "closest to GTO", that's a bit more complicated. As you run more samples, the exploitability within the abstraction will converge towards zero. So you eventually reach "perfect GTO" for the game where all players have to play within the restrictions of the abstraction.

The exploitability for the full game (not restricted by the abstraction) can actually peak and then drop off slightly after some point though. Essentially, as strategies reach full equilibrium for the abstracted game, players will start abusing some spots where the other players can't respond optimally due to limitations of the abstraction. This obviously won't work for the full unabstracted game and the strategies can become a bit more exploitable in the full game. (It's not a big drop off in the games we tested and that effect shouldn't be relevant in practice. Read up on abstraction pathologies if you are interested in details.)

i havent download the latest 2 versions so i dont know if this was implemented but are you planning to support 1rfi+3callers instead of 2 in the next update?

Hasn't been implemented yet but will be first supported as part of the scripted building. Prototyping looks good, I hope we'll have a first version ready for public testing within a week or so.

Obviously, expect much larger trees with 4+ players Postflop.

in lower stack depths we have many situations that allin and fixed rfi is required. Since the range of both depend to each other it would be very helpful having the option to choose with ctrl multiple action to rerun

Same but not so important with pruning. I constantly misclick prune 3bets and i have to rerun and prune from the beginnig. Having the option to select and then prune multiple actions would avoid this problem

Thanks

For that scenario it doesn't matter which of the two ranges (rfi or all-in) you select, they both start at the same decision point and subtree sampling will update both actions no matter which one you selected.

e.g. If you select a rfi ranges then subtree sampling processes all samples where it is folded to the selected player (or in other words, all samples where the player has to make the decision whether to rfi or not). That player open shoving all-in also falls within that same subtree.

We'll look into multiple selections, shouldn't be hard to support. We'll focus on these quality-of-life improvements once the scripting / sizing features are ready.

Hopefully much of the pruning should no longer be necessary with scripted builds anyway.

Amazing new beta !

Im playing with differents solutions for PKO and i would like to change bit some things that could be interesting (Im reading that u are working on some of bit)

Some ideas:
- Allow Limps only for SB or positions u decide pre building
- Sizing 3B IP - Sizing 3B OOP
- Only one auto sizing postflop in function of the SPR (Like Monker has, and aprouch good results in less time)
- Can decide maximum players in the pot postflop. I dont want OR HJ + CC CO + CC BTN for example. Maximum 3 per MW pot and next option will be 3b or fold
- Dont create big trees with solutions that never happens like before spot or for example or+ 3bet, cold call 3bet, and plus other call behind, etc

Thank you so much !!

I think all of the above should be easy to do with the new scripting. Hopefully we'll have a first version later this week, give it a try and let me know if you need any changes.

How do i solve that happens in a PKO phase tournament on day 1?
Should i add half the prize pool in prizes and then the total chips 25k x 95
any difference is the phase1 is on late reg or not ?
thanks

https://gyazo.com/957fb8db11a643d8ea06399958466caf
https://gyazo.com/8ef767218283fc12fc8fea751c501fb0