Silly example. It compresses the phrase "do or do not" that has 6 symbols (d, o, r, n, t, space), builds a huffman tree just for these and then assumes significant compression by using 8 bits per character for the uncompressed case.
Wouldn't any compression algorithm be a silly example when using such a small amount of data as the overheard to communicate information about the compression would take more data than was saved and potentially more data than the original message?
I think it still suffices as an example because it would be easy to infer how this scales up to an entire book. Finer details are left out, but is that the sort of detail that should be present in a very short introductory article?
Not communicating enough info to rebuild the tree is a separate issue, but it is mentioned in the article so the reader is not left guessing. In the example however, we have a set of 6 symbols that would require 3 bits each to represent uncompressed but instead assume 8 bits. It invites fairness questions, which would distract a reader that has not been exposed to the concept before. This is an otherwise nice intro to the topic though.
My intention was to pick an example that produced a small tree with only a few leaf nodes (so that the diagram was easy to follow), but still contained some duplication.
My hope was that somebody new to the concept could then infer the results for larger inputs.
I did not intend to imply that this would be a valid use case for building a Huffman tree in practice.
What's silly about that? If I were just getting started with this kind of thing, I think this would've been a great post for me. As I haven't done this since an intro class in college, it was actually a nice quick refresher. 6 symbols is easy to keep in the head all at once.
