Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/3/85; site ukma.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!cbosgd!ukma!sean
From: sean@ukma.UUCP (Sean Casey)
Newsgroups: net.dcom,net.micro
Subject: Re: Squeezing program files.
Message-ID: <1861@ukma.UUCP>
Date: Mon, 10-Jun-85 20:55:39 EDT
Article-I.D.: ukma.1861
Posted: Mon Jun 10 20:55:39 1985
Date-Received: Tue, 11-Jun-85 08:39:22 EDT
References: <1414@ecsvax.UUCP> <784@turtlevax.UUCP>
Reply-To: sean@ukma.UUCP (Sean Casey)
Organization: The White Tower @ The Univ. of KY
Lines: 23
Xref: watmath net.dcom:1032 net.micro:10731

In article <784@turtlevax.UUCP> ken@turtlevax.UUCP (Ken Turkowski) writes:
>I think you should consider changing to Lempel-Ziv Compression (posted
>to the net as "compress", version 3.0), which normally gives 70%
>compression (30% of original size) to text.  The program is fast, and
>adapts to whatever type of data you give it, unlike static Huffman
>coding.  It usually produces 90% (!) compression on binary images.

WHOA BUDDY!

Lempel-Ziv doesn't do NEARLY that well.  We've been using it for
months, and we've found that text and program sources usually get about
55-65% compression, while binaries get about 45-55% compression.  This
is encountered in the optimal case of compressing a large archive of
files.  As files get smaller, expecially as they drop below about 8k in
size, compression worsens. I seriously doubt that most binaries contain
only 10% of unambiguous information, much less being compressable to
that size.

-- 

-  Sean Casey				UUCP:	{cbosgd,anlams,hasmed}!ukma!sean
-  Department of Mathematics		ARPA:	ukma!sean@ANL-MCS.ARPA	
-  University of Kentucky