Poker Mavens Statistics Question (2 Viewers)

@BearMetal is there an admin setting that looks like this?
70D73EA7-5F66-434A-A4E9-FBB768EDE5A7.png
 
Wait, is this the part of the discussion where we all start breaking out our college degrees and transcripts? :ROFL: :ROFLMAO: Probability and statistics is my area of expertise. I use it every day at work, and it's what I studied in grad school (I got As, not Cs). I assure you that my "assumption" is not baseless. In fact, I'll prove it to you - whether you guys will understand it, I don't know, but here you go anyhow, just for fun...

AA is dealt 1 in 221 hands
Pocket pairs, in general, are dealt 1 in 17 hands
221/13 = 17

If each pocket pair is dealt 1 in 189 hands as @BearMetal says his data suggests, then any pocket pair is dealt 1 in ~14.5 hands
189/13 = 14.53846

The probability of all specific pocket pairs being dealt averaging out to 1 in 189 hands after 10,000 hands have been dealt follows a binomial distribution with the probability of success being 0.06878308 (1 in 14.53846). We can calculate this using statistical programming software (I'm using R) as follows:
> 1-pbinom(10000/(189/13), 10000, 1/17)
= 1.887275e-05 or 0.00001887275
Thus, as I stated earlier, the likelihood that you'd average out 189 hands per pocket pair even over a sample size of just 10,000 hands would be essentially zero (as I've proven here, 0.00001887275 is pretty damn close to 0).

However, the probability of pocket pairs averaging 1 in 189 hands after 156,356 hands have been dealt is:
1-pbinom(156356/(189/13), 156356, 1/17)
= 0
Yep, 0. Not happening.


The standard deviation of the average expected number of total pocket pairs dealt after 156,356 hands is defined as sqrt(n*p*(1-p)) and can be calculated here as follows:
> sqrt(156356*(1/17)*(1-1/17))
= 93.03971

99.7% of observations fall within 3 standard deviations of the mean. Given the true probability of a pocket pair being dealt is 1 in 17 hands, we know that 99.7% of the time that we run this experiment with a fair deck after 156,356 hands, we will have between 8918 and 9477 total pocket pairs.
> (156356/17) - 3 * 93.03971 # Lower bound
= 8918.293
> (156356/17) + 3 * 93.03971 # Upper bound
= 9476.531

BearMetal claims that there were ~10,755 total pocket pairs dealt, as he said they averaged out to 1 in 189 hands per pair after 156,356 hands.
156356/(189/13) = 10754.65

This is basically impossible, as this would be almost 17 standard deviations away from the expected number of 9197 total pocket pairs dealt (156356/17 = 9197). Either the deck is stacked, or his calculations/data aggregations are wrong. As I stated before, and as I proved here, variance cannot explain his results.
(10755-9197)/93.03971 = 16.74554 standard deviations

Delicious, you explained this well using only 1st year stats. Very nice!
Its extremely unlikely to be more than 3std from the mean, with 17, I would suspect that there is an issue with the data.

O and here is my diploma


1614041112296.png


I actually have a real math degree, but this ones funny.
 
Wait, is this the part of the discussion where we all start breaking out our college degrees and transcripts? :ROFL: :ROFLMAO: Probability and statistics is my area of expertise. I use it every day at work, and it's what I studied in grad school (I got As, not Cs). I assure you that my "assumption" is not baseless. In fact, I'll prove it to you - whether you guys will understand it, I don't know, but here you go anyhow, just for fun...

AA is dealt 1 in 221 hands
Pocket pairs, in general, are dealt 1 in 17 hands
221/13 = 17

If each pocket pair is dealt 1 in 189 hands as @BearMetal says his data suggests, then any pocket pair is dealt 1 in ~14.5 hands
189/13 = 14.53846

The probability of all specific pocket pairs being dealt averaging out to 1 in 189 hands after 10,000 hands have been dealt follows a binomial distribution with the probability of success being 0.06878308 (1 in 14.53846). We can calculate this using statistical programming software (I'm using R) as follows:
> 1-pbinom(10000/(189/13), 10000, 1/17)
= 1.887275e-05 or 0.00001887275
Thus, as I stated earlier, the likelihood that you'd average out 189 hands per pocket pair even over a sample size of just 10,000 hands would be essentially zero (as I've proven here, 0.00001887275 is pretty damn close to 0).

