Re: LZ: Some interesting compression results...
[Prev][Next][Index][Thread]
At 11:13 PM 9/11/96 -0500, you wrote:
>That may be the state of things, but it could be just that program.
>There are a lot of good and bad [Huffman] implementations around. I'd try out
>some others as well
>
>Barry
Well, I might be wrong here (I've been wrong a lot lately :), but the
Huffman algorithm is pretty straightforward.
Basically, it makes a table of bytes which replaces the most-used bytes with
shorter bit-by-bit codes of themselves. For example, if the byte 11100011
was used more than any other byte the program, it would be replaced with the
bit 0. If 00000000 was used second most, it would be replaced with 01. If
11111111 was used third-most, it would be replaced with 001. Or something
along those lines. You probably get the idea. Sounds pretty nifty, and it
is for redundant data (like poorly-made programs that have repetetive code,
or pictures with vast blank spaces)
So, a different implementation wouldn't make much of a difference probably.
Actually, it could, if it had an intelligent way of representing the
shortened bytes. However, the algorithm was probably made to be pretty
efficient by the author, and any true Huffman compresser would adhere to
this algorithm like raving users to vaporware.
Basically, all I'm trying to say is that Huffman is probably not the best
algorithm to compress a typical ZShell program. Perhaps the Lempel-Ziv
thing is. Perhaps some other algorithm I haven't noticed is. When I get
more time, I'll look into it.
_______________________________________________________________________
|Martin Hock - oxymoron@aimnet.com - Oxymoron at #irchelp on EFnet|
|"I'm influenced by television? That's a load of rich creamery butter!"|
References: