Does anybody know if Julian Braun's program was a simulation or was he able to cycle thru every possible combination of player and dealer hands? I've written my own program to do the latter, but it can only handle 1 split in a reasonable amount of time (10 hours on my old PC).
What language are you working in?
I have a lot of C code, plus a *lot* of shortcuts I've developed over the years to minimize rounding errors, refrain from duplicating operations, etc.
I'm using the MS Visual C++ 6.0 compiler, but other than the I/O, it's all C code.
I've decided against supply you with actual code. The reason is that if you ran my code, you'd just be duplicating what I've already done. I think it better for each of us to use our own approaches.
But I don't think any harm will be done by giving you some hints.
Here is what I did to speed up the split process:
1. Determine the correct Hit, Stand, Double strategy.
2. For each pair, generate every possible card combination starting with that card using the above strategy. The first card is held in a file section header, and only the subsequent cards are recorded in a struct:
#define byte unsigned char;
{ char hand[14]; byte score; byte ways; byte bet; }
Yes, you need 14! Consider the hand AAAAAAAA4AAAAA (remember, soft 18 sometimes hits) -- 14 cards! Only 13 will be stored in the struct, but the way I calculated probs I needed the cards to be followed by at least one null char:
ptr = (char far*)&[the struct].hand;
numerator = 1.0;
while ( card = *ptr++ )
{...if ( !card_counts[card] )
........return;
....numerator *= card_counts[card]--;
}
[ignore the ".'s," they're just for spacing purposes]
The denominator is always the same for each number of cards, which can easily be determined by the strlen() function. IOW, for six decks the denominator for the one card will always be 309 (because two of the pair card and one of the dealer upcard will already have been removed from the shoe). The denominator for two cards will always be 309 * 308, etc. Thus you can precalculate all denominators and save a great deal of double precision math number crunching time.
As new combos are generated, the cards in the hand are sorted and the previously generated combos are searched for a match, and "ways" in the existing struct incremented for each match; or the combo added if no match.
This isolates each *unique* combination and records the number of times it occurs.
3. Once all unique combos are determined, they are sorted in ascending order of probability of occurance (remember to utilize the "ways" member when doing this), and written out to a disk file.
4. Do the same thing (2 & 3 above) with all dealer combos.
Now, with both files sorted in probability order, you will be handling the combinations of player and dealer structs in ascending order of probability, which automatically minimizes rounding errors, provided you handle it properly. I did it by accumulating the probs separately for each stage (first hand, second hand, dealer hand). IOW, the sum of all probs from the dealer stage was accumulated first, then those sums accumulated at the second hand stage; and those sums accumulated at the first hand stage. This method ensures that each value accumulated will never be significantly smaller (or too much larger, for that matter) than the previous one.
Because double and even long double precision numbers only have a limited number of bits of precision (56 and 80, respectively), if you don't do it that way, then the prob of just one frequently occuring situation (with an exponent of say 2^-10) will wipe out all the accumulated results of literally millions of situations with much lower exponents in the range of say, 2^-70 to 2^-140.
Now, even when using only the unique possibilities, and using the "ways" members to help calculate the actual probs, you will still have a *huge* number of permutations.
One way to radically speed up the process is to limit the number of situations you will consider. For example, you could decide to ignore all situations where there are more than 12 cards between the two player hands. IOW, the most extreme cases would be 10 cards in one hand in two in the other; or 6 in each, etc. Since the excluded such events are so *extremely* improbable, it's pretty safe to do this. I keep my results out to 5 decimal places; and found that ignoring such extremely improbable situations has no measurable effect on the results at that level of precision.
But I do *not* limit the number of cards in the dealer's hand -- I consider *all* dealer possibilities.
I hope all this helps.
If you run into problems, please don't hesitate to contact me.
Has anyone written or seen a program which actually verifies the basic strategy plays and strategy adjustments for count. I am attempting to write one of my own, however my results don't verify basic strategy or any strategy adjustments, and instead are slightly off; such as hitting 12 vs dealer 2. ( with over 300,000 hands run & using visual basic 5.0 ). My results show to stand when count is zero. I fully admit that my programming skills are at the beginner level, but I cannot find any errors in the code.
I would be happy to supply the code and would appreciate any comments !
Or reply to timkieper@buckeye-express.com
>...(with over 300,000 hands run & using visual basic 5.0)...<
Sounds to me like you're going about this the wrong way.
Just by playing and recording results, you'll never accumulate enough data for some of the rarer hands at the extreme counts.
For example, let's say a true count of +5 occurs only 2% of the time. The situation of A7 vs 2 (in 6-deck) only occurs 24 * 24 * 24 / 312 / 311 / 310 of the time. To be able to record the results of 100 million of these hands at a +5 count, you'd have to run an average of roughly 11 QUADRILLION total hands.
What you need to do is construct a "typical" deck/shoe for each count, then run every possible final hand for the initial 2-card hand against every possible final hand for the dealer's up card, keeping track of the results and accumulating the probs as you go.
Tim,
Back in the early 90's I did as OldCootFromVA suggests and wrote a program that allowed me to exactly compute the correct BS for single deck (it was still reasonably available at the time).
Found there were very few exceptions to what has been printed and the differences did not really matter.
Dtm
I'd like to know what you get for the following play:
(Single Deck, S17, NDAS, SPL1)
Splitting EV for 8,8 vs 9.
I assume that you're using a brute-force combinatorial analysis.
Thanks in advance.
Curious
Is there a translator in the house? NDAS has to mean no double after splitting and I guess S17 has to do with soft 17 (hit or stand?). But the rest has me puzzled.
If you want, I can take a look at your code.
I've made a BJ program in VB if anyone wants some source code I could clean it up a bit and send by next weekend. (March 23 or so)
NDAS=No double after split
S17=Dealer stands on soft 17
SPL1=Only one split (NO re-splitting)
Hope this helps.
Curious
Here's the numbers I get: player wins 33.03%, ties 11.76 and loses 55.21. Seemed wrong initially til I remembered we're talking about TWO hands of 8 vs. 9. Most of this is when the player gets 18 (37.69%) and the dealer gets 19 (35.74).
Could you get the expected value (EV) of the two hands?
Thanks
Curious
Do you mean the breakdown of the player's hand? If so, they are: 21 - 7.04%, 20 - 6.93, 19 - 13.24, 18 - 37.69, 17 - 11.69, bust - 23.41
Here's a link which defines exactly what I want:
Hope this helps.
Thanks,
Curious
That info was in my previous message. Player wins 33.03% and loses 55.21, so the EV = .3303 - .5521 = -.2218
but that's not the EV for splitting. Have you done any further work on that?
Thanks.
Curious
I don't know what you're asking for. The EV for splitting 8's vs. a 9 is -.22, i.e. for every dollar bet, you can expect to lose 22 cents. Are you looking for the difference between splitting and not splitting?