However, the probability of pocket pairs averaging 1 in 189 hands after 156,356 hands have been dealt is:
1-pbinom(156356/(189/13), 156356, 1/17)
= 0
Yep, 0. Not happening.


The standard deviation of the average expected number of total pocket pairs dealt after 156,356 hands is defined as sqrt(n*p*(1-p)) and can be calculated here as follows:
> sqrt(156356*(1/17)*(1-1/17))
= 93.03971

99.7% of observations fall within 3 standard deviations of the mean. Given the true probability of a pocket pair being dealt is 1 in 17 hands, we know that 99.7% of the time that we run this experiment with a fair deck after 156,356 hands, we will have between 8918 and 9477 total pocket pairs.
> (156356/17) - 3 * 93.03971 # Lower bound
= 8918.293
> (156356/17) + 3 * 93.03971 # Upper bound
= 9476.531

BearMetal claims that there were ~10,755 total pocket pairs dealt, as he said they averaged out to 1 in 189 hands per pair after 156,356 hands.
156356/(189/13) = 10754.65

This is basically impossible, as this would be almost 17 standard deviations away from the expected number of 9197 total pocket pairs dealt (156356/17 = 9197). Either the deck is stacked, or his calculations/data aggregations are wrong. As I stated before, and as I proved here, variance cannot explain his results.
(10755-9197)/93.03971 = 16.74554 standard deviations

Apologies. I stand corrected.

Not sure what to make of OP's data, then. Of course that whole first set was erroneous, but he seems to be looking at it the right way now, and farming the hand histories in a logical way. This is what a Mavens HH looks like, BTW. Obviously a little short because it's heads-up, but you can see it only shows each tabled hand once with the syntax he's using for his search string (verified even if there's a split pot, can dig that up if anyone cares).

Hand #1599-1536 - 2021-02-23 00:00:07
Game: CL Hold'em (100 - 1000000000) Cap 1 - Blinds 1/1
Site: Rungood Lounge
Table: RNG Test
Seat 3: RNGBOT2 (999999981)
Seat 7: RNGBOT1 (1000000019)
RNGBOT1 has the dealer button
RNGBOT1 posts small blind 1
RNGBOT2 posts big blind 1
** Hole Cards ** [2 players]
** Flop ** [7c 6h Js]
** Turn ** [Ks]
** River ** [4d]
** Pot Show Down ** [7c 6h Js Ks 4d]
RNGBOT2 shows [3d 8c] (High Card King +J876)
RNGBOT1 shows [Ac 6s] (a Pair of Sixes +AKJ)
RNGBOT1 wins Pot (2) with a Pair
Rake (0) Pot (2) Players (RNGBOT2: 1, RNGBOT1: 1)
** Summary **
Board: [7c 6h Js Ks 4d], Players: 2, Pots: 1, Total: 2, Rake: 0, End: Showdown
Seat 3: RNGBOT2 (-1) [3d 8c] Showdown with High Card King +J876
Seat 7: RNGBOT1 (+1) [Ac 6s] Showdown with a Pair of Sixes +AKJ

This is the string that counts all "player-hands" as we've defined that:

