Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!emory!ox.com!yale.edu!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.compression
Subject: Re: Reply to Dan Bernstein's criticisms of standard.
Message-ID: <3406.Jun2302.12.0491@kramden.acf.nyu.edu>
Date: 23 Jun 91 02:12:04 GMT
References: <4496@optima.cs.arizona.edu>
Organization: IR
Lines: 42

In article <4496@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
> How about the following: a compression procedure with parameters will
> use a global variable for each one (using some naming convention based
> on the name of the procedure).  The user's program does not have to
> refer to the global variable at all, and if it doesn't then some
> natural default is used.

I expect that Ross will disapprove of this because he can't pass the set
of parameters around as arguments if they're global variables. If you
have an array argument giving any number of { parameter, value } pairs
in any order, this problem disappears.

> (It seemed that Dan doesn't believe there can be an
> advantage in hard coding the parameters, which I find peculiar.  There
> are many optimizations that can be done with known values over
> variables.)

It depends. Parameters like hash table size (and hash function!) have to
be hard-coded if you want any efficiency, as do ``parameters'' like the
type you use for storing hash values. But I've never seen a parameter
that affects compression and has to be hard-coded. (You get about a 0.4%
speedup by specifying a single value of ``min'' in yabba, for example.)
Finally, any good language lets you say ``let foo() be a version of
bar() where argument x is 57'' and optimizes that independently.

> As to the stream/block problem, I suggest that it is unreasonable to
> try to force exactly _one_ interface on all algorithms and
> applications.

Exactly. I imagine modem manufacturers would love this standard, for
example, while UNIX users and programmers would love a program-based
standard. Here's a challenge, Ross: Rewrite compress to conform to your
standard. If you can do that, publish it and explain why it's useful.
I'm always wary of ``standards'' that haven't been given at least two
unrelated implementations.

> I'd also like to repeat someone else's suggestion of seperating the
> compression procedure and decompression procedure.

Ditto.

---Dan