
Originally Posted by
Cacarulo
After reviewing my code I realized that the method I was using was a Gaussian approximation. Back in the days when computers weren't that fast, doing it under strict combinatorial analysis took a lot of processing time, especially in shoes. In fact, to obtain the probability of a certain RC with N cards remaining, it was much faster to use a Normal approximation (there is an explanation of how to do it in TOB). My idea is to try to improve the results using the Gaussian approach.
Anyway, I can also do it using combinatorial analysis. Here are my numbers to 12 digits of precision so we can see if our programs match:
Code:
1) RC = +1 | CR = 38 | A removed (1D)
| 0.118480844761 | 0.062504209740 0.073908841110 0.073908841110 0.073908841110 0.073908841110 0.073908841110 0.078198599809 0.078198599809 0.078198599809 0.333355785282 |
| 0.118480844761 | 2.375159970136 2.808535962172 2.808535962172 2.808535962172 2.808535962172 2.808535962172 2.971546792759 2.971546792759 2.971546792759 12.667519840725 |
2) RC = -13 | CR = 52 | No cards removed (2D)
| 0.001319524919 | 0.051923076923 0.101923076923 0.101923076923 0.101923076923 0.101923076923 0.101923076923 0.076923076923 0.076923076923 0.076923076923 0.207692307692 |
| 0.001319524919 | 2.700000000000 5.300000000000 5.300000000000 5.300000000000 5.300000000000 5.300000000000 4.000000000000 4.000000000000 4.000000000000 10.800000000000 |
3) RC = -13 | CR = 52 | A removed (2D)
| 0.001748370518 | 0.046449210406 0.101757691595 0.101757691595 0.101757691595 0.101757691595 0.101757691595 0.077474361349 0.077474361349 0.077474361349 0.212339247570 |
| 0.001748370518 | 2.415358941111 5.291399962953 5.291399962953 5.291399962953 5.291399962953 5.291399962953 4.028666790158 4.028666790158 4.028666790158 11.041640873651 |
4) RC = -13 | CR = 52 | A,T,7 removed (2D)
| 0.002324475807 | 0.048194174755 0.102325104020 0.102325104020 0.102325104020 0.102325104020 0.102325104020 0.069010552983 0.078869203409 0.078869203409 0.213431345344 |
| 0.002324475807 | 2.506097087263 5.320905409029 5.320905409029 5.320905409029 5.320905409029 5.320905409029 3.588548755129 4.101198577291 4.101198577291 11.098429957881 |
5) RC = -13 | CR = 52 | T,7 removed (2D)
| 0.001752858519 | 0.053838176772 0.102492222353 0.102492222353 0.102492222353 0.102492222353 0.102492222353 0.068501931969 0.078287922250 0.078287922250 0.208622934993 |
| 0.001752858519 | 2.799585192160 5.329595562356 5.329595562356 5.329595562356 5.329595562356 5.329595562356 3.562100462394 4.070971957022 4.070971957022 10.848392619621 |
Sincerely,
Cac
PS: These days I am going to publish the exact insurance indices for Hi-Lo taking into account different penetrations.
It appears we are in complete agreement.
This is how I output insurance indexes:
Code:
Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
Decks: 8
Insurance Data (without regard to hand comp)
No subgroup (removals) are defined
**** Player hand: x-x ****
Cards RC TC ref
384 29 3.93
383 28 3.80
382 27 3.68
379 26 3.57
376 25 3.46
370 24 3.37
362 23 3.30
352 22 3.25
341 21 3.20
327 20 3.18
313 19 3.16
298 18 3.14
283 17 3.12
267 16 3.12
251 15 3.11
234 14 3.11
218 13 3.10
201 12 3.10
185 11 3.09
168 10 3.10
151 9 3.10
134 8 3.10
117 7 3.11
100 6 3.12
83 5 3.13
66 4 3.15
49 3 3.18
32 2 3.25
15 1 3.47
2 0 0.00
1 1 52.00
Press any key to continue
Above outputs in about a second or so. I can generate indexes for HiLo fairly efficiently. It takes about 3 minutes to generate HiLo RC indexes for a hand of 2-2 for 208 cards remaining from 8 decks for all up cards. T-6 for 8 decks takes only a second or so.
It's a different story for Wong Halves. For 8 decks with 208 cards remaining HiLo has 49 count subsets whereas Wong Halves has 582905. Insurance indexes are somewhat attainable but others are more of a problem.
8 decks is about the worst case to worry about. I wonder if efficiency can be further improved.
k_c
Bookmarks