Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!mcsun!ukc!edcastle!cs.ed.ac.uk!mikef
From: mikef@cs.ed.ac.uk (Mike Fourman)
Newsgroups: comp.software-eng
Subject: Re: Tolerance
Message-ID: <5614@skye.cs.ed.ac.uk>
Date: 5 Feb 91 09:27:14 GMT
References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <15863.27ad36b6@levels.sait.edu.au> <777@caslon.cs.arizona.edu> <87999@tut.cis.ohio-state.edu>
Sender: nnews@cs.ed.ac.uk
Reply-To: mikef@lfcs.ed.ac.uk (Mike Fourman)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U
Lines: 52

In article <87999@tut.cis.ohio-state.edu> William F Ogden <ogden@cis.ohio-state.edu> writes:
>In article <777@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>   ...
>>GJ: Can the tolerance idea get off the starting blocks?

I was hoping it wouldn't, but it has! I was tempted to flame the
original message, I can contain myself no longer... :-/
 
[stuff deleted]

>
>One difficulty in recognizing instances of tolerances in software is that
>we tend to have a fixation on the first setting where we were exposed to
>the notion of tolerance -- namely in the domain of real numbers. There
>it got tangled up with the metric notion of the distance between an
>ideal desired answer and an actual answer.

This analogy certainly colours our thinking. Unfortunately, it makes us
unwittingly think as though outputs must vary _continuously_ with
inputs. For example, small errors in machining a bearing produce only
small deviations from the desired behaviour of a mechanical system.
Unfortunately, digital systems don't behave like this; there is no
guarantee that changing one bit of an executable will only have small
(whatever that may mean) effects on the behaviour of a software system.
In traditional engineering, continuity allows us to derive tolerances
for parts from the tolerances specified for the whole. In digital
systems engineering deriving tolerances for parts from the tolerances
specified for the whole is much harder (it amounts to formal program
development).
[stuff deleted]

>The better perspective on the problem is that program specifications
>generally take the form of a relation between input values and output
>values rather than always being a function. 

Of course this is correct - but formal logic, the calculus for deriving
specifications of parts from the desired specification of the whole, is
(currently?) less tractable than real analysis.

[stuff deleted]

>So I suggest that if we bothered to specify our current software (provided
>of course we didn't over specify it), we would find tolerances to be
>quite common -- even leaving numerical analysis aside.

Yes, the question is, "Can we handle them scientifically?"

--
Prof. Michael P. Fourman                     email        mikef@lfcs.ed.ac.uk
Dept. of Computer Science                    'PHONE (+44) (0)31-650 5198 (sec)
JCMB, King's Buildings, Mayfield Road,              (+44) (0)31-650 5197
Edinburgh EH9 3JZ, Scotland, UK                 FAX (+44) (0)31 667 7209