Return-Path:
Return-Path: <john.harrison-request@uk.ac.cam.cl>
Received: from nsf.ac.uk by swan.cl.cam.ac.uk via JANET
          with NIFTP to fgate (PP) id <8965-0@swan.cl.cam.ac.uk>;
          Sat, 22 Jun 1991 01:32:21 +0100
Received: from vax.nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
          with SMTP inbound id <24747-67@sun2.nsfnet-relay.ac.uk>;
          Sat, 22 Jun 1991 00:03:28 +0100
Received: from [129.101.100.20] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP
          id aa21829; 21 Jun 91 23:23 BST
Received: from relay1.UU.NET by ted.cs.uidaho.edu (15.11/1.34) id AA08121;
          Fri, 21 Jun 91 15:15:24 pdt
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET
          with SMTP (5.61/UUNET-internet-primary) id AA13394;
          Fri, 21 Jun 91 18:17:36 -0400
Received: from inmos-c.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail)
          id 181651.17476; Fri, 21 Jun 1991 18:16:51 EDT
Received: from brwbf.inmos.co.uk by inmos-c.inmos.com with DNI-MTP [1.1]
          id brwbf-4936; Fri, 21 Jun 91 03:37:09 MDT
Received: from ganymede.inmos.co.uk by brwbf.inmos.co.uk;
          Fri, 21 Jun 91 10:40:25 BST
Received: from frogland.inmos.co.uk by ganymede.inmos.co.uk;
          Fri, 21 Jun 91 10:36:35 BST
From: David Shepherd <des@com.inmos>
Message-Id: <16345.9106210936@frogland.inmos.co.uk>
Subject: Re: select
To: sandy@com.tis (Sandy Murphy)
Date: Fri, 21 Jun 91 10:36:25 BST
Cc: info-hol@edu.uidaho.cs.ted (info-hol mailing list)
In-Reply-To: <9106202358.AA25006@TIS.COM>; from "Sandy Murphy" at Jun 20, 91 7:58 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: des@com.inmos.inmos-c

Sandy Murphy has said:
> Many math algorithms have a statement in them that denotes a choice to
> be made.  Something like: take any item X with the property P.  The
> specific item is not important, just the fact that it has property P.
> Using the @ function works fine in specifying such an algorithm, and you
> can go on to prove useful theorems about the algorithm.
>
> I believe that it is not possible to show that the function f correctly
> implements the @ function, given the usual meaning of "correctly
> implements".  (@x.Px) denotes some particular but unspecified x.  The
> usual meaning of "correctly implements" is that every state change in
> the implementation must be an allowed state change in the algorithm
> (this is an over simplification, but OK for now).  There is no way to
> show that the state change made by f is the same as the one made by @ --
> no way to show that f chooses the same x as @.

this is a simple misunderstanding about @ which mosy of us probably make
at first ... @x.P(x) is has a fixed value (given P) and it really an
implementation orientated object (i.e. the spec says use any x such that
.. so here's one that fits).

> I have concluded that @ is the wrong thing to use in specifying an
> algorithm, where your goal is to prove an implementation.

perhaps the problem is that your trying to specify the algorithm as a
function where, due to the choice of X, it is a relation at that level?

e.g. suppose your algorithm takes a value x and adds an odd number to
it. then the specification could be

ALG_SPEC x x' = ? y. IS_ODD y /\ (x' = x+y)

then a valid implmentation would be

f x = x + (@y.IS_ODD y)

and you could prove

! x. ALG_SPEC x (f x)



--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 529
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
                "pugh,  pugh,  barney mcgrew, cuthbert,  dibble,  grubb !"

