I have some questions regarding PLOCalc. You mentioned that this program is not a solver and you have plans of creating a solver in the near future. Can you let me know when the approximate date of the solver release?

Also if purchasing PLOCalc today, will the solver be considered in the same product line as PLOCalc so upgrading will be the difference in price?

Thirdly, how will the solver compare to MonkerSolver? Similar in functionality? Improved functionality?

Just make PioViewer's window bigger so there is enough space for the results to fit

What do you mean by "stops"? Is there any kind of error? Does it save the tree before reaching the desired exploitability?

We don't do ETAs. It's a problem which proved to be impossible to do correctly by about every software team in the world so we are not even attempting it.
There will be a free version of PLOCalc in foreseeable future as well (it's not the highest priority right now but we realize it's important if we start targeting wider audience).

Yes.

To be honest I don't know much about MonkerSolver. From what I've seen on their website and support thread here their software is based on heavy abstractions, they don't show full exploitability, EVs etc. We are going to do full solver without abstractions (similarly to Holdem, at least in the first release), show EVs for every hand at every point, total exploitability etc.

It's hard to say how good their abstractions are (by their own admission). It will be possible to say more once we ship the solver without abstractions so then you will be able to compare. Value of abstraction based approach is determined by how good those approximate the full game. It may be very good or very bad. It's really hard to say without testing against unabstracted solutions.

Here's some updated benchmarks, now overclocked at 3.95 ghz

No, the script just ends before it reaches desired exploit ability for flop 77. I will try again now to see if perhaps the issue was fixed. (I reformatted computer again)

Update: yes again even with my computer reformatted (i had completed hands from script saved to another hdd) it just stops working during flop 77. CPU Load drops to 0%. Looks like the flop its having trouble with is: 6s9dKc:0.16

which is the 77th flop from https://cdn.shopify.com/s/files/1/07...46264467327999

It seems to sometimes stop early on when exploit ability is still high like 50, and sometimes stopping when exploitability is lower. Seems random. I am continually restarting the script in the hopes it will get past this trouble flop.


Update:
Well after 6-7 restart attempts on the script, it looks like it finally made it through flop 77
(6s9dKc:0.16 ) without stopping. Hopefully it will go through the rest of the flops from the 95 flop list I used without anymore hitches. I will let you know if I have anymore issues with the script. I do wonder why it started having problems though.

I am really not sure what's going on. I've never seen such problem and our users run thousands of scripts at this point (some solve many spots on all 1755 flops for example).
Can you send me some kind of screenshot from the solver's window (when it stops on that flop before reaching the required accuracy). Does it save the flop and continues to the next flop or what happens?

It does sound like some kind of misunderstanding to be honest. I would really appreciate some more information of what exactly is happening.

One wild guess I have right now is that you are clicking on the console window and marking part of the text by accident. There is a feature in Windows that it causes the process to stop when you do that. That would explain why CPU usage goes to 0% (because you paused the process).
Another is that after some time the computer hibernates or goes into some kind of energy saving mode.

Again, I will need more information but it looks like something is interfering with the solver's process.

Well I was just about to say it paused again at flop 82, but then I think I somehow ended up resuming the process again by pressing any key on my keyboard.

So yeah it looks like highlighting the script was causing it to pause. Any way to disable this feature of windows?

Glad we found the reason and its not a big deal

To be honest I have no idea. I've got bitten by it in the past as well. It's not a Pio thing, it works for every console app in Windows

How can i have pio showing in colors the max ev line? for example here green should be the dominating color

In Strategy+EV view the colors represent strategies. On your picture it's around 85% bet and 15% call (eyeballing it). You don't really want "max EV line" to be highlighted because it doesn't convey useful information. The reason for it is that the EV is calculated against current equilibrium approximation which is not perfect yet. The action is mixed so it's safe to assume bet 110 and a check would have the same EV in perfect equilibrium. The difference in EVs among actions which are mixed is a good measure of how close the solution is to the perfect equilibrium but you can't really conclude that one action is better than the other (if that was obvious the solver would just choose this action with 100% frequency).

It's entirely possible that after a step of two of solving the EVs for bet 110 and check would flip or get closer to each other. For practical purposes they are essentially the same.

A couple questions from a long-time user of Pro Poker Tools about PLOCalc as a possible replacement/upgrade.

1. I couldn't tell from the videos whether PLOCalc is set up to do equities in multiway pots. Is this possible?

2. Is there any plan to add equity calculators for Omaha HiLo, Stud, Stud HiLo etc? I can see how this might be challenging given the advanced gui of PLOCalc.

Very impressive work btw!

Hey, if I understood correctly , it is prohibited to share second activation of my PioPro with some other person? Thanks

A few humble suggestions--
- When looking at hotness window, it would be cool to see the line frequencies across runouts... Esp useful for small saves where we lose that data.
- Undo/redo buttons/hotkeys in Select Range window
- Invert selection button in Range Explorer
- Time stamps for script window

