Help Required - Computing probability

Hi Guys

I've asked questions on this subject before and it seems it is quite a tricky one to answer. However I think I am near to a solution and I'm hoping someone can verify some figures for me. But let me start at the beginning...

What I am trying to do (and this has consumed me for a while now!) is calculate the probability of hitting to a specific value or range of values (a "Hit Window" as I have started to call it). It's easy to calculate if you do it for just 1 hit. For example, the probability of hitting exactly 18 starting from 14 is 1/13 = 7.69%. The probability of hitting to 18 or greater without busting in 1 hit is 4/13 = 30.77%. So far so good. But of course that doesn't tell the whole story as more often than not you'll need to take 2 cards to get to a hit window. Or 3 cards, or more. So in our example above the figure of 30.77% actually underestimates to total probability of making that hit window. If you hit a 2 with your 1st card you'd hit again. The overall probability of hitting to 18 or greater from 14 if we hit until we make a minimum of 18 is actually 38.43%, which is a vast difference and can and often does affect decision making.

Now I have already solved 1/2 of my problem sometime ago and have a table that I use to give me the figures for multiple hit probabilities. It was fairly easy to figure out in fact but only for hit windows in the range where the maximum value is less than 10. I know my figures in that table are correct because I have verified them. My problem arises when I want to know what my probability of hitting to hit windows where the maximum value of the range is 10 or greater (e.g. hitting 8 to 18) or where I will definitely have to hit twice to even get to the minimum value (e.g. hitting 5 to 17). It's far too time consuming and prone to error to figure this manually as I did for my initial table so I realised that I need a computer to figure this for me. My problem was that I couldn't find any off-the-shelf software that would do it and I have no programming skills. Or so I thought...

Actually when I was much younger I was quite a demon BASIC programmer and as I was perusing bjmath.com the mention of BASIC in an article made me think that I might be able to write a program for this problem myself. I hadn't written a BASIC program since the late 1980s but I thought if I learned it once I could probably learn it again pretty quickly. So I googled BASIC and found a neat little BASIC program called justBASIC which was FOC so I downloaded it. A quick scan of the manual reminded me of how it all worked and within hours I was writing programs again! I was amazed as it all came flooding back, just like riding a bike!

So long story short, I have spent the last week writing a program to help resolve this probability problem and I think I may well have done it. It calculates correctly all the probabilities that I can verify myself using my pre-existing table but of course I don't know whether it computes correctly for the figures greater than 10 etc. And this is where you come in. Can anybody who has their own software or charts or whatever verify some numbers?

So the rule is hit until you make at least the minimum value.

Code:

Initial Hand Value     Min Hit Value     Probability
10                     21                   16.76%
8                      18                   66.62%
9                      18                   68.85%
10                     18                   71.07%
6                      18                   48.09%
9                      17                   77.16%
9                      19                   58.91%
4                      19                   40.87%
4                      17                   59.94%
5                      17                   58.35%
6                      17                   57.68%
7                      17                   77.37%
 

I just plucked these figures out but if they are verified as correct then it would seem likely that they program works. I will probably work them all out in a chart if that's the case and hopefully somebody could give that the once over as well.

I would provide the source code but I'm very embarrassed by it. It's not very elegant and is very, very slow since it loops through all the potential hit combinations up to 5 hits and checks each one to see if it's valid. I know there are better, quicker ways and if this program proves to be accurate I will be able to refine my program.

Cheers

Reachy

 

I can't offer much help, but ...

Just to clarify - I assume all your calculations are based on an infinte deck, and also that you are not currently treating soft totals any differently from hard ones (e.g., stand on 17 means stand on all 17s, hard or soft).

I think someone mentioned previously that the dealer probabilities are useful as a comparison. Those of your examples that have a target total of 17 should give the same answer as 1 - p(dealer bust).

You can check them against Ken's table http://www.blackjackinfo.com/bjtourn-dealercharts.php#IDS17

I looked at a few and they were either close or exact. Your total of 77.37% for a 7 looks suspiciously like a typo, since Ken's is 73.77%

Similarly, a target of 18 should be p(18) + p(19) + p(20) + p(p21) + p(17)*4/13
(Using the H17 table) i.e. dealer hits to 18+, or hits to hard 17 and then (somewhat unusually) takes one more card without busting [A..4]. I checked your example for a starting hand of 8, and that does indeed seem to be the case (allowing for rounding errors from summing the 2dp figures in the table).

 

