I?ve used the term True Count Compression several times over the last year and thought it deserved a chart to better describe the effect. An obvious example is the original version of Zen and the True Edge version of Zen. In the original version, true count was calculated by diving by the number of full decks remaining. In the second version, division is by quarter decks remaining. That is, the divisor is four times the size. Obviously, indexes and betting ramps are adjusted to accommodate the different divisor. But, there is a problem. When you use a larger divisor, you end up with a much smaller range of possible True Counts. The chart below illustrates this effect. The distribution of True Counts for each methodology is displayed in a 4.5/6 game.



In this chart, you see that using True Edge Zen, nearly 60% of all rounds began with a TC of zero. The vast majority began with TCs of -1 to +1. 99.6% of TCs fell in the range -3 to+3. But in the original Zen, the TCs were distributed over a much larger range of TCs. This affects both playing and betting. For playing indexes, there is substantially less resolution in the indexes. This makes index memorization easier, but reduces accuracy. In betting there are two problems. First, it is more difficult to come up with an acceptable optimal betting ramp with such a narrow range of counts. Secondly, in a good game, you should increase your bet well before +1. Closer to a TC of +.5. But, people don?t normally deal with fractional counts.

Now I am a fan of simplified indexes. But, the betting I saw as more of a problem. When the True Edge version came out, I quickly modified CVSim to allow collection of data by half counts and specification of a betting ramp by half counts as I felt people would have to start increasing bets at +0.5. I dropped this feature in CVData as I now simply believe it is easier to not divide by quarter decks for level II systems or half-decks for level I systems.

At least that's my opinion