Path: utzoo!mnetor!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!B.GP.CS.CMU.EDU!ralf@b.gp.cs.cmu.edu
From: ralf@b.gp.cs.cmu.edu (Ralf Brown)
Newsgroups: comp.sys.ibm.pc
Subject: Comparison of compaction routines
Message-ID: <1514@pt.cs.cmu.edu>
Date: 24 Apr 88 21:37:03 GMT
References: <483@csccat.UUCP>
Sender: netnews@pt.cs.cmu.edu
Followup-To: comp.sys.ibm.pc
Lines: 84

In article <483@csccat.UUCP> loci@csccat.UUCP (Chuck Brunow) writes:
}
}	The tester of the various routines for compaction titled as ...
}
}>                  TEST OF MS-DOS COMPRESSION PROGRAMS 
}
}	provided a cursory look at programs by name. It would be well
}	to specify what the method of compaction used in each case was.

ARC: 	    12-bit LZW
PKARC: 	    13-bit LZW
PKARC -oct: 12-bit LZW
ZOO: 	    12-bit? LZW
SQPC: 	    Huffmann
Compress:   16-bit LZW

}	Setting that aside, the author misses the principle point of
}	compaction: to make it small. Speed is not a good measure of
}	this function except as it relates to transmission speed, ie.
}	how small is it. The 16-bit compress clearly blew everything
}	else away in overall terms. 

But what if the compaction/decompression takes longer than the time saved
by sending a smaller file? (this is a definite concern with 9600bps modems)
Also, available memory is a definite concern on MSDOS machines.  16-bit
compress needs ~500K to run (~450K for the compression tables, ~25K for
the executable, plus other overhead).  This basically means unloading all
TSRs, exiting any operating environment (such as DESQview/Windows/etc), even
on a 640K machine.

}                                    Further, because the routines of
}	compress are widely available, and Unix compatible, that method
}	can be integrated into a program specially suited to the task

ARC's LZW code *is* the compress LZW code! 


-- 
{harvard,uunet,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- AT&T: (412)268-3053 (school) 
ARPA: RALF@B.GP.CS.CMU.EDU |"Tolerance means excusing the mistakes others make.
FIDO: Ralf Brown at 129/31 | Tact means not noticing them." --Arthur Schnitzler
BITnet: RALF%B.GP.CS.CMU.EDU@CMUCCVMA -=-=- DISCLAIMER? I claimed something?
Newsgroups: TEST OF MS-DOS COMPRESSION PROGRAMS
Subject: Re: Comparison of compaction routines
Keywords: good data, bad (biased) conclusion
Distribution: 
References: <483@csccat.UUCP>
Organization: Carnegie-Mellon University, CS/RI

In article <483@csccat.UUCP> loci@csccat.UUCP (Chuck Brunow) writes:
}
}	The tester of the various routines for compaction titled as ...
}
}>                  TEST OF MS-DOS COMPRESSION PROGRAMS 
}
}	provided a cursory look at programs by name. It would be well
}	to specify what the method of compaction used in each case was.

ARC: 	    12-bit LZW
PKARC: 	    13-bit LZW
PKARC -oct: 12-bit LZW
ZOO: 	    12-bit? LZW
SQPC: 	    Huffmann
Compress:   16-bit LZW

}	Setting that aside, the author misses the principle point of
}	compaction: to make it small. Speed is not a good measure of
}	this function except as it relates to transmission speed, ie.
}	how small is it. The 16-bit compress clearly blew everything
}	else away in overall terms. 

But what if the compaction/decompression takes longer than the time saved
by sending a smaller file? (this is a definite concern with 9600bps modems)
Also, available memory is a definite concern on MSDOS machines.  16-bit
compress needs ~500K to run (~450K for the compression tables, ~25K for
the executable, plus other overhead).  This basically means unloading all
TSRs, exiting any operating environment (such as DESQview/Windows/etc), even
on a 640K machine.

}                                    Further, because the routines of
}	compress are widely available, and Unix compatible, that method
}	can be integrated into a program specially suited to the task

ARC's LZW code *is* the compress LZW code!