Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.compression
Subject: Re: Reply to Dan Bernstein's criticisms of standard.
Message-ID: <4496@optima.cs.arizona.edu>
Date: 22 Jun 91 23:28:14 GMT
Sender: news@cs.arizona.edu
Lines: 44

I have to agree with Dan (readers of comp.lang.misc are probably
experiencing a feeling of unreality right now...) that parameters are
important.  Any standard that neglects them will be ignored by
everyone who implements an algorithm with natural parameters.

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.  When you name such a procedure for
comparison to other procedures, any parameters that are not mentioned
are assumed to be the defaults.

One advantage of this for C is that in those cases where you want to
hard code the parameters you can #define them in the source of the
compression function without changing the function's formal
parameters.  (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.)

As to the stream/block problem, I suggest that it is unreasonable to
try to force exactly _one_ interface on all algorithms and
applications.  Obviously there are applications for each and the
standard should apply to each.  In other words, there should be a
standard stream interface _and_ a standard block interface.  Let the
aplication programmer choose whichever interface is most appropriate
and let the compression implementer deal with any problems the given
compression procedure may have with either interface.  Add a field to
the identity records that says whether the algorithm works "best" with
streams, blocks, or either.

I'd also like to repeat someone else's suggestion of seperating the
compression procedure and decompression procedure.  I don't understand
how this effects having a compression method as a first-class
function.  So you have two first-class functions for each compression
method instead of one, what's the big deal?  For that matter, I'd add
a third function -- the one that returns the identity record.  I don't
see any value to having this be part of the compression function
itself.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman