Bunching affect on strategy

[exerco]

Hello! I tested new feature and noticed something peculiar: 1) Bunching option requires much less iterations to reach exploitability goal. I understand the decrease, but not the scale of it: 32 vs 140, 40 vs 130.

2) It "wierdly" affects strategy. F.e. OOP 3b Caller starts to donk 50% of his range in spot, where w/o bunching it checks almost 100%. Same parameters/tree & bunching ranges were for 4 players properly inverted from what they would've played in this spot. I see that EV changed in results so the changes are there, but should strategy change that drastically? I will try to find more useful examples.

[b-inary]

Thank you for your report! Since this is an experimental feature, I would really appreciate it if people would check the behavior.

This could be a bug, but it could also be possible. If the true Nash equilibrium with bunching enabled uses donk bets, the solver may be able to converge faster because it may be close to the initial value. But with exploitability >1% it is hard to tell anyway. We also cannot verify this because there is no other solver that can account for the bunching effect.

If possible, there are a few things I would like you to check.

1. Please go to the "Compare" tab and make sure that the equity and EV totals for both players are correct. For example, if the sum of the equity is not 100%, then there should be a bug (I am not using an implementation like (IP equity) = 100% - (OOP equity)).
2. What happens if we remove the donk betting action? If you remove the donk bet and the EV goes up, this is also suspected to be a bug.
3. What happens if you set the target exploitability to a lower value, say 0.5% or 0.3%?

Or, if you let me know the range you used, etc., I can check it on my end.

[exerco]

I've sent you an e-mail with config files. As for results of implementing your suggestions: seems like the problem was exploitability %. First time I encounter this at ~1%, maybe it's "boosted" in bunching because of less iterations. So maybe you should add that to info popup, that even though calculations are longer it's not recommended to decrease recommended exploitability. Results with 0.5%:

More iterations

Small % of donks

No problems with EV sum for both players

W/o donk enabled

EV decreased, as it should

No bunching results:

IP player responses with & w/o bunching

So there is no issue, great stuff as always!

[b-inary]

Glad to hear that the program seems to work as expected! One thing you pointed out in the e-mail, a problem with range format string when the range is inverted, may be a matter of floating point numbers. For example, with a single-precision (32-bit) number, 1.0 - 0.9 becomes 0.100000024, not 0.1. This can probably be patched by first converting a number to string, then parsing it as a double precision (64-bit) number, and finally converting it back to a single precision number.