Proving CA algorithms incorrect (or at least inexact)

[ericfarmer]

I don’t quite understand; what does it mean that some are not reachable via optimal strategy?

I’ll review the code later to see if I can find the differences. Thanks.

Sincerely,
Cac

For example, the first scenario listed, "868 88 86# 8", indicates that we have split to 4 hands, completed the first two, and have drawn a 6 to the third, on which we should double down... but I only meant that we would never encounter this particular situation in the first place, since upon drawing a 6 to the first (leftmost) hand, we would have stood, not doubled/hit to yield the busted 868.

[iCountNTrack]

In case you missed my earlier which was buried in the other page. I still dont get the same value. But it's closer now!

Aaaa, sorry I should have told you about this. The number of resplits means the number of splits AFTER the initial split. So when you input 3 that means you will end up with 5 split hands.

Action: Split
Expectation Value: 2.601398601398604
Standard Deviation: 4.285339825796309
Net Outcome Probabilities:
  Net Outcome: -7.000000000000000 units, Probability: 0.001398601398601
  Net Outcome: -6.000000000000000 units, Probability: 0.013986013986014
  Net Outcome: -5.000000000000000 units, Probability: 0.013986013986014
  Net Outcome: -4.000000000000000 units, Probability: 0.048951048951049
  Net Outcome: -3.000000000000000 units, Probability: 0.013986013986014
  Net Outcome: -2.000000000000000 units, Probability: 0.117482517482518
  Net Outcome: 0.000000000000000 units, Probability: 0.102097902097902
  Net Outcome: 3.000000000000000 units, Probability: 0.009790209790210
  Net Outcome: 4.000000000000000 units, Probability: 0.037762237762238
  Net Outcome: 6.000000000000000 units, Probability: 0.015384615384615
  Net Outcome: 7.000000000000000 units, Probability: 0.067132867132867
  Net Outcome: 8.000000000000000 units, Probability: 0.311888111888112

[ericfarmer]

Gentlemen, here are some interesting examples I’d like you to recalculate, especially the maximum expected value:

1. 0 0 0 0 0 4 7 0 0 0 | 7, 7 vs 6 |
2. 0 0 0 0 0 4 7 0 0 0 | 6, 6 vs 6 |
3. 0 0 0 0 0 6 4 0 0 0 | 7, 7 vs 6 |
4. 0 0 0 0 0 7 5 0 0 0 | 7, 7 vs 6 |

For now, just these.

Sincerely,
Cac

These cases are in the "CDP vs. maximum" table provided earlier; see the links to each corresponding line number:

1. 0 0 0 0 0 4 7 0 0 0 | 7, 7 vs 6 | 2.4285714285714284
2. 0 0 0 0 0 4 7 0 0 0 | 6, 6 vs 6 | 0.25
3. 0 0 0 0 0 6 4 0 0 0 | 7, 7 vs 6 | 2.4761904761904763
4. 0 0 0 0 0 7 5 0 0 0 | 7, 7 vs 6 | 2.8333333333333335

[Cacarulo]

For example, the first scenario listed, "868 88 86# 8", indicates that we have split to 4 hands, completed the first two, and have drawn a 6 to the third, on which we should double down... but I only meant that we would never encounter this particular situation in the first place, since upon drawing a 6 to the first (leftmost) hand, we would have stood, not doubled/hit to yield the busted 868.

That’s what I thought. But if the program is forcing situations that should never happen, how can the result still be correct? What would the EV be if, upon drawing a 6 to the first hand, the program executed the correct decision, which is to stand?

For this same example, I would also like to see what happens if doubling after splitting is not allowed. What would the resulting EV be?
Thanks in advance.

Sincerely,
Cac

[Cacarulo]

These cases are in the "CDP vs. maximum" table provided earlier; see the links to each corresponding line number:

