know to be optimal in terms of compression power, involves coding all events of the extended source X(n) through the coding-tree procedure described earlier. If the number of extended-source events is reasonably small, the proce- dure is easily and rapidly implemented. But it becomes impractical or prohibitive when the number of source events grows exponentially with the block size N. In the case where n = 16, for instance, the number of events is 2 16 = 4 294 967 296 or 4 billion. In the case where n = 64, the number of events becomes 264 = 18 446 744 073 709 500 000, or 18 billion billion! It does not make any sense to implement Huffman coding in such a case. Yet, we have been able here to determine a block code and to calculate its performance up to 2129 = 6.8 X 1038 = 680 X 109 X 109 X 109 X 109. The explana- tion is that the block-code assignment only takes the analysis of n + 1 block types, as opposed to 2n individual events. With a home computer, we can easily compute Huff- man codes up to a few thousand elements. What about Shannon-Fano coding? As we know, the codeword assignment is straightforward in this case. As with block codes, we do not have to consider the 2nd events individually to compute the mean codeword length. Optimal coding and compression Number of games n Figure 9.9 Comparison between Huffman coding (diamonds), block-coding (open circles), and Shannon-Fano coding (triangles) in the roulette-game example of Fig. 9.8, with data calculated up to n = 9. The results for both Huffman coding and Shannon-Fano coding, as applied to the roulette-game example, are shown in Fig. 9.9 for game sequence lengths n < 9. We observe from the figure that, as expected, the efficiency of the Huffman code is greater than that of any other codes. Unlike the block code, both Huffman and Shannon- Fano codes grow smoothly with the sequence length n. Interestingly, the block-code performance is observed to be bounded by the two envelopes made by the Huffman code (upper boundary) and the Shannon-Fano code (lower bound