Stuffle Tracking For Imbeciles - Part 2

[Sonny]

The Track-Factor

If only there was a way to get the final answer without going through all of the dividing and swapping and slug-number nonsense. Well, there is. Once I saw all the numbers in front of me, I saw the shortcut. Once we know the value of the shuffled slug, we simply divide it by the value of the original cut-off slug to get a simple conversion factor.

Conversion factor = shuffled slug / cut-off slug (before shuffle)

In the example from part 1, we used -7 + 1.4 = -5.6 as the value for our shuffled slug. We now get -5.6 / -7 = 0.8 as the conversion factor. We can now use this number to MULTIPLY by our original cut-off slug to get our final answer. Instead of fumbling with the "average count density" and adding it to the cut-off slug, we can have our answer with one simple multiplication! This new Track-factor (A.K.A.-the "Sonny is a brilliant imbecile" factor, although I have a feeling the former will probably stick) gives you all the power of shuffle tracking without all the messy "thinking". Now, to us imbeciles at least, multiplying by 0.8 isn't much easier than dividing 7 / 5, but there are more shortcuts to come.

I ran the same calculations for more running counts (-20 to +20) and found that the Track-factor was constant for all. This meant that no matter what the cut-off slug value was I could multiply it by 0.8 and get the value of the slug after the shuffle!

After a moment of euphoria, reality kicked in. This would ONLY work for six-deck games where five decks were dealt. I doubted if many people would find this information helpful, so I ran the numbers for six-decks with 4.5 dealt and again with 4 dealt. I figured that these would encompass most situations. What I found was fantastic!