1. 0 0 0 0 0 4 7 0 0 0 | 7, 7 vs 6 | 2.4285714285714284
2. 0 0 0 0 0 4 7 0 0 0 | 6, 6 vs 6 | 0.25
3. 0 0 0 0 0 6 4 0 0 0 | 7, 7 vs 6 | 2.4761904761904763
4. 0 0 0 0 0 7 5 0 0 0 | 7, 7 vs 6 | 2.8333333333333335

Yes, those cases aren't entirely random; they have a few additional layers of complexity. I was curious to see the results iCountNTrack obtained with his own CA before sharing my full analysis of the 4,840 cases from the file.

Sincerely,
Cac

[iCountNTrack]

These cases are in the "CDP vs. maximum" table provided earlier; see the links to each corresponding line number:

1. 0 0 0 0 0 4 7 0 0 0 | 7, 7 vs 6 | 2.4285714285714284 | 0.6666666 | 2.428571428571428
2. 0 0 0 0 0 4 7 0 0 0 | 6, 6 vs 6 | 0.25 | 0.00|0.5000
3. 0 0 0 0 0 6 4 0 0 0 | 7, 7 vs 6 | 2.4761904761904763 | 1.600 | 2.476190476190476
4. 0 0 0 0 0 7 5 0 0 0 | 7, 7 vs 6 | 2.8333333333333335 | 2.1515152 | 2.928571428571430

My appologies Cac, forgot to generate the values for you. I have two values, red value is from my locally optimum, blue value is from globally optimum approach. It seems that my globally optimum approach agrees with Eric more often than my locally optimum one

@Eric, I am not sure if you have had a chance to take a close look at my code that I had shared. I honestly cant find the reason behind the discrepancies and debugging recursive code is a royal pain for me!

I know that the numbers are off when there is a problem with the distribution of outcomes where the probabilities are not adding up to one. This indicates that the code is overlooking certain states. Please note that in both implementations I always compute the distribution first and then compute EV and Standard Deviation

[iCountNTrack]

For example, the first scenario listed, "868 88 86# 8", indicates that we have split to 4 hands, completed the first two, and have drawn a 6 to the third, on which we should double down... but I only meant that we would never encounter this particular situation in the first place, since upon drawing a 6 to the first (leftmost) hand, we would have stood, not doubled/hit to yield the busted 868.

That’s what I thought. But if the program is forcing situations that should never happen, how can the result still be correct? What would the EV be if, upon drawing a 6 to the first hand, the program executed the correct decision, which is to stand?

For this same example, I would also like to see what happens if doubling after splitting is not allowed. What would the resulting EV be?
Thanks in advance.

Sincerely,
Cac

I think for this exercise we only need to list the final optimum states (a state is a combination of played out split hands with an indication on whether the hand was double or not) that were used in the computation of the overall maximum Expectation Value. For this particular example (14 sixes and 13 eights 8,8 vs 8), is where all 3 different CA implementations (Eric's, locally optimum, globally optimum) are in agreement in terms of EV as well net outcome distributions between my two different implementations. Based on the results below where we see net outcomes of +5 (~0.7%), -5 (0.14%), indicating that there are in fact final states with doubled split hands that were used in the calculation of the maximum expectation value. Double hands can also be shown in the list of optimum final states

Action: Split
Expectation Value: 1.009777407946744
Standard Deviation: 3.136297215584209
Net Outcome Probabilities:
  Net Outcome: -6.000000000000000 units, Probability: 0.000510387221250
  Net Outcome: -5.000000000000000 units, Probability: 0.001391965148864
  Net Outcome: -4.000000000000000 units, Probability: 0.178410161651513
  Net Outcome: -3.000000000000000 units, Probability: 0.055194732355185
  Net Outcome: -2.000000000000000 units, Probability: 0.094620488095384
  Net Outcome: 1.000000000000000 units, Probability: 0.001035051008129
  Net Outcome: 2.000000000000000 units, Probability: 0.236713616172494
  Net Outcome: 3.000000000000000 units, Probability: 0.121697524443520
  Net Outcome: 4.000000000000000 units, Probability: 0.303419849321047
  Net Outcome: 5.000000000000000 units, Probability: 0.007006224582614

Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0)    1
Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0)      3
Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0)    10
Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0)    10
Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0)    10
Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0)    10
Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0)    7
Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0)    7
Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0)    7
Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0)    7
Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,6 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,6 (dblChk: 1) || Hand:8,6 (dblChk: 0)    4 This state has a doubled split hand and could result in +5 for the player if the dealer busts
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,6 (dblChk: 1) || Hand:8,8 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,8 (dblChk: 1) || Hand:8,6,6 (dblChk: 1)    4 
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,8 (dblChk: 1) || Hand:8,6,8 (dblChk: 1)    4 This state has 2 doubled busted hands and could result in -6 for the player if the dealer doesn't bust
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,8 (dblChk: 1) || Hand:8,8 (dblChk: 0)    4
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,6 (dblChk: 1)    4
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,6,8 (dblChk: 1)    4
Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0) || Hand:8,8 (dblChk: 0)    4

