Hi everyone,

My apologies for apparently ignoring the posts for the past few days.
Usually we receive a notification when a post is made, but this time it appears that this was not the case.
It's either that, or perhaps something went wrong on our end.

Scylla

Okay that worked, now I can see aggregate on 162.

No filters update for v1.37

Sad indeed.

Thanks for the update!
But there are not enough hand category filters, when can you expect?
For example, I want to see the hands: only the third pair + GS + no FD. No made + no GS \ SD + no FD.

Thanks for the update scylla! I can't tell how much I appreciate your work, your patience and the fact that you are truly listening to your costumers. You guys are the nuts of the poker software industry.
Keep up the good work!

Hello,

Maybe this has been answered in detail before but I wasn't able to find anything: Can you give some details on what exactly dEV means and how it should (or shouldn't) be used in practice?

I've been told that the dEV is the max amount of EV that either player can be exploited for, so if the pot is 10BB, EV of IP is 6BB, EV of OOP is 4BB and dEV is 0.1BB, that means that the max exploit strategy of OOP would reduce IP EV to 5.9 (if he didn't adjust) and likewise IP could increase his EV to 6.1 by changing his strategy to the max exploit. Is this correct?

I'm running some experiments solving the same board for different target dEV and I find it difficult to relate this concept to the actual output strategy and EV outputs of the solver. For example, solving to 0.3% or 0.1% I get almost identical strategy outputs and almost the same EV of each player even though the dEV is very different (comparatively). Is it really the case that the 0.3% strategy is exploitable for 3 times as much EV even though the strategies look near-identical?

I've also seen several people talk about dEV as if it were a sort of confidence interval for the unexploitable EV. So in the example above where the pot is 10BB, EV of IP is 6BB, and EV of OOP is 4BB they argue that if the dEV is 0.5BB then the "true" EV of IP with this tree could be anywhere from 5.5BB to 6.5BB. This doesn't seem correct to me empirically as, as I said, the EV of each player doesn't change much when solving the tree to higher precision, even though the dEV is changed greatly. Can you shine some light on this as well? Is this an incorrect way to look at it? And if so, what can the dEV then actually tell us about the "true" EV of a strategy (theoretically solved down to 0%), if we are for instance comparing the EV of two different trees (such as ones with different bet sizes on the flop for the same board)?

Sorry for the long comment, if you do have some sort of White Paper or similar documentation on how the algorithm actually works that you think would answer some of my questions then I'd be happy to have a look at that as well.

Hey Scylla, I ran two subset of flops with basically the same parameters except for flop sizings, one has Check+b25% and the other one Check+b75%, after that when I select, lets say, 50 flops from file 1 and the other 30 from file 2 - using the 80 flop subset - it's giving me an error when I try to merge them using "Use weights from a subset: 80". What might cause this error?
I delete all the flops I don't use for one sizing and they are not overlapping

Is it possible that the problem is some flop nodes having different number of possible actions giving the sizings used?

We had to work through quite a few other changes that were requested.
Unfortunately we did not get to this particular feature.

dEV is a measure for the accuracy of the solution. It's the most EV a player could gain by maximally exploiting all the tiny mistakes in their opponent's strategy. So if a player's EV is 6, and dEV is 0.2, then he would be able to achieve at most an EV of 6.2 if he were to exploit all the inaccuracies in his opponent's play perfectly (of course, for this, he would need to play sub-optimally himself, which would make him highly exploitable). As dEV becomes lower, the strategies for both players will get closer and closer to the perfect solution where dEV is 0. As a result, as dEV gets smaller, the strategies will barely change anymore. As a rule of thumb, we assume that below a dEV of 0.5% there won't be any significant changes anymore, and there's not much to be gained from spending more calculation time in achieving a lower dEV.

I have just tried, and apparently we're not checking for whether the trees are identical. Are you certain that there's a perfect overlap with the subset? Is it possible to send the files to support? Should they have been stored with "Extensive" storage, then just use "File->Save: Convert to Basic storage" to reduce the files in size.

It worked when I converted them to Basic files, so I guess it won't merge if the files have a few GBs on Extensive Storage. Bad thing is rerunning turns and rivers when drilling hands, especially cause I usually run the sims on a server and drill them on my PC

So one way to get around this seems to rerun the merged file and saving it with the Extensive Storage.

Thank you. Touching on the other thing I wrote, what determines how fast the EV's of each player converges to the true value (that at 0 dEV)? Clearly, it's much faster than the target dEV decreases, but is there a way to gauge how precise it is?

The storage method shouldn't be a factor, so it's difficult to say why originally you couldn't get the files to merge.

The overall EV is one of the fastest values to converge.
I don't have any metrics to quantify how fast it converges though.

Hello,

How to delete unsolved trees?

Under v134 changelog "Option to only delete solved/unsolved trees"

Tried searching this thread but could not find any previous posts about this one.

To delete an individual tree, use Ctrl+right-click.
To delete all unsolved trees, click on "Clear database" while pressing Ctrl.
To delete all solved trees, click on "Clear database" while pressing Alt.

Ok, thank you.

Could you add an option to show more decimals on the overall EV's? Perhaps you could show both players EV with more decimals on hover only if it gets too cluttered otherwise.

I believe that EV is currently displayed in cents.
Do you require a higher accuracy than that?
Or are you perhaps referring to a different value?

Hi, yes I think that would be good. Especially for situations where pot is small it can make a rather large difference in terms of % of pot.

I typically run sims with everything times a factor of 1000 to get more significant digits, but it would be nice to have it higher accuracy even with the pot in BB.

If it could show, for instance, EV=2.21 on screen but 2.2147 on hover it would be a good solution I think.

Ok, I will increase the accuracy below the table in the text output.

Hi Scylla,

So I receive the message Insufficient memory (3.0GB required), but I have 10GB-12GB available. Does it mean 3.0GB MORE required? If not, what does it?

This problem is solved by adding more RAM, isn't it?

If 3.0GB is required, and 10GB is available, then the tree should solve.
Or is over 7GB perhaps used by other software?

If you upgrade to v137, then GTO+ will tell you how much RAM was required, and how much was available.
See the pic below.

Should for some reason the available RAM not properly be detected on your system, then you can disable auto-detect by clicking on the GB field.
See the pic below.

This is strange. My system has 16GB RAM, now I test it by running GTO+ first thing after booting.

13GB is avalaible, the tree is 3.0GB required, and it still does not solve.

I am running on v1.3.6.

Ok, and is 13GB actually indicated as being available?



Other than that, if you're trying to solve a single tree with insufficient RAM, GTO+ will tell you how much was needed:



And if you're trying to solve it in a database, mousing over the "Memory" icon will tell you how much was required, and how much was available: