Talk:Huffman coding
Umm... this is all wrong. Read the Wikipedia article. According to your scheme Huffman codewords would all be of the form 111...10 or 111...1, but that is not at all the case. --76.167.241.45 03:59, 26 March 2009 (UTC)
- Yep. It is not Huffman coding. (Hmm, I do like the wikipedia description of the two queue method though ...) --Paddy3118 06:56, 26 March 2009 (UTC)
- I did it based on what I learned in class today. If you look at the "Basic technique" section on the WP it shows codes identical to ones I used in the example so I'm pretty sure it is Huffman coding. There must be a few ways to generate them that give different actual codes with the same idea. --Mwn3d 13:44, 26 March 2009 (UTC)
- For the example given, the Huffman code indeed looks like this. But as a general algorithm, it's wrong. What you should do is that you "combine" the last two elements in the table, and sort them back into your list. So starting with the example,
- I did it based on what I learned in class today. If you look at the "Basic technique" section on the WP it shows codes identical to ones I used in the example so I'm pretty sure it is Huffman coding. There must be a few ways to generate them that give different actual codes with the same idea. --Mwn3d 13:44, 26 March 2009 (UTC)
(A=?): 50% (B=?): 25% (C=?): 12.5% (D=?): 12.5%
- you first assign the bit to the last two items (C and D), and then combine them, adding the frequencies, and sorting it into the right place
(A=?): 50% (B=?): 25% (C=?0,D=?1): 25%
- Then you do the same again:
(A=?): 50% (B=?0, C=?10, D=?11): 50%
- And finally you get
(A=0, B=10, C=110, D=1110): 100%
- Thus the result is indeed as given in the example. However, assume that you start with
(A=?): 25% (B=?): 25% (C=?): 25% (D=?): 25%
- Your algorithm would still give the same result, while it's obvious that using just the standard two-bit numbering is optimal for this case. And indeed, the first step of the Huffman coding gives:
(C=?0, D=?1): 50% (A=?): 25% (B=?): 25%
- Note how the (C,D) case moves up, because it's probability is larger than the 25% of each of A and B. Therefore the next step combines A and B:
(A=?0, B=?1): 50% (C=?0, D=?1): 50%
- (I've made the convention that items with the same probability are sorted lexicographically; of course other conventions, like e.g. leaving the newly formed pair as low as possible, also work). Now our final combination provides:
(A=00, B=01, C=10, D=11): 100%
- which obviously is an optimal code for this case. --Ce 14:17, 26 March 2009 (UTC)
- Huffman coding in the case where all the symbols have the same frequency is not practical, though. If all the symbols have the same frequency no thought needs ot be put into it at all and you can just use ordinary binary encoding. --Mwn3d 15:59, 26 March 2009 (UTC)
- Huffman coding in the case where all the symbols have the same frequency will precisely generate the binary encoding. That's the whole point. Huffman coding always generates an optimal symbol-by-symbol coding.
- Anyway, a better example of Huffman coding I think would be something like the example at the top right of the Wikipedia article. The frequencies are taken from the string "this is an example of a huffman tree", and produces the following:
- Huffman coding in the case where all the symbols have the same frequency is not practical, though. If all the symbols have the same frequency no thought needs ot be put into it at all and you can just use ordinary binary encoding. --Mwn3d 15:59, 26 March 2009 (UTC)
- which obviously is an optimal code for this case. --Ce 14:17, 26 March 2009 (UTC)
Char Freq Code space 7/36 111 a 4/36 010 e 4/36 000 f 3/36 1101 h 2/36 1010 i 2/36 1000 m 2/36 0111 n 2/36 0010 s 2/36 1011 t 2/36 0110 l 1/36 11001 o 1/36 00110 p 1/36 10011 r 1/36 11000 u 1/36 00111 x 1/36 10010
- Your coding doesn't have to be exactly the same, but it should be equivalent to the above (i.e. codeword lengths should be the same, except that symbols with equal frequencies might be switched around). --76.167.241.45 18:55, 26 March 2009 (UTC)
By hand
I made tons of that when coded my first Static Huffman cruncher eons ago (68k assembly, maybe I still can find the codes on old 3.5 floppies); by hand I made so
A 50% ----------------\ B 25% ----------\ \ C 12.5% \ \ \ 100% D 12.5% / 25% / 50% /
so being "up" 1 and "down" 0: A=1, B=01, C=001, D=000. From here an algo can be extracted (by word in short: group 2-by-2 less frequent leaves; so first we have 12.5% and 12.5%, then we have the new leaf at 25%, and another one at 25%, so we join these... and so on). Dynamic Huffman Encoding is a little bit harder, not too much anyway, but I have never implemented that. I like this task, with a little bit of maquillage it's ok.
Now let's take the case all 25%
A 25 \ 50 \ B 25 / \ C 25 \ / 100 D 25 / 50 /
Id est, two bit for each letter. --ShinTakezou 16:33, 26 March 2009 (UTC)
By the way, what is exactly wrong? The examplanation? Or the java code? --ShinTakezou 16:37, 26 March 2009 (UTC)