Brilliant!

Thanks for that tip Colin. And yes it was I typo. I'm excited now!!!!

Cheers

Reachy

 

You're most welcome

You may have a problem wth low starting hands, where drawing an ace will give a soft total that must be hit (and could then become a hard total by 'busting' if the ace were to be treated as 11, or could become a slightly higher soft total if a small card comes out.)

Your 5-to-17 figure (58.35%) is only 0.01 different (and that might be a rounding issue), but your 4-to-17 figure (59.94%) differs by 0.61 from the table's 60.55%.

Looks like you're definitely on the right track though.

 

Bugger!

I knew it was too good to be true :sad:

It's got to be to do with my Ace Value Allocation Algorithm! The difference between hitting 4 and 5 to 17 is significant. 2 Aces, 1 valued at 11 and 1 at 1 will hit 5 to 17 but not 4. I wonder whether that is it...?

More data to follow...

Cheers

Reachy

 

What else?

Could their be another reason why mine a Ken's figures are different?

Just hoping....

Cheers

Reachy

 

Hard to say without knowing more. Are you just talking about the example(s) above, or have you identified a whole set that are different?

From some of your earlier comments, I wondered if you were working with combinations of cards, rather than permutations, forgetting that not all combinations are possible. E.g., the dealer, who must stand on 17, can reach 19 by 10 + 2 + 7, but not by 10 + 7 + 2.

 

Perm

I'm working with permutations. The algorithm does correctly detect the differences in the example you outlined. I'm looking through the output data and I've yet to find any combinations that are illegal. My concern is that it is ruling out combinations that are valid and that would be much harder to spot. Currently going through it with a fine tooth comb....

Cheers

Reachy

 

I think I may have cracked it/up!

I've spent (too) many hours on this but I'm not going to give up now!!!

I think I may well have got this sorted now. After trying with loads of different algorithms I finally ended up with what is the most obvious one, so obvious in fact that I didn't think about it until last night!

Previous attempts included calculating all possible hand totals that fell into the hit window then eliminating them one by one. Or calculating all the 2 card combinations, 3 card combinations, etc... And various refinements.

What jumped out at me last night (I really don't know why I didn't think of it from the off ) was an algorithm that played the hand as if it were in a "real" game. That is, take a card, if it doesn't take me to my hit window then take another card, and so on. Cycle through all the different combinations and there you go. It seems to work and is a heck of a lot quicker than my previous attempts!

Still there is a slight issue. I think. To test the accuracy of the program I have been comparing the results of hitting from hand totals of 2-10 up to 17-21 with Ken's dealer outcome charts for an infinite deck S17 (e.g. what's the probability of hitting a hard 8 to at least 17 without busting). They all match up exactly now. Apart from a few that is!!

The table below illustrates my problem. "Total" corresponds to my starting hand total; "Ken" corresponds to Ken's data as described above and "Reachy" is my data generated by my program. As you can see it's all hunky dory from 5 to 9. But 2,3,4 and 10 are off and I can't figure out why. I have a hypothesis for the 2/3/4 error but I can't think why the 10 might be out. I think the 2/3/4 are off because I restricted myself to hitting with up to 5 cards only. Hitting from low numbers to big numbers can often involve 6 or 7 cards and theoretically, using an infinite deck, could take 13,14 or 15 cards! Is this the source of my error in this case do you think? And what about the 10? Please help me I going MAD!!!!!!! Hatstand.

Code:

Total	2	3	4	5	6	7	8	9	Ten
Ken	64.64%	62.61%	60.55%	58.36%	57.68%	73.77%	75.53%	77.16%	77.02%
Reachy	63.62%	61.77%	59.83%	58.35%	57.68%	73.77%	75.52%	77.16%	78.78%

Cheers

Reachy

PS. I will post my hand outcomes for hitting 10-17+. If you can see any glaring inaccuracies please tell me. I can't see the wood for the trees anymore.

 

Hit 10 Outcomes

