Download AN INTRODUCTION TO SOAR PROGRAMMING

context
slots
state=top-state:
operator=?
working
memory
preference
memory
time=noon
[... +]
weekday=Friday
[... +]
day-type=payday
[... +]
agenda=lunch
[... +]
[operator=exercise, +]
[... +]
[operator=eat-steak-at-FredÕs +]
[... +]
[operator=exercise >]
state=substate-1:
problem=two-operators-tied
tied-item-1=exercise
tied-item-2=eat-steak-at-FredÕs
superstate=top-state
Chunking
As described in the introductory overview, this is the point at which Soar forms chunks.
As soon as the production firing in the substate reaches up and puts the > preference into
the top-state, the Soar system will report, ÒBuild: chunk-1Ó and the following chunk will be
added to the list of productions that define this modelÕs permanent knowledge:
IF
[operator=exercise +]
[operator=eat-steak-at-FredÕs +]
THEN operator=exercise >
This has the problemÕs cause on the IF side and the problemÕs solution (from the
programmerÕs original production) on the THEN side. And, it is a production that will
apply in the top-state as soon as the operator preferences are moved into working memory,
without subgoaling.
Neat, huh? It all fits together!
Impasse Resolution and Subgoal Collapse
Now, once the > preference is added to the top state, no other production fires, so
quiescence has been reached. Soar goes into another decision phase, considering first the
context slots in the top state and working down. Specifically, it considers the three
preferences for operator in the top state. The standard preference arbitration rules can now
resolve the tie between eat and exercise, with the result that exercise is selected as the
operator. It Ògoes into slot.Ó That resolves the operator tie, so the substate (which depended
on the tie) is eliminated. More accurately, the system eliminates the tie, and everything that
depended on the tie gets garbage collected.
And that ends the decision cycle, so the next elaboration cycle can begin on the revised
working memory:
Soar Introduction
13