all in luck calculator

[Phil153]

No insults required Pete...my testing prior to beta released hadn't revealed a skew being significant, so I hadn't thought it was a huge issue. After seeing enough graphs it was obvious that there was. That's why it's a beta and not a final product.

[ QUOTE ]
there's no flaw. we're trying to measure how lucky/unlucky you get on the cards that come after all the money is gone in. we don't care about how lucky or unlucky we got on earlier streets.

[/ QUOTE ]
Exactly!! Which is why I do it the way I do it now.

[ QUOTE ]
AA vs 22 gets 95% of the money in preflop ($950 each). 22 flops a set ($50 each goes in). by your method AA runs bad by about $10 by not sucking out. by my method AA runs bad by about $100. by your method 22 runs good by about $10. by my method 22 runs good by about $100.

[/ QUOTE ]
And? You forget the flip side, which invalidates your point completely (see below). I've already stated I measure a smaller amount to avoid the difficulties of your method.

Consider the case where 50% of the money goes in preflop. A comparison of methods:

I calculate on the $1000 flop contributions and ignore the rest. You calculate on a $2000 preflop + flop contributions.

When AA loses:

Me: AA runs bad by $100
You: AA runs bad by $200

When AA wins:

Me: AA runs good to the tune of $900
You: AA runs goods to the tune of $1800

Which one is screwed up now? You've overestimated AA's genuine, dollar matched luck by $900 more than I have.

I don't know whether your example was a genuine mistake or not, but it only looks at one side of the equation and represents no inherent advantage to your method - since it will simply be over or under estimating by larger amounts. I prefer to match luck with the dollar values of the street where the money goes in, measure a slightly smaller portion and thereby avoid massively overestimating people's good/bad luck in certain scenarios.

[Phil153]

[ QUOTE ]
[ QUOTE ]

to put it another way, when using these calculations to adjust your winrates, your model assumes that 22 got the preflop money in with 100% equity.

[/ QUOTE ]

and this is the key here. it's better to estimate the money going in on earlier streets with the same equities as on the final street, than it is to assume it went in with 100% equity for the person who actually ends up winning the pot. in very rare cases this estimate will be worse than your method's estimate (like in your KK vs AA example where the equities go 20-90-10), but on average my estimate will be much more accurate.

-stinkypete

[/ QUOTE ]
I assume this is pete?

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.

Anyway, I'm putting the option in a config file so you'll have it available if you want to calculate by that method.

[stinkypete]

[ QUOTE ]

And? You forget the flip side, which invalidates your point completely (see below).

[/ QUOTE ]

my point was to illustrate the flipside of your example, which is isolated and rare and doesn't tell the whole story at all. i was a bit rushed so i may not have been as clear as i should have been.

[Phil153]

Fair enough. I don't want to waste more of your or my time but I will put the option in there, just not in the main area.

Thanks for all your input, both now and before, it's been helpful.

[stinkypete]

[ 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.

[flight2q]

[ QUOTE ]
I'm guessing this is the way people like stinkypete and me get the all-in luck adjusted equity the way we want it:

[/ QUOTE ]
Okay, with some investigation, I can answer my own question. The all-in on river check box on Game Analysis Graphs tab does not do what we want. It throws in some equity based on the cards held and bets placed on earlier streets - well, should be no surprise since this is the tao of that tab. But if used to adjust the win rate estimator it makes it biased.

What we want is an unbiased estimator with as much power as we can get. The actual win rate is an unbiased estimator, but we already know that. The simple way to avoid bias is to adjust using the all-in situations. The Luck Graphs tab doesn't provide the unbiased estimator with the most predictive power. We want an option to include entire pot amount (less rake) instead of just the betting on one street in Luck Graphs tab. That provides the most powerful unbiased estimator possible from restricting ourselves to the all-in situations.

[stinkypete]

[ QUOTE ]

What we want is an unbiased estimator with as much power as we can get. The actual win rate is an unbiased estimator, but we already know that. The simple way to avoid bias is to adjust using the all-in situations. The Luck Graphs tab doesn't provide the unbiased estimator with the most predictive power. We want an option to include entire pot amount (less rake) instead of just the betting on one street in Luck Graphs tab. That provides the most powerful unbiased estimator possible from restricting ourselves to the all-in situations.

[/ QUOTE ]

exactly. now convince phil that it's more powerful than his method.

[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).

[stinkypete]

[ 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.

[/ QUOTE ]

it's not incorrect. your way would be "correct" if your starting point was zero and you calculated your all in luck from there. but your starting point is your actual results, so my way is actually much more "correct". i understand that it's a little bit counterintuitive, but sometimes what seems like it should be intuitively correct is very much wrong. you have to start from a counterintuitive point (your result rather than zero), so you have to think backwards.


[ QUOTE ]

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?

[/ QUOTE ]

you're worrying too much about the outliers. the reason your method works better for the flopped set/overpair sucks out example is because, as i explained, when youre starting point is your winrate rather than zero, you implicitly estimate all preflop money going in with 100% equity for the person who won the pot. ie. 100% for AA. but it's just an outlier and you would be much better off using the flop equity in almost every situation. consider a situation where you're 50/50 before the flop and a bunch of money goes in, say KhQh vs 2c2d, and the flop comes JhTh2s, so now its like 42/58. the rest of the money goes in on the flop. you're much better off using the flop equity for the entire pot than assigning 100% equity to the winner, as you do now.

and the flop equity will be a much better estimator on average, because flop equities will be much closer to preflop equities than river equities will be. (that should be obvious)

[ QUOTE ]
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.

[/ QUOTE ]

it's not difficult to understand. i understand that you're wrong. other people in this thread understand that you are wrong. NOBODY agrees with you. the problem is you're focusing too much on what's counterintuitive to you and ignoring what's correct.

and you're wrong about people using the all-in luck mostly for the short term. the point of it is to get a better estimate of your winrate than just looking at your winrate. your "sklansky bux" estimate is more of a short term tool. this is a medium-long term tool. but that doesn't even matter, because the full pot method is better regardless.

[ QUOTE ]
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).

[/ QUOTE ]

long-term, short-term, it doesn't matter. the method i described is better regardless.

[ QUOTE ]
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).

[/ QUOTE ]

this has nothing to do with short-stack vs. full-stack, it's a better method regardless of what size stack you play with. if your method were better, it would be even more beneficial for short stacks than full stacks, since they're more often in situations where a large percentage of their stacks go in preflop. the fact is your method is WRONG.

[flight2q]

It doesn't matter, stinkypete. People who know what they're doing will use the all-in-before-river checkbox thingy when that is appropriate, and will use the Luck Graphs tab with config option on when that is appropriate. Phil is trying to help out the casual users who don't have any idea how to interpret the data.

Putting the option in the interface instead of a config file would only be useful if people wanted to look at both ways of computing all-in luck and quickly switch between them. Maybe you'd want to do that out of curiosity a couple of times. But for practical purposes you'd rarely want to see both.