Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!uunet!philmtl!atha!rwa
From: rwa@cs.AthabascaU.CA (Ross Alexander)
Newsgroups: comp.sys.atari.st
Subject: Re: The *new* DC Squish from Double Click Utilities...
Keywords: hoo boy
Message-ID: <1171@atha.AthabascaU.CA>
Date: 18 Oct 89 01:08:31 GMT
References: <891013.16005173.072949@SFA.CP6>
Organization: Athabasca University
Lines: 60

Z4648252@SFAUSTIN.BITNET (Z4648252) writes:
>      One joy that a user-enthusiast has when receiving new
>software is the observation of the evolving improvement of
>already great packages.
	[ much lyrical exposition ommitted ]
>PROGRAM            ORIGINAL SIZE      OLD SQUISH      NEW SQUISH
>Turbo 1.60             52.587 K         26.858 K       23.412 K
>Flash 1.60            137.492 K        106.222 K       97.220 K
>WordPerfect (Aug 89)  204.280 K        161.726 K      151.632 K

Ok, let's assume wordperfect is a pretty average binary file.  If
anyone knows otherwise, please fill me (and the net) in.  I observe
from the numbers given that it compresses ( 1 - ( 151632 / 204280 ) ) %
or about 26%.  The other examples range from ~ 29% to 56%.  I am
suspicious of the 55% value, but what the hay.  I say this because I
notice that as the files get bigger, performance drops off.  This is
counter-intuitive, to say the least...

Anyway, I just tried compressing GNU emacs - original 991232 bytes,
compressed image 492357 bytes.  Compression = ( 1 - ( 492357 / 991232
) ) %, or about 51%.  This was done with the freeware version of
16-bit LZW compress (the same compress that comes as part of GNU)
running on my 1040.  I think emacs is as typical a binary as exists.
(What that says about me is left as an excercise for the reader ;-).

Or /usr/local/bin/vnews, ~200K, compresses about 39% (this is done on
a BSD box that's handy, but its exactly the same code on both
machines).  Both of these binaries are 'pretty average', I'd say.
Big, but average.  Notice big files work better, not worse.

Now compress is unfriendly, and cryptic, and free, and it's been
around a long time, and everybody has one on their crufty old unix
box, and the DOS guys have a version, and we ST guys have a version,
and the minix-ST people have a version, and they all interoperate, and
you can get the source code for free from damn near anybody.  I can
speak personally for the unix, st, and minix people, since I'm one of
each.  And I have one of each :-).

Whereas DC Squish works I-know-not-how (and it clearly changes with
the phase of the moon), and if they've got DOS or unix or minix
versions you don't mention it, and I expect the source is proprietary
as all heck, and they sell binaries for money.  That's private
enterprise, which I support.  Wholeheartedly.

But from your numbers, compress easily matches DC-squish on
performance, and creams it on almost every other metric I can think of
(except user interface: honestly, compress doesn't have one).  Us
old-timers, we're hard to impress.  BTW, there are some clever
techniques out there - fractional huffman encoding comes to mind -
that can beat Lempel-Ziv-Walsh encoding (the "LZW" above).

Sorry to rain on your parade, but "Just the facts, ma'am, just the facts".

	Ross

ps: anyone want a copy of compress?  I'm suprised it hasn't come by
again on comp.binaries.atari.st - the program is _small_, about 32k.
Steven Grimm, you out there ?

	r