In the 4.5/6 game, the Track-factor was a constant 0.67 (actually 0.6 repeating, but who multiplies to the 3rd decimal place in their head? Not us imbeciles! We're only giving up about 0.5% accuracy anyway), and the Track-factor for 4/6 was an even 0.5. This meant that if you were "lucky" enough to find a game that cut-off two full decks (something that most counters would point and laugh at all the ploppies in) you could take HALF the value of the cut-off slug as the value of the shuffled slug. You are now playing in a game where the conversion is EASY and you know the average count of four of the six decks. Imagine cutting the last two decks to the bottom and playing in a four-deck game with a positive running count off the top! Gee, maybe the "brilliant imbecile" title WILL stick. This is a fantastic compromise: The casinos get to keep their lousy games and we get to make a profit on their backs! Yaaaay!

Not quite. There are limitations to this. Although it does become easier to calculate in games with close to four-deck penetration, it is completely useless with anything worse. As Malmuth points out, if only three decks are dealt, they will most likely closely resemble the undealt portion the majority of the time. Also, the reduction in EV due to the poor penetration level, even at the four-deck level, can be very costly. Conversely, the more cards that are dealt, the less cards there are to track. In this case, however, even knowing that a few extra fours and fives are behind the cut card can give you a good advantage.

Although I am certainly not encouraging players to seek out tables with two decks cut-off (I'm not a TOTAL imbecile), I am pointing out that if you are stuck playing in a poor game (due to location or bankroll) this technique becomes simplified and may help you to get your edge back.

So the next time you see someone playing at a six-deck shoe with lousy penetration, he may not be a ploppy - he may be an imbecile!

-Sonny-

P.S.-He may also be an imbecile ploppy.

 

[Running Count]

Going for Best Posts, Sonny? ;-)

Okay, knowing NOTHING about shuftracking, let me see if I got this right, homeslice.

Say I'm playing a 1.5 cutoff shoe game. RC at the shuffle is +10. 1.5 deck slug is riffled into another deck-and-a-half. Multiply 10 x 2/3 to get 6.7. Divide by the number of decks in the combined slug, and our TC for the 3-deck slug is 2.2. Put the cut card carefully to push those 3 decks to the front, and you have 3 decks-worth of somewhat rich cards?

Is this right?

Do casinos really shuffle this way (One part of shoe into only one other part of shoe)?

Cheers, and nice post,

RC

 

[Sonny]

Following your footsteps!

>RC at the shuffle is +10. 1.5 deck slug is riffled into another
>deck-and-a-half. Multiply 10 x 2/3 to get 6.7. Divide by the
>number of decks in the combined slug, and our TC for the 3-deck
>slug is 2.2.

Not exactly. The "old fashioned" way to do it would be to divide the RC of the discards (+10) by 3 (How many 1.5 deck slugs are in a 4.5 deck discard tray?). Now you know that each 1.5 deck slug in the discard tray should have an average +3.33 RC. If you mix the cut-off slug (-10, the opposite of the discards) with one discard slug (average=+3.33) then you would get a 3 deck slug with a count of -6.67. Now, a slug with -6.67 RC worth of high cards is pretty darn good in my book. I would cut them right to the front, start my RC at +6 (truncate it to be safe), and play the next 3 decks as though it were a 3-deck shoe (divide your RC by 3 to get your TC). After those 3 decks, I would either leave or drop my RC by 6 point to play the "un-tracked" part of the deck. This would easily let you come off the top of the shoe with larger bets, and since you're only dividing by 3 to get your TC you will have more plus-count opporunities.

My "new fangled" method is much simpler: just take the RC of your cut-off slug (-10) and multiply it by 0.67 (the Track-factor for a six-deck 4.5 dealt game). This gives you a -6.67 RC right away. Why bother with all the other junk? Just MAKE SURE that your deck estimation is correct since a 2-deck cut-off slug should be multiplied by 0.5 (half of the RC) and a 1-deck cut-off slug should be multiplied by 0.8 to get the proper Track-factor numbers. If you find a sloppy dealer, they may give you diferent penetration levels for each shoe, so keep your eyes open!

>Do casinos really shuffle this way (One part of shoe into
>only one other part of shoe)?

No, they don't. Although if you find one that does, CALL ME!

Serously though, no. You will probably not find a single-pass shuffle in any reputable casino. I saw one in an Indian casino last year, but it didn't last long. The techniques I described are just a simplified way to accomplish the task. They can be tailored to fit different shuffle types, but that is something for the readers to do. I don't know what type of shuffles your local casinos will be using.

Also, you will NEVER see a dealer grab two 1.5 deck stacks of cards and shuffle them together. That would be one MONSTER PILE that no dealer could properly execute. Most likely the dealer will pick up full or 3/4-deck slugs and shuffle them together. This is not a problem since two 3/4-deck slugs would be the 3-deck slug you're tracking. It's still in the same place, but it took 2 tries for the dealer to fully get through it.

I hope this helps people.

-Sonny-

 

[alienated]

Nice posts, a minor nitpick...

Your suggested method for estimating the running count for the segment is perfectly fine. It is also correct to calculate the starting true count for the segment by dividing this segment running count by the number of decks in the segment. So in the example with a 3-deck segment with total running count +6.67, it is fine to calculate the initial true count as 6.67/3. However, it is not appropriate to adjust your true count throughout the segment using a true-count divisor of 3 - n, where n is the number of decks dealt from the segment. The reason for this is that you only have specific information about 1 1/2 decks in the 3 deck segment. That is, your information is only partial. To update your true count throughout the segment would require use of the NRS formula. If you don't want to use the NRS formula for practical reasons, it is better to play the entire 3-deck segment as if the true count is always 6.67/3. (It is only appropriate to use a true-count divisor of 3 - n in situations where you have specific information about all cards in your segment; eg, if two 1 1/2 deck slugs were married, and you had a count on each of them.)

None of this alters your main insight, which is that the correct initial true count can be determined by using the running-count estimation method you outline.

I enjoyed reading your entertaining posts.

alienated

 

[Sonny]

Re: Nice posts, a minor nitpick...

>(It is only appropriate to use a true-count divisor of 3 - n in situations
>where you have specific information about all cards in your segment; eg, if
>two 1 1/2 deck slugs were married, and you had a count on each of them.)

Shouldn't the TC conversion of 3-n be appropriate since we are estimating the value of the unknown 1 1/2 deck slug to be the average of the full 4 1/2 decks seen? In this regard, we do have general information about all the cards in the segment. This is the method that Malmuth suggests in his Card Domination section. Although we only have specific information about the cut-off slug, the Track-factor does account for the unknown segment by estimating the average value and integrating it into the result. Let me know if I misunderstood your post (or if my concept is truly flawed, preferably the former!).

I'm glad you enjoyed my post. Thanks for your input.

-Sonny-

 

[alienated]

TC Estimation in Shuffle Tracking - Part I

Sorry for the excessive length of my reply. It touches on various related issues, so hopefully it will be of some benefit to others as well.

Consider a 3-deck segment within a 6-deck shoe. Suppose the 3-deck segment contains a 1.5 deck slug with count X. Suppose also that this slug is mixed with another 1.5 decks that are drawn randomly from the 4.5 decks not in our known slug. Call the 4.5 decks not in our slug 'others'. The count of the others is -X. As you correctly point out, our best estimate off the top of the shoe is that the 1.5 decks drawn from these 4.5 decks with count -X will have a count of -X/3, since these cards represent one third of the others. You then correctly point out that our estimated overall count for the 3-deck segment should be:

RC = X + (-X/3) = 2/3*X

or

TC = -RC/3 = -(2/3*X) / 3 = -2/9*X.

For example, if X = -10, our estimate of the segment's overall running count is 2/3*(-10) = - 6 2/3, and our estimate of the true count is + 2 2/9. These are our best guesses off the top of the shoe.

It is important to realise, however, that our estimated true count will not, in general, be equal to the *actual* true count. Rather, it is equal to the *expected* true count. On average our true-count estimate will be correct. That is, if we repeated the exercize many times, the average actual true count would approach our expected true count. But in many of these trials our expected true count would deviate from the actual true count. Our estimate is simply our best guess off the top of the shoe. But we are making our best guess with only incomplete information. We cannot be sure that our estimate is correct.

This means that although our expected true count is our best guess off the top of the segment, it will usually not remain our best estimate all the way through the segment. This is because part way through the segment we will have more information about the likely composition of the 1.5 decks that are not from our slug than we had at the start of the segment. If we don't take account of this new information, we will no longer be basing our decisions on the best possible true-count estimate.

An example might help. The hi lo count is assumed throughout. Consider a 3-deck segment from a 6-deck shoe containing a 1.5 deck slug with count -9 and 1.5 decks drawn randomly from the other 4.5 decks. Off the top, we would expect that the 3-deck segment has a total running count of -9 + 1/3*(9) = -6 (= 2/3*-9), implying an expected true count of +2. Accordingly, the IRC could be set to +6. After 1 deck is dealt we would expect the running count to be +4 (6 - 2 = 4), leaving our true count estimate unchanged at +2 (4/2). But suppose, as will often happen, that things do not go as expected, and the running count rises to +12 over the first deck rather than falling to +4. If we were to estimate our true count as +12/2 = 6, we would be considerably overestimating our edge. Although in one sense the rise in running count strengthens our belief that it will fall over the remainder of the segment, it simultaneously undermines our confidence in our original assumption that the 1.5 decks of others really had a count of 1/3*9 = 3. It is starting to appear as if, of the 4.5 decks of others, a disproportionate amount of small cards just so happened to get mixed with our slug, so that the 3-deck segment seems less likely really to have a total running count of -6.

The basic point is made clearer if we consider the implications of an extreme scenario where, with 4 cards remaining, the running count is +8. Since in this case it is obviously impossible for the running count to drop by 8 over the next 4 cards, it would clearly be nonsensical to calculate the true count as 8/(4/52) = +104! (This true count does not even make sense, since the true count of a level-1 count cannot possibly exceed 52 in absolute value.) In other words, it is no longer evenly remotely possible that our initial count estimate could be correct.

 

[alienated]

TC Estimation in Shuffle Tracking - Part II

Notice the difference between our current situation, where we only have partial information about some of the cards in the segment, and a situation of complete information. An example of the latter is where you know the actual (not expected or average) counts of two 1.5 deck slugs that are married to form a 3-deck segment. If the two slug counts add to -6, then you know that the running count must fall by 6 over the segment. If the running count initially rises, this in no way undermines your confidence, since you *know* the total count of the segment. (Of course, in practice we will still need to worry about tracking errors, shuffling imperfections, etc, but this is a separate issue to the one we are currently discussing, and will apply equally whether we have complete or incomplete information in the sense in which we are using those terms here.)

Returning to the case of incomplete information, the tracker can approach the situation in a variety of ways, some better than others. Let's consider the ramifications of using three commonly proposed methods:

NRS Formula: This is the optimal method if it is assumed that the 'others' in our segment really are drawn randomly from the 4.5 decks not in our slug. The formula allows for our uncertainty by specifying a larger initial true-count divisor (that is, we treat the segment as if it contains more decks than it really does) as well as modifying the slug count by applying a multiplier. The size of the initial true-count divisor and the size of the multiplier depend on the degree to which our slug information is 'dispersed' (ie, the size of our slug relative to our segment). The greater the dispersion, the weaker our information, and the more conservatively we must figure our edge. Now, off the top of the segment, the NRS formula gives the same true count as the other method we used above. For instance, in our previous example, both methods give an off-the-top true count of +2. This reflects the fact that our alternative, simpler method does represent our best possible guess prior to the dealing of any cards from the segment. However, the great value of the NRS formula is that it enables us to update our best guess as cards are dealt. For this reason, our true-count estimate will constantly be fluctuating, and we can base our decisions on the latest true-count information. It is critical to remember, though, that these updated true-count estimates are not based on an initial true-count divisor of 3, but are calculated using a number of decks (or 'pseudodecks') that better reflect the uncertainty over the precise segment count. It is only in the special case of complete information that the NRS formula reduces to the simpler procedure of treating the 3-deck segment as a 3-deck 'shoe'.

Constant TC: In this method, the off-the-top true count is calculated in the simpler way we used earlier. Importantly, however, the tracker plays the entire segment as if the true count is always equal to the off-the-top true count. While this method is not optimal, it does have practical benefits, and it avoids the extreme over (and under) betting that would occur if the 3-deck segment were to be treated as a 3-deck 'shoe'. It also has the merit of having some of the logic underlying the NRS formula naturally built into it (though only up to a point). In particular, by keeping the true count constant when the running count falls slower than expected (or rises), the method implicitly allows for the fact that it is becoming increasing likely that the 'others' in the segment are poorer in high cards than was initially assumed off the top of the segment. Similarly, by keeping the true count constant when the running count falls faster than expected, the method makes some allowance for the growing likelihood that the 'others' are richer in high cards than was initially supposed. So although the 'Constant TC' method is suboptimal, it does have considerable merit, both in practical and logical terms. The method is recommended, for instance, by Arnold Snyder in _Blackbelt in Blackjack_ (1998 edition).

Segment = Shoe: This is the flawed method we have been discussing. The method enables optimal play off the top of the segment, but will cause overbetting (often extreme overbetting) whenever the running count falls slower than expected (or rises). The slower than expected fall in the running count contradicts our initial best guess of the overall segment count. We should downgrade our estimate of the segment's favorability to reflect this, not raise our bets by persisting with an assumption that is no longer as likely to be correct. Conversely, the method will cause underbetting whenever the running count falls faster than expected. By dropping your bet when more high cards than expected are dealt early in the segment, you will fail to capitalize on many favorable situations. While it is possible that this drop in the running count was caused by lots of slug cards being dealt early in the segment, it is more likely that the 'others' in the segment just so happened to be richer in high cards than was initially assumed. (The NRS formula weights these two possibilities appropriately.)

Here is another way of seeing the flaw in the 'Segment = Shoe' method. Consider once again a 3-deck segment within a 6-deck shoe. Now, without observing the previous shoe, I know that there is a 0-card slug with count 0 mixed with 3 decks of 'others' drawn randomly from the 6 decks of cards not in my known 0-card slug. So my best guess for the segment count, prior to the dealing of any cards, is RC = 0 + 1/2*(0) = 0 = TC. So far, so good. Now suppose that after 1 deck is dealt, the running count is +10. By the logic of the 'Segment = Shoe' method, I would be entitled to calculate the true count as 10/2 = +5! But we know that this is incorrect, since without tracking information, the true count must clearly be 10/5 = +2. The error in the 'Segment = Shoe' reasoning is that our best guess for the overall segment count is no longer 0 as soon as the running count deviates from 0. Instead, our best guess becomes RC - TC*n, where n is the number of decks remaining in the segment. For instance, with a running count of +10 after 1 deck, our best guess for the overall segment count is 10 - 2*2 = +6. In other words, we now expect the running count to be +6 by the end of the 3-deck segment because, by the true-count theorem, we expect the true count to stay exactly where it is.

I hope this last example does not seem too flippant. That is not my intention. Those with moderately long internet memories may recall that I made a very similar logical error in the not-too-distant past. Specifically, I was concerned with an n-deck shoe for which each 4n-card segment contained 4 cards from each deck of the previous shoe. Accordingly, I reasoned that the expected total running count for each 4n-card segment off the top of the shoe would be:

4n/52*(c1+c2+...+cn) = 0

where c1,...,cn denote the counts of the n decks of the previous shoe. I then reasoned that if the running count rose by just 1 over the first 2n cards of the shoe, the true count for the first segment would be, not 1/(8 - 2n/52), but 1/(2n/52)! For example, in an 8-deck shoe, a running count of +1 after the first 16 cards would indicate a segment true count of 1/(16/52) = 3.25! I hesitate to dredge this up, as it was one of my more embarrassing moments, but I think it illustrates quite well the logical traps we can sometimes fall into. Of course, in most scenarios the 'Segment = Shoe' method will not lead to such disastrous results as I managed to derive! But the same basic logical flaw is common to all applications of the method to situations of incomplete information.

 

[alienated]

TC Estimation in Shuffle Tracking - Postscript

Having said all this, it would be misleading for me to suggest that the issue of the appropriate true-count divisor has been completely free of controversy. You may be aware of the extremely interesting debate that occurred between Arnold Snyder and Don Goren. Some of it can still be found in the archives at Michael Dalton's site, though I think it costs $35 to join. In brief, Goren argued in his _Blackjack Review_ series (1997) that his neural networks approach enabled him to base his true-count calculations on the number of decks in the segment, rather than some larger amount of pseudo decks. This was despite the presence of uncertainty in the situations he was addressing. However, it is important to realise that Goren's method was based on an attempt to predict the count of the segment based on information relating to *all* cards that were *likely* to be in the segment, not just a specific slug and some 'others'.

Goren's argument was controversial. If we *knew* that our 3-deck segment contained two 1.5-deck slugs, each with a known running count, we would be completely justified in using an initial true-count divisor of 3. Very few, if any, would disagree with this. But Goren didn't know the exact count, but rather used a method which enabled him to predict the most likely count for each segment, based on the counts of the previous shoe's segments and the most likely postshuffle locations of those cards from the previous shoe. In other words, he was calculating the average count, and the variance of counts around the mean. Thus, while his initial true-count divisor would be set to the number of decks in the segment, it is possible that his estimate of the overall segment count took account of uncertainty, rather than being a simple averaging procedure.

When I first read Goren's work I was convinced it was correct in every way. I'm not really sure now. I don't think he provided us with enough information to assess the method fully. Since his method does not adjust the initial true-count divisor, its validity appears to hinge on the appropriateness of his initial count estimate. However, it does seem hard to see how such a count estimate could allow for both the possibility that the running count falls slower than expected *and* the possibility that it will fall faster than expected.

Now, it may be that Goren's neural networks enabled him to account for effects of which I am not aware. He refers to 'dynamic equations' in his response to Snyder, even though his articles in _BJ Review_ only presented static ones. He also mentions a narrowing of the count distribution the deeper into the segment we go, as well as a statistical breakdown occurring when only a small number of cards remain, so that it is important never to divide the running count by less than some minimum fraction of a deck when calculating the true count. It does appear that by limiting the reduction in the true-count divisor, he is in some way allowing for the possibility that his best guess has changed, part way through the segment.

This controversy aside, I think it is safe to say that in the absence of some more sophisticated method, such as may possibly be provided by Goren's neural networks approach, the tracker should stick either to the NRS formula or the 'Constant TC' approach when faced with incomplete information.

 

[Rob McGarvey]

Estimation Will Always be Estimation

Actual location is another matter, but estimation also plays a role. Math it do death, you are right or wrong, or close as in horseshoes n hand gernades. Nice to see you posting again Ali.

 

[Sonny]

RATS!

Foiled again! I'll get you next time, you shifty shuffle!

So let me get this straight: Even IF I find a shuffle that can be tracked AND I figure out a decent way to track it, I STILL can't use the information I've got because I don't have an optimal way to apply it?

Damnit!

Why can't shuffle tracking just be EASY! I can feel the thirteen-year-old inside of me taking over.

Oh well. At least I know it now before I blow all my money at the tables.

Thanks enormously for your help, Alienated. I can see you've put a lot of thought (and typing) into this. I guess it's time for Phase II - "Sonny The Imbecile Goes Back To The Drawing Board."

Unfortunately I got frustrated and snapped all my pencils, and my crayons don't erase.

-Sonny-

 

[alienated]

Re: RATS!

Don't get discouraged. Everything you posted was great except for one small point which you can easily fix. Don't forget I was only explaining why you shouldn't treat the n-deck segment exactly like an n-deck 'shoe' (unless you have 'complete' information). Your method of calculating the off-the-top segment count is entirely correct. You just need to choose how you want to treat true-count fluctuations part way through segments. You have at least two choices:

1. Play as if the segment's true count is always equal to its (correct) initial value throughout the entire segment.

or

2. Use the NRS formula.

Although option 1 is not optimal, it is still a good method to use and is based on sound principles. Among other things, it makes use of the true-count theorem (which, loosely speaking, states that the true count is most likely to stay where it is), and engenders some of the underlying logic of the NRS formula, as I tried to explain in my other posts.

EXAMPLE: 6-deck shoe, 3-deck segment, 1.5-deck slug, slug count = -9.

Using the method you came up with and outlined in your post, the expected total running count for the segment equals (2/3)*(-9) = -6. This implies a true count of -(-6)/3 = +2. For the entire 3-deck segment, simply play as if the true count is +2.

Arnold Snyder in _Blackbelt in Blackjack_ suggests the following tweaks to this method:

i) Figure the initial segment true count conservatively; eg, you could assume a slug count of -7 instead of -9, because maybe the slug was broken or you miscounted or something;

ii) If the running count drops *way* more than you expect, you could drop your bets for the rest of the segment, just to be safe.

You should only take measure ii) when the drop in count is extreme. Remember that a more rapid than expected fall in running count is always telling you two contradictory things: a) a more than proportionate number of cards from your slug may have been dealt; b) the 'others' in your segment may be richer in high cards than the 'others' overall.

Lastly, my nitpick only applies when your information is partial. If you have complete information, you can treat an n-deck segment exactly as you described - ie, as an n-deck 'shoe'.