Below is the output generated by my program. I hope it speaks for itself. Each number represents a card value and these are, according to my software at least, all the 1, 2, 3, 4 and 5 card combinations that will achieve the goal of turning a hard 10 into at least a 17. If you feel minded to do so I would appreciate you casting your eyes over this. You may spot something that I have missed. Your help is greatly appreciated.

Code:

Current Hand Value?10
Minimum Required Hand Value?17
Min 7 Max 11
11
2 1 1 1 2
2 1 1 1 3
2 1 1 1 4
2 1 1 1 5
2 1 1 1 6
2 1 1 2 1
2 1 1 2 2
2 1 1 2 3
2 1 1 2 4
2 1 1 2 5
2 1 1 3
2 1 1 4
2 1 1 5
2 1 1 6
2 1 1 7
2 1 2 1 1
2 1 2 1 2
2 1 2 1 3
2 1 2 1 4
2 1 2 1 5
2 1 2 2
2 1 2 3
2 1 2 4
2 1 2 5
2 1 2 6
2 1 3 1
2 1 3 2
2 1 3 3
2 1 3 4
2 1 3 5
2 1 4
2 1 5
2 1 6
2 1 7
2 1 8
2 2 1 1 1
2 2 1 1 2
2 2 1 1 3
2 2 1 1 4
2 2 1 1 5
2 2 1 2
2 2 1 3
2 2 1 4
2 2 1 5
2 2 1 6
2 2 2 1
2 2 2 2
2 2 2 3
2 2 2 4
2 2 2 5
2 2 3
2 2 4
2 2 5
2 2 6
2 2 7
2 3 1 1
2 3 1 2
2 3 1 3
2 3 1 4
2 3 1 5
2 3 2
2 3 3
2 3 4
2 3 5
2 3 6
2 4 1
2 4 2
2 4 3
2 4 4
2 4 5
2 5
2 6
2 7
2 8
2 9
3 1 1 1 1
3 1 1 1 2
3 1 1 1 3
3 1 1 1 4
3 1 1 1 5
3 1 1 2
3 1 1 3
3 1 1 4
3 1 1 5
3 1 1 6
3 1 2 1
3 1 2 2
3 1 2 3
3 1 2 4
3 1 2 5
3 1 3
3 1 4
3 1 5
3 1 6
3 1 7
3 2 1 1
3 2 1 2
3 2 1 3
3 2 1 4
3 2 1 5
3 2 2
3 2 3
3 2 4
3 2 5
3 2 6
3 3 1
3 3 2
3 3 3
3 3 4
3 3 5
3 4
3 5
3 6
3 7
3 8
4 1 1 1
4 1 1 2
4 1 1 3
4 1 1 4
4 1 1 5
4 1 2
4 1 3
4 1 4
4 1 5
4 1 6
4 2 1
4 2 2
4 2 3
4 2 4
4 2 5
4 3
4 4
4 5
4 6
4 7
5 1 1
5 1 2
5 1 3
5 1 4
5 1 5
5 2
5 3
5 4
5 5
5 6
6 1
6 2
6 3
6 4
6 5
7
8
9
10
10
10
10
78.7889888
Current Hand Value?

Cheers

Reachy

 

Minimum information puzzle

I can only really come up with a few general considerations for you -

You are right that the best approach is to play out the hand, drawing cards until you bust or reach your target. I don't think you should be limiting the number of cards though; that must surely lead to discrepancies.

Recursion (if your BASIC allows it) is a powerful tool for this sort of thing, making the code simpler to write/understand. (This might remove your need to limit the number of cards to five.)

With starting totals of 6 and above, an ace drawn to the hand will always retain its value of 1 or 11 (if your target is 17), whereas for lower totals it will sometimes need to be changed later, from 11 to 1, in order to avoid busting. Perhaps you have not implemented this properly, which would explain the increasing discrepancies for totals below 6. Maybe multiple aces in the hand complicate this situation.

This overall approach, once you have got it working, ought to be easily modified to work with specifc deck sizes, rather than just infinite deck. When you draw a card from the deck you just need to -

• first check that there are indeed some of that denomination left in the deck
• decrement the number of that denomination (n)
• decrement the total number of cards in the deck (t)

(and reverse the process, putting the card back in the deck, when you take it out of the hand.)
The individual card probabilities rather than being 1/13 or 4/13, are then just n/t (prior to removing the card from the deck)

 

