Choose that.

Explanation: a .zip file is a file that contains other files, compressed to save download time or storage space. It also saves download complexity -- you download one file rather than many. The one file is also known as a ZIP archive. To be used, the compressed files in the archive (.zip file) must be taken out of that file and de-compressed. This process is known as unpacking or extracting.

ok thanks, i have done that though and still seem to be having problems. i will try tackling it later, got things to do for now. thanks for your guys help

Hello,
Why don't add a feature to be able to load scripts?
Now, I have to open .txt file of the script, Select All, Copy, Go to the PioViewer, Paste tree building config, Generate Script, Type the boards, Generate Script and finally Run this script
I propose
Open PioViewer, Load Script, Execute Script

What do you think?

Hello,
Tools->Solver->Load Script
does exactly that - it loads and executes a script.

I'd like an option to be able to generate flops for scripts randomly on the fly based on there not being a strategically identical (in the strict sense: AhKs3h is the same as AdKc3d but not as AsKh3h) flop already in the target folder, and also to be able to save based on generalised notes on board texture (at the moment I manually rename AhKs3h as AK3tt - I get there can be minor differences but I'm not at a stage they matter to me).

While the generation works that way (it won't include the same flops, just increase weight for them if they are picked more than 1 time) it is for now impossible for the generator to be aware what flops were calculated in the target folder.
This is a nice suggestion but we need to think about how to implement it (the problem here is that the names in the folder can be arbitrary and the viewer would need some way to extract the flops from files).

Feature request accepted. Notice that it could be done via a script from any programming language so if you know someone who would be willing to code it they could do that without implementing any solver logic (just operating on file names).

As I am getting a lot of general theory/solver questions on my email and Skype I've decided that I will answer the ones I think could be of general interest publicly. I hope it's going to be more efficient as more people can see the answer and there will be a way to link in the future. I am starting the one from today:

I am going to describe the simplest way to think about it.

The aggressor changed their play from GTO to only value-betting. This means they stopped making some +EV or neutral bluffs. As only neutral and +EV plays could be part of GTO this means their overall EV can't be higher than before which in turn means ours is at least not lower (as EVs add up to the starting pot).

Now, what happens with our 22 (our bluff catcher)? We don't catch bluffs anymore and we only pay-off. This means we make less money with 22 than before. This is true but on the other hand we make more money with our hands which are going to win at showdown but would fold to a bluff. Overall the opponent is going to make the same amount of money from value bets (obviously because we call the same hands as before as we didn't change anything) but they are going to make less money from bluffs. It's true that some of our hands are going to suffer from it and we could adjust to win even more but overall we will make up our "losses" with 22 with other weak hands if they don't bluff enough.

Summing up:

1)they make the same amount of money with value bets
2)they make less money with hands they don't bluff anymore
3)we make less money with our bluff catchers
4)we make more money with hands which would fold to a bluff but now win at showdown
5)overall we make at least the same and probably more than before

Hello punter11235,

Preflop solving issues (Edge version).

Improving upon a given strategy
-------------------------------------

Imagine that I setup some simple parameter problem, e.g. push-or-fold. PioSolver can then compute very quickly (as no flops are needed) the EV of the solution, with an excellent accuracy.

Now, I want to compute the same problem, with an extra strategy for the player that is first to act. e.g. push-or-limp-or-fold. If the extra strategy is a good one, it should improve the EV for this player. If the extra strategy does not improve the EV for this player, then it should be discarded.

- PioSolver cannot figure out that a given strategy should be used 0% of the time. It will decrease from 1% to .5% to .25% etc. but it will never reach zero. In the meantime, the EV with the extra strategic choice is not as good as the EV without it.

- This effect is the same when several bet sizings are available; often one sizing (sometimes two) will prevail, however the % for the other sizings, although very small, do not reach zero. Yet EV is not improved with a wider choice of sizings.

- Having the possibility to setup a starting point for solving would drastically improve the search for better strategic options, e.g. if PioSolver computes 73% push 27% fold for the first player, then we should be able to start 73% push 0% limp 27% fold the new strategy. If the new strategy drastically improves the EV, then the gradient (or whatever you use here) will tell the solver to increase the % of limp. Some "Build Tree using current solution as a starting point" button would be awesome.

