Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu
Newsgroups: comp.unix.wizards
Subject: Re: function "prratio()" in sources to BSD compress
Message-ID: <17277:Jun1304:57:3890@kramden.acf.nyu.edu>
Date: 13 Jun 90 04:57:38 GMT
References: <1990Jun7.023616.25034@athena.mit.edu> <1990Jun7.184525.962@riacs.edu>
Distribution: usa
Organization: IR
Lines: 26

In article <1990Jun7.184525.962@riacs.edu> jaw@riacs.edu (James A. Woods) writes:
  [ calculation of ratios in compress ]
> i agree that it should revert to floating point.

I disagree. Say you want to print the floating-point ratio of integers x
and y, rounded down and accurate to 4 digits. 10000 * (x / y) is fast;
(10000 * (x % y)) / y is easy with appropriate shifts, with no chance of
overflow; and that's it. On anything other than a Cray this is much
faster than any floating-point calculation, not to mention more
reliable. (Of course, you can just take the squeeze 1.7 approach of
assuming that 10000 * x won't overflow. :-) )

The coming version of squeeze still prints to only 1% accuracy, since I
don't find further digits relevant; to calculate (100 * (x % y)) / y, it
does a binary search (with power-of-two deltas). No kidding. It's pretty
damn fast, too.

> better yet would be to speedup dan bernstein's 'squeeze',
> a miller/wegman/ziv/lempel coder which has better c-rates. 

Eliminating unsqueeze's I/O bottlenecks and making it faster than
uncompress, adding compress compatibility, improving portability, and
using a new extensible hash scheme have all come first. I suppose I'll
get around to speeding up squeeze itself at some point...

---Dan