Path: utzoo!utgpu!news-server.csri.toronto.edu!csri.toronto.edu!wayne Newsgroups: comp.compression From: wayne@csri.toronto.edu (Wayne Hayes) Subject: Re: Compression figures Message-ID: <1991Apr21.123219.27208@jarvis.csri.toronto.edu> Organization: CSRI, University of Toronto References: <17734:Apr1614:47:4391@kramden.acf.nyu.edu> Date: 21 Apr 91 16:32:21 GMT Lines: 26 In article victor@watson.ibm.com writes: > I've just come back from DCC '91 (which was a pretty good conference), > and was reminded of one of my pet peeves: reporting compression > figures. There doesn't seem to be any standard way. > > 1) Orig/New > 2) New/Orig > 3) (Orig-New)/Orig > 4) Orig/(B*New) I much prefer 2) over all the others. It's the most obvious: it gives you the size of the new one compared to the old one. That's usually how size differences are compared: (new thing) vs (old thing). So 30% means it's 3/10ths the size of the original. This is COMPRESSION, so we should be thinking "smaller is better", not "bigger is better." My vote goes whole-heartedly behind 2). It's also the least ambiguous. I always get 1 and 3 confused: does 100% mean nothing happened or we got a factor of 2? With 2), it means nothing happened. Easy. Yes, it takes a bit of a view shift, but once you're used to it it's the easiest method to understand by far. -- NOTICE: Due to the complexity of nearly all topics, the opinions expressed above are in continual process of formation and may be changed without notice. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525