About flop subsets
---------------------
I have some trouble in evaluating the accuracy of flop subsets based on their size. Maybe I missed a link where you explain how these were built / how the balance between simple/exhaustive/accurate is created? I really would like to be able to use in PioSolver the complete 1755 flop subset with the exact weights that describe perfectly the 22100 flops. The point is not to use more RAM and more time to make unnecessary computations; the point is to have a better understanding of the accuracy of each flop subset.

I have the idea of some simple problems to test the 1755 flop subset.

Thank you for your help.

That the solver is slow to reach 0 is a known issue which is hard to fix without making an average case worse (or without using significantly more memory). It shouldn't be a problem with pure preflop solutions though as you can just use postflop solver for that and it they should reach 0 comfortably.

Can you paste the config? I would be very surprised if it's the case with any noticeable difference in rakeless trees.

The trees are big and it takes a while, again it's important if you use rake there. If you do, there are other reason for that, if you don't the EVs should very quickly be accurate and you shouldn't notice it.

It's complicated and not easy. If it was that easy it would already be available.
I can make the algorithm to get to 0 quickly and reliably in those cases. The problem is that it's not as good in average case then.
We would of course like to improve the algorithm but a quick fix like that won't help.

We have used the results computed on all 1755 flops to find subsets which approximate the EVs most accurately. More here:

http://piosolver.myshopify.com/blogs...the-whole-game

If you have enough RAM or trees simple enough you can do it. You can find the full subset here:

http://pastebin.com/rJKh4sxN

There is a bug in currently shipped version of the solver which will cause a crash if you use ~1500+ flops. Please email me with your key (or registered email) so I will ship a bugfix for you.

Yep, rakeless tree.

5bb deep, push or fold (no flop here): EV(SB)=5.621 bb/100h with 0.016 accuracy ("exploitable for").
5bb deep, push or limp or fold (17-flop subset) : EV(SB)=5.598 bb/100h with 0.03 accuracy;
5bb deep, push or limp or fold (68-flop subset): EV(SB)=5.611 bb/100h with 0.024 accuracy.
Parameters : When SB limps, BB can check or shove preflop; postflop both players have two bets to reach all-in (the first bet is half-pot, the next bet (or the first raise) is a shove).

The point is to notice that the limping range is a tiny (like 0.3%) fraction of the range and that so far, SB didn't improve its EV by limping. Note : here SB is OOP postflop (non-HU situation), I will also check this when SB is IP (HU).

Of course, I doubt to find any improvement for SB by limping OOP 5bb deep; but when SB plays IP postflop and chip depth goes 8bb or above, I think there is some room for improving the push or fold strategy, SB-wise.

E-mail sent to piosolver.

Well, you are comparing a tree which converges instantly to almost perfect solution to one which takes a very long time. It's true that it may take a while for the EVs to where they should be, especially in the case of preflop solver which is way less precise (because it needs to save memory). In case where the EV differences are very small it may never converge (as the precision for the strategies in a preflop solver is quite big grained it might not be enough to make the final step).

Again, this is something we hope to improve but it's not that easy.

Preflop computation, setting up the flop strategies : I would like to force the OOP check, but I don't want IP to be forced to bet. IP may check or IP may bet.

- If I check "OOP check + IP must bet" and I set 0% as a possible bet sizing, the tree bets 1 chip (minimum bet sizing, regardless of the blind size) instead of 0. Betting 1 chip is not allowed in the game; and there is a bias in solving as OOP will fold a tiny fraction of its hands, even facing 201:1 odds.

- If I check "OOP must bet" and I set 0% as a possible bet sizing, then 1 chip is the minimum bet instead of 0

Any possibility to have a "OOP must check the flop" checkbox on the flop - which happens to be, more often than not, the best strategy for OOP on the flop? This would reduce the size of the tree in the RAM for preflop solving. Thank you.

It's already available (it was available in the first version of the solver as well). Here:

http://imgur.com/OBoLfkV

I have an i7 with 12GB of RAM. About how long do you think it will take to run the preflop solver over 25 flop subsets? 50 flop subsets? Considering it's a laptop computer, should I be worried about over-heating?

Also, is there any information on what kind of postflop inputs are used in the PioCloud 6-max pack?

Trying to solve some simple situations with the preflop solver. "Select flop subset" is offered to select flop subsets. Are you supposed to click a file of flop subsets somewhere?
I don't have any coming with my installation, are these files downloadable somewhere and in what format do they need to be in case you want to make your own?

You won't be able to build any preflop trees beyond toy games with 12GB of RAM.

