Quote:
Hi, I don't run PIO (Mac user, are there any Mac options beside Parallels?)
Any VM that runs Windows or Bootcamp (but that means booting into Windows).
Quote:
but I am using the PIO weighted flop sets for calculation in CREV
We don't support that and I have no idea how that works but I am going to answer your questions assuming you would run it in Pio.
Quote:
How card removal effects affect the results.
This is taken into account by the solver. For example if you have two flops:
-As7h2d:1.0
-As6h2d:1.0
the starting pot is 100$ the ranges are 77 vs AK with simplistic assumption that 77 always wins on As7h2d and always loses on As6h2d then there are:
3 * 12 = 36 matchups on the first flop (3 combinations of 77 and 12 combinations of AK)
6 * 12 = 72 matchups on the second flop (6 combinations of 77 and 12 combinations of AK)
The total EV for 77 is then:
(36 * 100$ + 72 * 0$) / (36 + 72) = 33.333$
If you introduce other weights than 1 there, the math changes but the principle remains the same: flops which are less frequent when you hold a particular combo are counted with smaller weight when calculating overall EV.
Quote:
should I recalculate the PIO 95 weights by multiplying each weight with the probability for getting the flop the weight is associated with?
It's already done for you by the solver. It takes that into account when solving flops, when doing aggregation reports as well as when solving preflop trees. Notice that it wouldn't be possible to adjust the subset itself as probability of getting various flops is different for every single matchup (so for example 22 gets a differently weighted subset than QQ). Again - it's all taken care of by the solver's internals.
If you run aggregation reports you will see some details about relative probabilities in them.
One interesting point is that it's a bit complicated when it comes to preflop solving as our tests show it's better to assume an all-in preflop is always on 1755 flops even if the postflop solving is only done on a subset. This means that there is different card removal effect when all-in preflop and when going for postflop. It introduces some challenges when accounting for card removal and it's the reason the preflop solver is a bit more complicated to correctly implement that it looks at the first glance but again - it's worth taking care of because the results are better (by that I mean that you need less flops to approximate real solutions than you would need if you assumed all-in on a subset of flops as well).
Last edited by punter11235; 08-25-2016 at 12:23 PM.