[Cacarulo]

My appologies Cac, forgot to generate the values for you. I have two values, red value is from my locally optimum, blue value is from globally optimum approach. It seems that my globally optimum approach agrees with Eric more often than my locally optimum one

@Eric, I am not sure if you have had a chance to take a close look at my code that I had shared. I honestly cant find the reason behind the discrepancies and debugging recursive code is a royal pain for me!

I know that the numbers are off when there is a problem with the distribution of outcomes where the probabilities are not adding up to one. This indicates that the code is overlooking certain states. Please note that in both implementations I always compute the distribution first and then compute EV and Standard Deviation

0  0  0  0  0  4  7  0  0  0 |  7, 7 vs  6 | 2.4285714285714284 | 0.6666666 | 2.428571428571428
0  0  0  0  0  4  7  0  0  0 |  6, 6 vs  6 | 0.25               | 0.00      | 0.5000
0  0  0  0  0  6  4  0  0  0 |  7, 7 vs  6 | 2.4761904761904763 | 1.600     | 2.476190476190476
0  0  0  0  0  7  5  0  0  0 |  7, 7 vs  6 | 2.8333333333333335 | 2.1515152 | 2.928571428571430
 

Thank you iCountNTrack, for sharing your results. Through the scenarios proposed by Eric, I’ve noticed that in depleted shoes, it’s often not possible to split three times, as doing so might leave us without enough cards.
In such cases, the optimal approach is to split fewer times. Moreover, there are instances where splitting more isn’t necessarily better than splitting less.

Here are the results of my analysis for these four specific cases. I’ll share the full analysis of Eric’s 4,840 scenarios in a separate post.

+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| A  2  3  4  5  6  7  8  9  T |    PLAY     |       E[X_MAX]       |       SPL1             SPL2             SPL3        | BEST |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| 0  0  0  0  0  4  7  0  0  0 |  7, 7 vs  6 |  2.4285714285714284  |  2.4285714285714  3.1071428571429  2.7142857142857  | SPL2 |
| 0  0  0  0  0  4  7  0  0  0 |  6, 6 vs  6 |  0.25                |  0.2500000000000  0.5000000000000  0.5000000000000  | SPL2 |
| 0  0  0  0  0  6  4  0  0  0 |  7, 7 vs  6 |  2.4761904761904763  |  2.4761904761905  2.7619047619048  2.2857142857143  | SPL2 |
| 0  0  0  0  0  7  5  0  0  0 |  7, 7 vs  6 |  2.8333333333333335  |  2.4761904761905  2.8333333333333  3.0476190476190  | SPL3 |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+

Sincerely,
Cac

[Cacarulo]

This is the analysis of the 4,840 cases proposed by Eric. Wherever the term "-nan" appears, it means it was not possible to split SPLx times.

https://github.com/Cac-2023/files/bl...ack_farmer.txt

Sincerely,
Cac

[iCountNTrack]

