Those solutions seem to work. Thanks for explaining.

Does monker take all flops into account or only a subset?

What do compress and regret do when saving?

Found the answer earlier on:

"Regret is required to continue solving the tree and viewing the strategy where you don't have the average strategy, which is all but the first street unless changed in settings.

Compress will do a slightly lossy compression of the strategy to significantly reduce save size (around 10-20 times smaller)."

I'm trying the monkersolver free version, but I can't seem to get PLO simulations to run. NLHE seems to run just fine, but when I try PLO it gets stuck on "Starting..."

I've tried to monotone board, river, low SPR, but it still wont start running.
My pc has 12gb ram and ive set the document to "-Xmx12g"

Suggestions?

https://imgur.com/a/xrqW1

Yes, atleast relative to other solvers. I'm not certain how important it is.

MonkerSolver does not use subsets, and distinguishes between all flops. This is reflected by the "Texture" abstraction setting, where the only possible setting for the flop street is "Perfect". Turn (unless "Perfect" is chosen) and river will however not be perfectly distinguished.

As turns and rivers are merged, flop subsets would not significantly affect the overall game size. When reducing the number of flops, the real purpose is to reduce the turns and rivers, but this is already done due to the abstraction model MonkerSolver employs.

The only reason I know of which has that effect is an invalid game tree. Did you try with an empty default check-down tree?

Other than that, not sure. Try updating java and reinstalling MonkerSolver.

Do keep avg strategy (street) and EV (street) do the same thing? For mw trees, it is okay to set both to 0?
Would you explain what exactly they mean?

EV disappeared from strategy view (in Solve) with the recent update.

Could you add some sort of copy/paste from one subtree onto another? What I mean is, I often run a preflop tree with 2 sizes to compare them and I have to create both postflop scenarios. Since I'm using %s for postflop bets, copy/pasting them would be very useful and would save a lot of time.

When I compress a save, it's barely a dozen KB large. Is it supposed to be this small?

When I load it up, it throws me a NullPointerException in the status bar.

I get the same mistake please fix it asap

The feature to export to excel got added? I'm missing something, when I click export there is no excel file in the ranges folder. Just .rng files.

nvm, figured it out.

Has Monkersolver been used to compute accurate multiway pre flop ranges for sale by anyone? The BTN/SB/BB equilibrium would be interesting to look at.

preflop estimates appear to be quite off for larger trees.. the largest ones I am able to get off the ground with 128gb are <90gb

Just to make sure, to include 5% rake we just put "5.0" in the Settings, not 0.05. Right?

No, they don't do the same thing. It may be okay to set both to zero depending on the circumstances.

EV allows you to see the EV of hands on the specified number of streets. It will not affect the strategy in any way.

Avg strategy is needed for exact frequencies, as the current strategy (which will be shown if no average is available on the street) tends to oscillate around the correct frequency.

An example of this would be the nut/bluff vs bluffcatcher river spot, where the nut/bluff player has a pot bet left. The equilibrium would be to bet 100% nut, and 50% bluff. The bluffcatchers correct frequency would be to call 50%. However, the solver will not reach this equilibrium without averaging, but instead the bluff and bluffcatch frequencies (which are not dominated) will oscillate around 50%.

In practice, it's often enough to know whether a hand is mixed or not. Also, in Omaha, due to the large number of combos, it's less important. It's also less important (and potentially harmful) in multiway games as there are no exact non-exploitable frequencies. In this case, the aim should be to remove dominated actions, which is done without the averaging process.

Both of the settings will impose a RAM and speed overhead, which is why the default settings are 1 street.

Could you elaborate on this? Possible, it's due to changing the EV (streets) setting.

I'm reluctang to add this feature as copying subtrees from one spot to another may add unneeded or too few actions to the new tree. The intended way of doing this is to use a custom filter (which can be saved) to populate the postflop spot, and then reuse the filter in the new spot. This allows the actions to adjust to the specific postflop tree.

When unchecking "Regret", saves will be very small. I assume this is the reason. However, you will not be able to continue solving the tree efficiently, or view the solution on streets other than the amount of streets specified by "avg streets". This should be explained by the tooltip (especially when changing defualt settings, it's recommended to check for tooltips.)

The bug has been fixed, thanks for the report.

Solutions (including 3-way) are available for purchase in MonkerViewer.

Could you send an email to support with game and settings? We've had some reports of inaccurate estimates, but unfortunately very little feedback on when they occur.

Right.

sent

For me, pretty much every tree is inaccurate by around 10-20GB especially when you increase buckets over 30.

Is there a way we can load a sim into the solver in a way that uses little memory simply for the purposes of viewing a strategy? I compressed a sim (no regret) and the file came out rather small but when I load it into the solver it still takes up a good bit of memory. When its loading the "stop" btn becomes available so it seems it's running in a way.

Basically I prefer to view the strategy in the solver over the viewer.

This isn't possible at the moment. It would be particularly useful for PLO where trees are larger and we don't have a viewer.

That would be a really great addition if it's doable IMO (even if only PF). This way you could solve on the cloud and transfer the small file to your personal machine and view them easily in the solver interface which is much nicer and easier than the viewer, at least for PLO in particular.

This was my use case yes. I believe it does work to some extent for preflop, as the RAM requirements to load an Omaha preflop tree are lower than to start it (I'm guessing this has something to do with the way the Omaha tables work). For me this makes a difference, since I can just barely not start an Omaha preflop tree on my laptop which has 16 GB RAM, but if I run it on a server first and just want to view the solution, it will load on my laptop for trees that fit within the 16 GB of RAM. Other than that, it still won't work obviously. I believe the solution would be to be able to access the solution from disk rather than from RAM, which would essentially be like giving the solver viewer functionality.

How many iterations / node would be acceptable for accuracy? Assuming this is the best measure that is.

Is there a way to see (or export) exact frequencies for all combos in the solutions?

10 was noted on their website as a decent accuracy point iirc.