If you have 7, 8, and 9 exactly correct, but not 10, my guess is that you are handling the case of a dealt BJ differently from Ken. For example, Ken probably does not count a dealt BJ as a case of having a 10 up and getting a successful hit (since for the purposes of BJ strategy, you should assume the dealer does not have a dealt BJ; if he does, there's nothing you can do strategy-wise). However, if you are calculating the probability of not busting with a 2-card 10, you absolutely count the A as a success.

Hope that helps.

 

imbecile

Thanks for your help guys, really appreciate it. Complicated problem (for me) so any help is great.

I discovered a problem with the algorithm just before I went to bed last night. If an Ace is initially given a value of 11 and then is subsequently reassigned as a 1 it stays as a 1. I need to reassign its 11 value after each sequence.

How does recursion work and how will I know if my BASIC supports it?

Cheers

Reachy

 

That would be cool.

One of my favourite web tools seems to have recently disappeared http://www.gamblingtools.net - "This domain has been suspended or does not exist on this server". Anyone know what's become of this?

It only offered hand expectations though, more useful for regular play than for tournament decisions.

I've been working on a few ideas myself, but progress has been sporadic to say the least.

I was thinking along those lines too, but I don't think that's it. I may well be missing something, but as I see it an analogy is being drawn between a player hitting a notional total until reaching 17 and the dealer starting with a particular up card. (The notional totals must therefore be in the range 2-10). The player's first hit card is equivalent to the dealer flipping their hole card.

Recursion requires that you can use functions/procedures, rather than the archaic GOSUB/GOTO, and that those functions can have separate copies of local variables each time they are called. (So that the function can call itself and start with a clean slate, so to speak.)

The simplest example is the factorial function. Mathematicians define it recursively -
1! = 1
n! = n * (n-1)!

You define the trivial case, when n is 1, and then you define the general case in terms of itself.
So,
4! is
4 * 3! is
4 * 3 * 2! is
4 * 3 * 2 *1! is
4 * 3 * 2 *1

In programming terms, factorial is not a good candidate for implementing recursively because it is almost as simple and much more efficient to do it iteratively, but there are many problems which require hundreds of lines of error-prone, hard-to-follow, iterative code but can be expressed in a handful of lines using a recursive algorithm.

So, in some sort of BASIC-like language, the factorial function might be implemented iteratively as

Code:

function f(x)
 a =1
 for i = 1 to x
   a = a * x
 next
 return a 
end

or recurively as

Code:

function f(x)
 if x = 1 then 
   return x
 else
   return x * f(x-1)
end

For the BJ problem, the trivial case is hitting once and either busting or reaching your target, and the general case is is hitting, generating a new total and feeding that total into the same algorithm.

Hope that all makes sense.

 

My results

I couldn't resist having a go myself. I get the following -

Code:

Target: 17+

Total: 2        Prob: 0.646392
Total: 3        Prob: 0.626125
Total: 4        Prob: 0.605532
Total: 5        Prob: 0.583596
Total: 6        Prob: 0.57685
Total: 7        Prob: 0.737688
Total: 8        Prob: 0.755259
Total: 9        Prob: 0.771575
Total: 10       Prob: 0.787891

Which is more or less the same as Ken's, except for the 10, which is more or less the same as yours. So maybe toonces was on to something about the dealer BJ issue, but I can't quite work out what would be causing the difference.

 

i hate you

I spend bloody weeks and still can't get the right answer and you knock a program off in your coffee break....

You bugger!

:joker:

Cheers

Reachy, Chief Programmer, Reachsoft

 

And for an encore ...

I've realise what the 10 difference is caused by. Ken's figures for 17 .. 21 and Bust add up to 100%. i.e. they are conditioned on the dealer having already checked for a BJ and not found one.

I confess I wasn't starting from scratch with my code. I had some samples which I could hack into shape.

 

Don't speak french

PASCAL is French for BASIC right ? So if i downloaded a PASCAL compiler I could just copy and paste your code into it Ken?

I'm going to crack this tonight as I know where my error is. I'm reassured that Ken's code is at least as long as mine.

Incidentally I added extra lines to my code last night to allow hits of up to 7 cards. The affect on the probability was a matter of a few 0.01%.

I'll report back later with my results!

Cheers

Reachy