Dear bachfan,
Many thanks for your feedback. We’d like to briefly look at the points you’ve raised.
Apples, Oranges and Tangerines
The difference between "Oranges" and "Tangerines" is not in the flop selection. It goes without saying that in Equilab Omaha, those flops which conflict with the given hands or ranges are not selected. The difference is in the calculation method and in this example, probably in the low number of flops considered. Due to potentially long calculation times, the internal selection of the number of flops and the iteration depth of the calculation were restricted. However generally, this should represent a suitable compromise between precision and speed.
We have created a precise graph for the example "7s7h5c2d vs. AA**". So we haven’t taken a large number of randomly generated flops for this example, but rather all the various permutations. Of the C (52, 3) = 22,100 possible flops, there are precisely 17,292 in this example without any collusion with the given hand or range. As a result, we get the following graph:
We believe that the differences between both graphs (PPT and Equilab Omaha) and this graph lie in the number of flops selected and the depth of iteration alone. Why the Equilab Omaha graph is almost always a bit below this and why the PPT graph almost always a bit above this is a research topic we will be happy to investigate in the future. We are also just as excited about the results. However, the fact is that there are some flops where "7s7h5c2d" has an equity of precisely zero (flops with two aces). In our opinion, this is well represented by the small zero percentage of the blue line far right, near the 100 % mark.
"AsAhJsJh vs. AA**“ vs. "AAJJ/ds vs. AA**"
We think that these two graphs must be different.
In the first instance, a hand is calculated against a range. Here, PPT HvR and Omaha Equilab should create more or less the same graphs.
However, in the second instance, a range is calculated against a range. Here we can clearly see the difference between the calculation methods. Using flops, Equilab Omaha calculates the equity of "range vs. range". Clearly, PPT takes a hand from the first range each time and then calculates this against the range. Do please correct us if we have misunderstood this.
If you now actually calculate "range vs. range", you can instantly see that the graph from the hand "AsAhJsJh" must be significantly lower than graphs with the range "AAJJ/ds" (6 combinations). For example, "AsAhJsJh" on the flop "7d6d5d" only has remaining equity of approx. 27%. In contrast, "AAJJ/ds" on the same flop has equity of over 37%. It’s easy to see here that these graphs must be different.
From the calculation methods selected, we can also explain why both PPT graphs are the same in this case. PPT does not calculate equity with the entire initial range given, but takes a random hand combination from this range each time.
In order to give a stable basis for discussion, we have also calculated the graphs for all permutations here.
"AsAhJsJh vs. AA*" with 15,180 flops:
"AAJJ/ds vs. AA*" with 17,292 flops:
We will double-check to what extent the quality of the graphs can be optimised. It may make sense to let the user choose whether he wants to iterate all flops or if he wants a certain number of random flops to be calculated.
Nomenclature:
The descriptions "propokertools" and "exact equities" are pretty much dictated by history and are in no way pejorative or similar. We will replace these in the next update with more suitable descriptions, e.g something such as "hand vs. hand" and "hand vs. range or range vs. range".
All the best from Germany, nopi, PokerStrategy.com