On-line Soar Tutorial Version 2
Last revised 8/III/96

		[Quick HT]	    [Quick Analogy]

Soar is a production system often used in writing artificial intelligence (AI) programs, but it is also often used for cognitive modelling.

This document aims to be a completely self-contained online introductory tutorial of Soar with an emphasis on cognitive modelling. We will pay some heed to the AI and programming aspects of Soar, as we must -- as a cognitive modelling theory Soar proposes that intelligence consists of a set of mechanisms that do not change across tasks, that is, the architecture, and that knowledge of how to perform tasks is also necessary -- hence intelligence has aspects of being programmable. What this means and how we go about doing it with Soar is what this tutorial is all about.

The major difference between this tutorial and other Soar materials and other Web documents, is that it is designed to be used with a running Soar. We have included several simple (and some not so simple) exercises to test and further your understanding while reading the tutorial.

This tutorial when presented 'live', takes about 3.5 hours for the hungry-thirsty material and about 3.5 hours for the analogy material. You might plan on spending about that time, including some reading, unless you run into problems with getting Soar installed or a silly syntax bug such as forgetting to close a parenthesis.

If you have any questions, please email one of us -- Frank Ritter, 28 Feb 1996.

Using the tutorial: Details on how to use the Soar tutorial. If you have never seen a hypertext document before then you should click the mouse here before looking at how to use the tutorial.
Soar tutorial based on the hungry-thirsty model: A full Soar tutorial, including exercises to do on a simple Soar model.
Analogy tutorial: A set of more advanced exercises on part of a real world Soar model.

Updates to this tutorial should follow the Soar Tutorial HTML Standards, which can be found as comments at the top of the raw pst.html file.

Richard M. Young
MRC Applied Psychology Unit
15 Chaucer Road
Cambridge CB2 2EF
Richard.Young@mrc-apu.cam.ac.uk

Frank E. Ritter
Psychology and Computer Science Departments
University of Nottingham
Nottingham NG7 2RD
Frank.Ritter@nottingham.ac.uk

Gary Jones
Psychology Department
University of Nottingham
Nottingham NG7 2RD
gaj@psychology.nottingham.ac.uk

If you are viewing this tutorial from diskette rather than from a web site, then it is possible that a more up-to-date version exists. This file is http://www.psychology.nottingham.ac.uk/users/ritter/pst2/pst.html. You can also request the latest copy by writing to one of us stating your current version.

Currently, this tutorial is best viewed in Netscape, but Mosaic is ok too.

Other Soar resources: The Soar FAQ

Hungry-Thirsty Soar Tutorial Version 4

If you are viewing this tutorial from a remote site then you will need to download the Soar code for the exercises. This can be done by viewing the relevant code (which can be accessed from Program listings), and then saving it as a file. This is done in Netscape, for example, by selecting the "File" option, and then choosing "Save As...". You can then save the code you are viewing into your own directory.

Information on how to startup Soar is in Starting up Soar help and referenced later in the tutorial.

Tutorial: The first half of the Psychological Soar Tutorial using the hungry-thirsty model, incorporating pointers to the exercises.
Exercises: Hungry-thirsty tutorial exercises. If you want to go there directly.
Traces: Traces from the hungry-thirsty tutorial exercises.
Program listings: Hungry-thirsty tutorial source code.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were). Introduction to the Soar Cognitive Architecture

Introduction to the Soar Cognitive Architecture

List of topics. Click on one or scroll past to tutorial body.

How to use this tutorial.
Overview of hungry-thirsty model.
Fundamentals of Soar concepts.
Soar as a theoretically constrained architecture.
Soar as a problem space architecture.
Knowledge in Soar.
Default rules. (Including Exercise 1)
Soar at the symbol (programming) level.
Knowledge as production rules.
Representation of working memory elements. (Including Exercise 2)
Preferences and decisions. (Including Exercise 3)
Rule Syntax. (Including Exercises 4 & 5)
Impasses and subgoals.
Kinds of impasse.
Resolving impasses. (Including Exercise 6)
Chunking. (Including Exercise 7)
Rule templates. (Including Exercise 8)
The persistence of knowledge. (Including Exercise 9)
Mapping between Soar and cognition.
Further readings and references.

HT tutorial: Overview of the hungry-thirsty model

We will use a deliberately very simple model to teach the basic concepts in Soar. Suppose you have a robot that can carry out just two actions, EAT and DRINK. Imagine that initially it is both hungry and thirsty, and that its goal is to be not hungry. How can it use its actions to achieve that goal?

The problem is presented to Soar in terms of states. This is done straightforwardly:

Each state has two attributes, one called "hungry" with possible values "yes" or "no", the other called "thirsty" also with values "yes" or "no".
There are two operators which can be applied to the states, EAT and DRINK. EAT can apply to any state with attribute hungry = yes, and yields a new state with attribute hungry = no. Note that when this is applied, the "thirsty" attribute on the new state is the same as on the old state. DRINK can apply to any state with attribute thirsty = yes, and yields a new state with attribute thirsty = no. When this is applied, the "hungry" attribute on the new state is the same as on the old state.
The initial state has both hungry = yes and thirsty = yes.
The goal (or desired state) is to be in any state with hungry = no.

This analysis gets implemented in Soar as a problem space model made up of production rules. We will use the model in the exercises incorporated in the tutorial. Answers for these exercises are also in the tutorial, and should only be viewed once you have completed the relevant exercise.

Back to Table of Contents

Fundamentals of Soar concepts

For a discussion of Soar as a candidate Unified Theory of Cognition (UTC), see Allen Newell's Unified Theories of Cognition (1990). It is important as background, but we will not be explicitly dealing with it in the tutorial, except to note that the book includes arguments and discussion of the virtues of unification:

For coherence in theorising: "It is one mind that minds it all".
For bringing to bear multiple constraints from empirical data.
For reducing the theoretical degrees of freedom.

The intellectual origins of this approach can be found in (among many other sources) the work on Production System architectures from the 1970s onwards -- Newell's 1980 paper on The problem space as a fundamental category of cognition, and his 1982 paper on The knowledge level. Full references for these and other relevant papers are included in the References section of this tutorial.

Back to Table of Contents

Soar as a Theoretically Constrained Cognitive Architecture

As an approximation to a knowledge level architecture, Soar can be thought of as an engine for applying knowledge to situations to yield behaviour.
Soar takes the form of a programmable architecture with theory embedded within it.
Hence, Soar is not usefully regarded as a "programming language", for example, for "implementing" your favourite psychological theory.
Soar is not "programmed" in the usual way. Rather, we want to think of the modeller as performing a "knowledge analysis" of a task, expressing the knowledge in terms of Soar objects and rules, giving those rules to Soar...and seeing what behaviour emerges.
Each individual Soar rule, if "translated into English", should make sense as a piece of task knowledge the agent would plausibly have.

