7 # a ` 5 f f f f f ~^ " : H H h x * f J . 1 x : '
Introduction to the
Soar Cognitive Architecture
Frank E Ritter
University of Nottingham
Richard M Young
University of Hertfordshire
Tutorial Version 12
January 1998
F E Ritter & R M Young, 1996, 1997, 1998
Version Control (no OHP!)
These OHPs currently belong to RMY.
Version 12: Lightly modified by RMY in January 98, for use at UH. Coupled with extensive revision of HT exercises & code, and use with TSI.
Version 11: Modified by RMY in March 97, based on Version 10. Used at AISB/ECCS tutorial, Manchester, April 97. Brought more closely into line with the WWW version of the tutorial, particularly as regards sequencing (which was in bad shape) and NNPSCM content.
Version 10: Used by FER at Berlin, November 96. Many glitches accumulated by now (sequencing and NNPSCM content), and out of synch with WWW version.
Timetable
TIMETABLE
09.30 Session 1: Basics, hungry-thirsty example
11.00 coffee
11.30 Session 2: More on hungry-thirsty
13.00 lunch
14.00 Session 3: Analogy
15.30 tea/coffee
16.00 Session 4: Working with Soar, Discussion
17.30 End
Orientation
Who we are, and why were here
Its assumed that most tutees will have had some expo sure to Soar, e.g. via the UTC book. But getting access to some running Soar code will help make those rather abstract ideas more real.
TIMETABLE
Fundamentals: Soar and UTC
For discussion of Soar as a candidate Unified Theory of Cognition, see Allen Newells Unified Theories of Cognition (1990). It is important as background, but we will not be explicitly dealing with this topic.
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
Intellectual origins in (among many other sources) the work on Production System architectures from the 1970s onwards, Newells 1980 paper on The problem space as a fundamental category of cognition, and his 1982 paper on The knowledge level.
Well introduce Soar by discussing it at three levels: briefly with the first two, spend most time on the third.
Soar (1) 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, e.g. 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 knowl edge in terms of Soar objects through rules, giving those rules to Soar and seeing what behaviour emerges.
Each individual Soar rule, e.g. if translated into English, should make sense as a piece of task knowl edge the agent would plausibly have.
Soar (2) as a Problem Space Architecture
In Soar, all behaviour is seen as occurring in a problem spaces, made up of States (S) and Operators (O or Op). (The implementation, however, has changed somewhat from Newells 1990 book.)
Within a space there is a current state.
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.
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.
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, which we will say more about soon.
Knowledge
In order to act in a domain, Soar must have knowledge of that domain (either given to it or learned).
Its useful to divide domain knowledge into two categories:
(a) basic problem space knowledge: definitions of the state representation, the legal move operators, their applicability conditions and their effects.
(b) control knowledge, which gives guidance on choosing what to do, such as heuristics for solving problems in the domain.
Given just the basic knowledge, Soar can proceed to search 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 knowledge centres round the operators:
when an operator is applicable
how to apply it
how to tell when it is done.
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.
Those minimal default rules can also be seen as playing an important theoretical role. Without them, bare Soar is really a rather weird kind of production system inter preter. 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 encod ing 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.
Practical-1: Running without Knowledge
Turn to x(Practical-1) and follow the directions there.
Make the point! No knowledge => no behaviour.
Soar (3) at the Symbol (Programming) Level
Although we think of Soar as operating conceptually at the problem space level, we have to realise it by encoding knowledge at the more concrete symbol level. Most of todays tutorial is concerned with how to realise the problem space level at the symbol, or programming, level.
At this level, each state (or context) has one other context slot: the operator.
The display on the right is in watch 1 trace format, a term we will return to later on.
Soar on a Slide
Soar on a Slide
The Context Stack
There can be several problem spaces (i.e. contexts) active at any one time. Each may lack some of the knowledge needed to continue fluently with the process of repeatedly choosing an operator and applying it to a state. When this happens, Soar sees an impasse and automatically sets up a new context (or substate), whose purpose is to find the missing information and supply it to the context above.
Each major cycle in Soar called a decision cycle, which we will return to later ends with some kind of change to the context stack. If the knowledge available to Soar (i.e. in the productions) specifies a unique next operator, then that change is made. Otherwise, an impasse arises because the immediately applicable knowledge is insufficient to specify the change.
You saw this behaviour in the running Soar in Practical-1.
Production Rules: Form of knowledge
Knowledge in Soar is encoded in production rules. A rule has conditions on its LHS, and actions on the RHS: C --> A.
Two of Soars memories are of relevance here: the production memory (PM), 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 pat terns 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.
The rule firings have the effect of changing 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, i.e. quiescence.
Example Rule Translated into English
For example, the following rule proposes the operator eat if we are hungry and desire not to be hungry:
;; propose eat
sp {ht*propose-op*eat
(state ^problem-space ^desired )
( ^name hungry-thirsty)
( ^hungry yes)
( ^hungry no)
-->
( ^operator )
( ^name eat) }
IF we are in the hungry-thirsty problem space, AND
in the current state we are hungry, AND
we desire to be not hungry
THEN propose an operator to apply to the current state,
and call this operator eat.
NB We will shortly return to look more closely at the syntax of the rule.
Concrete Representation
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
(x35 ^isa block ^colour red ^size large)
Attributes commonly have just a single value, though they can have multiple values. (There are theoretical and practical reasons for avoiding multiple values whenever possible.)
Operators are represented as attributes on a state, and always have at most one value:
(s13 ^operator o51)
The symbols like s13, o51, and x35 are generated by Soar, not written by hand. They are identifiers, and can be used to link through WM from one object to another:
(x35 ^isa block ^colour red ^size large ^above x47)
(x47 ^isa cylinder ^colour green ^below x35)
The names of rules and objects and almost all attributes are chosen by the programmer. There are very few reserved words in Soar: state, ^operator, and a few other attribute names well meet later: ^superstate, ^attribute, ^impasse, ^item, and one or two others.
Simple Diagrams of Representation
For informal discussion, it can be helpful to use a simple diagrammatic depiction of Soar objects in WM.
The coloured blocks of the previous slide might be shown as:
Simple Example: hungry-thirsty
So, how do we represent a problem to Soar?
Suppose we have a robot that can perform just two actions, Eat and Drink. Initially it is both hungry and thirsty, and its goal is to be not hungry.
Represent the state as having two attributes
one is hungry, with possible values yes and no
other is thirsty, also with possible values yes and no.
In the initial state the robot is both hungry and thirsty, so we have ( ^hungry yes ^thirsty yes).
The goal (or desired) state is to achieve ( ^hungry no).
The operators are named Eat and Drink:
Eat can apply to any state with (^hungry yes), and yields a new state with (^hungry no). The ^thirsty attribute remains unchanged.
Drink can apply to any state with (^thirsty yes), and yields a new state with (^thirsty no). The ^hungry attribute remains unchanged.
For each operator, we have to supply knowledge (in the form of production rules) about:
when to propose the operator
how to apply (or implement) the operator
when to terminate the operator.
Practical-2: Simple Run
Turn to the practicals and do x(Practical 2).
Preferences and Decisions: 1 WM (non-Operator Slots)
We need to look a little more closely at the way rule firings change WM.
First, we look at changes to ordinary WMEs, i.e. ones other than the operator slots.
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.
Instead, rules vote for changes to WM, by producing preferences. Thus, one rule might say that WME-1 is acceptable, another that it is better than WME-2, and a third that it should be rejected.
After each cycle, all the preferences are examined by a decision procedure, which makes the actual changes to WM.
So 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:
Preferences and Decisions: 2 Operator Slots
The most important changes are those to the operator slots. So, to gather all the available knowledge, Soar runs a sequences 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 operator slots.
So we have the idea of a decision cycle, consisting of a number of elabo ration cycles, followed by quiescence, followed by a change to some operator slot (or by the creation of a substate if the preferences dont uniquely specify a change to the operator slots):
Soar runs by executing a sequence of decision cycles until told to stop.
Practical-3: Tracing and Printing
These are the main kinds of preference well meet:
+ acceptable: an object must have an acceptable preference to be considered.
- reject: the object will not be considered.
> better, best: one object is better than another, or (unary) the object is best.
< worse, worst: similarly.
= indifferent: one object is indifferent to another, or (unary, and more usually) the object is indifferent.
& parallel: the object can be one of multiple values.
The semantics of these preferences is roughly, and at least in most cases what you would expect.
You should turn to x(Practical-3) and do it now.
Production Rules: Syntax
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
sp {blocks*paint*propose
(state ^problem-space ^block )
( ^name blocks-world)
( ^isa block ^colour ^above )
( ^isa block ^colour <> )
-->
( ^operator )
( ^name repaint ^object ^colour )}
Features: sp, name, variables,
Further features: negation, conjunction, alternatives, negated conjunction, Well deal with them as we meet them.
On the RHSs of rules, + (i.e. the acceptable preference) is assumed by default:
( ^operator ) means ( ^operator +)
( ^name eat) means ( ^name eat +)
Production Rules: Shorthand Syntax
Shorthand: path names, local structure e.g. the LHS of the rule above:
(state ^problem-space.name blocks-world
^block ( ^isa block )
( ^isa block ))
An example from the hungry-thirsty program:
sp {ht*propose-op*eat
(state ^problem-space.name hungry-thirsty
^hungry yes ^desired )
Practical-4: Preferences
You should open up x(Practical-4) and do it.
Follow up Exercise 4D
Practical 5: Add an Operator
Now open x(Practical-5): Add an operator, and do it.
Follow up: explain how to do it.
Impasses and Substates
When Soar encounters an impasse at level-1, it sets up a substate at level-2, which has associated with it its own current state and operators.
The goal of the 2nd level is to find knowledge sufficient to resolve the higher impasse, allowing processing to resume there.
The processing at level-2 might itself encounter an impasse, set up a substate 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 state), and each context has its own current S and Os.
Example:
Notice that the architectures problem solving approach is applied recursively at each level.
Kinds of Impasses
So, Soar automatically creates substates in order to resolve impasses. This is the only way that substates get created.
What types of impasses are there? Roughly, for each kind of context slot (O), there can be
no candidates for the slot ==> a no change impasse
too many, undifferentiable candidates ==> a tie impasse
inconsistency among the preferences (A > B and B > A) ==> a conflict impasse.
The most common kinds (youre unlikely to meet any others) are concerned with operators:
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)
Resolving Impasses
Each kind of impasse, for its straightforward resolution, requires a particular kind of knowledge:
An SNC/OZ needs operator proposal knowledge.
An OT needs control knowledge.
Interestingly, there are three possible reasons for an ONC
(a) Knowledge of how to implement the operator may be lacking, in which case thats whats needed.
(b) The preconditions of the operator may not be satisfied, which case requires operator subgoaling.
(c) The operator may be incompletely specified, and need to be augmented.
Note that there are other ways to deal with an impasse, such as rejecting one of the context items that gives rise to it.
Practical 6: Watch an Impasse
Inpreparationforcreatingyourfirstchunk now do x(Practical-6): watch an impasse.
Follow up on Exercise 6C.
Chunking 1: Basics
Soar includes a simple, uniform learning mechanism, called chunking. (It is sometimes regarded as an arcane and difficult topic, but it isnt really.)
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 next time a sufficiently similar situation occurs, the impasse is avoided.
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.
Chunking 2: Impasses and Chunks
Just as each kind of impasse, for its straightforward resolution, requires a particular kind of knowledge, so it also gives rise to a characteristic kind of chunk:
An SNC/OZ needs operator proposal knowledge (and gives rise to an operator proposal chunk).
An OT needs control knowledge (and gives rise to control chunks).
The three kinds of ONC
(a) Knowledge of how to implement the operator may be lacking, in which case thats whats needed (yielding operator application chunks).
(b) The preconditions of the operator may not be satisfied, which case requires operator subgoaling. (NB Dont ask about chunking for this case!)
(c) The operator may be incompletely specified (yielding operator modification chunks).
Practical 7: Watch a Chunk
Now open and do x(Practical-7): Watch a chunk, where Hungry-Thirsty learns an operator selection chunk.
Chunking 3: 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 perfor mance on a task, we expect to be able to model learning
cf. position in Cognitive Science until just recently
Even when no chunk is actually built (because learning off, or bottom up, or duplicate, or whatever), an internal chunk called a justification is formed.
Its needed to get persistence right, e.g. to provide i- or o-support (which we will mention later).
Rule Templates
Writing models in Soar typically does not proceed from scratch. Typically, new models are built by copying old models and modifying them.
The same applies to individual rules.
There are templates for the common actions in a problem space.
state initialisation / impasse recognition
state augmentation and problem space proposal
for each operator:
- proposal
- implementation
- termination
goal recognition / return result
Practical 8: Create a Problem Space
Do x(Practical-8), which involves creating an operator implementation space for Hungry-Thirsty.
Talk through the construction of an operator implementation space.
Basics of Persistence
Information in WM is supported by a kind of TMS (Truth Maintenance System). 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.
Rules that modify the state can be divided into two categories:
(a) Elaboration rules, which make explicit information that is already implicit in the state. E.g. whenever a block has any ^colour, we would 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.
(b) Operator application rules, which change the state from one configuration to another. E.g. when we apply the repaint operator, we change the block from its old colour to the new.
Information put into WM by op 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).
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).
Practical 9: Support
Do x(Practical-9), OI-Support, will show you some of the O- and I-support issues in hungry-thirsty.
Soar and Cognition
Mapping between Soar and Cognition
One of the strengths of Soar is that the correspondence between model and psychology is pinned down, not free floating.
Mainly in terms of timescales,
e.g. elaboration cycle ~~ 10 ms
decision cycle ~~ 100 ms
per-operator time 50-200 ms
CONSTRAINTS ON A UTC
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
WEAK METHODS
Working with Soar
EXPRESSING A PROBLEM IN SOAR
Problem space computational model
CENTRALITY OF CHUNKING
Provides additional constraint
Where all the stuff in the problem spaces comes from
APPROXIMATION VIA SUCCESSIVE LEVELS OF CHUNKING
Create top level behavior
What behavior and learning could give rise to this?
Recurse
LISTENING TO THE ARCHITECTURE
Resources and the Soar Project
RESOURCES
The Soar7 manual
Soar group email: soar-group@umich.edu
The Soar-FAQ (http://www.ccc.nottingham.ac.uk/pub/soar/nottingham/soar-faq.html)
Tcl/TK Soar Interface (TSI)
THE SOAR ENTERPRISE
North American and European Soar workshops
Soar sites and their research
Further Readings
Laird, J. E., Newell, A., & Rosenbloom, P. S. (1987). Soar: An architecture for general intelligence. Artificial Intelligence, 33(1), 1-64.
The original presentation of Soar from an AI perspective.
Newell, A. (1980). 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.
The above two papers provide some of the intellectual background.
Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.
Newell, A. (1992a). Prcis of Unified theories of cognition. Behavioral and Brain Sciences, 15, 425-492.
Newell, A. (1992b). Unified theories of cognition and the role of Soar. In J. A. Michon & A. Akyrek (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. (1988). Soar: A unified theory of cognition? Science, 241, 296-298; Toward a unified theory of cognition. Science, 241, 27-29.
This pair of articles provides a useful quick introduction, unfortunately now rather dated.
[See also the more extensive bibliography, slanted towards Soar-and-Y, at http://phoenix.herts.ac.uk/~rmy/cogarch.seminar/soar.html]
Soar Tutorial, v 12
Soar Tutorial, v 11
u u } dENIC o Laird, J. E., Newell, A., & Rosenbloom, P. S. (1987). Soar: An architecture for general intelligence. Artificial Intelligence, 33(1), 1-64.
Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.
Newell, A. (1991). Desires and diversions: Carnegie-Mellon Universtiy School of Computer Science Distinguished Lecture. Palo Alto, CA: University Communications.
Newell, A. (1992a). Prcis of Unified theories of cognition. Behavioral 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. f _ c 4
ENBB ;5 ;5 FC{
FC{
4
p
s 2 , Helvetica
. ( uOp1
FC{4
2 )`Op2
FC{4
0 S
3 P2 )`Op3 < FC{ F{ - 0 U [6 U [C F{` G 8 Q
FC{
t % % % %
T H@ hP HA i
& M< d2*8(4 TS < FC{ F{
- .
3 C F{` &< I
FC{
t '&' &
T @ P A
& < 2*8)ZS' < FC{ F{(gw-
3
8gwC F{` : \
FC{
t (d0l0l/d(i0l
T @ P A!
&< 2*8)[S" 04 04 04 d WORD 04
040 < / d0 c / , Helvetica
. +H S2 ( lO51 ( S: S2 (have-skates) *O: O51 (op-slide) ~ v
v
4 s
v , Helvetica
. ( new results
+
give rise to
( new productions
v4 _
\( actions write
+ into SDM
v4 x
{ ( conditions
+ test SDM c
v" c c " c 4 +D
(A
( # Production Memory (LTM)
v D , h@ , i
2 c
++)A & B => X
+!
( d C & D => Y
+!
( | =>
vD |x@ }y4; N
> K (H impasse
v4 1
.( operator: paint < v v'7 # $'7 v` ]G < r r a a Z Z
v
t $ , , $' , Z " 4< Z r " r i " i
T , P -
) ($ S1 m
v"\ < m n "\ D n TP hPP i
Te+4<S2
v4G0Zf
J3Wc(T5operator
v4_0rq
b3on* no-change
v4 "
( block
v4' :
* 7 (4 green
v4 S
P
+]Soars Working Memory (WM) [
v" l [ " 4 v v v` G
v
wwwwT P ^ " `@ ^ _ " \# _ ^ ^ ^ ^
t HOHH OH" p\ x < v v NZ~ zZ~,px<px v @` C ] h h g g h h
v
t dp ~ dp k ~w dp p dp ~ dp k ~w dp G G G ```
H H 8| @
m m m m + + ` m
! ~
m ~
! d m m m ( m
m m " D c Z S \ ] R q g M j c ] g f V t h ! @ ! > ( *
' ( )
& + B Z f
d
e
c
T
I ( ( ( * " 0 * Y y
n
! k
p
w
! e $ = A
* & 6 > f t s j h } e & : ? 9 3 5 C \ 9 d p h g g o c % 6 7 & ( ) 7 C 2 v
w 3 : R c Y Q Q c K
: ( , ( ( d WORD (
(P ] 1 t GP A X P P U kP " $" ! >" s > @ a H b 0" ֠ a z 0" T - " b DO" n EN " M S " S " F O" A >ס , Helvetica
. +S1 +#SS2 +$TS3 ( O x35 ( x47 ( @ +
superstate +}.above ( q ybelow +S(isa ( W isa ( D colour ( , size +V%block +Acylinder ( 4 red +green ( large " " # " !
" i" g " R ( dobject o d WORD
4 # 7 k o0 # 7 l p4 # o k 0 # o l 4 6 r L , Helvetica
. +wDD
" C
t G v O ~ O v G x M ~ O v" K t O v W ~ W v O x U ~ W v" S t W v _ ~ _ v W x ] ~ _ v" 7 C t 3 \ ; c 7 c ; \ 3 \ 7 c" C C t ? \ G c C c G \ ? \ C c" O C t K \ S c O c S \ K \ O c" [ C t W \ _ c [ c _ \ W \ [ c
4 # ( (elaboration cycle ` ; ( _
\` ; _ ` ^ ` ^ ( \" '04 ~ N ( preference
+phase " s 44 ( WM phase
(
(proposal) ) (insertion) y d WORD
" b g " e y " h " k " n " q " t " w " z " } " " - " ? " Q " c " b " t " " N Wt J S R [ J [ R Y L S J [
4 * Z O0 * [ P4 * O Z g0 * O [ h4 - S C f , Helvetica
. +X;D
" : c
t > W F _ F W > Y D _ F W" B ct F W N _ N W F Y L _ N W" J ct N W V _ V W N Y T _ V W " Q t L 9 X C R C X 9 L 9 R C
4 8 # M 5 ( F (E ` . 7
\` 7 ` 6 g` 6 . g \4 g ( decision cycle 4 ?0 @4 ? W0 ? X4 B U +?D
" R
t F N F H N F" Rt F N F H N F" Rt F N F H N F" t , 3 3 , , 3" t , 3 3 , , 3" t , 3 3 , , 3" t , 3 3 , , 3
4 W 0 W 4 0 4 )PD
"
t " t " t " c t | | | " c t | | | " c t | | | " c t | | |
4 0 4 0 4 )PD
"
t " t " t " t " t " t " t
4 /0 04 / G0 / H4 2 E )PD
" B
t 6 > 6 8 > 6" Bt 6 > 6 8 > 6" Bt 6 > 6 8 > 6" t # # #" t # # #" t # # #" t # # #
4 G o0 G p4 K k ( PD
" g
t S [ S V [ S" g t S [ S V [ S" g t S [ S V [ S
4 s C ( Helaboration cycle ` [
\` { [ ` { ~ ` ~ \" ' 4 N ( preference
+phase " K4 4 X ( ] non-context
+
changes " K4 3 (
quiescence " _ 4 ; ( @context changes,
+
substate
*creation/removal rt d WORD
T , L" h +
t y y " h +t O W P W O P " h / t d l h l d h 8p" . a
t G z T T Q z G T p G z T T Q z G T P ? 1 ` , Helvetica
. +G$S1 " h +
t d l h l d h
T X x P X y T X x P X y +@HS2 8p" s" t ; H H ; E H p ; H H ; E H" `+
t
T P T P pP P q +9S3 ( ! Context1 4 ^ S s } +=KContext2 4 ! K +=Context3 4 g -& ( % i? no operator proposed 4 Z o{ +Ewhich operator? ( PO' *O'' ( O''' ^ P @ d WORD
" B Kt . T 5 \ 0 \ 5 V . T 0 \ B B t > F B F > B " B AJt I Q Q I O Q
T 6 N P 6 O , Helvetica
. +
FA " z W
t b p i x d x i r b p d x z t
T n ( P n ) +8B T L d P L e +< E " . h$
t O x W W S x O W " a ,t G N G N G G
T V x n P V x o ( f D . h .
t * 2 . 2 * .
T " \ : tP " \ ; u ( 2 dC " B +
t M U S U M S
T 6 N P 6 O " V ,
t " Kt td |l vl |g td vl
T (P )" V
t 7 ? 7 ? 9 7" V kt kd rl pl rd kf pl
T J bP J c T " :0P " ;1T fl ~ P fl ( vtR O O4 ( IMPASSE 4 @ ( Chunk: A & B & D , Symbol )wޠ ) R ( !Circles are WMEs or sets of WMEs
*8Bold circles indicate nodes essential to the resolution
*;Arrow sets going into a node are rules that fire to add it
*&Numbered nodes are WMEs in the impasse ( F 1 ( 3!2 ( [ 3 + <4 ` B k H` 3 S ` RN` w # ` NG ar dENIC o Laird, J. E., Newell, A., & Rosenbloom, P. S. (1987). Soar: An architecture for general intelligence. Artificial Intelligence, 33(1), 1-64.
Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.
Newell, A. (1991). Desires and diversions: Carnegie-Mellon Universtiy School of Computer Science Distinguished Lecture. Palo Alto, CA: University Communications.
Newell, A. (1992a). Prcis of Unified theories of cognition. Behavioral 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. f _ c 4
ENBB E 7 ' d ENIC o ENB- 4 hV 2ENBB o 4 hV 2ENBB o " hV 2ENB- o _ c 4
4 7 X a j s t = F 2
Q
Z
^
h
r
|
: B # L S ] h z : G V W $ , @ s @ k @ j @ g @ @ b
J ~
_ n !
! ! "a $0 $Y %g %{ % % &" & '
' 'N 'v (\ (] )y ) ) ) ) ) ) ) ) ) ) ) *# *A *R *Y *o * * * * + +
+ +T +b + + + + , ,% ,= ,B ,G ,R ,l ,u , , - - . . / / 00 01 0a 0b 1 1 2 @
@ x
@ W 2 2 2 3~ 3 3 3 3 3 3 3 3 3 3 4 4K 4L 4M 4Z 4f 4g 4h 4t 4 4 4 4 5 5 5 5 6f 7z 8g 8z 8 8 8 8 8 8 8 8 8 8 8 9/ 9 9 :' :+ :] :i : : ; ; = = =$ =) =d =e =f > > ? ? ?_ ?g ? ? @ @. @Y @e @ @ @ @ A` Aq A A B @ ˠ
@
@ T B B C C C C C DN DY E E E G
G G G H; HB H I
Id Ix I I J0 J; J J J J K} K K K Lw L N N O P P Q Q Q Q R R S; SO T$ T+ T T T T U U+ U U U U U V V V V Vi Vj V~ V W W W YR [D [ \ \ \
@ @ |
@ N \ \ \ \ \ \ ]l ] ] ] ] ^. ^A ^^ ^ ^ ^ ^ _a _ _ `3 ` ` ` ` ` ` ` a= a a a a a a a a a a a a ܛ
@ P
@
@ @ @ * 4 5 6 7 F G ` a b c s t % U V W b c d i j t > H I J W X { < =þȯȩȯ
#( #( #( #( #( #( #( #( #( #( #( P #( #( #( $ #( % 7 = G H d e : = 3
}
S \
C x ) > ) b ) Q R V X ƶƱ𫼦漡 #( L #( 0 #( #( #( #( #( 0 #( #( ; #( #( #( #( 0 #( #( #( #( #( #( #( #( 4 7 \ !
!2 ! ! ! ! " " "3 "7 "M "a " " " # #0 #1 #| #} # $0 $Y % %g %{ &" &V & ' ' ( ºzt #( #( #( #( #( #( #( #( #( 0 #( #( #( #( #( 0 #( #( #( #( #( L - ( ([ (\ (^ (~ ( )A )p ) ) *C * * +0 + , ,3 ,a , , , , - - -Q - .i /. / 00 02 0a 0b닃}woiic[ #( h #( #( h #( h #( h #( h #( h P #( h #( #( <, @ @ @! @ #( <, @ @ @! @ #( #( #( #( #( #( #( #( #( #( 0b 1 2 2 3% 3I 3~ 3 3 4K 4f 4 5 5p 5q 5 5 5 5 6f 6 6 6 7 7- 71 7E 7z 7 8 8f 8 8 8 8 8 9/ 9\ 9| 9 9 9 9 : :'˞ڞzՌ #( #(
( #( #( #( #( #( #( | #( h #( #( 0 #( #( #( #( #( #( hh #( hh #( h #( h , :' :+ :F :G :u : : : : ; ; ; ; <0 =[ =d =f =g = = = >T > > ?! ?q ? @= @s @ @ AN A} A A B> B B Cj C C C C D D E E轸| #(h #( #( #( #( #( 0 #( #( #( #( #( #( #( h #( h #( h #( h #( h #( #( #( #( . E F F G
G+ G H- Hq H I I I J J J J J KL K K L L M M M M M N+ N[ Np N| N N N N N N OH O O O뻵땍|||sss||n #( #( 8 ( #( 8 #( h #( h #( h #( #( #( #( #( #( #( #( #( #( #( #( #( 0 #( #( #( ( O P Q Q S7 S T U V V V Vh Vi V} V~ V W W< W\ Ww W W W W X X* XE Xm X X X Y Y8 YR Y_ Yr Ys Y Y Y Y Z# ZS Zo Z Z Z Z Z Z [ [4ƻƱ˱ #( #( #( #( #( P #( #( #( #( #( #( #( #( h #( h #( h #( h #( h #( h 3 [4 [ [ [ [ [ \ \ \ \ \ ] ] ^. ^ ^ _ `Q ` a= a a a a a a a a a˿Ũ #(
$ #( h h #( h #( h #( h #( h h #( hh #( #( #( #(
Q OHP titleOHP bullet text
OHP normalOHP idOHP dash OHP program P
0 0
$ $
0 0
@ @ @ @ h0
0 @$ 0 J ` a b X K I y * 8 "~ & '_ + + /3 2& 4 7 9, 9 : < ? Bk B F I I K M N T Uj X` Y [
`
? )
' +
$
' " 7 . # # ! " $ # $ % & ' ( ) 4 7 2 B \ ܛ o p q r s = ( 0b :' E O [4 a t u v w x y z { |
! " H H
,6G{ H H
d ' @ A.h B B H -:StyleWriter II
Times Helvetica Courier Symbol .ICEmbdObject3_1
ICEmbdObject3
ICEmbdObject4 [ _ ` E y [ _ ` ( `o ( B 'Soar v2 tutorial OHPs
Psychology