Heads up, University is only for people who don't know how to learn since lectures came online since 2003. If you know how to learn, you can be a polymath in the time people go to uni for stuff. If you want to be a slave to student loans, by all means go to uni if you're into that kind of kink. If you're smart, just learn online.
I am amazed! I am a college student in Mozambique and I've been struggling to understand the Huffman Coding. Thank you for the simplicty of how you explain things
Learned more in 6 minutes than in two entire lectures and two tutorial classes at university. Why do Profs and teachers make it so hard, when it can be explained so easily?
Honestly speaking, this is the best video available on huffman coding throughout youtube Although I have a small doubt about... how to trace back to the original message from the encoded one ;) If someone could give a little brief. Thanks in advance!!
This demonstration was really great! My only complaint is I think it's unfair to compare the 46 bits with Huffman tree to 136 with ASCII at 8 bits per character. Those 8 bits are supporting up to 256 distinct characters, while the Huffman tree only accommodates 8 characters. So if we only need to encode the characters used in the message (ISPRMVE_), we could do that with just 3 bits per character. Then this fixed-size encoding would be 17×3=51 bits. So the Huffman tree still yields a savings, but it's more like 47/51 ~= 92% of the length of the original. [Full disclosure: I also have an explainer video about Huffman coding, and teach it pretty regularly.]
But you'd still need to send a mapping (full ASCII code to Huffman code), along with the encoded data, resulting in the transmitted data being longer than the original data (for this particular example)
Great video and well explained. Just one thing I would say about the ASCII coding, one of its 8 bits is used for parity check so perhaps it would be more fair to consider the ASCII characters as 7 bits. It would still be a great example of lossless compression though.
Kudos to the presentation, but... for a newbie like me there are some questions remain. The original string (used for demonstration only, I understand) is only 17 characters long, and chosen to show some recurring characters. The 'dictionary' for this message would contain 8 entries (1 byte each), and the 'paths' for each entry would fit into 8 bits (1 byte), so nothing is gained in this example... A much larger block of English text would benefit from the compression, obviously, but I wonder if protection is needed for long long branches on making Huffman trees?
Doesn't the dictionary also need to be saved, with the letters in their original 8 bit form for a total of 64 and the codes adding up to 26, making compressed text + dictionary add up to 136 again?
I'm not so sure, but for this example, without the Huffman coding, you can represent the letters with only 3 bit (8 characters = 2^3), not 8. 3 is the number of bits with which you have to calculate the percentage. So 3 bits x 17 total characters = 51 . (46/51)*100= 90.2, so the saving is only about 10%. You can't say that you need 8 bit to trasmit/represent each character without the Huffman coding, because in this case you have to use them also with it, which is useless.
But Huffman Coding is used mostly for text compression, so if you consider that any character of ASCII table can be used in the uncompressed text, the length of 8 bits has to be considered.
Great explanation. Thanks! One question: when building the tree, why did you choose to add PR4 and MVE_ instead of PR4 and S4? MVE_ and S4 have the same values of 4.
He's sticking with prioritizing the rightmost available sums when all else is equal. Try doing it the alternate way you've just outlined. Do you notice the potential to lose efficiency?
Did the huffman code provide the best solution? I mean in this example, can we use shorter unused bit for M, V..., like 10, 01 or 11, the total bits must be lower. Thank you for your explanation
Doing that would result in situations where you could end up with ambiguous combinations. Take representing M as 10 like your example. If I receive a string of bits 10100100 it's impossible for the receiver to tell is that's mmsi (10 10 01 00) or mpp (10 100 100) as all the computer has is the limited dictionary we gave it and the string of bits. Using the full dictionary provided and assuming M was given a value of 10 instead of 1100. When we try to write out Mississippi we get 100001010001010010010000. When the receiver gets this text we can assume it organizes letter by checking the string number by number until it hits an invalid combination then it steps back one and puts a break there. As it runs through this string it will see 1 then 0 and think I know this is an M but if the next number is 0 it is also a P so it checks, finds a 0, then checks the next, finds another 0 but knows there's nothing for 1000 but there is something for 100 so it thinks the first letter is 100 and moves on. If we run it through without any context the computer will try to break it up as pirissippi (100 00 101 00 01 01 00 100 100 00)
It doesn't matter. The Huffman binary tree is correct if each parent's key is equal to the sum of its childrens' keys and all nodes with elements are leaf nodes.
Why WE compress our language using our language when it IS to thé machine to compress it in its language . Why using A B C. .. when its simple tobuse 0 and 1
Sorry this might be unrelated but why does ASCII representation use 8 bits? As far as I can see, if you need to represent {a,...,z,A,...,Z} in binary code, surely you just need to minimise n subject to 2^n >= 52 (which yields n = 6). Then you can represent each letter uniquely, 6 bits each. Why use 8 bits?
6 bits doesn't actually give us enough room to work with, because there's a large variation of characters that can't be handled by a mere 6 bytes, including numerals, mathematical symbols, newlines, spaces, tabs, null, end of file characters, and so on. In fact, 8 bytes generally isn't enough either to include all the characters we need either, which is why Unicode was developed. As to why 8 bits per byte, it's mostly because it's the first power of two that can store a sufficient number of data to be flexible, while being small enough to be able to work around.
Why i paid 50k for college is beyond me when this explanation is free and is better than how my professor explained it
Because he doesn't hand out your certificate unfortunately.
Is this static or dynamic huffman?
Even better than my Course prescribed textbook.
Heads up, University is only for people who don't know how to learn since lectures came online since 2003. If you know how to learn, you can be a polymath in the time people go to uni for stuff.
If you want to be a slave to student loans, by all means go to uni if you're into that kind of kink. If you're smart, just learn online.
i paid 4L indian rupeee
Best explanation of Huffman coding!! Thank you! Great pace and simple explanation. Great job!!!
this was the best text compression teaching video ive ever watched thanks for helping
I am amazed! I am a college student in Mozambique and I've been struggling to understand the Huffman Coding.
Thank you for the simplicty of how you explain things
This is good explanation!! you explained it so simply. we need more explanation videos of this format!!
Learned more in 6 minutes than in two entire lectures and two tutorial classes at university. Why do Profs and teachers make it so hard, when it can be explained so easily?
Better to have 2 lectures wasted on something simple, than 2 lectures fully packed with content, no?
Thank you so much!! Now I understand Huffman coding much better than before.
Finally, I got some clear understanding of building the tree using smallest frequency values.. Thanks a bunch... Greetings from Pakistan...
What a stupendous, winsome, elegant, and terse explanation!
finally，i understand Huffman code
Thats the easiest and Best explanation on the subject. Thank you very much sir
man, you are a genius. your explanation is better than some professors
You have saved my life. thank you so much. Such an easy explanation.
Thanks man, cheers from IT student in Poland
Same situation here :P This guy up there, explained it to me in 6 minutes, when my professor wasn't able to do this is 6 months...
This is the best example I could find. Thank you!
Thanks, you explained it better than my professor.
The best explanation yet!!!
Honestly speaking, this is the best video available on huffman coding throughout youtube
Although I have a small doubt about...
how to trace back to the original message from the encoded one ;)
If someone could give a little brief.
Thanks in advance!!
Is this static or dynamic huffman?
You have to rebuild the tree so that the values are in the exact same place. Then you use the bits to go right or left in the tree.
Best video on this topic
sir, its too easy to understand thank you so much ,love from sri lanka
Wow that was actually pretty interesting
Best explanation...!! Thanks
Thank you! Great explanation. Subbed because of this great teaching video.
Finally got it
Nicely explain
Beautifully explained thank you
finally, i understand what Huffman coding is
absolute cinema
This video helped a lot thank you so much :) .
Best explanation I found on youtube!! :D
Actually.. you explained it the best! Thanks :)
Good explanation.. Thanks
Great explanation👌🏼
This demonstration was really great! My only complaint is I think it's unfair to compare the 46 bits with Huffman tree to 136 with ASCII at 8 bits per character. Those 8 bits are supporting up to 256 distinct characters, while the Huffman tree only accommodates 8 characters. So if we only need to encode the characters used in the message (ISPRMVE_), we could do that with just 3 bits per character. Then this fixed-size encoding would be 17×3=51 bits. So the Huffman tree still yields a savings, but it's more like 47/51 ~= 92% of the length of the original. [Full disclosure: I also have an explainer video about Huffman coding, and teach it pretty regularly.]
But you'd still need to send a mapping (full ASCII code to Huffman code), along with the encoded data, resulting in the transmitted data being longer than the original data (for this particular example)
Easy to digest 😁😁 Thanks
The best explanation
Clear and concise. Thanks!
thank you, that was really easy to understand.
Great video and well explained. Just one thing I would say about the ASCII coding, one of its 8 bits is used for parity check so perhaps it would be more fair to consider the ASCII characters as 7 bits. It would still be a great example of lossless compression though.
Kudos to the presentation, but... for a newbie like me there are some questions remain.
The original string (used for demonstration only, I understand) is only 17 characters long, and chosen to show some recurring characters.
The 'dictionary' for this message would contain 8 entries (1 byte each), and the 'paths' for each entry would fit into 8 bits (1 byte), so nothing is gained in this example... A much larger block of English text would benefit from the compression, obviously, but I wonder if protection is needed for long long branches on making Huffman trees?
Thank you so much, this technique is very easy
You !!!! please(100X) i love you ....What amazing explanation.... THNKS
So so good; thank you!
Good explanation sir😊
Great explanation, thanks.
I need it! Thanks for this video:)
thank you! from Bangladesh
Very clear. Thank you sir
Doesn't the dictionary also need to be saved, with the letters in their original 8 bit form for a total of 64 and the codes adding up to 26, making compressed text + dictionary add up to 136 again?
great video
THE BEST!!
Thank you very u saved my life
Thank you!
2:29 how come u didn’t join pr4 and the one to the right of it?
Does the mapping table also take place? The 46 bits probably do not contain it, right? How the receiver decodes it?
Correct, the storage of the conversion table (e.g. binary 00 => letter I) isn't included in the video. So that obviously increases the aggregate size.
I'm not so sure, but for this example, without the Huffman coding, you can represent the letters with only 3 bit (8 characters = 2^3), not 8. 3 is the number of bits with which you have to calculate the percentage. So 3 bits x 17 total characters = 51 . (46/51)*100= 90.2, so the saving is only about 10%. You can't say that you need 8 bit to trasmit/represent each character without the Huffman coding, because in this case you have to use them also with it, which is useless.
But Huffman Coding is used mostly for text compression, so if you consider that any character of ASCII table can be used in the uncompressed text, the length of 8 bits has to be considered.
thank you!
how would the receiving computer or whatever know how to translate the message though? would the binary values for all of the characters be sent too?
Nice and precise
Great Video, Thank you..
superb
adamsın corç :d
asdfadsfgasgs
Great explanation. Thanks! One question: when building the tree, why did you choose to add PR4 and MVE_ instead of PR4 and S4? MVE_ and S4 have the same values of 4.
He's sticking with prioritizing the rightmost available sums when all else is equal. Try doing it the alternate way you've just outlined. Do you notice the potential to lose efficiency?
And how do you reconstruct it? You have to save the table also but then for this example you didnt save space...
best explanation !!!!!!!!
please i need help , if there are a simple letter ,imagine it is 'm' what is value? is it equal to capital 'M' value ? or do we want to find it ?
Did the huffman code provide the best solution? I mean in this example, can we use shorter unused bit for M, V..., like 10, 01 or 11, the total bits must be lower. Thank you for your explanation
Doing that would result in situations where you could end up with ambiguous combinations. Take representing M as 10 like your example.
If I receive a string of bits 10100100 it's impossible for the receiver to tell is that's mmsi (10 10 01 00) or mpp (10 100 100) as all the computer has is the limited dictionary we gave it and the string of bits.
Using the full dictionary provided and assuming M was given a value of 10 instead of 1100. When we try to write out Mississippi we get 100001010001010010010000. When the receiver gets this text we can assume it organizes letter by checking the string number by number until it hits an invalid combination then it steps back one and puts a break there. As it runs through this string it will see 1 then 0 and think I know this is an M but if the next number is 0 it is also a P so it checks, finds a 0, then checks the next, finds another 0 but knows there's nothing for 1000 but there is something for 100 so it thinks the first letter is 100 and moves on. If we run it through without any context the computer will try to break it up as pirissippi (100 00 101 00 01 01 00 100 100 00)
Thanks for great explanation!
good one .....keep it up
thank u :)
Thanks
i think the calculation is wrong, lowest frequency should have the highest priority not the opposite
Great video, if I could give you two thumbs up I would. Thank you!
what software do you use for the dashboard ?
got it, thank you.
Best!!
"I love you telecommunication and network"
Can someone solve this using Huffman's tree and Huffman's code
can you explain how the receiver device understands the encoded message?
I have the same doubt
Sir, but this is wrong. 8 should switch with 9. The smaller number goes in the left child and the bigger in the right...
It doesn't matter. The Huffman binary tree is correct if each parent's key is equal to the sum of its childrens' keys and all nodes with elements are leaf nodes.
Can you share the code for this ? @Estudy
You did a mistake it’s actually 43 bits
Finally understand
if we have frequency 12,12,4,4 how result please help me
Combine 4 4, now ypu have 12,12,8. Then combine 12 and 8, now you have 12 20. An thn combine them and have 32
5:17 Compression Ratio
Why WE compress our language using our language when it IS to thé machine to compress it in its language . Why using A B C. .. when its simple tobuse 0 and 1
best knowladge received
So easly to understand
It's 16caractère not 17..you cant count the espace
Sorry this might be unrelated but why does ASCII representation use 8 bits? As far as I can see, if you need to represent {a,...,z,A,...,Z} in binary code, surely you just need to minimise n subject to 2^n >= 52 (which yields n = 6). Then you can represent each letter uniquely, 6 bits each. Why use 8 bits?
6 bits doesn't actually give us enough room to work with, because there's a large variation of characters that can't be handled by a mere 6 bytes, including numerals, mathematical symbols, newlines, spaces, tabs, null, end of file characters, and so on. In fact, 8 bytes generally isn't enough either to include all the characters we need either, which is why Unicode was developed.
As to why 8 bits per byte, it's mostly because it's the first power of two that can store a sufficient number of data to be flexible, while being small enough to be able to work around.
R2 IS SUBSET OF V1
It is. In fact, for this coding, the only thing is don't be a prefix. Being a subset is ok.
Sorry for my English... I think that the actual sentence has to finish this way : "...is not to be a prefix".
i think you did it wrong, looking at my class notes 0 should be on the right and 1 on the left
The number of edges is what is important, not whether you use 0 or 1 in a certain direction. It's the same number of bits.
grade 9 people watch this
I wonder who disliked
Wrong calculation
not visible at all, bad screen
gem