Hard to guess without seeing the script but with 9 sizings it's possible the tree is just too big. Anyway, please send us the script to support@piosolver.com and I will take a look.

I have a feature request, I don't know how feasible or useful it may be , but I will throw the idea out there:

It would be nice to be able to script node locks. One way of maybe achieving this could be to maybe allow a setting where you can force the solver to reduce / increase aggressive actions with indifferent hands at a given node. So all hands the at e.g. are +ev check raises still raise, and -ev ones still never x/raise but indifferent hands are weighted to x/raise some % lower than they would in unlocked solutions.

You could solve across flops for passive / aggressive subpopulations.

Would this be useful, or would it produce weird results. I imagine a lot of indifferences in other nodes would break etc.

Is there any information out there on how to use the range arithmetic tool? I can't work out how to use this tool. For example I was trying to see how an in position player might adapt if the pfr only c/r 50% of the original GTO check raise range Pio computed instead of all of it. I think I would want to use the multiple tool somehow but I'm not sure how.

Thanks.

Yes this is somewhere in the pipelene, but...

This is not as simple as conditions like: "do X with top pair" etc.
Here the solver would need to solve first (to see what takes aggressivea actions etc.), then lock, then re-solve from there.

I tried something similar in the past ("reduce bluffs on big rivers", "remove 20% of marginal calls" etc.) and the results are usually an obvious adjustments from the GTO strategy. That's why it's nice to know where the equilibirum line is - adjusting from it to a leak we can identify usually isn't very difficult.
Still, this is a nice feature and something we definitely have on the "would be nice to have" list.

It looks like you need node-locking, I made a video about it some time ago, here:
https://www.youtube.com/watch?v=a_OhaxBi7mY

It was before combo locking was implemented though.
What you want to do is:

-use the editor (ctrl + n) to get the strategy you want (it's visible in 13x13 grid in on the left)
-check "lock all hands" radio button at the bottom
-click "set strategy and close"

Now, before solving anything make sure the strategies are set to what you want. Navigate the tree to that decision and click "strategy" to confirm. You should also see "LOCKED" flag in the left upper corner in the node description.

Now go to treebuilding and calculation tab and click "go" to solve with the locked nodes.

If that doesn't clear all things up please let me know

hi punter, i have 2 questions regarding accuracy:

1) it appears that using an accuracy of 0.25% of pot in single raised pots, where the pot hu is usualy around 50chips (5bb), is very different from using the same accuracy in 3bet pots where the pot is around 200 chips (20bb), thats why Ive always used bb/100 for accuracy. Now, when i finally decided to use a script, in the settings up a script i dont have the option to set accuracy in bb/100. Should i just convert it from 0.25% of pot for 50 chips pot to 0.06% of pot for 200 chips pot?

2) when opening a small save tree (turns included) at what accuracy does it solves the rivers? It solves them at the accuracy that is happened to be set on the calculation tab (local setting), or it solves them at the accuracy that was used to solve the tree in the first place?

>>1) it appears that using an accuracy of 0.25% of pot in single raised pots, where the pot hu is usualy around 50chips (5bb), is very different from using the same accuracy in 3bet pots where the pot is around 200 chips

It is different although it's likely a good idea to use % because the errors relative to the pot will be of similar magnitude (and that's what determines the quality of the solution).

Yes, although our current algorithm is designed to save as much memory as possible at the cost of accuracy so going down to 0.06% might take a very long time, especially if the trees are complicated (with a single bet size it should get there).

It's determined in Tools->Configuration->Behavior, the default is 0.05% (0.0005 of the pot) although changing it to 0.0002 shouldn't introduce much delay (unless the river betting structure is really complicated). More here:

https://www.youtube.com/watch?v=VhG_YsEvfwU (question number 5)

A question about the use of weights:

I'm using the 100 flop set to study post flop play, and I have partitioned it into 5 non-overlapping classes of flops:

1. Trips
2. Monotone
3. Paired
4. High card (one, two, or three)
5. Medium/low cards

The categories are non-overlapping with lower categories not containing any boards that fall into higher ones. For example, category 5 contains all unpaired, two-tone or rainbow flops without a high card. Say I want to run an aggregation analysis on the category 5 flops. Should I include the weights when I set up the script for a most accurate result, or does the use of weights only make sense when doing aggregation analysis for the whole 100 flop set?

I am assuming that by "the 100 flop set" you mean one of the ones provided by us.

This is a tough question as subsets of a subset aren't tested for how good EV approximation they provide. My intuition would be to use the same weights and hope for the best though. I don't have a better answer that this vague suggestion though.

I calculated two very similar preflop scenarios (6BB, 25 flop subset, only difference is ISO size). The first took 30 min. or so to reach a Nash distance of 0.5BB/100. The second I've been running for 2 hours or so and still hasn't reached the same Nash distance! Looking at the logs, I see that the exploitability has been going up and down around 0.8BB/100, not really making any progress beyond that. Any idea why this is happening?

The preflop solver isn't very precise (because it needs to save even more memory than the postflop one) so it won't reach very low exploitabilities. If the goal is good approximation of the preflop ranges you don't really need anything lower than 2bb-3bb/100. Most of that exploitability is on rivers anyway.

