Talk:Canonical Huffman code

message: It seems to me that the pseudo-code given only works if the number of bits in the code only ever goes up by 1.
Take this, for example:
 1 bit: A
 3 bits: BCDE
The correct code would be as follows:
 A: 0
 B: 100
 C: 101
 D: 110
 E: 111
But the pseudo-code given will generate this:
 A: 0
 B: 10
 C: 11
 D: 100
 E: 101
Which is not prefix-free.
I think the outer loop needs to be on bit length, and then have an inner loop over symbols with that bit length, so the shift happens for every unit increase in code length.  —Preceding unsigned comment added by 131.107.0.86 (talk) 18:36, 26 May 2009 (UTC)
thread_title:  Holes in bit length sequences? 

message: I think there is confusion between numbers and codes:
"010" and "10" are the same number but are different codes, so the algorithm should be something like:
 code = as many zeros as the first code length
 while more symbols:
     print symbol, code
     code = code + 1
     if old bit length > code bit length
         insert a zero in front of code
     if old bit length > code bit length
         append a zero to the code  — Preceding unsigned comment added by 109.52.150.177 (talk) 19:19, 12 January 2013 (UTC)
thread_title:  Avoiding holes? 

message: The example makes no sense to me. The article states,
With our canonical version we have the knowledge that the symbols are in sequential alphabetical order and that a later code will always be higher in value than an earlier one.
But look at the canonical code book that we generated in the example:
By following these three rules, the canonical version of the code book produced will be:
B = 0
A = 10
C = 110
D = 111
But "the symbols are in sequential alphabetical order" does not hold. We could reorder them, but "that a later code will always be higher in value" would not hold. It seems either the example is wrong, the assumptions made about canonical code books are wrong, or I'm unable to build an understanding of what the article is discussing. (And it cites no references for me to try a paraphrasing of the article, either!) 
—Deathanatos (talk) 03:51, 22 July 2020 (UTC)
thread_title:  Bad example? 

message: The main reason for this article's problems (as alluded to in previous comments here on this talk page) is that it's focusing way too much on space savings. In reality, the main reason codecs use canonical huffman codes is for the decoding performance improvement that a single sentence of this article alludes to and dramatically understates. (To non-programmers: dramatically simplifying code does not usually make it dramatically faster, quite the opposite, so the word "dramatically" as it's used ATM is not emphasizing the speed benefit.)
Here's what I think should happen:
1) A new section should be written about specifically the decoder optimization. Strings encoded with canonical huffman codes can be decoded without traversing a tree, instead keeping track of the value below which the code terminates and above which it continues. This causes dramatically less memory pressure and compiles down to much more efficient assembly.
2) The notes about the "alphabetical sorting" of symbols are a space saving optimization applied *on top* of canonical huffman codes. They are not a detail of canonical huffman codes as such. It's frankly silly to think that a code can't be canonical if its alphabet isn't sorted within a given code length; some alphabets don't have properly-defined sorting functions! The sorting details should be in their own dedicated section and framed as an extension of the technique, not a core part. 67.246.18.8 (talk) 21:32, 9 December 2023 (UTC)
thread_title:  Article should focus on speed, not space; also, alphabetical sorting is optional