Blackjack simulation programming

[GZAN]

Hey,

I'm currently programming a blackjack simulator for learning purposes. I'm a beginner at blackjack and by doing this I hope to learn a couple of things about this interesting game.

I have implemented basic strategy for "6 decks, S17, D9, DAS, No Surrender, No Peek" using a chart I found on this site (link). The chart states that the house edge for these rules should be about 0.64%. I ran a couple of simulations with 400.000.000 rounds each but these consistently seem to (falsely) indicate a lower house edge. Somewhere, something must be going wrong.

I'm not sure about some rules used to compute that house edge of 0.64% but I'll state some assumptions I made.

• A player 21 loses against a dealer blackjack
• A player blackjack wins against a dealer 21 with a 3:2 payout
• The player is allowed to split different ten-valued cards (I don't think this should affect the simulation since the BS-chart states never to split tens anyways)
• The player is allowed to split a hand as often as he likes

Another aspect I'm not sure about is the shuffling. At first I simulated a CSM by resetting and reshuffling the deck after each hand. This was pretty slow and because I've not yet implemented any card counting strategy's I assumed it would be safe to only reset and reshuffle the shoe when there are less than about 52 playing cards left. I'm using the Knuth shuffling algorithm with a pseudo random number generator I downloaded from this site.

I'm aware this isn't a programming forum but I appreciate all helpful comments or suggestions on what might be going wrong. If anyone would like to see some code that might be relevant I don’t mind posting it.

Thanks,

GZAN



Data from some simulation runs:
Chips payed: 887515035
Chips received: 887590366
House edge: -0.00848714%

Chips payed: 887615113
Chips received: 887599272
House edge: 0.0017847%

Chips payed: 887562063
Chips received: 887593164
House edge: -0.00350397%

 

[callipygian]

I'm using the Knuth shuffling algorithm with a pseudo random number generator I downloaded from this site.

This could be the problem. You need a really good RNG if you're going to be running this many hands. There are some tests you can run on your RNG to see how random your numbers are. I don't know how well Mersenne Twisters hold up with this many runs, but hopefully QFIT will be by to reply in awesomely excruciating detail.

 

[Sonny]

[*]The player is allowed to split a hand as often as he likes

Typically the player is allowed to split three times for a total of up to 4 hands. It seems like something else is wrong though. One way to check for bugs is to have the program output the frequencies of each hand (both two-hand totals and final totals) and compare that to the theoritical numbers. If the program is using an insufficient RNG (I believe Mersenne Twister should be fine), using an insufficient shuffle, playing the hands improperly or just spazzing out somewhere, that will give you an indication of what is going wrong.

I feel your pain, bro. Debugging simulators sucks.

-Sonny-

 

[KenSmith]

This could be the problem. You need a really good RNG if you're going to be running this many hands. There are some tests you can run on your RNG to see how random your numbers are. I don't know how well Mersenne Twisters hold up with this many runs, but hopefully QFIT will be by to reply in awesomely excruciating detail.

Random number generators are very rarely the cause of big differences in simulation results. I'll wager 100 to 1 that this is not an RNG issue, but instead of bug of some sort.

And, Sonny's right. Debugging simulators isn't much fun. You really need to look closely at the results of a few hundred hands to see if anything becomes obvious. The numbers posted are significantly out of whack, so there's something wrong somewhere. Unlimited resplitting isn't the cause either.

One common mistake that is probably nowhere near enough to explain the discrepancy... You are aware that splitting Aces (which should then receive only one card each) can't lead to blackjacks, right? In other words, drawing a ten on a split Ace makes it a 21, not a blackjack.

 

[KenSmith]

Gzan:
Since the house edge estimates provided by the BSE are merely estimates, I ran an analysis of those rules to give you a perfectly accurate house edge.
For 6D, S17, D9, DAS, Split up to 3 times (except no resplitting Aces), and European No Hole Card (no peek):

House Edge -0.613721130967071%

Note that this is calculated in terms of the initial bet.
Traditionally, blackjack's house edge is presented in terms of the initial bet size, rather than the overall wagers including doubles and splits.
It looks like you were running 400,000,000 rounds betting 2 units each.
Thus, to compare to the number above, you should divide the profit or loss by 800,000,000 units initially bet to calculate the IBA or initial bet advantage.

Shuffling after every hand would be necessary to compare exactly to the number above, because of the so-called "Cut Card Effect". However, it does make the sim much slower to shuffle every hand. Dealing 5 decks roughly out of 6 before shuffling should still be very close to the above number.

 

[callipygian]

Upon reading Sonny's and KenSmith's responses, I retract my previous post. I thought you were getting house edges of 0.8%, -0.1%, and 0.3%, which suggest your sim is okay but your RNG is whacked. You're actually getting -0.008%, 0.001%, and -0.003% house edges, which seems to indicate that your RNG is fine but your sim is wrong.

Sorry.

 

[GZAN]

Thanks for all of your response they have been very helpful so far,

Typically the player is allowed to split three times for a total of up to 4 hands.

Ok, that’s fixed now.

One way to check for bugs is to have the program output the frequencies of each hand (both two-hand totals and final totals) and compare that to the theoritical numbers.

I just did a simulation that showed the frequencies of all hands with 2 cards. At first I thought something was wrong because some hands were coming up more often than others. But this off course is correct because some hands are split more often than others. I might do some more tests tomorrow.

One common mistake that is probably nowhere near enough to explain the discrepancy... You are aware that splitting Aces (which should then receive only one card each) can't lead to blackjacks, right? In other words, drawing a ten on a split Ace makes it a 21, not a blackjack.

Thanks, I wasn’t aware of that. It’s fixed now.

Since the house edge estimates provided by the BSE are merely estimates, I ran an analysis of those rules to give you a perfectly accurate house edge.
For 6D, S17, D9, DAS, Split up to 3 times (except no resplitting Aces), and European No Hole Card (no peek):

House Edge -0.613721130967071%

Thanks, that is very helpful. May I ask how this was percentage was determined?

Note that this is calculated in terms of the initial bet.
Traditionally, blackjack's house edge is presented in terms of the initial bet size, rather than the overall wagers including doubles and splits.
It looks like you were running 400,000,000 rounds betting 2 units each.
Thus, to compare to the number above, you should divide the profit or loss by 800,000,000 units initially bet to calculate the IBA or initial bet advantage.

Yes I was indeed using an initial bet of 2 units each. At first I was actually calculating the house edge by dividing the profit or loss by 2 * simulated rounds. But then I figured this wasn’t correct since splits and doubles cost the player money as well. Is there a reason, other than the fact that it’s a tradition, to calculate the house edge in terms of the intial bet instead of the total bet?

Shuffling after every hand would be necessary to compare exactly to the number above, because of the so-called "Cut Card Effect". However, it does make the sim much slower to shuffle every hand. Dealing 5 decks roughly out of 6 before shuffling should still be very close to the above number.

I’ve seen something about the “Cut Card Effect” before. I’ll do some research on that, thanks.


After implementing all of your helpful and very much appreciated suggestions I ran a new simulation and it gave me results that are more probable but still not quite right.

Chips received: 883197756
Chips payed: 886846432
House edge with respect to initial bet: 0.456085%
House edge with respect to total bet: 0.411421%

 

[jack.jackson]

And dont forget(like aces) when splitting Tens, its also a 21 and not a Bj if you get an ace.

 

[KenSmith]

Thanks, that is very helpful. May I ask how this was percentage was determined?[

That figure is the result of software that does a full combinatorial analysis of every possible hand and every possible outcome. It's not a simulation result.

Is there a reason, other than the fact that it’s a tradition, to calculate the house edge in terms of the intial bet instead of the total bet?

No good reason. It's just traditionally done that way.

 

[QFIT]

Is there a reason, other than the fact that it’s a tradition, to calculate the house edge in terms of the intial bet instead of the total bet?

If I remember correctly, Uston used TBA. All other books use IBA. The reason is that IBA is the correct method in that all risk calculations require IBA since your initial bet determines all eventual actions and therefore risk factors.

 

[Sonny]

Hey Qfit, since we're talking a bit about RNGs, have you heard of the NIST tests for randomness? I heard they are replacing the die hard tests but I don't know how reliable that info is.

-Sonny-

 

[QFIT]

Hey Qfit, since we're talking a bit about RNGs, have you heard of the NIST tests for randomness? I heard they are replacing the die hard tests but I don't know how reliable that info is.

-Sonny-

Nope, thanks for the ref. The massively fast parallel machines these days may very well require improved RNGs. Decades back, I would have never believed current speeds achieved.

I hear IBM is going to enter a computer on Jeopardy.

 

[GZAN]

Hey,

Shuffling after every hand would be necessary to compare exactly to the number above, because of the so-called "Cut Card Effect". However, it does make the sim much slower to shuffle every hand. Dealing 5 decks roughly out of 6 before shuffling should still be very close to the above number.

I think I understand the way this "Cut Card Effect" works. Shuffling at a certain percentage will give wrong results when simulating a CSM. However, shuffling after a fixed amount of hands are played shouldn't make a difference, should it? That way I could still avoid the big speed hit of reshuffling after every hand.

I did a couple of simulations in wich the shoe is reshuffled after every hand and they resulted in a house edge's between 0,4% and 0,5%. I'm not sure what is going wrong.

It would be very helpfull if there was an existing software package or library that could somehow mirror all the hands my simulator plays. This way I could check for hands that are being played wrong.

One way to check for bugs is to have the program output the frequencies of each hand (both two-hand totals and final totals) and compare that to the theoritical numbers.

I'm planning on doing some tests like this but I'm unsure about the theoratical numbers for this kind of statistics. Maybe there is an existing simulator that allows exporting the final hand totals?

Any other idea's on effectively debugging (blackjack) monte carlo simulators are very much apreciated.

Thanks,

GZAN

 

[GZAN]

Hey,

Using the method proposed by Sonny I eventually found another bug. This bug allowed to player to double on hands he was not allowed to double on. With this fixed I ran a simulation with 1.000.000.000 rounds and it resulted in an IBA of 0,611406%. This is very close to the theoretical edge of 0,613721130967071% posted by KenSmith.

Thanks again for all of the very much appreciated comments, I learned a lot from this project! Now the next step might be adding some sort of counting algorithm.

GZAN

 

[KenSmith]

Excellent. Sounds like you've squashed the bugs. And yes, you can safely side-step the cut card effect by dealing a fixed number of rounds between shuffles.