newscriptvar_no=27;

/* slide html pages */
execute("slide9 is "//pres_parsehtml("<h1>Introducing Empirical Modelling</h1>





<b>Semantic relations</b>

<p>The first display takes the form of a visual pun.</p>

<p>This is set up by interpreting the definitions that define the two <b>openshapes</b> <code>cabinet</code> and <code>led</code>, as specified in the file <code>eight.d</code> listed on the two slides immediately following:

</p>
<script>include(\"eight.d\");</script>
<p>In the display, the shapes on the left and right are respectively defined by the <b>openshape</b> observables called <code>cabinet</code> and <code>led</code>.</p>

<p>As a superficial inspection of the definitions of these <b>openshapes</b> shows, they are built up out of entirely different observables.</p>")//";");

execute("slide10 is "//pres_parsehtml("<b>
The contents of the file \"eight.d\" ... specifying a filing cabinet in floorplan:
</b>
<pre>
%donald
openshape cabinet
within cabinet {
    int     width, length	# the size of the filing cabinet
    point   NW, NE, SW, SE	# the 4 corners of the filing cabinet
    line    N, S, E, W		# the 4 edges of the filing cabinet

    N = [NW, NE]
    S = [SW, SE]
    W = [NW, SW]
    E = [NE, SE]

    width, length = 300, 300

    SW = {600, 200}
    SE = SW + {width, 0}	# the other 3 corners are ...
    NW = SW + {0, length}	# ... relative to SW corner
    NE = NW + {width, 0}	#

    ##### cabinet/drawer #####

    openshape drawer		# the filing cabinet has a drawer
    within drawer {
        real    open		# 1 = open; 0 = close
        real    length		# the length of the drawer
        line    N, S, W, E	# the 4 edges of the drawer

	length = ~/length * open
	open = 1.0		# the drawer is opened initially

        N = [~/NW + {0, length}, ~/NE + {0, length}]
        S = [~/NW, ~/NE]
        W = [~/NW + {0, length}, ~/NW]
        E = [~/NE + {0, length}, ~/NE]
    }
}
</pre>")//";");

execute("slide11 is "//pres_parsehtml("<b>
The contents of the file \"eight.d\" ... specifying an LED digit:
</b>
<pre>
openshape led
within led {
    int	digit
    point p1, p2, p3, p4, p5, p6		# 6 points
    line l1, l2, l3, l4, l5, l6, l7		# 7 segments
    boolean on1, on2, on3, on4, on5, on6, on7	# status of the 7 segments

    digit = 8		# initially display all segments

    p1 = {100, 800}
    p2 = {100, 500}
    p3 = {100, 200}
    p4 = {400, 800}
    p5 = {400, 500}
    p6 = {400, 200}

    on1 = digit != 1 && digit != 4
    on2 = digit != 0 && digit != 1 && digit != 7
    on3 = digit != 1 && digit != 4 && digit != 7
    on4 = (digit == 0 || digit >= 4) && digit != 7
    on5 = digit == 0 || digit == 2 || digit == 6 || digit == 8
    on6 = digit != 5 && digit != 6
    on7 = digit != 2

    l1 = if on1 then [p1, p4] else [p1, p1]
    l2 = if on2 then [p2, p5] else [p2, p2]
    l3 = if on3 then [p3, p6] else [p3, p3]
    l4 = if on4 then [p1, p2] else [p1, p1]
    l5 = if on5 then [p2, p3] else [p2, p2]
    l6 = if on6 then [p4, p5] else [p4, p4]
    l7 = if on7 then [p5, p6] else [p5, p5]
}
</pre>")//";");

execute("slide12 is "//pres_parsehtml("<p>Both shapes are made up of a family of observables that are linked by a set of definitions.

Such a family defines a state that supports a variety of interactions that are always open for exploration.

A typical interaction takes the form of a redefinition of an observable.</p>



<b>Examples</b>

<p>In the cabinet, redefining the value of the observable <code>open</code> to a value between 0 and 1 opens the drawer to a different extent:</p>
<script>%donald

within cabinet {

	within drawer {

		open = 0.5

	}

}</script>
<p>In the LED display, setting the value of the observable <code>digit</code> determines the digit displayed:</p>
<script>%donald

within led {

	digit = 5

}</script>
</p>")//";");

execute("slide13 is "//pres_parsehtml("<b>Features of the model</b>

<ul>

<li>The propagation of change via dependency ensures that redefining the single observable <code>open</code> changes many other observables in a conceptually simultaneous atomic fashion.</li>

<li>A redefinition can be undone, so that the original state can be restored by reloading the initial file:
<script>include(\"eight.d\");</script>
</li>

<li>All sorts of other redefinitions are possible, and are potentially interesting subject to being interpretable. Consider for instance:
<script>%donald

within cabinet {

	width = 250

}</script>

<script>%donald

within led {

	digit = 10

}</script>

<script>%eden

_led_digit is numx % 10;

numx = 13;</script>
</li>
</ul>")//";");

execute("slide14 is "//pres_parsehtml("<b>\"Composition\"</b>

<p>The LED and the filing cabinet plan are already 'composed' in so far as they participate in the same script. [They are <i>conjoined</i> in one experience.]</p>

<p>They can be viewed as independent components in that there is no dependency between the observables.</p>

<p>We can connect them by a dependency - for instance making the extent to which the drawer is open depend on the digit in the LED display:</p>
<script>%eden

_cabinet_drawer_open is _led_digit * 0.1;</script>
<p>Can exercise the script by redefining <code>digit</code>.</p>
<script>_led_digit = 7;</script>
<p>The match between the observables that make up the drawer and a real drawer is poor. For instance, I can't \"pull the drawer right out\".</p>
<script>_led_digit = 11;</script>
")//";");

execute("slide15 is "//pres_parsehtml("<p>I first attempt to fix this by modelling the back of the drawer more faithfully:<p>
<script>%donald

within cabinet {

   within drawer {

      S = [~/NW-{0, length*(1-open)},~/NE-{0, length*(1-open)}]

   }

}



%eden

A_cabinet_drawer_S = \"linestyle=dotted\";</script>
<p>I then notice that the sides of the drawer aren't correctly connected:</p>
<script>%donald

within cabinet {

   within drawer {

      S = [~/NW - {0, length * (1-open)}, ~/NE - {0, length * (1-open)}]

      W = [~/NW + {0, length}, ~/NW - {0, length * (1-open)}]

      E = [~/NE + {0, length}, ~/NE - {0, length * (1-open)}]

   }

}</script>
<p>It now looks as if I can \"pull the drawer right out\".</p>")//";");

execute("slide16 is "//pres_parsehtml("<b>From manual to automated redefinition ...</b>



<p>It is now natural to trace a sequence of redefinitions of <code>digit</code> such as correspond to shutting the drawer:</p>
<script>for (i=9; i>=0; i--) {

	_led_digit = i;

	eager();

}</script>
<p>This animates much too fast!</p>

<p>A much better paced animation ('empirically determined') turns out to be:</p>
<script>for (i=9999; i>=0; i--) {

	_led_digit = i / 1000;

	eager();

}</script>
</p>
<p>But it clearly doesn't work! The drawer gets appears to get shorter and shorter as it closes ...</p>")//";");

execute("slide17 is "//pres_parsehtml("<p>

I initially suppose that the problem will be resolved by making sure that the edges W and E of the drawer are of length <code>length</code> and locating the front of the drawer appropriately:</p>
<script>%donald

within cabinet {

   within drawer {

     S = [~/NW - {0, length * (1-open)}, ~/NE - {0, length * (1-open)}]

     W = [~/NW + {0, length * open}, ~/NW - {0, length * (1-open)}]

     E = [~/NE + {0, length * open}, ~/NE - {0, length * (1-open)}]

     N = [~/NW + {0, length * open}, ~/NE + {0, length * open}]

   }

}</script>
<p>Finally I realise that the problem is with the definition of the length of the drawer itself, which changes according to how far the drawer is open. This is fixed by:</p>
<script>%donald

within cabinet {

	within drawer {

			length = ~/length*1.0

 	}

}</script>
<p>... where the \"<code>length*1.0</code>\" circumvents a type clash.</p>")//";");

execute("slide18 is "//pres_parsehtml("<font color=\"#4444FF\">

<h2>Commentary on the digit-cabinet presentation</h2>

<p>

The following discussion of the digit-cabinet presentation was partly motivated by Michael Jackson's reflections in a talk given to the BCS FACS group in February 2007 on <i>What Can We Expect From Program Verification?</i>. It aims to highlight respects in which Empirical Modelling relates to the agenda raised in his book: <i>Problem Frames: Analyzing and Structuring Software Development Problems</i>, Addison-Wesley 2000.

</p>

<ul>

<li><b>More about the semantics</b>

<p>Jackson refers to a distinction between \"analogic\" and \"analytic\" models (see p12-13).

</p>

</li>

<li>

<b>Acknowledging the incalculable complexity of engineering practice</b>

<p>Jackson echoes Ferguson's concern on this theme (see page xv).</p>

</li>

<li><b>The term 'model'</b>

<p>Jackson recognises the ambiguity of the term <i>model</i> (p12-15, p346).</p>

</li>

<li><b>The role of composition</b>

<p>Jackson stresses the importance of postponing composition (p344).

</p>

</li>

<li>

<b>Procedural aspects and their interpretation</b>

<p>The relationship between state and behaviour is particularly subtle in EM.

</p>

</li>



</ul>")//";");

execute("slide19 is "//pres_parsehtml("<font color=\"4444FF\">
<h3>More about the semantics</h3>
<p>
Two different kinds of semantic relation are represented in the two component figures.

<ul>
<li>The interpretation of the filing cabinet is physically mediated through a similarity in shape and potential dispositions (\"analogic\").</li>

<li>
The digit has a conventional interpretation that is not directly mediated through transformations of its shape (\"analytic\").
</li>
</ul>

<p>The experience of interacting with a real filing cabinet, and the experience of interacting with the filing cabinet plan projection are conjoined in the mind of the modeller.")//";");

execute("slide20 is "//pres_parsehtml("<font color=\"#4444FF\">
<h3>Reflecting the \"incalculable complexity of engineering practice\"</h3>

<p>
<hr>

Eugene Ferguson, <i>Engineering in the Mind's Eye</i>, MIT Press, 1992, p.168:</p>

<blockquote>The  real  problem  of  engineering  education  is  the implicit  acceptance  of  the  notion  that  high-status analytical  courses  are  superior  to  those  that encourage the student to develop an intuitive 'feel' for  the <b>incalculable complexity</b>  of  engineering practice in the real world.</blockquote>
<hr>

<p>
The way in which changes to observables are linked in atomic interactions is crucial to the interpretation of the cabinet and the digit.

There are a whole variety of other atomic interactions afforded by the families of observables and dependencies associated with the cabinet and the digit. They form an open-ended family of possible redefinitions.
</p>

<p>
The extent to which particular instances of these are/aren't interpretable reflects the \"incalculable complexity\" of the meanings of these geometric figures. Consider for instance making the width of the cabinet or the LED very small, or making two vertices of the cabinet plan or LED coincident, and how these actions might be interpreted.

</p>")//";");

execute("slide21 is "//pres_parsehtml("<font color=\"#4444FF\">
<h3>About the term \"model\"</h3>

<p>
Note that speaking of the plan as a \"model\" of a filing cabinet presumes a more constrained relationship than is being assumed in general. It wouldn't normally be appropriate to think of changing the width of an actual filing cabinet, let alone making its cross-section triangular. It's only when we become familiar with interacting and interpreting computer artefacts like the plan and the digit in ritualised ways that it becomes appropriate to invoke the idea of serving as a \"model\". The word 'construal', borrowed from David Gooding is generally more apt.
</p>
<p>
There is a neutrality in the kind of agency and interpretation that is being invoked at all times. In the modeller's mind, the LED and the cabinet can be seen as disjoint or as conjoined, just as in everyday experience I may apprehend objects of both kinds in one scene (as when painting a picture or taking a photograph) or concentrate on one to the exclusion of the other.
</p>
<p>
Having ill-defined borders between ill-defined components means that the modelling activity can simultaneously address engineering the components and their composition. There are shades of the Chinese notion of <i>shi</i> - creating and exploiting favourable dispositions - in this holistic approach.
</p>")//";");

execute("slide22 is "//pres_parsehtml("<font color=\"4444FF\">

<h3>How EM deals with composition</h3>


<p>
Introducing dependencies to connect observables from different components is a form of composition. The primary emphasis is always on bringing things together \"in immediate experience\", not on combining abstract processes and behaviours. The first concern is for how introducing additional dependencies enhances the interpretative and exploratory possibilities. (Cf. the semantic problems associated with object composition that have been identified e.g. by David Bowers.) Only when experience of interaction identifies an 'objective' external perspective for agents and components is it appropriate to conceive the conjunction as resembling <i>a system</i>.
</p>

<p>
Note that in my attempts to enhance the conjunction between the cabinet plan and an actual cabinet, inconsistencies become exposed. The evolving family of dependencies accommodates nonsense in this way, and supports \"errors of interpretation\" on my part. As the experimentation with the drawer comes to resemble interaction with an actual drawer more closely, the semantic relation becomes more potent. It is not binary nor closed as in logic. Should I really have regarded the original cabinet plan as a drawer at all, seeing as it merely squashes down onto the cabinet, rather moving into and out of it?
</p>")//";");

execute("slide23 is "//pres_parsehtml("<font color=\"4444FF\">

<h3>Procedural aspects and their interpretation</h3>

<p>
The way in which the LED \"counts down\" as the drawer closes is indicative of the kind of interaction that informs a fundamentally experiential interpretation of the LED symbol as a digit. There is no boundary around the possible interactions of this nature that might be significant in appreciating its meaning: for instance, its physical size would be significant if it were part of a clock on a railway platform. The haze of possible <i>as yet unspecified</i> interactions and interpretations surrounding an artefact is an essential part of its informal semantics.
</p>

<p>
Is the speed of the closing of the drawer to do with the perception of the modeller, or the qualities of the physical cabinet? (Can introduce clocks to give this greater authenticity.) The interactive characteristics of the computer artefact are just as significant a part of the experience as the interactions with its \"referent\" - or mere \"external experient\". Fixing the typing for the <code>length</code> observables takes place conceptually in the same space as \"creating a more authentic physical representation of the drawer\".
</p>
<p>
There is an ambiguity in interpreting procedural ingredients defined through iteration etc, which may be intended to execute <i>as if</i> indivisibly, at speeds beyond human perception, or (as in the shutting of the cabinet drawer) in such a way as to expose intermediate states (whence the <code>eager()</code>).
</p>")//";");

execute("slide24 is "//pres_parsehtml("<font color=\"4444FF\">
<h3>About the EM Presentation Environment</h3>
<p>
The <b>Presentation Environment</b> itself is a physical artefact that is subject to precisely the same kind of open and evolving interpretation. Though it uses far more complex technical features of the EDEN interpreter (see the underlying <code>tkeden</code> interface through which the environment was constructed by Antony Harfield), it is still expressed by a family of observables and dependencies with which the model-maker can interact freely in many different agent roles.
</p>")//";");

pres_slidecount=24;
pres_slides=["slide9","slide10","slide11","slide12","slide13","slide14","slide15","slide16","slide17","slide18","slide19","slide20","slide21","slide22","slide23","slide24"];
pres_currentslideno=1;
