[Phil153]

Since you want to keep discussing the topic...

[ QUOTE ]
[ QUOTE ]

I prefer not to estimate at all...the only deviations from the all-in line should be verifiable ones. You're deviating from the all-in line based on estimates which will vary depending on how you and your opponents play.


[/ QUOTE ]

the problem with "not estimating at all" is that you're estimating implicitly. by not adjusting for the full amount, you assume you "ran neutral" on the portion of the pot you ignored. so if you beat KK with K2o it assumes all money that went in before the last street went in with 100% equity for K2o. so instead of making explicit estimates that are admittedly very rough, you end up making implicit estimates that are much worse.

[/ QUOTE ]
If I ignore ANY crude but non skewed method for estimating winrate (such as calculating vs a predefined range for unknown hands based on VPIP), then according to you I'm "implicitly estimating" the portion that I'm ignoring. This is incorrect. I'm calculating a smaller portion in return for a greater match with the actual dollar values of play.

I agree that your method calculates a somewhat (but not much) larger portion of luck, but it does it crudely and inaccurately, and makes assumptions. This is something I prefer to avoid. When someone looks at an all-in stat (say, overpair vs flopped set example above where a tiny bit goes in on the flop and the overpair wins), I want to avoid it saying that they got lucky for $1000 when in reality the exact opposite happened. Do you really want a program that can show a completely wrong estimate of luck after a session, one that is the complete opposite of what actually happened? Or one that calculates a smaller portion where that portion is verifiable and matches with the dollar value of play?

I don't see what's so difficult to understand about a somewhat smaller portion in return for the avoidance of large and counterintuitive inaccuracies over the short term. Especially since the program is most frequently used over a short term session.

I get that in the long term, the whole pot method can be measure a larger portion (but not necessarily does). But the price isn't worth it, imo. Hence, the program stays like it is, and you get your option in the config file (or get someone else to code it).

I'm not discussing this any more, there's no point. We just disagree and have different priorities for the program (I believe you shortstack, so I can appreciate how this may affect you more than full stackers).