Path: utzoo!attcan!uunet!ns-mx!umaxc.weeg.uiowa.edu!williams
From: williams@umaxc.weeg.uiowa.edu (Kent Williams)
Newsgroups: comp.os.minix
Subject: Re: compress and comic
Message-ID: <2026@ns-mx.uiowa.edu>
Date: 2 Aug 90 13:00:50 GMT
References: <26407@nigel.udel.EDU>
Sender: news@ns-mx.uiowa.edu
Reply-To: williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams)
Organization: U of Iowa, Iowa City, IA
Lines: 24

In article <26407@nigel.udel.EDU> drl@vuse.vanderbilt.edu (David R. Linn) writes:
>Since it looks like compress will soon be unavailable to the common
>man because it implements a patented algorithm, comic becomes *MUCH* more
>interesting.  Can anyone give a reference for the compression algorithm
>used by comic?
>
NO,NO,NO,NO Nobody is taking away compress.  As was pointed out by one of
the authors of compress in gnu.misc.discuss, compress was written
before the patent was applied for, and Unisys is mostly interested in
licencing hardware manufacturers who incorporate some form of LZW
compression.

Comic is way too slow for everyday use.  As near as I can tell it uses
an O(n*m) algorithm, where n is a function of the input size, and m is
the string table size.  Try comic-ing a >100K tar some time!

If someone spent some time finding a more efficient lookup for comic,
it might be a practical contender.  Compression ratios are certainly
good!

--
Kent Williams                    'Look, I can understand "teenage mutant ninja 
williams@umaxc.weeg.uiowa.edu    turtles", but I can't understand "mutually 
williams@herky.cs.uiowa.edu      recursive inline functions".' - Paul Chisholm