Ralf.Brown@B.GP.CS.CMU.EDU (08/13/88)
In article <962@lakesys.UUCP>, deanr@lakesys.UUCP (Dean Roth) writes: }The following message was taken from EXEC-PC BBS }in Shorewood, WI, and is from THE Phil Katz. } }================================================== } }c: IBM GNRL #25669 08-10-88 21:45 (Read 90 times) }f: PHIL KATZ }t: JIM DUNNIGAN (Rcvd) }s: R: R: WHAT ELSE? Reply to #25640 } }Jim, } }>>Aside from gaining a little speed and compression on PKPAK 3.61 . . . } }Well, hopefully more than just a little. While I don't want }to spill all my beans, but without the constraints of the }.ARC format or the Ziv-Lempel implementations used in .ARC files, }it is possible to do MUCH better than PKPAK 3.61. Also, the Sounds like Phil is planning to use the algorithm described in the August 1988 _Communications_of_the_ACM_ article "Application of Splay Trees to Data Compression." A modification of the basic algorithm matched or outperformed Unix "compress" while using only 1/3 the data storage. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/31 Disclaimer? I |Ducharm's Axiom: If you view your problem closely enough claimed something?| you will recognize yourself as part of the problem.