See the top rated post in this thread. Click here

Page 4 of 6 FirstFirst ... 23456 LastLast
Results 40 to 52 of 70

Thread: Double Down on Soft 12

  1. #40
    Senior Member Gramazeka's Avatar
    Join Date
    Dec 2011
    Location
    Ukraine
    Posts
    1,438


    Did you find this post helpful? Yes | No
    Yes you are right. My program does not take into account A AA3.
    Only AA 3.
    I check this.
    "Don't Cast Your Pearls Before Swine" (Jesus)

  2. #41


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Cacarulo View Post
    Quote Originally Posted by Gronbog View Post
    No such detail was overlooked in my generation of these indices. The indices were computed using simulation and therefore the data were collected across a wide variety of naturally occurring hand compositions, remaining deck compositions and penetrations. No attempt was made to construct representative instances of the possible situations.

    Ok, I understand what you are doing. Would you mind checking AAv3 again (S17 and H17)? I got +7 for both cases. We also have a discrepancy in AAv6. For S17 I got -1 and for H17 I got -2.
    Maybe it has to do with penetration, I don't know. I am using 4.5/6.
    Another back-track for me on this. Further investigation of my algorithm shows that my software indeed only examined A,A vs ? as the initial hand. Because playing split aces is not allowed by the rules, examination of A; A,A ? never occurred.

    Somehow Cac knew this psychically.

  3. #42


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Gronbog View Post
    Another back-track for me on this. Further investigation of my algorithm shows that my software indeed only examined A,A vs ? as the initial hand. Because playing split aces is not allowed by the rules, examination of A; A,A ? never occurred.

    Somehow Cac knew this psychically.
    You made me laugh about my psychic powers
    One thing you could try without modifying the code, is to remove an ace from the 6 deck pack, count it, and then recalculate AAv3. I think that would fix the problem.

    Sincerely,
    Cac

  4. #43


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Gramazeka View Post
    Yes you are right. My program does not take into account A AA3.
    Only AA 3.
    I check this.
    I tell you the same thing I told Gronbog. Try removing an ace from the 6 deck pack, count it, and then recalculate AAv3. Easy solution.

    Sincerely,
    Cac

  5. #44


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Cacarulo View Post
    One thing you could try without modifying the code, is to remove an ace from the 6 deck pack, count it, and then recalculate AAv3. I think that would fix the problem.
    Your psychic powers have failed you this time

    Each time the hand A,A vs ? is examined during the simulation for this game, anywhere from zero to 22 other aces may have been removed. This is the same as things occur during actual play of the game and the results for playing A,A vs ? are the amalgamation of these results. So the contribution of A; A,A vs ? is actually represented (a back-back-track or re-track on my part?) along with all of the other possibilities. Removing an ace from the shoe would mean that anywhere from zero to 21 other aces may have been removed, which does not represent any useful situation.

    Just curious. How do the CA algorithms handle the possibility that different numbers of aces may have actually been removed when playing this hand? In general, how do they handle the vast number of remaining deck compositions which are possible when playing any hand?

  6. #45


    1 out of 1 members found this post helpful. Did you find this post helpful? Yes | No
    Quote Originally Posted by Gronbog View Post
    Your psychic powers have failed you this time

    Each time the hand A,A vs ? is examined during the simulation for this game, anywhere from zero to 22 other aces may have been removed. This is the same as things occur during actual play of the game and the results for playing A,A vs ? are the amalgamation of these results. So the contribution of A; A,A vs ? is actually represented (a back-back-track or re-track on my part?) along with all of the other possibilities. Removing an ace from the shoe would mean that anywhere from zero to 21 other aces may have been removed, which does not represent any useful situation.
    Computing splits efficiently requires using a fixed strategy. Computing every possible strategy decision encountered in the course of splitting a pair can result in an enormous number of iterations, each of which requires calculating dealer probabilities.

    The split strategy known as CDZ- ignores computing post-split strategies altogether by applying pre-split strategies to split hands.
    CD means composition dependent
    Z means zero memory optimal strategy accounting for cards that have been played
    - means pre-splt

    I came up with a strategy which Eric Farmer calls CDP1. CDP1 uses the optimal strategy of the first split hand and applies it to all subsequent split hands. It is a fixed strategy because all split hands employ the same strategy. I think what Cacarulo is suggesting is something like this where split strategy indexes could potentially differ from indexes using pre-split strategy for splits. For a lot of decks there probably wouldn't be much difference.

    Just curious. How do the CA algorithms handle the possibility that different numbers of aces may have actually been removed when playing this hand? In general, how do they handle the vast number of remaining deck compositions which are possible when playing any hand?
    In the course of splitting varying number of pair cards are removed. A fixed strategy allows a very accurate estimate of split EV using a relatively small number of shoe states rather than having to consider all of the possible iterations.

    The first split algorithm I came up with was recursive and continuously removes pair cards until no more splits are allowed. The theory was that hand1 and hand2 of a split would have equal EV if each could be resplit the same number of times. I proceed as if hand1 EV = hand2 EV and the repair the erroneous EV.

    http://www.bjstrat.net/splitAlgorithm.html
    Last edited by k_c; 09-30-2022 at 08:56 PM.

  7. #46


    Did you find this post helpful? Yes | No
    Thanks k_c but, unless I'm reading it wrong, your response addresses improving the performance of the computation of basic strategy using some reasonable assumptions about how the split hands will be played. I am familiar with all of this. But computing basic strategy has the property that you know the exact composition of the remaining cards at all times and so it is naturally suited to CA methods.

    What I'm wondering about is the CA methods used by Cac, Zen and Gramazeka (and you? and others?) for computing indices. Cac speaks about removing specific cards and Zen references exact EOR numbers, but these only represent the situation off the top of the shoe. However, each true count is represented by a vast number of possible remaining deck compositions multiplied by a variety of penetrations. Cac then goes on to reference an assumed level of penetration (4.5/6 in this case).

    I know from experimenting with my own simulation algorithms that the final index numbers are sensitive to all of these factors. For each holding, the expected frequency of occurrence varies with penetration and the expected frequency of occurrence of remaining deck compositions, from "balanced" to "extreme", for lack of better terms, and it necessary to collect samples in numbers which reflect these frequencies. Using simulation makes this easy. I'm wondering how all of this comes together when using CA methods to calculate indices.

    If anyone is inclined to share insights, I suggest a new thread in the Advanced Strategies, Theory and Math forum.

  8. #47


    1 out of 1 members found this post helpful. Did you find this post helpful? Yes | No
    Quote Originally Posted by Gronbog View Post
    What I'm wondering about is the CA methods used by Cac, Zen and Gramazeka (and you? and others?) for computing indices. Cac speaks about removing specific cards and Zen references exact EOR numbers, but these only represent the situation off the top of the shoe. However, each true count is represented by a vast number of possible remaining deck compositions multiplied by a variety of penetrations. Cac then goes on to reference an assumed level of penetration (4.5/6 in this case).
    I can only speak for myself. I can try to illustrate approximately A-A versus 6, h17. This does not remove an additional ace which would be the case if A-A resulted from splitting aces.

    Basically,

    1. Compute rank probabilities based upon the running count of a given counting system and number of cards remaining, allowing for cards known to be specifically removed. This can immediately be used to find RC/cards remaining where insurance is +EV. However, for other indexes only player cards are specifically removed but not up card in order to adapt to the way my CA works.
    Code:
    Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
    Player hand composition: 2, 0, 0, 0, 0, 0, 0, 0, 0, 0:  Soft 12, 2 cards
    Decks: 6 (possible input for cards remaining: 1 to 312)
    Cards remaining before up card (current = 156, no input = no change):
    Initial running count (full shoe): 0
    Running count (before up card is dealt, no input defaults to 0): -4
    
    No subgroup (removals) are defined
    
    Number of subsets for above conditions: 37
    Prob of running count -4 with above removals from 6 decks: 4.78680e-002
    
    p[1] 0.069183  p[2] 0.079342  p[3] 0.079342  p[4] 0.079342  p[5] 0.079342
    p[6] 0.079342  p[7] 0.077406  p[8] 0.077406  p[9] 0.077406  p[10] 0.30189
    
    Press any key to continue:
    2. Create a shoe for the rank probs/cards remaining and teach my CA to compute using this shoe to get reasonable estimates of EVs for the input counting system. (Here RC = -4 before up card)
    Code:
    Number of decks: 6   Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
    Player hand composition: 2, 0, 0, 0, 0, 0, 0, 0, 0, 0:  Soft 12, 2 cards
    After player hand is dealt - Cards remaining: 156, Running count: -4
    Subgroup removals: No subgroups are defined
    Shoe comp (A-5):  {10.7925, 12.3774, 12.3774, 12.3774, 12.3774}
    Shoe comp (6-10): {12.3774, 12.0753, 12.0753, 12.0753, 47.0946}
    After up card is dealt - Cards remaining: 155
    Running count (up card 1 to 10): {-5,-3,-3,-3,-3,-3,-4,-4,-4,-5}
    
    Up card   Stand      Hit   Double  Split 1  Split 2  Split 3  Surr     Strat
    
       1    -72.406  -34.583  -71.762  -23.633                             split
       2    -29.435    8.442   -7.219   46.241                             split
       3    -25.528   10.667   -0.754   50.887                             split
       4    -21.226   12.863    5.990   55.808                             split
       5    -17.099   15.612   12.667   60.977                             split
       6    -12.900   18.219   18.509   65.142                             split
       7    -47.170   16.954  -17.892   45.021                             split
       8    -50.909   10.044  -31.606   33.259                             split
       9    -53.371    0.711  -44.945   21.492                             split
      10    -56.674  -11.666  -52.851    7.861                             split
    
    Overall hand EV vs all upcards: 30.6019
    
    Press c or C for EV conditioned on no dealer blackjack, any other key to exit
    3. Go through the range of all possible running counts and record RC indexes. I can only do this for one cards remaining value at a time.
    Code:
    ____________________________________ h17 ___________________________________
    
    Count tags {1,-1,-1,-1,-1,-1,0,0,0,1}
    Composition dependent indices for hand, rules, number of decks, and pen
    Player hand composition: 2, 0, 0, 0, 0, 0, 0, 0, 0, 0:  Soft 12, 2 cards
    Decks: 6 (possible input for cards remaining: 1 to 312)
    Cards remaining before up card = 156
    No subgroups are defined
    
                2      3      4      5      6      7      8      9      T      A
    
    Stand       h      h      h      h      h      h      h      h      h      h
    Double   >=38   >=22   >=11    >=3   >=-3      -      -      -      -      -
    Pair   p>=-36 p>=-37 p>=-39 p>=-41 p>=-45 p>=-30 p>=-26 p>=-24 p>=-25 p>=-16
    LS          -      -      -      -      -      -      -      -      -      -
    ES          -      -      -      -      -      -      -      -      -      -
    
    Press any key to continue
    4. Interpolate. Compute a more accurate true count that applies to the input cards remaining if desired,
    Code:
    Let up card = 6 and display hit and dbl EV
    RC = -3, hit EV = .18219, dbl EV = .18509, diff = .00290
    RC = -4, hit EV = .18017, dbl EV = .17833, diff = -.00184
    interpolate: -3.611814 (appox RC where hit EV = dbl EV)
    TC = 52 * (-3.611614) / 155 (156 - 1 to allow for upcard because this is relative to how my CA computes)
    TC = -1.2 for 155 cards remaining, RC = -3 after up card of 6
    I would guess that Cac has multiple methods and Zen uses algebraic approximation using eors. Not sure of what Gramazeka does.

    Hope this is helpful.

    k_c

  9. #48


    1 out of 1 members found this post helpful. Did you find this post helpful? Yes | No
    I would guess that Cac has multiple methods and Zen uses algebraic approximation using eors. Not sure of what Gramazeka does.
    It is true, the generation of indexes is a subject to which I have dedicated many years and for this reason I have developed
    five perfectly valid methods or algorithms to generate them. Of course, there are some algorithms that are more accurate than
    others. Among the most accurate I have are the simulation (or monte-carlo) method that also allows me to generate RA-indices,
    and two others based on combinatorial analysis that allow me to obtain the most accurate EM-indices.
    The difference between these last two is that one uses a Gaussian approximation to calculate the probability of a RC as a
    function of depth, while the other calculates it exactly.
    Among the three methods mentioned as the most accurate, penetration is taken into account, which allows generating an index
    for a given pen such as 4.5/6. I could even generate an index for a given range, say between 156 and 78 cards.
    Now, the point of all this is that my best index for a certain play must coincide with the one obtained by a commercial
    program like CVDATA or SBA. With Norman we have done exhaustive comparisons between his and mine and have had no discrepancies
    at all.

    Going back to the s12v3 topic (S17 and H17), there are some differences like the ones I already mentioned and in which I see
    that instead of looking for where the problem may be, the discrepancy focuses on discussing the methodology I use.
    I do not intend to enter into this discussion, but instead I can offer my results based on simulation and combinatorial analysis.
    Both are coincident.

    1) By simulation (4.5/6, TC floored and DR calculated to the nearest half)

    a) s12v3 (removing two aces and a three)

    S17 ==> index = +8

    Code:
       9   0.13878383731517   0.95298268109645   0.15605379110787   3.84169861524341   0.01726995379269           20510825
       8   0.13314496224470   0.95165358021652   0.13821013936613   3.83753694570823   0.00506517712142           54638958
       7   0.12866821974899   0.95065857856909   0.12349410668717   3.83467649711386  -0.00517411306182           73353055
       6   0.12352655451792   0.94936534028024   0.10572939340757   3.83057766564323  -0.01779716111035          175473323
       5   0.11931293657463   0.94822023537866   0.09073189214944   3.82704646259109  -0.02858104442519          242376517
    H17 ==> index = +8

    Code:
       9   0.14031439495973   0.95278975857870   0.16045575933684   3.84210503478041   0.02014136437710           20510825
       8   0.13457313735741   0.95144724392438   0.14245798757729   3.83797655877698   0.00788485021987           54638958
       7   0.12999822570444   0.95044181868090   0.12761557102155   3.83514551643418  -0.00238265468289           73353055
       6   0.12472556298486   0.94914074773634   0.10964141825706   3.83108682565953  -0.01508414472780          175473323
       5   0.12039505048255   0.94798496093580   0.09448997899413   3.82762034657013  -0.02590507148842          242376517
    b) s12v3 (removing three aces and a three)

    S17 ==> index = +8

    Code:
       9   0.14063114000671   0.95317559014766   0.16290075003612   3.84183315214897   0.02226961002942           18174858
       8   0.13480241717954   0.95193211784268   0.14439017450518   3.83792959763171   0.00958775732564           48979233
       7   0.13064566353950   0.95087697457766   0.12978466867655   3.83467020906411  -0.00086099486294           65611309
       6   0.12524759406831   0.94961221583436   0.11244530093101   3.83065818120981  -0.01280229313731          158336790
       5   0.12109088604987   0.94849882673876   0.09739390777932   3.82737340452408  -0.02369697827055          218408733

    H17 ==> index = +7

    Code:
       9   0.14214493450238   0.95299143465110   0.16713792206795   3.84220971630150   0.02499298756557           18174858
       8   0.13621889505701   0.95174567147673   0.14852012892893   3.83835549241859   0.01230123387191           48979233
       7   0.13193948012834   0.95067934096544   0.13376282433262   3.83513744558884   0.00182334420427           65611309
       6   0.12642562098171   0.94939865207574   0.11622557208593   3.83117075949310  -0.01020004889577          158336790
       5   0.12216189633773   0.94827271856387   0.10101586002058   3.82790783370370  -0.02114603631715          218408733
    2) By CA (4.5/6, TC floored and DR calculated to the nearest half)

    a) s12v3 (removing two aces and a three)

    S17 ==> index = +8

    Code:
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |     TC     |      Probability      |        Standing       |        Hitting        |        Doubling       |        Splitting      | 1 | 2 |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |          9 |   0.00092539067698442 |  -0.12917022205199663 |   0.14011569055336448 |   0.15957879423090041 |   0.79585853709522969 |   | P |
    |          8 |   0.00247047587046877 |  -0.14330615145561731 |   0.13426415395847002 |   0.14120409411534213 |   0.76824582210859671 |   | P |
    |          7 |   0.00325427764875370 |  -0.15467241478156299 |   0.12981883444506226 |   0.12642391133666261 |   0.74504830762024199 |   | P |
    |          6 |   0.00779282421421669 |  -0.16821356731640061 |   0.12460971566985264 |   0.10885443822433380 |   0.71722305067637682 |   | P |
    |          5 |   0.01061278454380245 |  -0.18015164631584346 |   0.12026917144858326 |   0.09329868963364041 |   0.69170924592385552 |   | P |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    H17 ==> index = +8

    Code:
    ------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |     TC     |      Probability      |        Standing       |        Hitting        |        Doubling       |        Splitting      | 1 | 2 |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |          9 |   0.00092539067698442 |  -0.12386813320699951 |   0.14172407755382635 |   0.16402194348223290 |   0.79588400213501842 |   | P |
    |          8 |   0.00247047587046877 |  -0.13797529638884171 |   0.13576659253706855 |   0.14550253428373039 |   0.76822783179372156 |   | P |
    |          7 |   0.00325427764875370 |  -0.14933683438832471 |   0.13121595198772082 |   0.13057780778124078 |   0.74499259553942065 |   | P |
    |          6 |   0.00779282421421669 |  -0.16286842424049261 |   0.12588648167164126 |   0.11283928371851466 |   0.71712039312600928 |   | P |
    |          5 |   0.01061278454380245 |  -0.17481572041229607 |   0.12142102483124835 |   0.09710879547536223 |   0.69156229635012800 |   | P |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    b) s12v3 (removing three aces and a three)

    S17 ==> index = +7

    Code:
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |     TC     |      Probability      |        Standing       |        Hitting        |        Doubling       |        Splitting      | 1 | 2 |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |          9 |   0.00082329091908529 |  -0.12566257170554379 |   0.14200507222817793 |   0.16606312627459091 |   0.80573680471920150 |   | P |
    |          8 |   0.00222447010469417 |  -0.13981056127953906 |   0.13612228083140540 |   0.14768136602602067 |   0.77811592606438951 |   | P |
    |          7 |   0.00292527393256047 |  -0.15113381460414851 |   0.13167269074469948 |   0.13297135589257120 |   0.75501869171403013 |   | P |
    |          6 |   0.00706867819074979 |  -0.16469380021947616 |   0.12642803546201123 |   0.11538741587188141 |   0.72717520669471736 |   | P |
    |          5 |   0.00961011705001321 |  -0.17660130231233276 |   0.12207341559898841 |   0.09988449383435030 |   0.70174293460253134 |   | P |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    H17 ==> index = +7

    Code:
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |     TC     |      Probability      |        Standing       |        Hitting        |        Doubling       |        Splitting      | 1 | 2 |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+
    |          9 |   0.00082329091908529 |  -0.12056852028635975 |   0.14357563899021553 |   0.17034709524296529 |   0.80574153048601871 |   | P |
    |          8 |   0.00222447010469417 |  -0.13468802509635666 |   0.13759214609464263 |   0.15182762543794312 |   0.77807967621833485 |   | P |
    |          7 |   0.00292527393256047 |  -0.14600618686184486 |   0.13304265662927098 |   0.13698030253569818 |   0.75494713452083662 |   | P |
    |          6 |   0.00706867819074979 |  -0.15955609516394698 |   0.12768346310638320 |   0.11923524917851459 |   0.72705940461724217 |   | P |
    |          5 |   0.00961011705001321 |  -0.17147178422333267 |   0.12321013574974345 |   0.10356604455407128 |   0.70158562624762077 |   | P |
    +------------+-----------------------+-----------------------+-----------------------+-----------------------+-----------------------+---+---+

    Sincerely,
    Cac

  10. #49


    Did you find this post helpful? Yes | No

    Question for Cac

    I don't know if I will explain this very well.

    I try to test my methods by trying them on a problem with an obvious answer. Use insurance count (tag non-tens as -1 and tens as +2) (sign of tag relative to what remains in shoe) as the basis for a question.

    For this count this is data listing min RC values for single deck where Prob(ten) >= 1/3, which we should agree on.
    Code:
    Count tags {-1,-1,-1,-1,-1,-1,-1,-1,-1,2}
    Decks: 1
    Insurance Data (without regard to hand comp)
    No subgroup (removals) are defined
    
    **** Player hand: x-x ****
    Cards   RC      TC ref
    
    48      0       0.00
    47      1       1.11
    46      2       2.26
    45      0       0.00
    44      1       1.18
    43      2       2.42
    42      0       0.00
    41      1       1.27
    40      2       2.60
    39      0       0.00
    38      1       1.37
    37      2       2.81
    36      0       0.00
    35      1       1.49
    34      2       3.06
    33      0       0.00
    32      1       1.63
    31      2       3.35
    30      0       0.00
    29      1       1.79
    28      2       3.71
    27      0       0.00
    26      1       2.00
    25      2       4.16
    24      0       0.00
    23      1       2.26
    22      2       4.73
    21      0       0.00
    20      1       2.60
    19      2       5.47
    18      0       0.00
    17      1       3.06
    16      2       6.50
    15      0       0.00
    14      1       3.71
    13      2       8.00
    12      0       0.00
    11      1       4.73
    10      2       10.40
    9       0       0.00
    8       1       6.50
    7       2       14.86
    6       0       0.00
    5       1       10.40
    4       2       26.00
    3       0       0.00
    2       1       26.00
    1       2       104.00
    Using TC as the index metric, obvious answer is buy insurance when TC > 0. Also acceptable, buy insurance when TC >= 0

    For any of the above data points I can get this answer by interpolating to find RC when prob(ten) = 1/3, using 27, 26, 25 cards remaining as example.

    27 cards (no interpolation necessary since prob(ten) = 1/3
    RC = 0, prob(ten) = 1/3
    TC = 52*0/27 = 0

    26 cards single deck insurance (insurance count)
    RC = +1, prob(ten) = 9/26
    RC = -2, prob(ten) = 8/26
    interpolate: RC = 0, prob(ten) = (8 2/3)/26
    TC = 52*0/26 = 0

    25 cards single deck insurance (insurance count)
    RC = +2, prob(ten) = 9/25
    RC = -1, prob(ten) = 8/25
    interpolate: RC = 0, prob(ten) = (8 1/3)/25
    TC = 52*0/25 = 0

    This is my question:
    How would your method of finding TC index work on this data set?

    Thanks,
    k_c

  11. #50


    Did you find this post helpful? Yes | No
    Quote Originally Posted by k_c View Post
    I don't know if I will explain this very well.

    I try to test my methods by trying them on a problem with an obvious answer. Use insurance count (tag non-tens as -1 and tens as +2) (sign of tag relative to what remains in shoe) as the basis for a question.

    For this count this is data listing min RC values for single deck where Prob(ten) >= 1/3, which we should agree on.
    Code:
    Count tags {-1,-1,-1,-1,-1,-1,-1,-1,-1,2}
    Decks: 1
    Insurance Data (without regard to hand comp)
    No subgroup (removals) are defined
    
    **** Player hand: x-x ****
    Cards   RC      TC ref
    
    48      0       0.00
    47      1       1.11
    46      2       2.26
    45      0       0.00
    44      1       1.18
    43      2       2.42
    42      0       0.00
    41      1       1.27
    40      2       2.60
    39      0       0.00
    38      1       1.37
    37      2       2.81
    36      0       0.00
    35      1       1.49
    34      2       3.06
    33      0       0.00
    32      1       1.63
    31      2       3.35
    30      0       0.00
    29      1       1.79
    28      2       3.71
    27      0       0.00
    26      1       2.00
    25      2       4.16
    24      0       0.00
    23      1       2.26
    22      2       4.73
    21      0       0.00
    20      1       2.60
    19      2       5.47
    18      0       0.00
    17      1       3.06
    16      2       6.50
    15      0       0.00
    14      1       3.71
    13      2       8.00
    12      0       0.00
    11      1       4.73
    10      2       10.40
    9       0       0.00
    8       1       6.50
    7       2       14.86
    6       0       0.00
    5       1       10.40
    4       2       26.00
    3       0       0.00
    2       1       26.00
    1       2       104.00
    Using TC as the index metric, obvious answer is buy insurance when TC > 0. Also acceptable, buy insurance when TC >= 0

    For any of the above data points I can get this answer by interpolating to find RC when prob(ten) = 1/3, using 27, 26, 25 cards remaining as example.

    27 cards (no interpolation necessary since prob(ten) = 1/3
    RC = 0, prob(ten) = 1/3
    TC = 52*0/27 = 0

    26 cards single deck insurance (insurance count)
    RC = +1, prob(ten) = 9/26
    RC = -2, prob(ten) = 8/26
    interpolate: RC = 0, prob(ten) = (8 2/3)/26
    TC = 52*0/26 = 0

    25 cards single deck insurance (insurance count)
    RC = +2, prob(ten) = 9/25
    RC = -1, prob(ten) = 8/25
    interpolate: RC = 0, prob(ten) = (8 1/3)/25
    TC = 52*0/25 = 0

    This is my question:
    How would your method of finding TC index work on this data set?

    Thanks,
    k_c
    I'll give you an idea of ??what I do. Maybe this can help you.
    Let's use as an example a deck of 52 cards and the unbalanced count of tens (1 1 1 1 1 1 1 1 1 -2).
    1) Remove an ace from the pack (which is the ace the dealer receives)
    2) Let's assume that we are going to play until there are 10 cards left (CL)
    3) Two nested loops are needed, one loop that goes through all the possible RC from a minimum to a maximum.
    It doesn't matter if you don't know the limits, it can be between -50 and +50. Then the ones that do not correspond
    will be discarded (they are the ones whose probability is equal to zero).
    The other loop will go through the different depths between 51 (52 -1) cards and 11 cards (10 have been left out).
    4) Within these two nested loops you are going to calculate, through a combinatorial analysis, the probability and the
    expected value for each combination of RC and depth and the values ??obtained are going to be accumulated into two arrays.
    The index of the array is going to be the TC which in turn you get from doing (RC / depth * 52).
    array1 (TC) += probability * EV
    array2 (TC) += probability
    5) You are going to get the index from array1. To do this, you have to go through that array from the lowest value of TC
    until you find the TC in which the expected value becomes positive. That point corresponds to the searched index.
    It's actually a little more elaborate but for now I don't want to complicate it for you.
    The other array is used to know the frequency of each TC.

    Hope this helps.

    Sincerely,
    Cac

  12. #51


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Cacarulo View Post
    I'll give you an idea of ??what I do. Maybe this can help you.
    Let's use as an example a deck of 52 cards and the unbalanced count of tens (1 1 1 1 1 1 1 1 1 -2).
    1) Remove an ace from the pack (which is the ace the dealer receives)

    The other array is used to know the frequency of each TC.
    Cac
    I store my data in a list.

    If I construct a list with a specific pen and rc for the insurance count it will contain either 0 or 1 entries (elems) depending upon rc. If elems = 0, probRC = 0.

    This is what I presently do:
    Code:
    list = new subsetList (inputCount, decks, pen, rc, specificRem);
    list->getProbRC(rc, probRC, pRank);
    long elems = list->elems;
    delete list;
    list = NULL;
    What I used to do was construct a list with all rc possible to use. For more complicated counts too much data crashes program.
    For the insurance count where pen = 26 there are 17 entries in the list and sum of probRC of each entry = 1. For any count sum of probRC of entries in list = 1 regardless of number of entries.

    What I could do is something like this:
    Code:
    list = new subsetList (inputCount, decks, pen, specificRem);
    
    for (rc = minValue; rc <= maxValue; ++rc)
         list->getProbRC(rc, probRC, pRank);
    
    long elems = list->elems;
    I can relate to probRC, but probTC? (relative to simple insurance count)

    k_c

  13. #52


    Did you find this post helpful? Yes | No
    Quote Originally Posted by Cacarulo View Post
    Going back to the s12v3 topic (S17 and H17), there are some differences like the ones I already mentioned and in which I see
    that instead of looking for where the problem may be, the discrepancy focuses on discussing the methodology I use.
    I do not intend to enter into this discussion, but instead I can offer my results based on simulation and combinatorial analysis.
    Please don't construe my questions as an attack on your methodology. My intent was not to question the validity of your methods (and those of others), but rather to ask questions about these methods in an effort to understand them better. With a better understanding of what we all do, a more focused investigation of the source of any differences can be made.

    I appreciate that we all have worked hard on our software over many years and that we do not necessarily want to divulge the details of algorithms that we have created and tested over the course of that time. I also appreciate the details which have been posted nonetheless. There's a lot here to consider and I will be reading each post carefully over the course of the next few days.
    Last edited by Gronbog; 10-03-2022 at 09:01 AM.