How do I run multiple scripts one after the other?

I've often heard you explain postflop exploitability in terms of 0.5, 0.35, and 0.25 % of pot. Do you have analogous numbers for preflop calculations?

Hey, I was just curious if PioSOLVER recognized Virtual RAM created on a Hard disk, or if it was solely Limited to the Physical memory installed in the system?

I answered this question in this thread, here:
http://forumserver.twoplustwo.com/sh...postcount=1578

Check out extended Skype group FAQ as well, here:
https://docs.google.com/document/d/1...h.g7mc8bun7z1o


It makes sense to use bb/100 in preflop calculations because it's not clear what the starting pot is (depends how you construct the tree it might be 0 or it might only contain bb etc.). I would recommend trying to get to 2bb-3bb/100 as the solutions really don't change much after that (at least preflop ranges) and the solver have problems going lower than that. 4-5bb/100 should be quite good already as well.
For some trees (when you force raise/3bet for example) it will be even higher than that (for obvious reasons: the starting pot is effectively way bigger).

It tries to be limited to physical memory relying on Windows reporting how much physical memory is left (which is not always accurate).
The reason for that is that using a swap file would be way too slow and your system would slow down to a crawl if you tried to do that.

There is an option to ignore the physical memory check, like here:
-open the viewer
-hit ctrl+b (arbitrary solver command windows is going to pop up)
-type: "ignore_mem_check on" (without quotes) there and hit enter
-build your tree

I strongly recommend against trying this though

When you say that preflop ranges really don't change much after 2-3bb/100, you mean how the solutions appear visually, right? Still, seems like a gain of another 1bb/100 would be significant. I imagine that you're saying this as a matter of practicality - that even if we get that extra 1bb/100, it's not really feasible to implement those changes into our game (because the strategies look very similar visually). But if we were to calculate to 1bb/100, the EV improvement would be entirely due to the change in preflop strategy, and not because postflop somehow improved, correct? (Because the postflop has to be recalculated each time the preflop strategy is changed.)

Also, what flop subset would you say is enough, and gains from anything beyond it wouldn't be worth it?

Edit: Just came across Jesolver. Looks like it came out a while ago...is it faster than the edge version's VAX solver?

No. I mean it's already good, good enough and won't improve.

It's the opposite. Most of the exploitability is postflop mainly because postflop we are saving memory to fit those tree so they are less precise than they would normally be.

It doesn't need to be recalculated, the same way turn doesn't need to be recalculated every time flop is changed. Postflop is converging step by step, the same way preflop is.

I don't want to answer this question because my intuitive advice was criticized both ways enough times (some people feel they need less flops, some feel they need more). It's a matter of judgement what you consider a significant change.
When it comes to EVs and overall frequencies and more or less "shape" of the solution then likely 60-70 is very good. If you want to see exact mixing in semi-bluff combos then it's likely more than that.

It's faster for postflop trees, mainly simple ones (by factor of 3x to 5x). Once you start adding bet sizes then the difference is way smaller. In general the bigger the tree the less speed difference there is.
Those speed differences assume infinite RAM, Jesolver uses way more RAM but can compress trees if needed. The cost of compression is performance, if you compress just a bit the performance suffers maybe 15%-20%, if you compress a lot it becomes way slower. You can download a trial version and test it on Qs Jh 2h flop as it works there.
Depending on your usecase it can be great value so I recommend you check it out.

Would it be possible to get a rough estimate for how long this preflop calculation would take on a dedicated server?

Estimated tree size: 256GB
Nash distance: 1bb/100 or 2bb/100
CPU: Intel Xeon E5 2 x E5-2650v3 20c/40t 2.3/3.0 GHz

It's hard to say, depends on the ree (some will never reach 2bb/100, some will be there very quickly). Likely around 15 hours.

First of all i would say sorry if the request isn't 100% inherent with PioSolver.


http://imgur.com/a/6sUTI

How can i line up those stats in excel file? I see that in video faq and guide all results are distribuited separated by columns and cells. I'm using windows excel 2007.

Thank you very much.

I've answered this question, here:
http://forumserver.twoplustwo.com/sh...postcount=1666

I'm trying to remove a part of the tree using the Remove Lines option. I'm IP and the flop goes check-check. I want to only have a folding range when OOP bets into me on the turn.

I tried to add these two to Remove Lines:

check, check, bet, raise
check, check, bet, call

I get an error message:

"Can't remove the line (it doesn't exist or is the last child)."

Removing only one of them (either one) works, but not both. What am I doing wrong?

Does anyone have any suggestions/reviews on buying preflop solutions for piosolver?

^^
MTT and shallow HU solutions*

^^
HU with antes

I might be able to help.

In the range tool define a new range where you select weight = 0.5 and select all the hands, then save as, say, "whole range weighted half".

Now, in the node locking tool, select the range tool on the check raise range and mult it by the pre-saved "whole range weighted half". The result will be half the check-raise range. By selecting the options in the node lock tool the no longer check-raised combos will be distributed to call or fold. Lock and save. Now rerun to exploit the lowered check raising rate.

Hope that helps!