egrep -e 'Seat.*\[\w\w \w\w\]' HandHistory/* | wc -l

I'm reading this as "Count the number of repetitions of 'Seat' followed by any amount of text, followed by '[XX XX]' where XX is any two characters." The rest is the location and probably settings enabling the wildcards.

And this is the one that counts AA:

egrep -e 'Seat.*\[A\w A\w\]' HandHistory/* | wc -l

Same thing basically, but specifically AX AX in the brackets.

I wonder if there's something in this stretch of the HH that it could be misinterpreting:

Seat 3: RNGBOT2 (999999981)
Seat 7: RNGBOT1 (1000000019)
RNGBOT1 has the dealer button
RNGBOT1 posts small blind 1
RNGBOT2 posts big blind 1
** Hole Cards ** [2 players]
** Flop ** [7c 6h Js]

If the player-hands formula were to trip over this, it would only count one extra player-hand per table-hand, so it wouldn't distort your count too dramatically there. But if it's also counting every flop that starts with "[Ax Ax" as a pair of aces, "[2x 2x" as a pair of deuces, and so on, it would bloat your pocket-pair count even more than your player-hands count, and it would do it with every pocket pair about equally.

Maybe try running this same string, but with "Summary.*\" before "Seat.*\"? If it's unintentionally counting anything from the earlier parts of the HH, this should prevent that.
 
Apologies. I stand corrected.

Not sure what to make of OP's data, then. Of course that whole first set was erroneous, but he seems to be looking at it the right way now, and farming the hand histories in a logical way. This is what a Mavens HH looks like, BTW. Obviously a little short because it's heads-up, but you can see it only shows each tabled hand once with the syntax he's using for his search string (verified even if there's a split pot, can dig that up if anyone cares).



This is the string that counts all "player-hands" as we've defined that:



I'm reading this as "Count the number of repetitions of 'Seat' followed by any amount of text, followed by '[XX XX]' where XX is any two characters." The rest is the location and probably settings enabling the wildcards.

And this is the one that counts AA:



Same thing basically, but specifically AX AX in the brackets.

I wonder if there's something in this stretch of the HH that it could be misinterpreting:



If the player-hands formula were to trip over this, it would only count one extra player-hand per table-hand, so it wouldn't distort your count too dramatically there. But if it's also counting every flop that starts with "[Ax Ax" as a pair of aces, "[2x 2x" as a pair of deuces, and so on, it would bloat your pocket-pair count even more than your player-hands count, and it would do it with every pocket pair about equally.

Maybe try running this same string, but with "Summary.*\" before "Seat.*\"? If it's unintentionally counting anything from the earlier parts of the HH, this should prevent that.

I’m somewhat in the same boat that I think something is unexpected with the data producing extra counts. But the fact that others are running the same query (supposedly) and getting more accurate results would mean that the histories aren’t stored the same on the different servers (I don’t know if there’s any options for logging that could cause this). Could it be that hand logging had changed formats at some point while the games have been running?
 
I’m somewhat in the same boat that I think something is unexpected with the data producing extra counts. But the fact that others are running the same query (supposedly) and getting more accurate results would mean that the histories aren’t stored the same on the different servers (I don’t know if there’s any options for logging that could cause this). Could it be that hand logging had changed formats at some point while the games have been running?
Good point. Mavens runs on multiple different versions simultaneously, so I suppose it's possible that oldier HHs don't have the exact same structure as newer ones, and people could all be using different versions that have different HHs at the same time. Be pretty easy to check that if the relevant parties feel like it.
 
My instinct is off. What would be an acceptable margin of error within one standard deviation?
One standard deviation should account for 68% of cases, 2 standard deviations for 95%, and 3 for 99.7%. Most people use 2 standard deviations for most projects like this. So if we take the expected 9197 pocket pairs from his 156,356 hand sample +/- 2 standard deviations and extrapolate that to the average of 1 per 221 hands (I'm not sure if the theory is technically correct here with respect to extrapolating the average of a series of averages, the central limit theorem makes me think this is ok to do, but if not, it's probably close enough), then we would expect to see 1 in 221 +/- 4.5 hands as the overall average for the 13 different pocket pair averages (note, this is different from one specific holding like AA, which will have wider variance).
 
@BearMetal are you sure you’re only counting hold ‘em? If there is a little omaha sample in there that would explain it
We've actually never played any other games aside from NLHE. I know, lame.

I'm scanning through the hand files now to see if it's just not counting some players hands...

One thing I want to say is that I really appreciate everyone's input on this thread. The whole point of it was to see if there was something I was missing and there certainly was. Honestly, if I got the numbers that I got after adjusting my queries in the first place I wouldn't have even thought to open a thread.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account and join our community. It's easy!

Log in

Already have an account? Log in here.

Back
Top Bottom