Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!am.dsir.govt.nz!marcamd!mercury!kcbbs!kc
From: Peter_Gutmann@kcbbs.gen.nz (Peter Gutmann)
Newsgroups: comp.compression
Subject: DDJ compression competition FLAME
Message-ID: <1991Apr8.160133.22070@kcbbs.gen.nz>
Date: 8 Apr 91 16:01:33 GMT
Lines: 54
Organisation: Kappa Crucis Unix BBS, Auckland, New Zealand

#flame on  
  A few days ago I finally managed to get hold of the Feb'91 DDJ.  There were 
two things about the compression competition that disturbed me:  
  
1. The test data is known in advance.  It is thus possible to write a  
compression program which will compress it arbitrarily well.  Since the output
of the program is known in advance, no information is being transmitted, thus 
the data can be compressed to 0 bytes.  In theory I could submit a program  
which, for compression, creates a 0 output byte file; for decompression, it  
copies data from a static internal buffer to the output file as fast as it can
This would take away all the prizes for max.compression and fastest program.  
   In practice this program will probably not be accepted....however it's stil
possible to create, say, a dictionary-based compression program which contains
an optimal dictionary (created after 2 weeks runtime on an IBM 3090) which  
compresses the test data far better than anything else in existence.  Even  
without resorting to this sort of thing, the results will *still* be biased:  
Everyone will no doubt be using the supplied data files to test their  
compressors, thus unconsciously tuning their compressors to the particular dat
being compressed.  
  
2. The type of system the compressor will be run on (a 25Mhz 386 with 128K  
cache and 8MB RAM).  This system will *not* determine who can create the best 
compressor.  What it will determine is who has access to high-end PC hardware;
who has mastered the intricacies of EMS/XMS programming; and only then who can
write the best compressor.  Most people won't have access to this kind of  
system - there'll be a lot of students using low-end (ie affordable) AT's and 
Mac SE's and the like with 640K or 1M of RAM, which means (unless they've  
achieved some amazing breakthrough in compression technology) they might as  
well not bother if they have to compete with finite-context compressors runnin
in 6MB of RAM.  
  The other problem with this kind of setup is somewhat similar:  Lets say the
winner is chosen, an order-5 PPM compressor which runs in 6MB of RAM.  Everyon
will look at it, think "Very nice", and then go back to using PKZIP, compress,
and StuffIt....  
  
(BTW I'm not writing this criticism out of "sour grapes" reasons:  The hardwar
requirements are no problem for me.  They are, however, unreachable for  
virtually everyone else I know.  This means I could submit a ho-hum compressor
which, due to the fact that it has huge amounts of memory to run in, will  
outperform a much better compressor which runs in around 512K.  My compressor 
may be completely impractical, but it would win under the given  
conditions....).  
#flame off  
  
Any comments, anyone?  
  
Peter.  
  
 Peter_Gutmann@kcbbs.gen.nz || peter@nacjack.gen.nz || pgut1@cs.aukuni.ac.nz  
                     (In order of decreasing reliability)  
Warning!  
  Something large, scaly, and with fangs a foot long lives between <yoursite> 
and <mysite>.  Every now and then it kills and eats messages.  If you don't  
receive a reply within a week, try resending...