0  0  0  0  0  4  7  0  0  0 |  7, 7 vs  6 | 2.4285714285714284 | 0.6666666 | 2.428571428571428
0  0  0  0  0  4  7  0  0  0 |  6, 6 vs  6 | 0.25               | 0.00      | 0.5000
0  0  0  0  0  6  4  0  0  0 |  7, 7 vs  6 | 2.4761904761904763 | 1.600     | 2.476190476190476
0  0  0  0  0  7  5  0  0  0 |  7, 7 vs  6 | 2.8333333333333335 | 2.1515152 | 2.928571428571430
 

Thank you iCountNTrack, for sharing your results. Through the scenarios proposed by Eric, I’ve noticed that in depleted shoes, it’s often not possible to split three times, as doing so might leave us without enough cards.
In such cases, the optimal approach is to split fewer times. Moreover, there are instances where splitting more isn’t necessarily better than splitting less.

Here are the results of my analysis for these four specific cases. I’ll share the full analysis of Eric’s 4,840 scenarios in a separate post.

+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| A  2  3  4  5  6  7  8  9  T |    PLAY     |       E[X_MAX]       |       SPL1             SPL2             SPL3        | BEST |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| 0  0  0  0  0  4  7  0  0  0 |  7, 7 vs  6 |  2.4285714285714284  |  2.4285714285714  3.1071428571429  2.7142857142857  | SPL2 |
| 0  0  0  0  0  4  7  0  0  0 |  6, 6 vs  6 |  0.25                |  0.2500000000000  0.5000000000000  0.5000000000000  | SPL2 |
| 0  0  0  0  0  6  4  0  0  0 |  7, 7 vs  6 |  2.4761904761904763  |  2.4761904761905  2.7619047619048  2.2857142857143  | SPL2 |
| 0  0  0  0  0  7  5  0  0  0 |  7, 7 vs  6 |  2.8333333333333335  |  2.4761904761905  2.8333333333333  3.0476190476190  | SPL3 |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+

Sincerely,
Cac

You bring up a good point about having compositions that dont have enough cards for 3 splits. I think we need to avoid using those compositions because they introduce an extra layer of complexity to the problem to check whether the code implementation properly handles the situation where we run out of cards to play out a game. The focus should be in comparing the multiple split algorithms to understand the differences. I think we need to choose compositions that are small enough to make strategy post split possible while having enough cards. The examples we had been working with sixes and eights is good, we can also throw in a couple of sevens

[iCountNTrack]

I went ahead and calculated the "Global Optimum" for all the compositions and compiled the results with all previously calculated results. Please see link below for the spreadsheet. Interesting summary underneath.

https://docs.google.com/spreadsheets...f=true&sd=true

All three match (Max, Local, Global): 3884
Max & Local match only but not global: 375
Max & global match only but not local: 319
Local & Global Match only but not Max: 4

[Cacarulo]

+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| A  2  3  4  5  6  7  8  9  T |    PLAY     |       E[X_MAX]       |       SPL1             SPL2             SPL3        | BEST |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+
| 0  0  0  0  0  4  7  0  0  0 |  7, 7 vs  6 |  2.4285714285714284  |  2.4285714285714  3.1071428571429  2.7142857142857  | SPL2 |
| 0  0  0  0  0  4  7  0  0  0 |  6, 6 vs  6 |  0.25                |  0.2500000000000  0.5000000000000  0.5000000000000  | SPL2 |
| 0  0  0  0  0  6  4  0  0  0 |  7, 7 vs  6 |  2.4761904761904763  |  2.4761904761905  2.7619047619048  2.2857142857143  | SPL2 |
| 0  0  0  0  0  7  5  0  0  0 |  7, 7 vs  6 |  2.8333333333333335  |  2.4761904761905  2.8333333333333  3.0476190476190  | SPL3 |
+------------------------------+-------------+----------------------+-----------------------------------------------------+------+

You bring up a good point about having compositions that dont have enough cards for 3 splits. I think we need to avoid using those compositions because they introduce an extra layer of complexity to the problem to check whether the code implementation properly handles the situation where we run out of cards to play out a game. The focus should be in comparing the multiple split algorithms to understand the differences. I think we need to choose compositions that are small enough to make strategy post split possible while having enough cards. The examples we had been working with sixes and eights is good, we can also throw in a couple of sevens

