Adding the Long Term Store

We have seen that the Short Term Store alone can generate a respectable recency effect. However, to produce a primacy effect too, we need to add two more components: a Long-Term Store (LTS), which should be a Propositional Buffer, and a Rehearsal Process. The Rehearsal process should be able to read from the STS, and write to the LTS. Input/Output should be able to read LTS. Given what you've learned about editing box-arrow diagrams in the previous section, you should be able to modify the old diagram to produce such an arrangement, so go ahead and do it. Feel free to rearrange the boxes to suit your taste -- you'll find that the arrows follow them around. It should end up looking roughly like this:

Next we need to make the Rehearsal process actually do something. Recall that its purpose is to take elements from STS and transfer them to LTS, and that it is capacity-limited. So open the Rehearsal Process window, and create a new rule in the "Initial Contents" view. Unlike the previous rules we have encountered, this one is not triggered -- the idea is that it is supposed to operate autonomously. However, the fact that it is capacity-limited means that we must restrict its firing somehow, so check the "Rule fires once per Cycle" box. Now the rule must read an item from STS, and add it to LTS, so as with the recall rule, we need a match condition which reads a word from STS. Finally the action should be an "Add" operation, to add the word to LTS. It should end up looking like this:

Now if you switch to the LTS box, "Current Contents" view, initialise and single-step through the model using the "Step" button, after a few steps you will see words accumulating in the LTS. But if you run a trial at this point, you will soon discover that it never stops. (Use the "Stop execution" button to terminate such runaway execution.) This is because the rehearsal rule is always able to fire, whatever else has happened. An ad hoc solution to this problem is to draw a "Send" arrow from the Input/Output box to the Rehearsal box, and add a new rule to Input/Output, so that it looks like this:

We will send a special stop message via this arrow to the rehearsal process whenever the recall phase of the trial starts. Create an appropriate triggered rule in the Input/Output box. The rule should have recall as its trigger and "send stop to Rehearsal" as its only action. (As a somewhat advanced exercise, find a principled solution to the problem of halting execution after recall.)

While we're in the Input/Output box, we need to modify the recall procedure to recall from both memory stores. First of all, we must define a Condition (actually a piece of pure Prolog), with two clauses, each of which reads from a different store. So, select "Condition Definition" from the "Insert" menu, and a new window will open; this is the Condition Editor. First of all, you should change the contents of the "Condition Name" field to a name of your choice. (Remember that you shouldn't use capital letters here.) We'll use the name recall. Then change the value in the "Number of Arguments" field to 1 -- this means that the condition takes a single argument -- and click the "Apply Changes" button.

Now select "New Clause" from the "Add Condition" menu, and a new entry will appear in the "Conditions" section of the window. Click on the new entries name (recall, in this example). A red box will highlight the clause. Now select "match" from the "Add Condition" menu. A new "match" subcondition will appear -- you should set it to read a Word from STS. Next type Word in the argument field in the head of the clause -- this variable shares the value of the word read from the buffer, and passes it up to the recall rule. Next, from the "Add Condition" menu, select "New clause" again. Now do it again, except this time read a Word from LTS instead of STS. In the end it should look like this:

Close the Condition Editor window. The condition that we have just defined states two ways in which a word can be recalled -- it can be recalled if it is in STS, and it can be recalled if it is in LTS. We must now adjust our recall rule to use this defined condition. Go to the Input/Output window and double-click on the main recall rule; a rule editor window will open. Click on the words "is in" in the Conditions part of the window (to select the "match" condition). A red outline box will appear to indicate the selection. Now pull down the "Add Condition" menu, and navigate to the "Prolog" submenu. You should see an entry for recall/1 (or whatever you called the recall condition). Select this, and it should appear after the match condition in the main rule editor window. Type Word in the argument field, and then delete the match condition (using "Delete Current Condition" on the "Rule Editor" menu). Close the rule editor window. By now the Input/Output box's "Current Contents" view should look like this:

At this point you can try running the model, while you monitor the graph output. If you run 20 or more trials, it should become clear from the graph display that there is now a Primacy effect as well as a Recency effect. We will improve on this behaviour in the next section, but for now you can consider the following questions:

  1. You should be able to account for the Primacy Effect on the basis of the considerations in the introduction. What's going on?
  2. If you monitor the Input/Output box's "Messages" view, you'll see that the model sometimes recalls the same word twice in the same trial. Why is this?
  3. The serial position curve still doesn't look like the one in the introduction. Try to characterise the difference. Can you account for it?