Lab 6: Using Cadence and EDEN together
Orientation
In this lab, you will learn how you can use Cadence in conjunction with EDEN.
To set up the basic environment, you first invoke Cadence using
~empublic/bin/cadence
then introduce the EDEN module to the Cadence environment by entering the following command in the DASM Input window:
%include "eden/eden.dasm";
The result is a hybrid environment in which you can interact via the Cadence IDE and the EDEN Input Window. Initially, observables in Cadence and EDEN are entirely separate. This lab will demonstrate ways in which it is possible to link Cadence and EDEN so that some observables are shared.
Sharing of observables has a number of advantages. Cadence supplies mechanisms that address deficiencies of EDEN where large families of similar definitions have to be created, as is the case in the Sudoku model discussed in Lab 1. It also affords more elegant and expressive ways to organise contexts and to introduce process-like observables. EDEN provides a way to handle input and output and to inject agency into Cadence models without having to use the more sophisticated techniques illustrated in the WGD.
In this lab, these features will be illustrated with rather simple and contrived examples. The mechanisms introduced can be applied more generally and may be seen to best advantage in developing more complex models.
Exercise 0: Communication between Cadence and EDEN
There are two types of shared observable that we use in communicating between Cadence and EDEN. The terms we use for these reflect a classification of observables relative to agents that wil be discussed later in the module. Within the Cadence root context there is a subcontext called eden. You can define new contexts within the eden subcontext to contain (Cadence) observables whose values are determined by EDEN (called EDEN "handles") and to contain (Cadence) observables whose current values are known to EDEN (called EDEN "oracles"). You should first explore these communication mechanisms experimentally as follows:
a. Set up a context in Cadence to contain EDEN handles by entering the following code into the DASM input window:
.eden testH = (new
type = Handle
)
Now observe the effect of defining the observable testH::x in EDEN by monitoring the testH context in the Cadence IDE browser. Note how this EDEN observable has a counterpart in the context .eden testH
b. Set up an oracle for EDEN by entering the following code into the DASM input window:
.eden testO = (new
type = Oracle
a = 1
)
Now monitor the value of the observable testO::a in EDEN as you redefine the value of the observable a in Cadence.
Exercise 1: Constructing the WordGame model
The WordGame model illustrates how the communication between EDEN and Cadence can be exploited. It sets up an environment to support interaction resembling that in the two player game Mastermind.
The essential principle is that one player chooses a four letter word (the 'target'), and the other player guesses the word (the 'guess'). In response to each guess, the first player gives feedback in the form of a display which comprises up to four black or red coloured panels:
- A black panel is included for every letter in the guess that is the same as the letter in the corresponding location of the target.
- A red panel is included for every letter in the guess that matches a letter not in the same location in the target.
The panel display is ordered linearly in such a way that black panels appear to the left of red panels. In this exercise, the role of the second player is automated using dependencies.
A simple but verbose way to construct the model
- Step 1: Define an observational context @wordgame in Cadence. Place two observables target and guess into this context.
- Step 2: Define EDEN handles in the subcontext called words of .eden in Cadence. Set up definitions in Cadence so that assigning four letter words to words::target and words::guess in EDEN sets @wordgame target and @wordgame guess in Cadence.
- Step 3: Define a subcontext match in @wordgame and define sixteen boolean observables 11, 12, ..., 14, 21, 22, ..., 24, ...., 44 in match so that @wordgame match 34 is true if and only if the third character in the target matches the fourth character in the guess etc.
- Step 4: Define observables a11, a12, ..., a14, a21, a22, ..., a24, ...., a44 of @wordgame so that @wordgame match a34 is 1 if and only if @wordgame match 34 is true.
- Step 5: Define observables numsame, numcomm, and nummatch in the context @wordgame that respectively represent: the number of instances where a character in the guess matches the character in the same position in the target; the number of instances where a character in the guess matches a character in a different position in the target; and the total number of matches.
- Step 6: Define a subcontext @colsig of @wordgame to record the colours col1, col2, col3, col4 of the four panels in the panel display. Define the observables col1, col2, col3, col4 as "black", "red" or "white" in accordance with the rules of WordGame set out above (white is to be interpreted as "not displayed").
- Step 7: Set up a panel of four windows in Scout so that their background colours can be set to different colours by assigning appropriate strings to EDEN observables col1, col2, col3, col4.
- Step 8: Set up EDEN oracles in a subcontext colsig within .eden in Cadence and connect the values of col1, col2, col3, col4 to these oracles in such a way that the Scout panel displays the appropriate response to each particular assignment to wordgame::target and wordgame::guess in EDEN.
It is a good idea to try to follow through these steps without assistance so that you become more familiar with Cadence syntax. If you need more guidance for steps 3-6, you can consult the skeleton definitions for the simple version of the Wordgame model.
A more appropriate way to define the internal model in Cadence
Explicit definition of the 16 boolean observables at Step 3 (likewise Step 4) leads to much repetition. Whilst there are some advantages to defining the internal model using Cadence rather than EDEN even when explicit definitions are used, cloning offers a more powerful - and scaleable - mechanism for achieving the same result. The boolean observables that result from matching the first character of the target with each of the four characters in the guess, and the counterparts of the observables defined at Step 4, can be defined within a subcontext match 1 of @wordgame as follows:
@wordgame match 1 = (new);
@wordgame match 1
i=1
%deep 1 = (new
i = 1
c is { @wordgame target (..i -1 ) == (@wordgame guess (.i = 1))}
a is { if (.c) {1} else {0}}
)
%deep 2 = (new union (@wordgame match 1 1) i = 2)
....
)
- subject to your filling in the missing definitions indicated by the "...".
Figure out how the above definition works, then use @wordgame match 1 as a prototype from which to derive definitions for @wordgame match 2 etc. You can then complete the internal model by framing definitions for the observables numsame, numcomm, and nummatch as characterised at Step 5 above.
An extension of this cloning technique might be used to generate the definitions of the four windows that make up the panel in the Scout display. For this purpose, it is useful to be aware of the facility for executing EDEN strings that represent valid EDEN input using the execute() procedure. As a simple example:
%eden
execute("a is b+c;\n b is 2*c;\n c=23;");
has the same effect as entering the three definitions specified in the string given as an argument to execute() via the Input Window. The same principle can be used to generate Scout windows suitably encoded as strings of the form "%scout\n ..." that can be dependent on the value of other observables.
The WordGame model is so small that the use of cloning techniques doesn't abbreviate the definition process very significantly, but these techniques are much more effective for larger models.
Exercise 2: Linking the Stargate and cartoon Stargate models
The WordGame model illustrates the benefits of using Cadence in managing observational contexts. Another application of Cadence is in the use of process-like observables that can then feed values into an EDEN model for animation purposes. In the directory ~empublic/teaching/cs405/lab6 you can find the scripts for the Donald cartoon Stargate models presented in an earlier lecture. As a second exercise, you should be able to link the animation of the Cadence Stargate model introduced in Lab 1 to that of the Donald cartoon Stargate by making use of the communication mechanisms linking Cadence and EDEN.