The Soar architecture

A basic overview of the principle components of the Soar architecture:

Back to Table of Contents

Soar as a problem space architecture

In Soar, all behaviour is seen as occuring in a problem space, made up of Goals (G), Problem Spaces (P or PS), States (S) and Operators (O or Op). In earlier versions of Soar these were all explicit choices. In the current NNPSCM Soar (Soar6 or Soar7), the Goal and Problem Space are treated as part of the State. Because of this, the State -- especially when thought of as containing the Goal and Problem Space -- is sometimes referred to as a "Context". In this tutorial, we will continue to use the term "Problem Space" sometimes in a deliberately loose way, to mean the Context.
There can be several problem spaces (i.e., contexts) active at any one time. Each may lack some required knowledge, and be able to provide knowledge to other contexts. The main idea behind splitting knowledge into problem spaces (contexts) is that it reduces the search for information. The idea has also been used as a software design technique because it is a successful way to partition knowledge.
- Within the context there is a current state, that is, the state itself. The current state specifies the position we are currently at. For example, in a blocks world, the state might consist of "block A is on top of block B, and block B is on the table".
- Problem spaces, as such, appear as attributes of a state. This means that various different states may all have the same problem space as an attribute.
- Fluent behaviour consists of a repeated cycle in which an operator is selected, and is applied to the current state to give a new (i.e., modified) current state. This new state will typically be associated with the same problem space as the old state. So in our previous example, we could have applied an operator to move block A to the table, in which case the current state would be that block A and block B are both on the table.
- So, once the situation is set up and running, the main activity of Soar consists of the repeated selection and then application of one operator after another, each application yielding a new state.
- But what happens if something prevents that process from continuing smoothly? For example, perhaps Soar knows of no operators to apply to that state. Or it knows of several, but has no knowledge of how to choose between them? In such cases, Soar encounters an impasse. We will have more to say about impasses later. (If you want to find out about them now, click here and then come back here to continue the tutorial.)
Back to Table of Contents

Knowledge in Soar

No knowledge => No behaviour.
In order to act in a domain, Soar must have knowledge of that domain (either given to it or learned).
It's useful to divide domain knowledge into two categories:
1. Basic problem space knowledge: definitions of the state representation, the "legal move" operators, their applicability conditions and their effects.
2. Control knowledge, which gives guidance on choosing what to do, such as heuristics for solving problems in the domain.
Given just the basic problem space knowledge, Soar can proceed to search using it. But the search will be "unintelligent" (e.g., random or unguided depth first), since by definition it does not have the extra knowledge needed to do intelligent search.
Important basic problem space knowledge centres round the operators: when an operator is applicable, how to apply it, and how to tell when it is done.

Back to Table of Contents

Default rules

Soar comes with a set of default rules that, among other things, provide a minimal, domain-knowledge-free response to each possible type of impasse. Without them, Soar essentially crashes if it hits an impasse for which it has no domain knowledge. With the default rules, it at least survives, either through some abstract planning or default searching for knowledge, or simply waiting with a WAIT operator.
Those minimal default rules can also be seen as playing an important theoretical role. Without them, Soar is really a rather weird kind of production system interpreter. With them, it becomes a problem-solving architecture.
The default rules unfortunately contain a mess of other things: some simple behaviour to indulge in when nothing else is specified; rules to support certain coding conventions; a technique for handling tie impasses; and so on. In this tutorial we will make little use of the default rules, and will not examine them in any detail.
Now try *Exercise 1*, which will show you what Soar does with and without the default rules.

Back to Table of Contents

Soar at the symbol (programming) level

Although we think of Soar as operating conceptually at the problem space level, its behavior is realised by encoding knowledge at the more concrete symbol level. In this tutorial we will mainly concentrate on how to realise the problem space level at the symbol, or programming, level.
At the symbol level, each context has two context slots, one for the state and one for the operator. Note that the problem space associated with the state is represented as an attribute of that state, rather than having an explicit context slot of its own (as was the case in earlier versions of Soar).

The display on the right is in "watch 0 trace format", a term we will return to later on.
Remember in Soar as a problem space architecture, we said that within the problem space there is a current state that gets modified by the application of operators. It is the context slots that tell us at any one time which is the current state for each context (and so which problem space we are in, since it is an attribute of the state), and which operator we are applying.

The Context Stack

Each major cycle in Soar (called a decision cycle, see later) ends with some kind of change to the context stack. If the knowledge available to Soar (i.e., the productions) specifies a unique slot filler (such as the next operator for some context) then that change is made. Otherwise, an impasse arises because the immediately applicable knowledge is insufficient to specify the change. For example, in the current state there may be no operators to apply, or we may not be able to choose between several operators.
You may have noticed this context slot filling behaviour during Exercise 1. Alongside each slot (e.g., S1) will be the name of the assigned state or operator.
Answer to Exercise 1.

Back to Table of Contents

Knowledge as production rules

Knowledge in Soar is encoded in production rules. A rule has conditions on its Left Hand Side (LHS), and actions on the Right Hand Side (RHS):
C --> A.
Two of Soar's memories are of relevance here: the production memory (PM) or long-term memory, permanent knowledge in the form of production rules; and the working memory (WM), temporary information about the situation being dealt with, as a collection of elements (WMEs).
The LHSs of productions test WM for particular patterns of WMEs. Unlike most other production systems, Soar has no syntactic conflict resolution to decide on a single rule to fire at each cycle. Instead, all productions whose conditions are satisfied fire in parallel.
For example, the following rule proposes an operator 'eat' if we are hungry and desire not to be hungry.

;; Propose eat. sp {ht*propose-op*eat (state <s> ^problem-space <p> ^desired <d>) (<p> ^name hungry-thirsty) (<d> ^hungry no) (<s> ^hungry yes) --> (<s> ^operator <o>) (<o> ^name eat)}
Translated into 'English', this rule would be:
```
If   we are in the hungry-thirsty problem space  AND
     we desire to be not hungry  AND
     the current state says we are hungry

then propose an operator to apply to the current state  AND
     call this operator 'eat'
```
The rule firings have the effect of adding elements to WM (as we shall see), so that yet more productions may now have their conditions satisfied. So they fire next, again in parallel. This process of elaboration cycles continues until there are no more productions ready to fire. That is quiescence.

Back to Table of Contents

