drl@vuse.vanderbilt.edu (David R. Linn) (08/02/90)
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? David David Linn, System Manager/Postmaster |INET: drl@vuse.vanderbilt.edu Vanderbilt University School of Engineering|Phone: [+1] 615-343-6164 Post Office Box 3241, Station B |Disclaimer: Nashville, TN, USA 37235 | I speak only for myself.
oz@yunexus.yorku.ca (Ozan Yigit) (08/02/90)
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 This is simply not true. For a better understanding of the issue, see James Woods' article on gnu.misc.discuss. oz --- First learn your horn and all the theory. Internet: oz@nexus.yorku.ca Next develop a style. Then forget all that uucp: utzoo/utai!yunexus!oz and just play. Charlie Parker [?] York U. CCS: (416) 736 5257
williams@umaxc.weeg.uiowa.edu (Kent Williams) (08/02/90)
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
drl@vuse.vanderbilt.edu (David R. Linn) (08/02/90)
>>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 >> >>This is simply not true. For a better understanding of the issue, see >>James Woods' article on gnu.misc.discuss. According to RMS, this may or may not be true (he explicitly offers no opinion due to lack of relevant expertise) but this response sidesteps the original question: >> Can anyone give a reference for the compression algorithm used by comic?
jms@cs.vu.nl (Jan-Mark) (08/03/90)
In an article williams@umaxc.weeg.uiowa.edu (Kent Williams) writes: > 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! Question: Where you talking about COMIC 1.0 or 1.0B? -- (:> jms (_) ========""======