It isn't. Unfortunately range vs range vs range equity seems unlikely. Even range vs range takes a few seconds. Existing tools calculate it based on monte-carlo method (and not for all hands in range) and that kind of defeats the purpose of our tool (where you can graph resutls for all hands, sort them, see exactly which hand is in the middle etc.)
Full equity 3way preflop is completely impossible without approximations (notice that current pf equity tables are 1GB big already).

Not immediate plans but it's possible as we could probably use most of our current interface. Calculating preflop tables alone takes about 2 weeks on quite a big server so it's not a trivial amount of work

Most of the features in our tool is based on range. You can sort it, filter parts of it, graph it, split to various hand categories etc. I am not sure if tools based on range makes as much sense in Stud/Stud HiLo. My intuition is that they don't. Probably monte-carlo based tools for single hand vs range are a better fit for those games.

From our point of view there is one owner of the license - the original buyer. You can choose to share the license but the other person has 0 rights to it (That includes support, requesting resets etc.). From our point of view is that you running the license on some other computer.

We are ok with it as long as you accept those terms. For this reason it's also a very bad idea to re-sale part of the license. The buyer has 0 recourse if the owner changes their mind. Various scam attempt based on re-selling licenses already happened. The simplest scam the potential buyer has no defense against is this:

1)person A buys a license from us
2)person A re-sells it to person B
3)person A requests a refund or hit us with a chargeback dispute which causes the license to terminate (naturally).
4)Person B is left with nothing and no recourse.

Another one is this:

1)person A buys a license from us
2)person A re-sells the license to persons B and C
3)(optional) person A requests a refund or hit us with a chargeback

We have no interest in either facilitating those or arbitrating inevitable mess resulting from those transactions. If you buy a Pio license second hand you will be scammed one way or another unless you know the person very well and trust them.

You can show frequency across runout in the main window (right upper corner). This data is available for the streets saved in the tree. Calculating it for streets beyond that would require recalculating the whole tree.
Would you like to have the same number displayed when opening the hotness tool or do you mean something else?

Added to the to-do somewhere but I will be honest: it won't be a priority for a long time.

This is pretty cool, added to the to-do

Solver output contains time but I guess you would like overall time displayed from time to time? This is easy to implement for us and in fact you could insert the command displaying time between trees right now (solver_time command) but I would like to understand how often you would like those timestamps be displayed.

I was thinking wrong before about how it works, never mind.

But maybe after solving rivers again to display upper right, not sure if useful. I saw early itt you said you didn't recommend using the 'rebuild_forgotten_streets, solve_all_splits rivers' method for small saves. I was trying it just now in a 3bet pot but cancelled. Does it take the same amount of time as solving a new tree?

The local time at the time of the tree dump along with seconds elapsed. Not super necessary, just a thought.

I was actually working on getting rebuild_forgotten_streets to work correctly for both preflop and postflop yesterday so that will be more reliable in the next release although still the recommended path is going to be:

1)rebuild_forgotten streets
2)set_equal_strats (so you reset the tree to its initial state)
3)solve

I don't recommend doing it now because the implementation is not very good and it will take much longer to solve than just solving from scratch.

Probably about the same time. The problem here is that you need to choose river accuracy you want the tree to be recalc to. If it's standard recalc accuracy we use for browsing small saves it will take forever (this accuracy is very good, we can afford it because it's only recalculated on rivers you visit - a small fraction of all runouts). I will see if I can add a functionality of normal solving with flop/turn "locked" but from the tests I've run in the past it won't be much faster than solving from scratch. Currently solver_all_splits works with recalc_accuracy as well so unless you change it to something less demanding it will just hang trying to get there on all rivers.

Seconds elapsed you can already get by inserting solver_time command in the "command to execute on each tree before saving" field in the tree generation window.
Local time: I will add it to the to-do but no promises for the next release.

Thank you for the illuminating reply

I think I'm now up to speed on the current situation of computation in PLO, but just to make sure:

For range versus range full computation is possible (PLOCalc).

For range versus range versus range (multiway) full computation is unfeasible, and the best alternative is sampling approximation (monte carlo) (Pro Poker Tools etc.).

Given that multiway is so important in PLO and that PLOCalc is the best for range versus range, is this a recipe for insanity ? Two tools, one full solution, one approximation, two scripting languages, shuttling back and forth between them etc.

Any advice would be welcome.

Yes, this is possible without approximations and for all hands in range.

Yes. It would also be very costly to calculate equitie for all hands in range in range vs range vs range scenario so my guess is that it's usually done for one hand vs 2 ranges in other tools.

Is it really that important? I understand preflop all-ins scenario where you want to see if you have enough equity, that we may add at some point (doing sampling, the tables necessary to calcualate it exactly would be more than 1TB big). Do you think postflop equity multiway is important as well or are preflop scenario the main use case?

