Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

endless compression



markw at mohawksoft.com wrote:
> 
> When you look at a ZIP compressed file, it does not compress well using
> standard stream compressors. This is because there are few if any
> repeating paterns. The fact that it has few repeating patterns, makes this
> stream interresting. It means that it is less likely in a universe of
> streams. If it is less likely, then it can be represented with fewer bits.

I don't see why it matters how "likely" the stream is.  Even if the 
stream I want to compress is extremely unlikely, there might be some 
very large number of other streams that are equally unlikely.

If your recompression engine can say "aha, even though this stream does 
not have any 'repeating patterns' that a ZIP compressor can recognize, 
the data in the stream could be reconstituted with the following 
formula...", then the engine could write out some abbreviation that 
formula, and the corresponding uncompression engine could read the 
abbreviation and regenerate the stream.

Of course, you might as well apply that pattern-recognition technology 
to the original document, rather than the ZIPped version, right?

And once you reach the point where the formula to reconstitute the 
stream takes up just as many bits as the original stream, then you lose.

-- 
"Remember that "freedom" is not just a word. It is a squishy,
  concept-lite word which invokes positive feelings." --Fafblog
// seth gordon // sethg at ropine.com // http://dynamic.ropine.com/yo/ //






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org