Exactly! The interesting thing about these particular cases is the following:

1. The maximum possible splits without running out of cards is 1.
2. The maximum possible splits without running out of cards is 1.
3. The maximum possible splits without running out of cards is 1.
4. The maximum possible splits without running out of cards is 2.

All four cases have been verified through simulations.
Unfortunately, my CA doesn't always realize this (despite correctly calculating the splits) and could mistakenly assume that the correct EV is SPL2 or SPL3.

Sincerely,
Cac

[ericfarmer]

That’s what I thought. But if the program is forcing situations that should never happen, how can the result still be correct?

You can review the code to see what's happening; don't think of it as "forcing" situations that should never happen, but rather "exploring" all possible situations, playing out all possible strategies to completion, some of which (like this situation) will end up not contributing to the eventually selected optimal strategy, for no deeper reason than, for example, when we compute max(1,2,3,4,5)=5, the 1, 2, 3, and 4 end up not "contributing" to the computed maximum of 5.

There isn't anything fancy here (indeed, that's the point of this approach, that it's simple and thus only feasible for these really small shoes), but the benefit of that simplicity is that we can, also, for example, by tweaking just a few lines of code, evaluate not just the maximum expected value of a given situation, but all possible expected values, among all possible strategies-- including those "pathological" strategies where we hit or double on 86 instead of standing, etc.

What would the EV be if, upon drawing a 6 to the first hand, the program executed the correct decision, which is to stand?

I might misunderstand your question. If you are asking, "what is the expected value of splitting 8-8 vs. dealer 8?" then the answer hasn't changed; it's still the same 4854/4807=1.0097774079467443 value provided earlier. And the strategy that realizes this expected value would direct us to stand on an 86 drawn after the initial split.

If you're instead asking, "given that we have already split 8-8 vs. dealer 8, and drawn a 6 to the "first" hand, what is the expected value of the round resulting from standing on that 8+6=14?" then it's maybe worth noting that there are still arguably three possible relevant questions here, depending on how many resplits we might have already executed before eventually drawing that 6. Following are those results (with the optimal strategy being to stand in each of the three cases):

>>> # Split 8s, draw a 6; optimal strategy is to stand
>>> player((0, 0, 0, 0, 0, 0, 13, 0, 10, 0, 0), 8, ((8, 6), (8,)), (1, 1), 0, True)
  Hand         Stand          Hit         Double         Split
8,6 vs 8    0.987310173   0.573786827   0.542730926              
Fraction(4746, 4807)

>>> # Split 8s, draw an 8 and resplit, then draw a 6; optimal strategy is to stand
>>> player((0, 0, 0, 0, 0, 0, 13, 0, 9, 0, 0), 8, ((8, 6), (8,), (8,)), (1, 1, 1), 0, True)
  Hand         Stand          Hit         Double         Split
8,6 vs 8    1.156527683   0.830099312   0.826203209              
Fraction(1692, 1463)

>>> # Split 8s, draw two 8s and resplit twice, then draw a 6; optimal strategy is to stand
>>> player((0, 0, 0, 0, 0, 0, 13, 0, 8, 0, 0), 8, ((8, 6), (8,), (8,), (8,)), (1, 1, 1, 1), 0, True)
  Hand         Stand          Hit         Double         Split
8,6 vs 8    1.028571429   0.799724802   0.822782446              
Fraction(36, 35)

For this same example, I would also like to see what happens if doubling after splitting is not allowed. What would the resulting EV be?
Thanks in advance.

Sincerely,
Cac

NDAS will take some work. Remember, this implementation was simple-- partly because I wanted results quick, but with hindsight partly because the simplicity makes it hard for bugs to "hide" in there-- and I mean reeaallly simple. I can't even handle aces in the shoe, let alone H17, let alone NDAS.