Representation of working memory elements

Soar uses an attribute-value scheme to represent information in WM. Thus a conceptual object that stands for a large red block might be represented as:

(<x> ^isa block ^colour red ^size large)
All attributes are marked by a ^ (called an up-arrow or caret) and their values directly follow them. Note that the attribute-values do not have to be in any specific order, so we could have put ^isa block last in the list. Attributes can be added to working memory by the application of rules whose conditions have been satisfied.
Attributes commonly have just a single value, though they can have multiple values. However, there are both theoretical and practical reasons for avoiding multiple values whenever possible.
The operator, which is a context slot, is represented as an attribute of a state symbol, though as we shall see (when we come to talk about the decision cycle) the slot gets its value only after quiescence is reached, i.e. when there are no more productions to fire. The context slots (state and operator) always have at most one value.
Within a production rule, symbols like <x> are variables, and so can be used to link one object to another. For example, in the clauses below, <y> is used to reference one object from another:

(<x> ^isa block ^colour red ^size large ^above <y>) (<y> ^isa cylinder ^colour green ^below <x>)
In Soar, each of these variables will be bound to a unique, internally generated identifier (ID) such as x35, which represents the object, though we need not concern ourselves with this since we primarily reference objects through variables such as <s>. However, the ID's appear in the trace (which we will come to later), and can also be used to print objects for inspection.
The variables used for the attribute values do not necessarily have to take the initial letter of the attribute name (such as <o> for the ^operator value), but it will make your productions easier to understand, and hence you should take some care in naming them.
Now try *Exercise 2* in order to familiarise yourself with the hungry-thirsty model.

Back to Table of Contents

Preferences and decisions

Working Memory (non-Context Slots)

