Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!itivax!dhw
From: dhw@itivax.iti.org (David H. West)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: lharc algorithm (was Re: Final Vote Tally/Summary)
Summary: what about 16- (or so) bit compress?
Message-ID: <949@itivax.iti.org>
Date: 11 Apr 89 18:40:29 GMT
References: <19456@iuvax.cs.indiana.edu>
Reply-To: dhw@itivax.UUCP (David H. West)
Organization: The Forgotten Legions of ... um ... er ...
Lines: 28

In article <19456@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
>[...]  I am really curous to see how that algorithm stacks up against
>16-bit LZW compression as represented by UNIX compresses.

People have posted figures indicating that in compression ratio, lharc 
has somewhat of an edge over pkzip, which may have a slight edge over 
arc.
I haven't done any method-exhaustive tests, but in my (small sample)
experience, 16-bit un*x-style compress beats arc quite substantially.
Example (the .arc file was crunched):

-rw-r-----  1 dhw       1794048 Apr 11 12:53 sbp_v3.tar
-rw-r-----  1 dhw       1071444 Apr 11 13:20 sbp_v3tar.arc
-rw-r-----  1 dhw        916473 Dec 28 10:41 sbp_v3.tar.Z

Someone who has the time should do more extensive tests...

There may be a problem though, in that I've never seen a 16-bit
MSDOS compress (as opposed to uncompress, which was posted a few
weeks ago); there are rumors to the effect that to get a 16-bit
compress to run in 640K, you have to swap pieces of the table to disk, 
which slows execution to a crawl.  A refutation of this, preferably in 
the form of public domain code, would be very welcome.

-David West            dhw@itivax.iti.org
		       {uunet,rutgers,ames}!sharkey!itivax!dhw
COMPIS, Industrial Technology Institute, PO Box 1485, 
Ann Arbor, MI 48106