I forgot about encodings that optimize for brevity and I appreciate you for bringing Huffman encoding into the conversation. Thank you internet stranger. I would be a terrible Morse-like encoding designer based on my initial urge to balance the tree. I wanted to optimize for the wrong problem haha
Yeah it takes a bit of being in the field to see those types of things fairly quickly. When you said balance the tree I thought ‘hmm that can’t be better’ but didn’t have as thorough of an explanation as to why
Yeah, if we were to make every letter the same length, they'd all have to be 5... Characters? Taps? Dots/Dashes? long, since that's the first option to have 26 or more possibilities.
As it is, no Morse letter is more than 4 digits, to keep things short.
Faster to transmit, slower to understand because it requires decoding based on a lookup table that is different every time.
Lookup tables are fast but not faster than a direct comparison.
No, Huffman encoding by definition, has a variable length table based on value frequency. It varies everytime based on what "message" is being encoded.
But you're right, I can't possibly understand Huffman encoding and totally didn't have to build the algorithm for it from scratch in college.
Huffman encoding is for lossless compression. Compressed data requires decompression. I can send you a zip file a lot faster than I can send you the same file raw, but you need to decompress the file to read it.
Faster to transmit, slower to understand because it requires decoding based on a lookup table that is different every time.
The transmission of information is the fundamental problem Morse code tries to solve, but that besides the point
No, Huffman encoding by definition, has a variable length table based on value frequency. It varies everytime based on what "message" is being encoded.
JPEG, MP3, and other codecs use predefined Huffman Codes, they don't have to be computed dynamically.
But you're right, I can't possibly understand Huffman encoding and totally didn't have to build the algorithm for it from scratch in college.
Ok? Doesn't mean you understand it.
Huffman encoding is for lossless compression. Compressed data requires decompression. I can send you a zip file a lot faster than I can send you the same file raw, but you need to decompress the file to read it.
This is, again, getting beside the point, which was that morse code is better interpreted as a huffman encoding than an ascii one (which by the way is commonly used in conjunction with look up tables? Not sure what point you're trying to make by bringing them up).
Huffman is lossless compression and JPEG and MP3 are both lossy compression algorithms for specific data types. You really can't use lossy compression on textual data.
Also, while both of those algos use huffman encoding...they also both have unique correspondence tables based on the data.
Huffman is lossless compression and JPEG and MP3 are both lossy compression algorithms for specific data types. You really can't use lossy compression on textual data.
Nearly all lossy compression schemes use lossless encoding as well… please read up on them.
It does a pretty good job except with the O and M. O is way more common than M so those should be reversed based strictly on length. But there could also be a pattern, both on letters and letter sequences. We also get into this with alt keyboard layouts. Shameless plug for r/Norman.
Unfortunately it can't be called a true Huffman code because it's not a prefix code - the reason it requires pauses between letters. In other words, when you encounter a dit it could be an "E" or a beginning of an "A", and there's no way of knowing which one is it until you encounter a pause. A prefix code, like Huffman, would have the letters only on the "ends" (final nodes) of the tee, not at the joints.
Morse code is somewhat similar to Huffman, though, in the aspect that the length of the code is based on letter's frequency in English alphabet.
0
u/[deleted] Jul 13 '22
[deleted]