We will likely add range format converters once we understand which tools are the most popular right now (as long as they have open format for ranges). We may add multiway equity based on sampling at some point as well if there is demand.

I'm not sure I've ever seen any sort of study looking at whether multiway pots are more of a factor in PLO than holdem, and it's an interesting question. It certainly feels as though they are.

I think a common scenario in PLO is one where you are holding AAxx multiway. With AAxx heads-up, if a substantial portion of the stacks have gone in before the flop, you'll have the green light to push on just about any flop and against just about any part of the opponent's range. Multiway gets much trickier, and there are a lot more amber and red lights, if that makes any sense.

Perhaps what I'd say is that heads-up range versus range is the basis of PLO, as in holdem, but that I'd guess based on the nature of the games that there's a little more additional to be gained from studying multiway in PLO than in holdem.

I'm purchasing PLOCalc today, and looking forward to using it!

Anyway to get piosolver to load "runouts aggregated frequency analysis over multiple files" faster? I'm trying to load a 95 flop file, but its taking very long (at least 5 hours, maybe longer). Also doesn't seem to be utilizing my computer's full power to load the file, as cpu is sitting around 1%-5% load

Yeah, those simple scenarios are probably possible to calculate (as long as there isn't complicated play preflop and postflop) even multiway. On the flop you can calculate it exactly. With some effort you can do that with PLOCalc (you would need to filter folding range and calling range and then calculate your equity against calling range). We may add simple decision tree functionality at some point (although even now it's possible to simulate it just requires doing some of the calculation by hand) if there is demand. Scenarios as you describe would be a perfect fit for that.

I can definitely see that preflop and in the scenarios you described with very shallow stacks on the flop.

We hope you like the tool. It's still early in the release. We appreciate any feedback/suggestions. As it's a still small user group we spend more time talking to users (both emails and Skype) so if you would like to be more engaged in the feedback/suggestions department drop us an email and I will give you Skype contact.

Are you running report on the river using small saves? If that's the case then yeah, that's going to be slow as it needs to recalculate big part of the tree as it goes and it doesn't do it in the most efficient manner. Reports on full saves or on small saves as long as they are calculated on the flop/turn should be very fast.

Oops double post

Im loading a report from a full save on the flop. Took about 10 hours to load 95 flops.

Its definitely not recalculating anything - since cpu load is remaining low

Yeah, ok it's slow because:

1)loading from disc is slow
2)building the tree itself isn't the fastest process
3)unloading previous tree is very slow because we are using default Windows memory allocator which is god-awful slow

3) is especially painful if those are big trees.
In general it's way better idea to do small saves, reports on flop/turn are going to be very fast then. On rivers they will be slow but apparently they are too slow loading from full saves as well.

This is sadly something unlikely to change. While we can make 3) much faster with custom allocator which will likely happen at some point reading from disks is always going to be slow and building trees (from scratch or from saves) is likely to stay single threaded.

Hey punter!

I am currently running PIO edge on a virtual server, amazon cloud EC2 m4.10xlarge which has 160gb memory and 40 vcpu.

When I run the first instance say small blind open, big blind defend with unlocked ranges, PIO is lightning fast. From there, I try to keep the tree up for the second round (since saving the full file so I can node lock takes up almost all of the disc space), and when I node lock and click "Go" I notice that piosolver is taking a very long time to even process the "Go" request. I've noticed this sim has taken 3x the amount of time as the first and it's only solved down to 12bb/100 (not going to try to solve down to 3bb/100).

Now I'm trying to click the stop button to just end the sim and it's been 30 minutes and nothing has happened. It's showing 47% RAM usage in task manager and nothing is happening. This is what always seems to happen with PIO edge, the longer I keep it on and running the slower and slower it becomes until it's basically unusable. This is the reason I purchased the amazon cloud services is so that computer ram or speed wouldn't be an issue.

I'm forced to just run the first iteration of the tree and either quit there, or try saving the full tree, restarting amazon cloud and re-loading the tree back up for the next solving round where I'm trying to now put in the pools 3bet frequencies.

Thank you for your time and help with this issue! Cheers!

I am not 100% sure I understand what you are doing exactly but I am assuming this:

1)build tree
2)solve it to good accuracy
3)node-lock
4)continue solving

Sadly this won't work well because the solver remembers it was already far into solving and internal "step" variable got quite low.
Better way is to do this:

1)build tree
2)node-lock (without solving)
3)solve

I really have no idea why that happens tbh. Stop waits for the iteration to stop which may take a while but then your CPU usage would be very high.

Most likely it's an issue with Windows memory allocator. It's a good idea to restart Pio between very big trees.

Wait, what happens if you just let it running?
Basically it's a bad idea to node-lock on already solved tree and continue from there. You should node-lock on a fresh tree and only then solve.

Please let me know if it's not what you meant.