#### kmccormick100

##### 4 of a Kind

@BearMetal is there an admin setting that looks like this?

You are using an out of date browser. It may not display this or other websites correctly.

You should upgrade or use an alternative browser.

You should upgrade or use an alternative browser.

- Thread starter BearMetal
- Start date

@BearMetal is there an admin setting that looks like this?

Wait, is this the part of the discussion where we all start breaking out our college degrees and transcripts? 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

I actually have a real math degree, but this ones funny.

Love the Wolfenstein reference. Such a great game.

It's this.

View attachment 641853

Anybody who played Contra knows it's B then A, not A then B.

Hold on I can figure this out, let me dust off my computer.

isn’t it select start too and not just start???Anybody who played Contra knows it's B then A, not A then B.

Wait, is this the part of the discussion where we all start breaking out our college degrees and transcripts? 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.

For 2 players it is. If just one player, then no.isn’t it select start too and not just start???

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?

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

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).My instinct is off. What would be an acceptable margin of error within one standard deviation?

So more like 2% give or take, not 10% like I was assuming.1 in 221 +/- 4.5 hands as

So still probably something wrong with the haystack.

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.

I’m just subscribing to see which of you doesnt complete the Oregon Trail.

Damn it. You're right, I didn't fact check. Also, it's select start because two player was always better than one.Anybody who played Contra knows it's B then A, not A then B.

Obv answer is obv. OP needs to reboot.

I rebooted my Windows PM server and I get this now. I guess something was wrong after all:

Just ask this guy

- Locked

- Replies
- 172

- Views
- 6K

- Locked

- Replies
- 280

- Views
- 9K

- Locked

- Replies
- 32

- Views
- 4K