Page 4 of 6 FirstFirst ... 23456 LastLast

Similar Threads

  1. When to Double Down on a Soft 21?
    By Captain Jack in forum General Blackjack Forum
    Replies: 22
    Last Post: 04-03-2018, 11:41 AM
  2. Double on a soft 19
    By radio1324 in forum General Blackjack Forum
    Replies: 47
    Last Post: 12-29-2017, 11:00 AM
  3. Soft Hand Double Down Questions
    By Bushie in forum General Blackjack Forum
    Replies: 32
    Last Post: 06-30-2017, 08:43 PM
  4. Is it correct to double soft hands in Europe?
    By chonkolonko in forum General Blackjack Forum
    Replies: 5
    Last Post: 07-19-2016, 10:37 AM
  5. BJPlayer: Double soft 19 vs. 4
    By BJPlayer in forum Blackjack Main
    Replies: 1
    Last Post: 08-23-2011, 09:19 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

About Blackjack: The Forum

BJTF is an advantage player site based on the principles of comity. That is, civil and considerate behavior for the mutual benefit of all involved. The goal of advantage play is the legal extraction of funds from gaming establishments by gaining a mathematic advantage and developing the skills required to use that advantage. To maximize our success, it is important to understand that we are all on the same side. Personal conflicts simply get in the way of our goals.