Path: utzoo!mnetor!tmsoft!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!spool.mu.edu!sdd.hp.com!wuarchive!udel!rochester!pt.cs.cmu.edu!ORCRIST.GANDALF.CS.CMU.EDU!cwk
From: cwk@ORCRIST.GANDALF.CS.CMU.EDU (Charles Krueger)
Newsgroups: comp.software-eng
Subject: Reuse, Tolerance, and Tradeoffs  (was Re: Tolerance)
Summary: Tolerance and Tradeoffs
Message-ID: <11803@pt.cs.cmu.edu>
Date: 6 Feb 91 15:49:24 GMT
References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <785@caslon.cs.arizona.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 29

In article <785@caslon.cs.arizona.edu>, dave@cs.arizona.edu (Dave P. Schaumann) writes:
 
> Ok, so I stand corrected.  There are a lot of applications out there that
> don't need exact answers.  But my question was in the context of code re-use.
> ...
> I can't see how the "tolerence paradigm" could possibly lead to a reasonable
> means of code re-use.

There are some dimensions in resuable artifacts in which tolerance makes
sense.  In particular, there are tradeoffs in many reusable artifacts, and
these tradeoffs can involve tolerance.  As a simple example, a sine routine
is never a pure mathematical sine function.  It's just sort of "siney".
As a reuser, I would like to decide how much computation time I am willing
to spend in order to make it more siney.  I can dedicate arbitrarily large
amounts of time if my tolerance for error is small, or vice versa.

With your stack example, I can imagine some flexibility in the stack
semantics, based on tradeoffs with other constraints.  For example, maybe
in the "pure" definition of a stack, an error is generated when you try to
pop an empty stack.  However, in my application I can guarantee that an
empty stack will never be popped, so I don't want to pay the overhead of
checking for an empty stack.  By omitting this check, the artifact is no
longer a pure stack, but just sort of stacky.

The key to making this work, of course, is to keep the tolerance and the
variability in the artifacts well defined.  The person reusing the
artifact must clearly know what can be varied and the effect on the
semantics.  Abstraction is the key to presenting this information to the
reuser.  It is a hard problem.