We need to look a little more closely at the way rule firings change Working Memory (WM).
First, we look at changes to "ordinary" WM Elements (WME's), that is, ones other than the context slots (state and operator).
With parallel rule firings, it is important that rules are not able to change WM directly, else there could be inconsistencies in WM and faulty knowledge could pre-empt correct knowledge.
So, in Soar, the RHS's of rules do not make changes directly to WM. Instead, they vote for changes to WM by producing preferences.
After each cycle, all the preferences are examined by a decision procedure that makes the actual changes to WM.
This means we have the idea of an elaboration cycle, which is a single round of parallel rule firings, followed by changes to the (non-context) WM:

Context Slots

The most important changes are those to one of the context slots (i.e. S or O). To gather all the available knowledge, Soar runs a sequence of elaboration cycles, firing rules and making changes to WM (which may trigger further rules) until there are no more rules to fire, i.e. until quiescence is reached. Only then does it look at the preferences for the context slots.
So we have the idea of a decision cycle (not to be confused with the decision procedure mentioned above), consisting of a number of elaboration cycles, followed by quiescence, followed by a change to some context slot (or by the creation of a subgoal if the preferences don't uniquely specify a change to the context slots):

Decisions for ordinary WM changes are made at the end of each elaboration cycle.
Decisions for context slot changes are made only after quiescence, which is at the end of each decision cycle.
Soar runs by executing a sequence of decision cycles or elaboration cycles (depending on what command it was given) until told to stop or the number of cycles specified in the command.
We can see how elaboration cycles and decision cycles take place from the example below using run:

Soar> run 1 0: ==>S: S1 Firing default*top-goal*elaborate*state*name*top-goal*top-state Firing ht*propose-space*ht Soar> run 1 Firing ht*propose-op*drink Firing ht*propose-op*eat Soar> run 1 Firing ht*compare*eat*better*drink Soar> run 1 1: O: O2 (name: eat) Soar>
This is a run of the hungry-thirsty model, where we are watching rule firings only. Note that 'r 1' tells Soar to run for one elaboration cycle, which as we can see may complete a decision cycle if quiescence is reached. The decision cycle is denoted by the number alongside it, so we can see that the first decision cycle ('0') was to select a state (with no name associated with it) for the context slot. After this, there are elaboration cycles to vote for which operator should be selected for the empty operator context slot. The second decision cycle ('1') then selects the 'eat' operator to fill the operator context slot, which is about to be applied to the state so that it becomes modified. Such processing will continue until the goal is satisfied, or until every possible manipulation has been made without success, at which point Soar will halt having failed to satisfy the goal.
Now try *Exercise 3*, where you can examine the different detail levels within Soar using commands such as 'watch'.
Answer to Exercise 2.

Back to Table of Contents

Rule Syntax

We now go down yet another level and examine the syntax of the rules.
Consider a rule for the following statement:
"In the blocks world, if one block is on top of another block of a different colour, then propose repainting the lower block to be the same colour as the upper block".
When translated into a Soar model, it looks like this:

sp {blocks*paint*propose (state <s> ^problem-space <p> ^desired <d>) (<p> ^name blocks-world) (<s> ^block <block1> <block2>) (<block1> ^isa block ^colour <col1> ^above <block2>) (<block2> ^isa block ^colour
```
<>
```
<col1>) --> (<s> ^operator <o>) (<o> ^name repaint ^object <block2> ^colour <col1>)}
Many of the basic rule features are shown in this rule:
- sp ("soar production"), followed by the production name.
- Attribute-value pairs, such as ^name blocks-world.
- Conditions of the rule, which appear before the -->, and the actions appearing after. Note that each condition and each action is enclosed in a set of parentheses. For the rule to fire, each condition must be satisfied.
- Variables, such as <s> and <block1>, which denote the state we are in and a block respectively.
- Logic features, such as <> which denotes 'not equal'; that is, the colour of <block2> must not be the same as <block1> for this rule to fire. There are other logic features in Soar, such as:
  - ^colour << red blue >> denotes that the colour attribute should have a value of red or blue.
  - -^colour red denotes that the condition is that there is not a colour attribute with a value of red.
  Further features exist which may be noted in the code for the exercises.
Sometimes the syntax appears to get in the way by being verbose, but with practice rules become easier to read.

Shorthand syntax of rules

There are shorthands for several common constructs. We can just give path names to access local structures. For example, using some of the shorthand available, the above rule begins:

(state <s> ^problem-space.name blocks-world ^block (<block1> ^isa block ...) (<block2> ^isa block ...)) ...
Now try *Exercise 4*, which looks at the effect of altering the initial state, and *Exercise 5*, where you will create a new operator for the model.
Answer to Exercise 3.

Back to Table of Contents

Impasses and sub-goals

When Soar encounters an impasse in context level-1, it sets up a subcontext (or "subgoal") at level-2, which has associated with it a new state, with its own problem space and operators. Note that the operators at level-2 could well depend upon the context at level-1.
The goal of the 2nd level context is to find knowledge sufficient to resolve the higher impasse, allowing processing to resume there. For example, we may not have been able to choose between between two operators, so the level-2 sub-goal may simply try one operator to see if it solves the problem, and if not, tries the other operator.
The processing at level-2 might itself encounter an impasse, set up a subgoal at level-3, and so on. So in general we have a stack of such levels, each generated by an impasse in the level above. Each level is referred to as a context (or goal ), and each context can have its own state, problem space and operators.
For example:

Notice that the architecture's problem solving approach is applied recursively at each level.
Answer to Exercise 4.
Answer to Exercise 5.

Back to Table of Contents

Kinds of impasse

Soar automatically creates subgoals in order to resolve impasses. This is the only way that subgoals get created. (Note, therefore, that production rules never vote directly for states. The only context slot rules vote for is for operators.)
What types of impasses are there? Roughly, for the operator slot, there can be:
- No candidates for the slot ==> a no change impasse.
- Too many, undifferentiable candidates ==> a tie impasse.
- Inconsistency among the preferences (e.g. A > B and B > A) ==> a conflict impasse.
The most common kinds (you're unlikely to meet any others) are:
- No operators ==> a state no change impasse (SNC)
  (perhaps better thought of as an operators zero impasse (OZ)).
- Too many operators ==> an operator tie impasse (OT).
- Insufficient knowledge about what to do with the operator ==> an operator no change impasse (ONC).
Back to Table of Contents

Resolving impasses

Each kind of impasse, for its straightforward resolution, requires a particular kind of knowledge:
- An SNC/OZ needs operator proposal knowledge, which is sought by producing sub-goals to find or construct an operator.
- An OT needs control knowledge, which may be found by selecting each tied operator until one which resolves the sub-goal is applied.
Interestingly, there are three possible reasons for an ONC:
1. Knowledge of how to implement the operator may be lacking, in which case that's what's needed.
2. The preconditions of the operator may not be satisfied, whereby a state must be found whereby the operator can apply (a case which requires operator subgoaling).
3. The operator may be incompletely specified, and need to be augmented.
It should be noted that there are other ways to deal with impasses, such as rejecting one of the context items that gives rise to it.
Now try *Exercise 6*, where you will examine an impasse.

Back to Table of Contents

Chunking

Basics

Soar includes a simple, uniform learning mechanism, called chunking. Whenever a result is returned from an impasse, a new rule is learned connecting the relevant parts of the pre-impasse situation with the result. This means that next time a sufficiently similar situation occurs, the impasse is avoided.

The above diagram shows the WMEs that are created during an impasse, the resolution being the addition of the WME 'R', which solves the sub-goal. An arc between arrows denotes 'AND', so for WME 2 to be created, WME's C and 3 must exist. Notice that R is dependent upon the existence of WME's 3 and 4, so if we work our way back, we find that these elements require A, B and D only. This is why the chunk created will have these in its condition, and R in its action. You may think that C should also be included, since it is required in order for D to be added. However, D already exists at the time the impasse occurs, so it is not necessary to include C.
Chunks are formed when Soar returns a result to a higher context. The RHS is the result. The LHS are things that have been tested by the linked chain of rule firings leading to the result, the set of things that exist in the higher context ("pre-impasse") on which the result depends.
Identifiers are replaced by corresponding variables (and certain other changes are made).

Chunks and types of impasse

Just as each kind of impasse, for its straightforward resolution, requires a particular kind of knowledge, so also it gives rise to a characteristic kind of chunk:
- A SNC/OZ resolved by operator proposal knowledge gives rise to an operator proposal chunk.
- An OT resolved by control knowledge gives rise to a control chunk.
For the three varieties of Operator No Change:
- An ONC resolved by knowledge about how to implement the operator gives rise to operator application chunks.
- An ONC requiring operator subgoaling gives rise to ... don't ask about this case, at least until after you've finished the tutorial!
- An ONC resolved by fleshing out the details of the operator gives rise to operator modification chunks.
Implications

Problem solving and chunking mechanisms are thus tightly intertwined: chunking depends on the problem solving and most problem solving would not work without chunking.
Now we are at the point where, if we can model performance on a task in Soar, we expect to be able to model learning (cf. position in Cognitive Science until just recently).
Even when no chunk is actually built, an internal chunk called a justification is formed. This can happen because learning is turned off, or bottom up (a learning state that only learns from the bottom problem space), or because the chunk is a duplicate of one that already exists, or whatever.
Justifications are needed in order to get persistence right; for example, to provide support (i-support or o-support, which are covered later) within Soar's truth maintenance system.
Now try *Exercise 7* where you will be able to see a chunk being created.
Answer to Exercise 6.

Back to Table of Contents

Rule templates
Writing models in Soar typically does not proceed from scratch. Typically new models are built by copying old models and modifying them. There are also templates for the common actions in a problem space:
- State initialisation.
- State augmentation and problem space proposal.
- For each operator:
  - Proposal. This is so that preferences for operators can be put forward.
  - Implementation. Once an operator is selected, this will fire so that the operator can modify the state in some way. For example, we may eat if the eat operator was selected in the decision cycle.
  - Termination. This tells Soar to reconsider what should be in the operator slot, and therefore means that another decision cycle to fill the context slot is required.
- Return result.
- Goal recognition.
Now try *Exercise 8* where you will create a new problem space to implement an operator.
Answer to Exercise 7.

Back to Table of Contents

The persistence of knowledge

Information in WM is supported by a kind of Truth Maintenance System (TMS). When the conditions of a rule are satisfied, it fires, and produces various preferences. When the conditions become untrue, the rule (instance) is retracted, and the preferences may be retracted too. WMEs supported by those preferences may disappear from WM.
This issue of persistence is potentially complicated and confusing (and a source of subtle bugs). For now, we just take a simple view.
1. Rules that modify the state can be divided into two categories:
  - Elaboration rules, which make explicit information that is already implicit in the state. For example, whenever a block has any ^colour, we might like it also to have (^tinted yes). If it has no ^colour, then we would like it to have (^tinted no). Notice that such rules are monotonic: they add to the state, but they do not modify or destroy information already there.
  - Operator application rules, which change the state from one configuration to another. For example, when we apply the repaint operator, we change the block from its old colour to the new.
2. Information put into WM by elaboration rules is non-sticky . We want the information to disappear from WM as soon as the conditions it depends on no longer hold. Preferences for such information are said to have i-support (i for rule instantiation).
3. Information put into WM by operator application rules is sticky . We want the information to remain even after the conditions that fired the application rules have ceased to hold. Preferences for such information are said to have o-support (o for operator).
Most of the time, with cleanly written rules the issue of persistence takes care of itself, and you do not have to worry about it.
Now try *Exercise 9*, which looks at o-support and i-support.
Answer to Exercise 8.

Back to Table of Contents

Mapping between Soar and cognition

One of the strengths of Soar is that the correspondence between the model and psychology is pinned down, not free floating. Newell explains this in detail in his Unified Theories of Cognition (1990) book. One of the most straightforward ways of achieving this correspondence is in terms of timescales, for example:
- Elaboration cycle ~~10ms, where ~~ means "within a factor of about 3".
- Decision cycle ~~100ms.
- Per-operator time 50-200ms.
Constraints on a unified theory of cognition

Newell explains this topic in detail in his Unified Theories of Cognition (1990) book. A shortened list is provided here.
- Behave flexibly.
- Adaptive (rational, goal-oriented) behaviour.
- Operate in real time.
- Rich, complex, detailed environment ...
- Symbols and abstractions.
- Language, both natural and artificial.
- Learn from environment and experience.
- Acquire capabilities through development.
- Live autonomously within a social environment.
- Self-awareness and a sense of self.
- Be realisable as a neural system.
- Arise through evolution.
You are now ready to move onto other modules in the psychological Soar tutorial. Take a look at the further readings and references that follow, and then go BACK a level or two to find other parts of the tutorial.

Back to Table of Contents

Further readings and references

Soar: Frequently Asked Questions (FAQ's).
Soar home page at Carnegie-Mellon University (CMU).
Soar home page at the University of Southern California.
University of Michigan Soar-group.
Soar Archives.
Laird, J. E., Newell, A., & Rosenbloom, P. S. (1987). Soar: An architecture for general intelligence. Artificial Intelligence, 33(1), 1-64.
Newell, A. (1980b). Reasoning, problem solving and decision processes: The problem space as a fundamental category. In R. Nickerson (Ed.), Attention and Performance VIII Hillsdale, NJ: LEA.
Newell, A. (1982). The knowledge level. Artificial Intelligence, 18, 87-127.
Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.
Newell, A. (1991). Desires and diversions: Carnegie-Mellon University School of Computer Science Distinguished Lecture. Palo Alto, CA: University Communications.
Newell, A. (1992a). Precis of Unified theories of cognition. Behavioural and Brain Sciences, 15, 425-492.
Newell, A. (1992b). Unified theories of cognition and the role of Soar. In J. A. Michon & A. Akyurek (Eds.), Soar: A Cognitive Architecture in Perspective. Dordrecht, The Netherlands: Kluwer Academic Publishers.
Rosenbloom, P. S., Laird, J. E., & Newell, A. (1992). The Soar Papers: Research on Integrated Intelligence. Cambridge, MA: MIT Press.
Waldrop, M. M. (1988a). Soar: A unified theory of cognition? Science, 241, 296-298.
Waldrop, M. M. (1988b). Toward a unified theory of cognition. Science, 241, 27-29.
Soar Manual 6.1.
ACT-R home page.
ACT-R hypercard tutorial.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were). HT tutorial: Exercises
HT tutorial: Exercises

Answers for these exercises are available in the tutorial.

Exercise 1
What Soar does without domain knowledge, and loading the default rules into Soar.

Exercise 2
Loading and running the hungry-thirsty code.

Exercise 3
Using watch and print to examine the models behaviour.

Exercise 4
Changing the initial state and examining preferences.
Examining preferences.

Exercise 5
Adding a third operator, scratch-head.

Exercise 6
Examining an impasse, and checking production mapping.

Exercise 7
Watching how chunks get created.

Exercise 8
An operator no-change impasse and creating an operator implementation problem space to solve it.

Exercise 9
Examine how long rules apply: o-support and i-support.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing PST HT Tutorial Exercise 1 - Without knowledge
HT Tutorial Exercise 1
What Soar does without domain knowledge

You should try running Soar without any knowledge to see what happens. Soar is an architecture, and as such, it takes knowledge to be added to the architecture to generate behaviour.
If you type d 5, which is the command to run Soar for 5 simulation cycles, called decision cycles, nothing really happens (this is also shown in Trace 1). When Soar is started up, it completely lacks any knowledge and just keeps noting this fact.
If you type just d and don't give a limit of decision cycles to run, Soar will run until it reaches a halt operation. This operation is specified in the Unix environment by pressing Control and C together. In MacSoar, you need to hold down the clover (apple) key and type a period (.).

Loading the default rules into Soar

There is a set of rules to provide some simple default behaviour when specific knowledge is lacking called default rules. These provide, for example, for some simple look-ahead search mechanisms, and more intelligent behaviour in the event that no knowledge applies to the current situation (e.g., the wait operator in the top-ps). As the situation changes, internal knowledge may become relevant and the wait operator will be replaced with another more appropriate operator.
Rules are loaded from a full path specification or from Soar's default directory. pwd will print out the default directory; cd will change it. The initial default directory is the one that Soar is started from.
Directories on the Mac start with the disk name, and are separated by a ":". You might typically load files like "Harddrive:MacSoar:ht.s7". From within MacSoar, the command cd "::" moves you up from the current directory. If you only use files from within the folder Soar is in, you won't need these commands.
You should load the default rules, with the following command:
source "default.s7"
Each asterisk that appears indicates that a rule was loaded successfully. Reset Soar using init-soar. Now when you run Soar ahead, it waits for something to happen (this is also shown in Trace 2).

Follow up questions (for homework):
- What will Soar "do" with the Tower of Hanoi?
- How is knowledge organised in Soar?
- How is knowledge represented in Soar?
- Do you want to read the default rules?
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 2 - Run the model
HT Tutorial Exercise 2 - Run the model

Loading and running the hungry-thirsty code

Type the following into Soar (How to startup Soar if you forgot.):
source "ht.s7"
If you now init-soar and type d 2, Soar will run two decision cycles until the problem is solved and then halt. You can then examine the trace (what Soar prints out as it runs), to see what happened (this trace is also shown in Trace 3). Alternatively, you can type d 1, and examine each object as they are selected.
Several of the attributes in this model are traced (such as hungry and thirsty on the state), but there are several that are not. You can examine the problem space elements (and their substructures) in their entirety with p identifier. The identifier of each context element appears in the trace, such as S1, so an example usage would be p s1. This command can be recursively applied to sub-objects, or you can find out how to print them all at once by consulting help p.
If you lose track of how far you have run the model, you can type pgs to Print (the) Goal Stack. The current state is the state that is lowest down in the goal stack. The goal, or desired state, will normally be seen as an attribute of the current state.

Follow up questions
- How is this behaviour different from plain OPS5 or even GPS?
- What happens if you "excise ht*compare*eat*better*drink"?
- Try changing how the selection process works (use user-select).
- How would you extend the model from a single to double conjunct goal? (i.e., be not hungry and not thirsty?).
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 3 - Using watch
HT Tutorial Exercise 3 - Using watch
Using watch and print to examine the models behaviour
There are several levels of built-in trace. So far we have set watch to level 0, which only traces context elements. By manipulating the level, we can see some of the finer level workings of the architecture.
Remove the hungry-thirsty rules, keeping the default ones, by using excise -task, or re-start Soar and load the default rules. Then re-load the original "ht.s7".
Try running the model with the following watch commands. Try them individually, and then together. After each run, make sure you init-soar.
It is worth noting that default rules begin with default*, and hence you should not take too much notice of these when reading through the traces. Such rules begin their conditions with :default also.
The more sporting of you may wish to then examine the rules that fired. You can either examine them in ht.s7, or by printing them out in the running process with the command p . It is possible that some rules contain attributes or features that you are not yet familiar with. These should be covered later in the tutorial.
If you want to trace just one rule firing you can do this by using the pwatch command.
Follow up questions
- What the heck is going on? Can you tell based on these traces?
- Now that you can see all the working memory elements, can you see how the conflict resolution mechanism works in Soar?
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 4 - Eating
HT Tutorial Exercise 4 - Eating

Before altering Soar code, if you are using Word as your editor you may wish to consult PST Mac help.
Note that Soar uses LISP-like comment characters. As you read code you may notice that single line comments are prefaced with semi-colons, and blocks of comments are prefaced with a sharp and bar and end with a bar and sharp. Such material is ignored by Soar.
Changing the initial state

Open the file ht.s7 in your editor, and examine the production rules that make up the eat and drink operators. (Its directory will appear in the link above.) Modify the last clause in ht*propose-space*ht
by cutting the production and then pasting it at the Soar prompt, changing the initial state before hitting return. This will reload the production, overwriting the previous version. Now, when the model is run the drink operator could apply, but doesn't because the desired state has been found, that is, to not be hungry (this is also shown in Trace 4).

Examining preferences

There is a command that summarises the preferences for objects attached to the state.
gives a listing of preferences.
preferences s1 operator
would be a typical version that you might type. You can then run the problem on the four different initial states (yes yes; yes no; no yes; no no) that are possible, examining for yourself the preferences the model has in terms of eating and drinking. You should try this for S1, and another object, such as an operator.

Follow up questions
- Do productions map one-to-one onto operators?
- Do operators map one-to-one onto productions?
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 5 - Scratch
HT Tutorial Exercise 5 - Scratch
Adding a third operator, scratch-head
Create a new file, and in it create a Scratch-Head operator that:
- Is always applicable.
- Has no effect (or virtually no effect) when applied.
Write the four rules by analogy with existing proposal and application rules in ht.s7. You will need:
1. A proposal rule, like ht*propose-op*eat.
2. An application rule, like ht*apply-op*eat.
3. A termination rule, like ht*terminate*eat.
4. A rule that makes it worst (or best!), like ht*compare*eat*better*drink (You can make a unary preference by just deleting the compared object in the existing rule).
If the operator gets selected (e.g., if you make it best), it has to do something (i.e., modify an attribute), or else this will be detected and an operator no-change impasse will be created, so make sure that you include a rule to have it do something.
In order to make this file easy to use and make debugging easier, you will probably want to a put a line in your new file that loads ht.s7 (e.g., source ht.s7). That way, when you load the new operator file, the ht code gets loaded too. Alternatively, you can first load ht.s7 by hand.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 6 - Examine an impasse
HT Tutorial Exercise 6 - Examine an impasse
Examining an impasse

Remove the hungry-thirsty rules, keeping the default ones, by using excise -task, or re-start Soar and load the default rules. Load "ht2.s7" this time. This file has more rules, but less high-level knowledge.
Run the model through the impasse that will appear, and compare your trace with Trace 5.
Do this at various watch levels. If you wish to know which rules will fire, you can use the command ms to find out the current match-set. In order to step at a finer grain through the program, use the run or r command.
In order to understand this impasse, you will have to see the preferences that are available for the operators in S1. You can see the preferences for context slots with the previously covered preferences command.

Checking production mapping

Try out matches selection*evaluate*drink*thirsty when you are in the subgoal, and find out why it doesn't match (the problem is not subtle).
Run ahead a decision cycle and try the command again, to see what's going on. This can be repeated if necessary.

Follow up questions
- What caused the impasse?
- What rule would have prevented the impasse?
- Why is selection*evaluate*drink split into two rules (*thirsty and *not*thirsty)? Why separate the clauses in this way?
Follow up exercise

How can any set of attributes influence behaviour in the selection space? Write a new production(s) that modifies the selection based behaviour so that drinking is preferred if the beverage is 'real-ale'. Then, for your own amusement, modify the productions that create the drink operator to propose an operator that includes beverage Guinness.
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 7 - Watch a chunk
HT Tutorial Exercise 7 - Watch a chunk
Watching how chunks get created

Remove the hungry-thirsty rules, keeping the default ones, by using excise -task, or re-start Soar and load the default rules. Now load (source) "ht2.s7", turn watch the chunk creation trace. (Note that learning is normally turned on when Soar starts up, but we turned it off in the ht.s7 files in order to simplify the model's behaviour earlier.)
Now run the model through the impasse, and compare your trace with Trace 6.
Then init-soar and run through the impasse again, and compare your trace with Trace 7.
You can remove all learnt chunks in order to watch chunks get learned anew by using the excise command.

Follow up questions
- Does the built chunk look familiar?
- What's missing from this chunk that we might have expected to see?
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 8 - Create a PS
HT Tutorial Exercise 8 - Create a PS
Watch an operator no-change impasse

Remove the hungry-thirsty rules, keeping the default rules, by using excise -task, or re-start Soar and load the default rules. Now source "ht2.s7", and
excise ht*apply-op*eat ht*terminate*eat
Now try running the model (for several decision cycles) through a new impasse that will appear, that of an operator no-change. This impasse occurs when an operator has been selected but the operator does not lead to any change to the state. You can compare your trace with Trace 8. This impasse can be seen in very fine detail by setting the watch level to 2.

Creating an operator implementation problem space to solve the impasse
In order to fix this impasse, you will need to write several productions (all straightforward) that create a problem space to implement the operator. Productions will be needed to:
- Create and propose an 'eating' problem space, somewhat like how default*selection*propose*space*selection proposes the selection space (but remove the :default keyword that appears in the production).
- Propose, in this case, an exceedingly simple operator to implement the super-space's operator (eat). You can access the supergoal's state through the superstate. If you print a state, you will see how it keeps track of its superstate. The rule will look somewhat like ht*propose-op*eat.
- Apply the sub-problem space eating operator to the super-state. (like ht*apply*eat, except modify the super-state instead of the state).
When you've loaded and run your code, you should get a chunk that looks a lot like ht*apply-op*eat.
If you are doing this for homework, email the file of code and a trace of it running.
Follow up questions
1. Does chunking just provide speedup learning?
2. Does chunking just provide deductive closure?
3. Could chunking also provide an inductive closure?
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help PST HT Tutorial Exercise 9 - O/I-support
HT Tutorial Exercise 9 - O/I-support

Learning how long rules apply: O-support and I-support

Remove the hungry-thirsty rules, keeping the default ones, by using excise -task, or re-start Soar and load the default rules. Now load "ht.s7" and set the watch level to 0. Now initialise Soar (using init-soar and use pwatch to look at ht*propose-op*eat and ht*apply-op*eat fire.
Now type run 3 to go to where the action starts. Now look around. There are objects that have o-support and objects that have i-support.
preferences s1 operator
will show you objects with i-support.
preferences s1 hungry
will show you values with o-support.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).
Program Listing
PST Soar Help "Simple Analogy" Soar Tutorial Version 3
"Simple Analogy" Soar Tutorial Version 3

If you are viewing this tutorial from a remote site then you may need to download the Soar code for the exercises. This can be done by viewing the relevant code (which can be accessed from Program listings), and saving it as a file. This is done in Netscape, for example, by selecting the "File" option, and then choosing "Save As..." to save the code into your own directory. This code is designed to work with Soar7.
Note that when in Soar you should alter the present working directory to be the one which you downloaded the code to. Information on how to do this is given in Soar help.

Tutorial

The analogy tutorial, incorporating internal pointers to the exercises when appropriate.

Exercises

Analogy tutorial exercises.

Traces

Traces from Analogy tutorial exercises.

Program listings

Analogy tutorial source code.

Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were). PST: Analogy Tutorial
Analogy Tutorial

Table of Contents
- How to use this tutorial.
- What the Analogy model is.
- Models that learn.
- Analogy method: General and specific.
- Problem-Space unpacking.
- Initial ideas: Two of the problem spaces.
- The Perform space (including Exercise 1).
- The Action-Proposal space (including Exercise 2).
- Use Analogy (operator).
- The Use-Analogy space.
- Imagine Task (including Exercise 3).
- Summary of behaviour.
- Interesting aspects of its behaviour (including Exercise 4)
- References.
Back to Table of Contents

What it does

Background

Analogy is a "real" Soar program, for doing deliberate analogy. It is not large, consisting of about 30 rules, but it's part of a serious piece of research:

Rieman, J., Lewis, C., Young, R. M. & Polson, P. G. (1994) "Why is a raven like a writing desk?": Lessons in interface consistency and analogical reasoning from two cognitive architectures. In Proceedings of CHI'94: Human Factors in Computing Systems. 438-444. ACM Press.

Overview

Consider a computer user who has basic Macintosh skills and knows how to launch the Word program on a Mac, but does not know how to launch programs in general. Their task is to launch Cricket Graph.
- If knowing how to launch one program is going to help at all to know how to launch another, there must be some kind of consistency in the interface.
- One of the purposes of this model is to understand more about that notion of consistency.
- Two approaches to accounting for the ability to launch the second program might be:
  1. The user might have learned the general skill from knowing how to launch the first program. Or
  2. The second program might be launched by analogy with the first.
    (This is what we'll explore with the model here.)
Note that the Analogy tutorial incorporates various exercises. Answers for these are also in the tutorial, and should only be viewed once you have completed the relevant exercise.

Back to Table of Contents

Models that learn

Most "user models" just perform, they don't learn. There are a few exceptions, such as TAL (Howes & Young, 1991), EXPL (Lewis, 1988) and EXPLor (Howes & Payne, 1990). The last two use a form of analogy to interpret a sequence of actions.
The Analogy model is one that models the analogy route for the task of launching Cricket Graph, and has been done in both Soar and ACT-R.
Collaborators: John Rieman, Clayton Lewis, Peter Polson, with help from Marita Franzke (all U Colorado at Boulder).

Back to Table of Contents

Analogy Method

There exists a fairly general method for analogy (based on Holyoak, etc.):
- Recall an example task you know how to do, similar in some relevant way to the new task.
- Identify a mapping between the example task and the new task.
- Apply the mapping to the action for the example task to give a candidate action for the new task.
For example,
(launch Word) :: (launch CG) =
(double-click Word icon) :: (double-click CG icon).
A specific, simple version of this is used in our model:
1. If the task involves some Effect on an Object Y,
2. where the Object is of a known Class,
3. and we can recall another member X of that Class,
4. then we try to imagine an action for achieving the Effect on Object X,
5. and if we can do it, we substitute Y for X in the action,
6. and return it as the recommended action.
Back to Table of Contents

Problem Space Unpacking

Soar lends itself to a distinctive style of model development, which we will call problem space unpacking. We will use this technique to explain the analogy model. Like many software methods, it's an iterative technique:
1. Starting with one problem space, we ask what knowledge an agent needs in order to be able to perform some task. We add that knowledge by hand, and try to get a satisfactory running model.
2. We then argue that the agent wouldn't have arrived in the situation with that knowledge already in place. So we ask: What problem could the agent have set itself, solved in a lower space, that would have given rise to the knowledge by chunking?
So on each iteration we effectively push the knowledge down by one level.
As with any software development method, this approach works best if used just as guidance, and applied flexibly.
Back to Table of Contents

Initial ideas

Unpacking the top two Problem Spaces

What ideas do we have about the spaces we might need?
1. The top space is probably a Perform space, that is, a space in which we have only fully automatised behaviour -- behaviour that occurs without any of the uncertainty about what to do that characterises an impasse. Given a task, there will be rules that specify what action to take.
  Those task-action mapping rules (TAM rules) will, of course, be learned by chunking, so the automatised behaviour will not be seen until these chunks are in place.
2. We have a definite idea of the particular method of simple analogy that we are looking for. So somewhere there will be a space in which our six-step method is executed -- a Use-Analogy space.
  Such a multi-step sequence is most naturally thought of as the implementation space for some operator. So we'll expect to see a Use-Analogy operator somewhere, with the implementation space below it.
Back to Table of Contents

The Perform space

So we have the notion of the top space as a Perform space, with automatised task-action mapping rules.
To be definite, suppose that the state has on it a ^task to specify the task, and wants an ^action to specify the corresponding action. Once the action is known, the motor system will carry it out -- that part does not have to be learned.
The mapping from ^task to ^action could be done by an operator, but initially we'll imagine it's just a state-elaboration chunk.
Let's start building a diagram of the different spaces and their relationships:

Now do Exercise 1.

Back to Table of Contents

The Action-Proposal space

When the model starts, the TAM chunks in the Perform space have not yet been learned. So the appropriate ^action for the given ^task will not be known. Hence there will be an impasse -- a State No Change, given our commitments so far -- into a subgoal whose job is to propose an ^action. So we think of it as having an Action-Proposal space.
In this space we'll put knowledge (by hand) about how to launch Word and Draw, assumed known to the agent. But we don't have knowledge about CG (Cricket Graph) or XL (Excel).

Now do Exercise 2.
Answer to Exercise 1.

Back to Table of Contents

Use Analogy (operator)

In the Action-Proposal space, if the task is to launch a program other than the ones we know about (Word, Draw), what do we do? Well, there might be several possible tactics for finding out (e.g. asking someone, ...), but the one we'll focus on is to try using analogy. So we'll propose an operator called Use-Analogy.
That operator is of course the one we had anticipated. So we know that it will impasse into an operator implementation space, where our six-step simple analogy method actually gets applied:

Answer to Exercise 2.

Back to Table of Contents

The Use-Analogy space

In the Use-Analogy space, we implement the six-step analogy method:
1. Recognise that the task involves some effect on some object Y, so that the method is appropriate. Record this by putting (^analogy-method analogy-1) on the state.
2. Get the class of the object. We record it by marking the state e.g. (^object-class program).
3. Recall another member, X, of the same class. We mark the state with (^class-member X).
4. We ask if we know how to achieve the effect with X (more on this later). If we do, we mark the state with an ^imagined-action.
5. In that action, we replace all occurrences of X by Y. That gives us an ^analogised-action.
6. Then we return the ^analogised-action as the recommended ^action on the top state.
Back to Table of Contents

Imagine-Task

Continuing with the problem-space unpacking, there is the crucial issue of how we know "whether we can achieve the effect with X". We would not expect the model to start with a chunk that encodes this knowledge, so where does it come from?
Soar gives us a natural way to discover whether we can do something without having the meta-knowledge beforehand. We simply set up the task in a subgoal, and see what happens. We do this with an Imagine-Task operator, which impasses into an operator implementation space that is very much like the top Perform space, so we can see what action, if any, gets taken:

When we put it all together, and take care of what happens if we don't know how to handle X, we get:

Now do Exercise 3.

Back to Table of Contents

Summary of behaviour

Behaviour 1: Simple Chunk for Word
We assume a user who knows how to launch Word, but not, for example, Cricket Graph.
Presumably in the past the user learned to launch Word by instruction or demonstation, and this knowledge resides in the Propose-Action space.
So, again at some point in the past, the task of launching Word was run, and yielded a chunk that encodes a task-action mapping rule in Perform space:

Now, when that same task is done, the TAM chunk fires:

Behaviour 2: Learning to launch Cricket Graph by analogy
The diagram below simply summarises the way the analogy method works, as we have developed it through the problem-space unpacking.
From the top Perform space, because no action is proposed, the model impasses into the Action-Proposal space. There the Use Analogy operator goes into slot, but to be implemented it impasses into an implementation space, the Use-Analogy space. Most of the work of the analogy method is carried out there, but at the point where the model has to ask itself if it knows how to launch some other program, perhaps Draw, it impasses into an Imaginary version of the Perform space.
In the Imaginary Perform space, chunk-1 fires, recalling the relevant action (double-click on Draw). This result is passed up as the result of the imagine-task operator, creating chunk-2. The action is analogised to be appropriate to the given task (say, double-click on CG), and is passed up as the result in the Action-Proposal space, forming chunk-3. From there, it is recommended into the top Perform space as the action to be done, and forms chunk-4, a new specialised TAM rule for launching CG.

Behaviour 3: Positive Transfer
The diagram below shows what happens if the model is then given the task of launching yet another program, in this case Excel.
The processing follows the same general course as in the previous case, for CG. But at the point in the Use-Analogy space where the model has to ask itself whether it knows how to launch some other program, Draw, this time chunk-2 fires to give the answer directly: "Yes, you double-click on Draw". This time there is no need actually to imagine doing the task in an Imaginary Perform space.

Answer to Exercise 3.

Back to Table of Contents

Two interesting points about the model
- The learning is specific (e.g. to how to launch Cricket Graph), so for Excel the analogy process has to be used again. Nevertheless, the analogy process speeds up.
  In particular, a chunk is learned for the Imagine-Task operator for launching Word, so the model no longer has to set itself the task and do it in imagination.
- The analogy process requires the model to ask itself "Do I know how to launch Word?". It answers this without using meta-knowledge, by imagining the task and seeing if it knows what to do.
Note that these points are dictated by the architecture. They follow from asking: How does Soar lend itself to doing the analogy task?
Further exercises: Exercise 4.
Answer to Exercise 4 (first part).

References

Howes, A. & Payne, S. J. (1990) Semantic analysis during exploratory learning. In J. C. Chew & J. Whiteside (Eds.) CHI'90 Conference Proceedings: Human Factors in Computing Systems, 399-405. ACM Press.
Howes, A. & Young, R. M. (1991) Predicting the learnability of task-action mappings. In S. P. Robertson, G. M. Olson & J. S. Olson (Eds.) in Proceedings of CHI`91: Human Factors in Computing Systems, 113-118. ACM Press.
Howes, A. & Young, R. M. (1996) Learning consistent, interactive, and meaningful task-action mappings: A computational model. Cognitive Science, in press.
Lewis, C. H. (1988) Why and how to learn why: Analysis-based generalization of procedures. Cognitive Science, 12, 211-256.
Rieman, J., Lewis, C., Young, R. M. & Polson, P. G. (1994) "Why is a raven like a writing desk?": Lessons in interface consistency and analogical reasoning from two cognitive architectures. In Proceedings of CHI'94: Human Factors in Computing Systems. 438-444. ACM Press.
Return to main page of: Introduction to Psychological Soar Tutorial
(or use the Back button to return to where you just were).