It depends on manufacturer, condition of your cooling system and climate you live in. In general laptops aren't made to run a lot of hours in a row at max CPU usage. It's recommended to get a cooling pad if you plan to do that.

They are in the "preflop_subsets" subfolder in your installation folder.
If you haven't changed the default settings in the updater that will be: C:\PioSOLVER\preflop_subsets

I show how to choose them, here:
https://youtu.be/LX8n2E3OGok?t=359

I have my raise size for both OOP and IP set to 2.5x but I am getting 3 bet sizes that are not the correct size. For example with starting stacks of 500, versus a flop bet of 26 the first raise is correctly 65, but then the 3 bet is to 123 instead of 163 (or 162). Am I missing something or is this a bug?

2.5x after bet to 26 is 26 * 2.5 = 65.
The raise is (65 - 26) = 39.
39 * 2.5 = 97.5

So the correct 3bet size is 97.5 more which is 97.5 + 26 = 123.5

that makes sense, thanks

About 1 in 10 preflop trees that I solve for will reach a certain point of exploitability and then actually jump up. For instance my most recent simulation which is a 40% opening range versus the big blind, 50 blinds deep using 108 flops (a 116 GB tree) has the following log readouts starting about 10 hours into the simulation:

running time: 36635.600
EV OOP: -1.876
EV IP: 16.876
MES OOP: -1.478
MES IP: 17.163
Exploitable for: 0.342
SOLVER:
running time: 41874.481
EV OOP: -1.870
EV IP: 16.870
MES OOP: -1.521
MES IP: 17.113
Exploitable for: 0.296
SOLVER:
running time: 47129.306
EV OOP: -1.945
EV IP: 16.945
MES OOP: -0.183
MES IP: 18.366
Exploitable for: 1.592
SOLVER:
running time: 52374.835
EV OOP: -1.890
EV IP: 16.890
MES OOP: -1.139
MES IP: 17.511
Exploitable for: 0.686
SOLVER:
running time: 57622.428
EV OOP: -1.878
EV IP: 16.878
MES OOP: -1.383
MES IP: 17.292
Exploitable for: 0.455

Do you know the reason for this? I vaguely recall seeing someone else with this same problem somewhere back in this thread or in the Skype group but I don't remember.

It's a natural behavior of many self-playing algorithms.
It's not easy to fix without using way more memory.

Okay. So in the example above, would you expect that the frequencies and ranges of the solution calculated at running time: 41,874.481 when the log said the exploitability was 0.296 would be very different from the solution at running time: 47,129.306 when exploitability jumped up to 1.592? Is the second solution somehow better/more on the "right track" towards having low exploitability than the earlier solution? Or am I now stuck with an inferior solution and my only recourse is to let the solver continue to run for several more hours until I get a solution with a "low enough" exploitability (which I could arbitrarily say is less than 0.3 exploitability)? So basically I'm wondering if I should be periodically stopping and saving my
solutions so that in case the exploitability suddenly jumps up I don't have to wait an extra 8 hours to go back to the previous level or if later calculated solutions are always strictly better than earlier calculated solutions even if their exploitabilities are higher?

I left the solver running for several more hours and at running time 62,875.468 the log said that the exploitability had returned back to 0.276. Would the frequencies and ranges in this solution look more like those at time 41,874.481 or 47,129.306?

Hi!
Is there any easy way to get the "average" flop "stats" for a given situation?

I mean i wanna know things like 9bb sb limp pot - sb bets flop %.

Now i can do it like watch it on every flop than weight it (like weighted in the flop subset) than calculate an average

Is this is the only way to do it?

Notice that when it got back on track it improved over previous interations.
It's not easy to make any definite statement about the solution before/after the jump other that one was exploitable for more than the other. Where that exploitability comes from is a technical issue I am not going to go into but I hope to be able to fix it one day.

You shouldn't. If it was that clear, the solver would do that itself instead of going into the jump.

It depends how you define "better". The exploitaibility is worse. It mainly comes from parts late in the tree and mainly from rare branches. If you only care about preflop for example it doesn't matter much how big exploitability is after say 150-200 iters as preflop itself won't change much (the info is produced every 25 iters).

I don't know. It's a hard question.

Yes, like here:

https://www.youtube.com/watch?v=VhG_YsEvfwU
(question number 7 - links in the video description)

Hey!
Thanks for the answer.
I tried it and it writes "index is too big". I tried it on a 8.5BB hu solution after sb limped and bb check behind.
And also hide line frequency is unchecked but i cant se the line frequency.