Soar: Frequently Asked Questions List

Frank E. Ritter: frank.ritter@psu.edu
Jong W. Kim: jongkim@psu.edu

Last updated 21 March 2006

Table of Contents

Section 0: Introduction

Section 1: General Questions

(G0) Where can I get a copy of the Soar FAQ?

(G1) What is Soar?

(G2) Where can I get more information about Soar?

(G3) What does "Soar" stand for?

(G4) What do I need to be able to run Soar?

(G5) Where can I obtain a copy of Soar?

(G6) Who uses Soar for what?

(G7) How can I learn Soar?

(G8) Is Soar right tool for me?

(G9) Is there any support documentation available for Soar?

(G10) How can I find out what bugs are outstanding in Soar?

(G11) Other links and awards in Soar

(G12) How does Soar currently stand as a Psychology theory?

(G13) What tools are available for Soar?

(G14) Can Soar be embedded?

(G15) Resources for teaching Soar

(G16) Who has worked on the Soar FAQ?

Section 2: Technological/Terminology Questions

(T1) What is search control?

(T2) What is the data-chunking problem?

(T3) What is the data-chunking generation problem?

(T4) What do all these abbreviations and acronyms stand for?

(T5) What is this NNPSCM thing anyway?

(T6) How does Soar 7 differ from Soar 6?

(T7) What does using a ^problem-space.name flag buys you apart from providing a conventional label within which to enable operator proposition?

Section 3: Programming Questions

(P1) How can I make my life easier when programming in Soar?

(P2) Are there any guidelines on how to name productions?

(P3) Why did I learn a chunk here?

(P4) Why didn't I learn a chunk there (or how can I avoid leaning a chunk there)?

(P5) What is a justification?

(P6) How does Soar decide which conditions appear in a chunk?

(P7) Why does my chunk appear to have the wrong conditions?

(P8) How is it possible for Soar to generate a duplicate chunk?

(P9) What is all this support stuff about? (Or why do values keep vanishing?)

(P10) When should I use o-support, and when i-support?

(P11) Why does the value go away when the subgoal terminates?

(P12) What's the general method for debugging a Soar program?

(P13) How can I find out which productions are responsible for a WME?

(P14) What's an attribute impasse, and how can I detect them?

(P15) How can I easily make multiple runs of Soar?

(P16) Are there any templates available for building Soar code?

(P17) How can I find all the productions that test X?

(P18) Why doesn't my binary parallel preference work?

(P19) How do I use indifferent preferences to generate probabilistic behavior?

(P20) How can I do multi-agent communication in Soar 7?

(P22) How can I use sockets more easily?

(P22) How do I write fast code?

(P23) In a WME, is the attribute always a symbolic constant?

(P24) How does one write the 'wait' operator in Soar8.3?

(P25) How does one mess with the wme's on the IO link?

(P26) How can I get Soar to interpret my symbols as integers?

(P27) Has there been any work done where new operators are learnt that extend problem spaces?

(P28) How can I find out about a programming problem not addressed here?

(P29) Why identical WME's illegal in Soar?

(P30) How to count Objects including WME's?

Section 4: Downloadable Models

(DM0) Burl: A general learning mechanism

(DM1) A general model of teamwork

(DM2) A model that does reflection

(DM3) A model that does concept/category acquisition

(DM4) A model for Java Agent Framework (JAF) component

(DM5) Herbal: A high level behavior representation language

(DM6) dTank: A competitive environment for distributed agents

(DM7) A model that counts attributes

(DM8) VISTA: A toolkit for visualizing an agent's behavior

Section 5: Advanced Programming Tips

(APT1) How can I get log to run faster?

(APT2) Are there any reserved words in Soar?

(APT3) How can I create a new ID and use it in the production?

(APT4) How can I access Tcl and Unix variables?

(APT5a) How can I access Soar objects?

(APT5b) How can I find an object that has attributes and values?

(APT6) How can I trace state changes?

(APT7) How can I connect Soar to large database?

(APT8) How can/do I add new Tcl/Tk libraries?

(APT9) How can and should I use add-WME and remove-WME?

(APT10) Frequently found user model bugs, or How can I stick beans up my nose metaphorically in Soar?

(APT11) Why there seem to be no preferences in preference memory for (id^attribute value) triples acquired through C input functions?

(APT12) Why is "send" in Soar different from "send" in Tk?, or What do I do if my Soar process comes up as 'soar2'?

(APT13) How to get Soar to talk to new Tk displays?

(APT14) How to avoid memory leaks?

(APT15) How to represent waypoints and partial results in hierarchical goal stacks?

(APT16) How do I use SML (Soar Markup Language)?

(APT17) How to create JavaToh project using Eclipse on Windows?

Section 6: Miscellaneous Resources

(M0) Comparisons between Soar and ACT-R

(M1) Unofficial mirror of Soar FAQ and LFAQ

(M2) Soar memorabilia

(M3) Soar in the news

(M4) Other interesting things with Soar in it

(M5) What was TAQL?

(M6) Soar and Design models

Section 0: Introduction

This is the introduction to a list of frequently asked questions (FAQ) about Soar with answers. The FAQ is provided as a guide for finding out more about Soar. It is intended for use by all levels of people interested in Soar, from novices to experts. With this in mind, the questions are essentially divided into six parts as follows:

Questions in the first section have their numbers prefixed by the letter G (for General); those in the second section are prefixed by the letter T (for Technological); those in the third section are prefixed by the letter P (for Programming); those in the fourth section are prefixed by the letter DM (for Downloadable Models); those in the fifth section are prefixed by the letter APT (for Advanced Programming Tips); and, finally, those in the sixth section are prefixed by the letter M (Miscellaneous Resources). It also attempts to serve as a repository of the canonical "best" answers to these questions. So, if you know of a better answer or can suggest improvements, please feel free to make suggestions.

This FAQ is updated and posted on a variable schedule.We scan the Soar Workshop Proceedings yearly. We read Soar-group emails with the FAQ in mind. We solicit answers where we can see common and important questions. Full instructions for getting the current version of the FAQ are given in question (G0). In order to make it easier to spot what has changed since last time around, new and significantly changed items have often been tagged with the "new" icon on each major reference.

Suggestions for new questions, answers, re-phrasing, deletions etc., are all welcomed. Please include the word "FAQ" in the subject of your e-mail correspondence. Please, use the mailing lists noted below for general questions, but if they fail or you do not know which one to use, contact one of us.

This FAQ is not just our work, but includes numerous answers from members of the Soar community, past and present. The initial versions were supported by the DERA and the ESRC Centre for Research in Development, Instruction and Training. The Office of Naval Research currently provides some support.

Gordon Baxter put the first version together. Special thanks are due to John Laird and the Soar Group at the University of Michigan for helping to generate the list of questions, and particularly to Clare Bates Congdon, Peter Hastings, Randy Jones, Doug Pearson (who also provided a number of answers), and Kurt Steinkraus. The views expressed here are those of the authors and should not necessarily be attributed to the UK Ministry of Defence, the US Office of Naval Research, or the Pennsylvania State University.

Frank E. Ritter (frank.ritter@psu.edu)
Jong W. Kim (jongkim@psu.edu)

Back to Table of Contents

Section 1: General Questions

(G0) Where can I get a copy of the Soar FAQ?

The latest version of the list of Frequently Asked Questions (FAQ) for the Soar cognitive architecture is posted periodically to the Soar-group mailing list, and to the following newsgroups:

comp.ai

sci.cognitive

sci.psychology.theory

If you are reading a plain text version of this FAQ, there is also an html version available, via either of the following URLs:

    
acs.ist.psu.edu/soar-faq/

that you can access using any Web browser.

If you find that material here is out of date or does not include your favorite paper or author, please let us know. The work and range of material generated by the Soar group is quite broad and has been going on for over 20 years now.

Back to Table of Contents

(G1) What is Soar?

Soar means different things to different people. Soar is used by AI researchers to construct integrated intelligent agents and by cognitive scientists for cognitive modeling. It can basically be considered in several different ways:

  1. A theory of cognition: It is the principles behind the implemented Soar system.
  2. A set of principles and constraints on (cognitive) processing: Thus, it provides a (cognitive) architectural framework, within which you can construct cognitive models. In this view, it can be considered as an integrated architecture for knowledge-based problem solving, learning, and interaction with external environments.
  3. An implementation of these principles and constraints as programming language
  4. An AI programming language

Soar incorporates:

  • Problem spaces as a single framework for all tasks and subtasks to be solved
  • Production rules as the single representation of permanent knowledge
  • Objects with attributes and values as the single representation of temporary knowledge
  • Automatic subgoaling as the single mechanism for generating goals
  • Chunking as the single learning mechanism

The Soar licence is in the public domain and thus the software releases are free to download and use. For more information regarding Soar licence, please refer to sitemaker.umich.edu/soar/license. In addition, the Soar video is available to download (10.4M) to find out more about Soar.

Back to Table of Contents

(G2) Where can I get more information about Soar?

Books

The following book will help you to get an introductory idea of Soar as a Unified Theory of Cognition.

Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.

If you want to find out things that people have modeled by using Soar, please, take a look at:

Rosenbloom, P. S., Laird, J. E. & Newell, A. (1993). The Soar Papers: Readings on Integrated Intelligence. Cambridge, MA: MIT Press.

This book also helps you understand modeling and simulation issues in military applications:

Pew, R. W., & Mavor, A. S. (1998). Modeling Human and Organizational Behavior: Applications to Military Simulations. Washington, D. C.: National Academy Press.

In addition, a review by Ritter et al. provides an understanding of the integration and usability of the models in synthetic environments as a general update to Pew & Mavor's book. It also includes a summary comparing Soar and ACT-R as an appendix.:

Ritter, F. E., Shadbolt, N. R., Elliman, D., Young, R. M., Gobet, F., & Baxter, G. D. (2003). Techniques for modeling human and organizational behavior in synthetic environments: A supplemetary review. Wright-Patterson Air Force Base, OH: Human Systems Information Analysis Center (HSIAC).

Journal Articles and Book Chapters

Recent and forthcoming publications related to Soar include:

Huffman, S., & Laird, J.E. (1995). Flexibly instructable agents. Journal of Artificial Intelligence Research, 3, 271-324.

Jones, R. M., Laird, J. E., Nielsen, P. E., Coulter, K. J., Kenny, P., & Koss, F. V. (1999). Automated intelligent pilots for combat flight simulation. AI Magazine, 20(1), 27-41.

Laird, J. E., & Rosenbloom, P. S. (1996) The evolution of the Soar cognitive architecture. In D. Steier & T. Mitchell (eds.), Mind Matters: A Tribute to Allen Newell. Mahwah, NJ: Lawrence Erlbaum Associates.

Lehman, J. F., Laird, J. E., & Rosenbloom, P. S. (1996) A gentle introduction to Soar, an architecture for human cognition. In S. Sternberg & D. Scarborough (eds.), Invitation to Cognitive Science, Volume 4.

Lewis, R. L. (2001). Cognitive theory, Soar. In International Encyclopedia of the Social and Behavioral Sciences. Amsterdam: Pergamon (Elsevier Science).

Lewis, R. L. (1999). Cognitive modeling, symbolic. In Wilson, R. & Keil, F. (Eds.), The MIT Encyclopedia of the Cognitive Sciences. Cambridge, MA: MIT Press.

Ritter, F. E. (2003). Soar. In Encyclopedia of Cognitive Science: Macmillan.

Tambe, M., Johnson, W. L., Jones, R. M., Koss, F., Laird, J. E., Rosenbloom, P. S., & Schwamb, K. (1995). Intelligent agents for interactive simulation environments. AI Magazine, 16(1), 15-39.

Web Sites

There are a number of Web sites available that provide information about Soar at varying levels:

The first place you should visit is the Soar homepage at University of Michigan where Soar is maintained. The Artificial Intelligence (AI) lab at the University of Michigan has a collection of Web pages on Cognitive Architectures. This includes a section on Soar, and there is also a web page available for the Soar group at University of Michigan.

The Information Sciences Institute (ISI) at the University of Southern California provides a collection of Soar-related Web pages including the Soar group at ISI, and the Soar archive which contains a publication bibliography, document abstracts, official software releases, software manuals, support tools, and information about members of the Soar community.

Carnegie Mellon University - where Soar was originally developed - has its own Soar projects page.

The University of Hertfordshire website includes Soar resources on the Web and elsewhere, a few of Richard Young's papers, and an annotated bibliography of Soar journal articles and book chapters (but not conference papers) related to psychology that is intended to be complete.

ExpLore Reasoning Systems has a summary with some new links at www.ers.com/Html/soar.htm.

There is also a site at the University of Nottingham that includes mirrors of several of the US sites as well as some things developed at Nottingham, including the Psychological Soar Tutorial. There is a nascent site at the Pennsylvania State University will appear at Frank Ritter's homepage.

Frank Ritter also has papers on Soar that are available for download at acs.ist.psu.edu/papers.

Mailing Lists

There are several mailing lists that exist within the Soar community as forums for discussion, and places to raise queries. Currently, the mailing lists are provided via SourceForge.net. You can subscribe or unsubscribe the mailing lists via the SourceForge.net. The main ones are:

  • Soar-group mailing list (soar-group@lists.sourceforge.net) - You can discuss Soar and its components.

  • Soar-games mailing list (soar-games@lists.sourceforge.net) - You can get a discussion for development of games using Soar. If you want to see collection of prior postings to the list, please, visit the Soar-games Archives.

  • Soar SML projects mailing list (soar-sml-list@lists.sourceforge.net) - This is the discussion list for Soar SML projects.

  • Soar consortium mailing list (soar-consortium@lists.sourceforge.net) - This mailing list sends a mail to the current Soar Consortium Board members.

  • Soar-Umich mailing list (soar-umich@lists.sourceforge.net) - This is a mailing list for Soar researchers at the University of Michigan.

There used to be (1988 to 2000) a European mailing list. The eu-soar list merged with the Soar-group list in June 2000.

Newsgroups

At present, there is no Soar newsgroup. There has occasionally been a talk about starting one, but the mailing lists tend to serve for most purposes. Matters relating to Soar occasionally appear on the comp.ai newsgroup.

Soar Workshops

There have been two workshops series, one based in the USA and one based in Europe (which led to a series of international workshops and conferences on cognitive modeling, starting with the First in Berlin, and recently at the University of Pittsburg). Listed below are a few of the previous North American Workshops:

The next 26th Soar Workshop will be held Monday, May 22 to Friday, May 26, 2006, in Ann Arbor, MI. hosted by the Center for Cognitive Architecture at the University of Michigan, and Soar Technology, Inc.

Soar Training

Saor tutorials are offered each year at the Soar Workshop. There have been Soar tutorials at several conferences and held as additional training for academia, industry and government. The University of Michigan group has probably done it the most. Contact John Laird for details.

Often, a one-day psychology oriented Soar tutorial was offered before EuroSoar workshops, and often at AISB conferences.

Back to Table of Contents

(G3) What does "Soar" stand for?

Historically, Soar stood for State, Operator And Result, because all problem solving in Soar is regarded as a search through a problem space in which you apply an operator to a state to get a result. Over time, the community no longer regarded Soar as an acronym: this is why it is no longer written in upper case. You can, in fact, tell who is in the Soar community by how they write the word Soar (or at least, tell who has read the FAQ!).

Back to Table of Contents

(G4) What do I need to be able to run Soar?

The Soar software page is your first port of call. Older versions of Soar are available here: sitemaker.umich.edu/soar/soar_archive. There are a number of versions of Soar available for different combinations of machines and operating systems.

Soar Version 8.6.0 Release: Soar Suite 8.6.0 is now avaiable for download. This version is a Windows-only release. Before the Soar Workshop, it is anticipated that a version of 8.6.1 should include Linux and Mac releases. One of major changes is that the Soar 8.6.0 provides an alternative approach for interfacing into Soar called SML (Soar Markup Language). This interface provides several strengths such as multiple language support (Java, C++, and Tcl), and a uniform method for building I/O interfaces, etc. In addition, the Soar Java debugger is newly provided. The debugger interfaces with Soar via SML and provides much higher performance than the TSI for detailed trace.

Soar Version 8.5.2 Release (as of July 2004): Soar Suite 8.5.2 is availble. Currently, Soar Suite 8.5.2. is available for the Windows, Linux, and Mac OS X. You can also check the SourceForge site to download the latest version releases.

Soar Version 8.5.0. Soar Suite 8.5.0. is available for all Windows, Linux, and Mac OS X platforms.

Soar Version 8.3 Release: Soar 8.3 adds several new features to the architecture and resolves a number of bug reports. A change to the default calculation of O-Support may require changes to existing Soar programs. These are described in the Soar 8.3 Release Notes. Soar 8.3 still includes a compatibility mode that allows users to run using the old Soar 7 architecture and methodology. Users must specify "soar8 -off" before loading any productions to run in Soar 7-compatibility mode. Available for Unix, Mac, and Windows.

Soar Version 8.2: Soar 8 introduces architectural changes which require changes to existing Soar programs. These are described in the Soar 8.2 Release Notes. Soar 8.2 does include a compatibility mode that allows users to run using the old Soar 7 architecture and methodology. Users must specify "soar8 -off" before loading any productions to run in Soar 7-compatibility mode.

Tiny Soar: TinySoar is an implementation of Soar that is intended to run on a memory-constrained device, such as a robot. TinySoar consists of two primary components:

  • a portable, light-weight runtime that implements the Soar decision cycle as a host for a Soar agent
  • Tcl extension that is used to create and debug Soar agents, and then export them into a format that can be compiled into the runtime component.

Scott Wallace has installed TinySoar on a lege brick when he was in University of Michigan. He mentioned that installation went relatively painlessly, except that TinySoar ends up overwriting the bricks I/O software. Thus, note that you must take the batteries out to reset the thing before you can reload anything (e.g., bug fixes to your rules).

There are a few differences between TinySoar and Soar 8.3. One such difference is that it uses (@ -- reconsider preference). Impasses are supported, although chunking is not yet implemented. For more information, please visit the TinySoar webpage.

Previous Versions:

Unix - Soar 7.0.4. This requires about 10 Mb of disk space (including source code) for most of what you will need, although the file that you retrieve via ftp is much smaller, since it is archived and compressed. The Unix version of Soar 7 is compiled with Tcl/Tk, which allows users to easily add commands and displays to their environment. The Soar Development Environment (SDE), which is a set of extensions to GNU Emacs, offers a programming support environment for earlier versions of Soar, and can still be used albeit in a more limited way for more recent versions.

Mac - MacSoartk 7.0.4 + CUSP - this version MacSoar comes with Tk included, along with a number of extensions added by Ken Hughes to improve the usability of Soar on the Mac. You will require around 10 Mb of disk space to run this version, and will need version 7 of Mac OS (version 7.5 is recommended). Some versions of Soar can also be run under MacUnix.

PC - There was a version of Soar which runs under Windows 95 and Windows NT. It is a port of Soar to WIN32, and includes Tcl 7.6/Tk 4.2. It is available from the University of Michigan, as a zipped binary file. You should read the accompanying notes (available at the same URL) carefully, because there may be a problem with the Win32 binary release of Tcl 7.6/Tk 4.2.

In addition there is an older, unsupported PC version called WinSoar, based on Soar version 6.1.0, which includes a simple editing and debugging environment, runs under Microsoft Windows 3.x. It is also known as IntelSoar.

Several people have also successfully managed to install the Unix version of Soar on a PC running under the Linux operating system, although some problems have been reported under versions of Linux that have appeared since December 1996.

Version 7.1 of Soar is currently being revised to utilize the latest release of Tcl/Tk (8.0) prior to its official release. The new release of Soar will include the Tcl/Tk Soar Interface (TSI). Currently, Soar 7.1 uses Tcl 7.6 and Tk 4.2, not Tcl 8.0.

Back to Table of Contents

(G5) Where can I obtain a copy of Soar?

You can simply click on the version you want from the Soar Software Page at University of Michigan. In addition, you can directly surf the SourceForge site.

A new version of Visual Soar has been posted. Recent improvements include fixing bugs in drag and drop operations and formatting. Also new are commands to automatically format and redraw a document in the Rule Editor. The latest version of Visual Soar can be found at www.eecs.umich.edu/~soar/projects/visualsoar/

KB agent is a commercially available version of Soar for developing intelligent agents in enterprise environments. It is based on the public version, but the code has been optimized, updated, and reorganized for linking to other programs in Windows 95/NT.

Ralph Morelli, in 1996, created a prototype of a WWW client/server model where Soar (6.2.4) is the server and a Java applet is the client. This allows one to "talk to Soar" via Netscape or some other Web browser.

There is a Lisp based version of Soar 6 that Dr. Jans Aasman (ja@franz.com) built a while back. You should contact him for details.

There is a partially completed (as of Apr.13, 2000) Java based version by Sherief (shario@usa.net). Its source code and more details used to be available at www.geocities.com/sharios/soar.htm.

Back to Table of Contents

(G6) Who uses Soar for what?

Soar is used by AI researchers to construct integrated intelligent agents, and by cognitive scientists for cognitive modeling.

The Soar research community is distributed across a number of sites throughout the world. A brief overview of each of these is given below, in alphabetical order.

Brigham Young University (BYU)

NL-Soar is being actively developed at BYU Soar Research Group. Deryle Lonsdale (lonz@byu.edu) is the point of contact.

Carnegie Mellon University

Development of models for quantitatively predicting human performance, including GOMS, and more complex, forward-looking and sophisticated models have been built using Soar. For more information contact Bonnie John (Bonnie.John@cs.cmu.edu).

ExpLore Reasoning Systems, Inc.

As well as its academic usage, Soar has been used by ExpLore Reasoning Systems, Inc. in Virginia, USA. A commercial version of Soar, called KB Agent, was developed as a tool for modeling and implementing business expertise.

Information Sciences Institute (ISI) and Institute for Creative Technologies (ICT), University of Southern California

Soar projects cover five main areas of research: development of automated agents for simulated environments (in collaboration with UMich); learning (including explanation-based learning); planning; implementation technology (e.g., production system match algorithms); and virtual environments for training. For more information contact Jonathan Gratch (gratch@ict.usc.edu), and Randall Hill (hill@isi.edu).

Pace University

The Robotics Lab at Pace University focuses on building and testing a robot control architecture using the Soar cognitive architecture as its basis and the DARPA Image Understanding Environment to process visual data.

Pennsylvania State University

The Soar work at the Pennsylvania State University involves using Soar models as a way to test theories of learning, creating a high level language for modeling, and improving human-computer interaction. Other projects include the development of the Psychological Soar Tutorial and the Soar FAQ!. For more information, please contact Frank Ritter (frank.ritter@psu.edu).

Soar Technologies

Bob Marinier (rmarinie@eecs.umich.edu) saied that Soar Tech utilizes advanced artificial intelligence that is grounded in scientific principles of human-system interaction and implemented through sound software engineering. The work of Soar Technology, Inc. has been primarily focused on projects concerning TacAir-Soar. Soar Tech develops intelligent autonomous agent software for modeling and simulation, command and control, information visualization, robotics, and intelligence analysis, for the U.S. Army, Navy, Air Force, DARPA, JFCOM, DMSO, and the intelligence community. Soar Tech has also developed useful tools for programming in Soar such as SDB, the Soar Debugger.

University of Hertfordshire and University College London Interaction Center (UCLIC)

The Soar work at University of Hertfordshire includes modeling aspects of human-computer interaction, particularly on the use of eye movements during the exploratory search of menus. Richard Young used to work at University of Hertfordshire, but he left for the UCL Interation Center (UCLIC). For more information contact Richard Young (r.m.young@acm.org).

University of Leiden

Ernest Bovenkamp (E.G.P.Bovenkamp@lumc.nl) has been using Soar as an agent architecture for parsing and understanding medical images.

University of Michigan

The Soar work at University of Michigan has four basic research thrusts:

In addition, the application of Soar to computer games is also researched.

Perhaps, the largest success for Soar has been flying simulated aircraft in a hostile environment. Jones et al. (1999) report how Soar flew all of the US aircraft in the 48 hour STOW'97 exercise. The simulated pilots talked with each other and ground control, and carried out 95% of the missions successfully.

For more information, please contact John Laird (laird@umich.edu).

University of Michigan/Psychology

NL-Soar work at University of Michigan was done by Rick Lewis (formerly @ Ohio State) who focused on modeling real-time human sentence processing, research on word sense disambiguation, and experimental tests of NL-Soar as a psycholinguistic theory. Rick has moved to ACT-R with his work.

Deryle Lonsdale at BYU continues to work on NL-Soar.

For more information, please contact Rick Lewis (rickl@umich.edu)

University of Portsmouth

The Intelligent Agent Group at the University of Portsmouth is currently involved in a range of Soar related activities, particularly: (a) Soar agents for intelligent control in synthetic environments, (b) Teamwork/C2 structures within groups of Soar agents, (c) off-line knowledge extraction from legacy production sets, and (d) Soar development tools. For further information, contact Tony Kalus (tony.kalus@port.ac.uk).

Back to Table of Contents

(G7) How can I learn Soar?

Probably, the best way to learn Soar is to actually visit a site where people are actively using Soar, and stay for as long as you can manage (months rather than days).

In order to help people, however, there are manuals and tutorials available. Before studying them, you should first visit Soar's getting started page.

The manuals and tutorials, were developed for anyone interested in learning Soar, and are based on Soar 8. They are used in classes to teach Soar (e.g., at University of Michigan where they were developed, and at other universities).

Another tutorial was developed mainly with psychologists in mind. The latest version is based on Soar 8. The Web version of this tutorial was developed by Frank Ritter, Richard Young, and Gary Jones. A Powerpoint presentation on the Psychological Soar Tutorial can be found at acs.ist.psu.edu/papers/pst14/bamberg-soar.ppt, which worked with Soar 8.

There is no textbook, as such, on how to program using Soar, although John Rieman has written a set of notes entitled An Introduction to Soar Programming (gzipped postcript format). Even though the notes are based on version 6 of Soar (NNPSCM), they provide a useful bare bones introduction to Soar as a programming language.

In addition, the Soar Coloring Book also provides user-friendly instructions with hands-on examples and exercises. Please, visit the web page of the Soar Coloring Book.

Also, Soar dogma will help get a feel for how to program Soar (You can find the link in G9 section).

Andrew Nuxoll wrote: The Soar dogma contains a collection of Soar wisdom gathered during a series of conversations between John Laired and myself as I mounted the Soar learning curve over the course of my first year as a graduate student at the University of Michigan. My hope was that by writing these guidelines down I might ease the curve for future Soar users. To get the most value from this document, I recommend you read it once at the beginning of your Soar experience and then read it again once you've started using Soar in earnest.

From version 7 onwards, Soar is closely linked to Tcl/Tk. If you wish to get a copy of a Tcl tutorial computer aided instruction package, you could start by looking at Clif Fynt's home page. There is a set of notes on experiences with using Tcl/Tk to construct external environments, written by Richard Young. These may be useful to anyone who is heading down this line, since they highlight some of the good and bad points about Tcl/Tk.

Back to Table of Contents

(G8) Is Soar the right tool for me?

For building AI systems: Soar's strengths are in integrating knowledge, planning, reaction, search and learning within a very efficient architecture. Example tasks include production scheduling, diagnosis, natural language understanding, learning by instruction, robotic control, and flying simulated aircraft.

If all you want to do is to create a small production rule system, then Soar may not be right for you. Also, if you only have limited time that you can spend developing the system, then Soar is probably not the best choice. It currently appears to require a lot of effort to learn Soar, and more practice before you become proficient than is needed if you use other, simpler, systems, such as Jess.

There are, however, a number of basic capabilities that Soar provides as standard. If you need to use these, then Soar may not only be just what you want, but may also be the only system available:

  • Learning and its integration with problem solving
  • Interruptibility as a core aspect of behaviour
  • Large production rule systems
  • Parallel reasoning
  • A knowledge description and design approach based on problem spaces

For cognitive modeling: Soar's strengths are in modeling deliberate cognitive human behavior, at time scales greater than 50 ms. Example tasks that have been explored include human computer interaction tasks, typing, arithmetic, video game playing, natural language understanding, concept acquisition, learning by instruction, and verbal reasoning. Soar has also been used for modeling learning in many of these tasks; however, learning adds significant complexity to the structuring of the task and is not for the casual user. Although many of these tasks involve interaction with external environments and the Soar community is experimenting with models of interaction, Soar does not yet have a standard model for low-level perception or motor control.

Back to Table of Contents

(G9) Is there any support documentation available for Soar?

As mentioned in the previous section, there are manuals, tutorials, and other documents available for Soar users:

  1. Soar 8 Users Manual.
  2. Online Soar kernel and Tcl interface Doxygen documentation.
  3. The Soar Tutorial
  4. Soar Dogma

These documentations provide lots of useful information about programming in Soar, and, in particular, version 8.

The Soar 6 User Manual is still available for browsing on the Web.

Back to Table of Contents

(G10) How can I find out what bugs are outstanding in Soar?

To retrieve information on what bugs are outstanding in Soar, visit the Soar Bugzilla: winter.eecs.umich.edu/soar-bugzilla. Through this system, you can report all bugs in using Soar.

Back to Table of Contents

(G11) Other links and awards in Soar

Links2Go

This page has won an award, but more importantly, there is another list of Soar resources assembled by Links2go.

Links2Go
Soar 

Congratulations! Your page 
(http://www.ccc.nottingham.ac.uk/pub/soar/nottingham/soar-faq.html) has been 
selected to receive a Links2Go Key Resource award in the Soar topic!

The Links2Go Key Resource award is both exclusive and objective. Fewer than 
one page in one thousand will ever be selected for inclusion. Further, unlike 
most awards that rely on the subjective opinion of "experts," many of whom 
have only looked at tens or hundreds of thousands of pages in bestowing their
awards, the Links2Go Key Resource award is completely objective and is based
on an analysis of millions of web pages. During the course of our analysis, we
identify which links are most representative of each of the thousands of topics
in Links2Go, based on how actual page authors, like yourself, index and
organize links on their pages. In fact, the Key Resource award is so
exclusive, even we don't qualify for it (yet)!

Please visit:
www.links2go.com/award/Soar. 

[Now, the site is no longer active, but we did win it!.]

LA Times - Using Interactive Play to Explore How We Think

Game AI programs have become so sophisticated in recent years that a few university researchers have taken an interest in the field, including John E. Laird, a professor of electrical engineering and computer science at the University of Michigan.

Back to Table of Contents

(G12) How does Soar currently stand as a psychology theory?

Sadly, there is not a cut and dried answer to this question. Answering this fully will require you to figure out what you expect from a psychology theory and then evaluate Soar on those criteria. If you expect a theory to predict that humans are intelligent, and that they have been and can be shown to learn in several domains, it is nearly the only game in town. If you require limited short term memory directly in the architecture, that's not in Soar yet (try ACT-R).

With this in mind, there are numerous resources for finding out more. The first port of call should be Newell's 1990 book, Unified Theories Cognition. This may satisfy you. This makes the most coherent case for Soar, although it is slowly becoming out of date with respect to the implementation. There are also two big books, The Soar papers (Vol. 1 and 2), that provide numerous examples of Soar's use. The examples tend to be more biased towards AI, but there are numerous psychology applications in them.

If you go to the ISI paper archive, or often the CHI, ICCM and Cognitive Science conference proceedings, and the Soar Workshop Proceedings, you will find some more up-to-date papers showing what the community is currently working on. You may also find further pointers in the FAQ on individual web sites to be quite useful in seeing the current state of play in the area you are interested.

Richard Young has prepared an annotated bibliography of Soar journal articles and book chapters (but not conference papers) related to psychology that is intended to be complete.

The best cognitive model written in Soar is less clear. There are Soar models of teamwork (Tambe, 1997), procedural learning (Nerb, Ritter, & Krems, 1999), natural language understanding (Lewis, 1996), categorization (Miller & Laird, 1996), syllogistic reasoning (Polk & Newell, 1995), and using computer interfaces (Howes & Young, 1997; Ritter & Bibby, 2001).

There is a book from the National Research Council called "Modeling Human and Organizational Behavior: Applications to Military Simulations" that provides a summary of Soar.

Todd Johnson proposed a list of fundamental cognitive capacities in 1995 that we have started to organize papers around. Each paper (or system) has only been cited once, and it is far from complete, but the framework is now in place for expanding it. If you have suggestions, please do forward them for inclusion.

Nerb, Krems & Ritter (1993; 1999) was later revised, and showed some good matches to the shape of variance in the Power Law taken from 14 subjects and to transfer between abduction problems. The first paper was in Cog Sci proceedings, the second in the Kognitionwissenschaft [German Cognitive Science] journal. The paper from Krems & Nerb (1992) is a monograph of Nerb's thesis, which it is based on.

Peck & John (1992) and later reanalyzed in Ritter & Larkin (1994) is Browser-Soar, a model of browsing. It is fit to 10 episodes of verbal protocol taken from 1 subject. The fit is sometimes quite good and allowed a measure of Soar's cycle time to be computed against subjects. It also suggested fairly strongly (because the model was matched to verbal and non-verbal actions) that verbal protocols are appearing about 1 second after their corresponding working memory elements appear.

Nelson, G., Lehman, J. F., & John, B. E. (1994) proposed a model that integrated multiple forms of knowledge to start to match some protocols taken from the NASA space shuttle test director.  No detailed match.

Aasman, J., & Michon, J. A. (1992) presented a model of driving. While the book chapter does not match data tightly, the later Aasman book (1995) does so very well. The book is not widely available, however.

John, B. E., Vera, A. H., & Newell, A. (1992; 1994) presented a model matched to 10 seconds of a subject learning how to play Mario Brothers. This was available as a CHI conference paper initially.

Chong, R. S., & Laird, J. E. (1997) presented a model that learns how to perform a dual task fairly well. It has not matched to data very tightly, but it shows a very plausible mechanism. This was a preliminary version of Chong's thesis.

Johnson et al. (1991) presented a model of blood typing. The comparison was done loosely to verbal protocols. This was a very hard task for subjects to do, and the point of it was that a model could do the task, and it was not just intuition that allowed users to perform this task.

There have been a couple of papers on integrating knowledge (i.e., models) in Soar. Lehman, J. F., Lewis, R. L., & Newell, A. (1991) and Lewis, R. L., Newell, A., & Polk, T. A. (1989) both presented models that integrate submodels. I don't believe that either have been compared with data, but they show how different behaviours can be integrated and note some of the issues that will arise.

Lewis et al. (1990) address some of the questions discussed here about the state of Soar, but from a 1990's perspective.

Several models in Soar have been created that model the Power Law. These include Sched-Soar (Nerb et al., 1999), physics principle application (Ritter, Jones, & Baxter, 1998), Seible-Soar and R1-Soar (Newell, 1990). These models, although they use different mechanisms, explain the Power Law as arising out of hierarchical learning (i.e., learning parts of the environment or internal goal structure) that initially learns low level actions that are very common and thus useful, and with further practice larger patterns are learned but they occur less often. The Soar models also predict that some of the noise in behaviour on individual trials is different, measurable, and, predicted amounts of transfer between problems.

References

Aasman, J., & Michon, J. A. (1992). Multitasking in driving. In J. A. Michon & A. Akyürek (Eds.), Soar: A cognitive architecture in perspective. Dordrecht, The Netherlands: Kluwer.

Aasman, J. (1995). Modelling driver behaviour in Soar. Leidschendam, The Netherlands: KPN Research.

Chong, R. S., & Laird, J. E. (1997). Identifying dual-task executive process knowledge using EPIC-Soar. In Proceedings of the 19th Annual Conference of the Cognitive Science Society. 107-112. Mahwah, NJ: Lawrence Erlbaum.

John, B. E., Vera, A. H., & Newell, A. (1994). Towards real-time GOMS: A model of expert behavior in a highly interactive task. Behavior and Information Technology, 13, 255-267.

John, B. E., & Vera, A. H. (1992). A GOMS analysis of a graphic, interactive task. In CHI'92 Proceedings of the Conference on Human Factors and Computing Systems (SIGCHI). 251-258. New York, NY: ACM Press.

Johnson, K. A., Johnson, T. R., Smith, J. W. J., De Jong, M., Fischer, O., Amra, N. K., & Bayazitoglu, A. (1991). RedSoar: A system for red blood cell antibody identification. In Fifteenth Annual Symposium on Computer Applications in Medical Care. 664-668. Washington: McGraw Hill.

Krems, J., & Nerb, J. (1992). Kompetenzerwerb beim Lösen von Planungsproblemen: experimentelle Befunde und ein SOAR-Modell (Skill acquisition in solving scheduling problems: Experimental results and a Soar model) No. FORWISS-Report FR-1992-001). FORWISS, Muenchen.

Lehman, J. F., Lewis, R. L., & Newell, A. (1991). Integrating knowledge sources in language comprehension. In Thirteenth Annual Conference of the Cognitive Science Society. 461-466.

Lewis, R. L., Newell, A., & Polk, T. A. (1989). Toward a Soar theory of taking instructions for immediate reasoning tasks. In Annual Conference of the Cognitive Science Society. 514-521. Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.

Lewis, R. L., Huffman, S. B., John, B. E., Laird, J. E., Lehman, J. F., Newell, A., Rosenbloom, P. S., Simon, T., & Tessler, S. G. (1990). Soar as a Unified Theory of Cognition: Spring 1990. In Twelfth Annual Conference of the Cognitive Science Society. 1035-1042. Cambridge:MA.

Nelson, G., Lehman, J. F., John, B. (1994) Integrating Cognitive Capabilities in a Real-Time Task, In Proceedings of the Sixteenth Annual Conference of the Cognitive Science Society.

Nerb, J., Krems, J., & Ritter, F. E. (1993). Rule learning and the powerlaw: A computational model and empirical results. In Proceedings of the15th Annual Conference of the Cognitive Science Society, Boulder, Colorado. 765-770. Hillsdale, New Jersey: LEA.

This was revised and extended and published as:

Nerb, J., Ritter, F. E., & Krems, J. (1999). Knowledge level learning and the power law: A Soar model of skill acquisition in scheduling.Kognitionswissenschaft [Journal of the German Cognitive Science Society] Special issue on cognitive modelling and cognitive architectures, D.Wallach & H. A. Simon (eds.). 20-29.

Using a process model of skill acquisition allowed us to examine the microstructure of subjects' performance of a scheduling task. The model, implemented in the Soar-architecture, fits many qualitative (e.g., learning rate) and quantitative (e.g., solution time) effects found in previously collected data. The model's predictions were tested with data from a new study where the identical task was given to the model and to 14 subjects. Again a general fit of the model was found with the restrictions that the task is easier for the model than from subjects and its performance improves more quickly. The episodic memory chunks learn while scheduling tasks show how acquisition of general rules can be performed without resort to explicit declarative rule generation. The model also provides an explanation of the noise typically found when fitting a set of data to the Power Law -- it is the result of chunking over actual knowledge rather than "average" knowledge. Only when the data are averaged (over subjects here) does the smooth Power Law appear.

Newell, A. (1990). Unified Theories of Cognition. Cambridge, MA: Harvard University Press.

Peck, V. A., & John, B. E. (1992). Browser-Soar: A computational model of a highly interactive task. In Proceedings of the CHI '92 Conference on Human Factors in Computing Systems. 165-172. New York, NY: ACM.

Ritter, F. E., & Larkin, J. H. (1994). Using process models to summarize sequences of human actions. Human-Computer Interaction, 9(3), 345-383.

Tambe, M. (1997). Towards flexible teamwork. Journal of Artificial Intelligence Research, 7, 83-124.

Back to Table of Contents

(G13) What tools are available for Soar?

There are tools and projects which help you to develop your own Soar model. Please, check this site out: sitemaker.umich.edu/soar/soar_tools___projects

SCA and SoarDoc:

Ronald Chong and Robert Wray at Soar Tech have been using SCA to fit some quantitative learning data and make predictions in a real-time performance/learning task (part of the AFRL AMBR program). They presented a paper at the International Conference on Cognitive Modeling on this work:

Wray, R. E. & Chong, R. S. (2003). Quantitative Explorations of Category Learning using Symbolic Concept Acquisition. In Proceedings of the 5th International Conference on Cognitive Modeling. Bamberg, Germany. April.

There are some minor modifications to SCA to update it for Soar 8. They also have (monotonically) extended SCA to map novel feature values to trained values (introducing novel values is often used in psychological "transfer" experiments). The updated source code for SCA, including a description of the transfer task extensions, is available at: www.speakeasy.org/~wrayre/soar/sca/html/index.html

Wray wrote:

Even if you are not currently interested in SCA, I encourage you to visit this URL. We documented SCA using a new tool, SoarDoc, a Doxygen-like tool that automatically generates HTML documentation for Soar systems. It includes a component that creates graphical state descriptions and works with both Soar 7 and Soar 8 source files. SoarDoc was developed by Dave Ray at Soar Technology.

Visual Soar: Visual Soar is a development environment for Soar programming. Documentation and downloads can be found at www.eecs.umich.edu/~soar/projects/visualsoar/.

Herbal: Herbal is a high-level behavior representation language. It supports creating a cognitive model for Soar architecture. For more information, please visit acs.ist.psu.edu/projects/Herbal/.

Back to Table of Contents

(G14) Can Soar be embedded?

Soar 8.6.0 addresses this problem most directly now (05/05).

Paul Benjamin wrote:

A student at Pace has embedded Soar within Java. There is a package called feather from NIST that implements a TclInterpreter class in Java, and the student extended that class to a SoarSession class. He used it to write a poker-playing Soar program. I also used it to connect Soar to our robot. With minor changes, it can be used to connect any Java system to Soar.

His source, and all the package info, is at www.codeblitz.com/poker.html.

Another option is to take the C library header files and run SWIG over them (www.swig.org). SWIG is able to generate wrapping code to interface Java, Perl, Tcl, Python, and others to any C/C++ library.

There are several ways that Soar has been tied to other pieces of software. A now out of date overview is available from:

Ritter, F. E. & Major, N. P. (1995). Useful mechanisms for developing simulations for cognitive models. AISB Quarterly, 91(Spring), 7-18.

A list of ways to fit Soar to an application, in order of complexity, is:

You can tie Soar to itself through multi-agents, that is, having multiple Soar agents and having them talk with each other.

[I believe this is originally by Tom Head, around Oct '96.]

Reading and writing text from a file can be used for communication. However, using this mechanism for inter-agent communication would be pretty slow and you'd have to be careful to use semaphores to avoid deadlocks. With Soar 7, I see a natural progression from Tcl to C in the development of inter-agent communication.

  1. Write inter-agent communication in Tcl. This is possible with a new RHS function (called "tcl") that can execute a Tcl script. The script can do something as simple as send a message to a simple simulator (which can also be written in Tcl). The simulator can then send the message to the desired recipient(s). You could also do things such as add-wme in a RHS but I'd advise against it since its harder to see what's going on and more error prone.
  2. Move the simulator into C code. To speed up the simulated world in which the agents interact, recode the simulator in C. Affecting the simulator can be accomplished by adding a few new Tcl commands. The agents would be largely unchanged and the system would simply run faster.
  3. Move communication to C. This is done by writing Soar I/O functions as documented in section 6.2 of the Soar Users Manual. This is the fastest method.

A generic AI engine for video games

Question, Date: April 2003

I would like to know whether Soar is always a stand-alone product or if it can be incorporated in another system. I remember John Laird and Mike Van Lent presented a paper at the GDC on why Soar should be used as a generic AI engine for video games. I imagine that game developers would need to somehow embed Soar in their games the way they to third party graphics engines. So is this possible or would game and other commercial developers need to use the sockets interface that I believe the Quake bots use?

Answer:

Bob Wray wrote:

Yes, it's completely possible to run Soar within an application. We are using Unreal Tournament for an application and have a version in which Soar is complied into the game. I can run at least five agents (haven't tried more than that) within the game process and maintain game framerate on my 1 Ghz P4 laptop.

This is not at all a plug-and-play solution but there is a API that makes it relatively straightforward to embed Soar, especially, if you already are comfortable with interfacing software.

One limitation of embedding Soar agents is that you generally lose the user interface (UI) for Soar (the maintained UI is implemented in Tcl). We handle this in the application by using a socket-based connection to Soar/Tcl for development and the embedded version of performance situations.

Back to Table of Contents

(G15) Resources for teaching Soar

Soar has been taught as a component of non-programming classes on cogntive architectures at several universities, including at least, CMU, Michigan, Sterling in Scotland, Pace, Penn State, Portsmouth, and in Japan.

If you want students to program with Soar, that might be difficult to do to a great depth in two weeks, but as Michigan folks, Ritter, and Young have offered hands-on one-day tutorials, so clearly you can cover something in a day. Note that the day is about 6 hours of instruction. This can take at least 6 hours of instruction in a university class to cover, or two to three weeks in a class, more if you give homework. In class you get more out of it because the exercises are done in more detail. Herbal has also been used to teach Soar at a conference and in the classroom.

More resources can be found at the Ritter's class website. Please, contact Frank Ritter.

Back to Table of Contents

(G16) Who has worked on Soar FAQ?

The current Soar FAQ has been initiated and better shaped with invaluable help from former colleagues as follows:

Kevin Tor: tor@cse.psu.edu
Alexander B. Wood: abwood@unity.ncsu.edu
Gordon D. Baxter: gbaxter@psych.york.ac.uk
Marios Avaramides: avaamides@psych.ucsb.edu

For updating the current version of Soar FAQ, Bob Marinier (rmarinie@eecs.umich.edu) provided more than 90 comments and suggestions.

Back to Table of Contents

Section 2: Technological Issues

(T1) What is search control?

Search control is knowledge that controls search process in that it guides search through comparing proposed alternatives. In Soar, search control is encoded in production rules that create preferences for operators.

Bob Marinier (rmarinie@eecs.umich.edu) wrote:

Search control rules are rules that prefer the selection of one operator over another. Their purpose is to avoid useless operators and direct the search toward the desired state. Theoretically, you could encode rules that select the correct operator for each state. However, you would have had to already solve the problem yourself to come up with those rules. Our goal is to have the program solve the problem, using only knowledge available from the problem statement and possibly some general knowledge about problem solving. Therefore, search control will be restricted to general problem solving heuristics.

Back to Table of Contents

(T2) What is the data-chunking problem?

Data chunking is creation of chunks that allow for either the recognition or retrieval of data that is currently in working memory. Chunking is usually thought of as a method for compiling knowledge or speed-up learning, and not for moving data from working memory into long term memory. Data chunking is a technique in which chunking does create such recognition or retrieval productions, and thus allows Soar to perform knowledge-level learning.

Simplistically, then, data chunking is the creation of chunks that can be represented by the form a=>b i.e., when 'a' appears on the state, the data for 'b' does too. Another example is "The capital of France? => Paris".

Bob Marinier wrote:

The data-chunking problem is discussed in section 6.4 of Newell's "Unified Theories of Cognition" (1990).

"This is what we call the data-chunking problem - that chunks that arise from deliberate attempts to learn an arbitrarily given data item will have the item itself somewhere in the conditions, making the chunk useless to retrieve the item. Normally, chunking acquires procedures to produce an effect. When what is given is a data item, not a bit of behavior, the attempt to convert it to procedural learning seems stymied". (p 327)

To solve the data-chunking problem, Newell (1990) suggests the following. Note, GID is an example object that Soar is trying to learn to recognize:

"The key idea is to separate generating an object to be recalled from testing it. The desired object here is GID. We want the process that generates GID not to know that it is the response that is to be made - not to be the process that tests for the item. Thus, to achieve the required learning, Soar should create for itself a task to be solved by generate and test. It is alright for the test to contatin the result, namely, GID. The test is to find an instance of GID, so the test not only can have GID in some condition, it should have it. As long as the generator doesn't produce GID by consulting the given object (GID), then GID will not occur in the conditions of the chunk that will be built". (p 331-332)

For more information, see question T3 and read section 6.4 of "Unified Theories of Cognition" by Newll (1990).

Back to Table of Contents

(T3) What is the data-chunking generation problem?

Whenever you subgoal to create a datachunk, you have to generate everything in the subgoal that might be learned, and then use search control to make sure that the chunks you build are correct. Doing this, without touching the supergoal, means that the chunk that is learned does not depend on the cue. The cue is then used in search control (which is not chunked) to select the object (the response) to return.

Back to Table of Contents

(T4) What do all these abbreviations and acronyms stand for?

  • CSP: Constraint Satisfaction Problem
  • EBG: Explanation-Based Generalisation
  • EBL: Explanation-Based Learning
  • GOMS: Goals, Operators, Methods, and Selection rules
  • HI-Soar: Highly Interactive Soar
  • ILP: Inductive Logic Programming
  • NNPSCM: New New Problem Space Computational Model
  • NTD: NASA Test Director
  • PEACTIDM: Perceive, Encode, Attend, Comprehend, Task, Intend, Decode, Move
  • SCA - Symbolic Concept Acquisition
  • PE: Persistent elaboration
  • IE: I-supported elaboration

Back to Table of Contents

(T5) What is this NNPSCM thing anyway?

Really, this is a number of questions rolled into one:

  1. What is the PSCM?
  2. What is the NNPSCM?
  3. What are the differences between the two?

What is the PSCM?

The Problem Space Computational Model (PSCM) is an idea that revolves around the commitment in Soar using problem spaces as the model for all symbolic goal-oriented computation. The PSCM is based on the primitive acts that are performed using problem spaces to achieve a goal. These primitive acts are based on the fundamental object types within Soar i.e., goals, problem spaces, states and operators. The functions that they perform are shown below:

Goals

  1. Propose a goal.
  2. Compare goals.
  3. Select a goal.
  4. Refine the current information about the current goal.
  5. Terminate a goal.

    Problem Spaces

  6. Propose a problem space for the goal.
  7. Compare problem spaces for the goal.
  8. Select a problem space for the goal.
  9. Refine the information available about the current problem space.

    States

  10. Propose an initial state.
  11. Compare possible initial states.
  12. Select an initial state.
  13. Refine the information available about the current state.

    Operators

  14. Propose an operator.
  15. Compare possible operators.
  16. Select an operator.
  17. Refine the information available about the current operator.
  18. Apply the selected operator to the current state.

More details about exactly what these functions do can be found in the current User Manual.

What is the NNPSCM?

The New New Problem Space Computational Model (NNPSCM) addresses some of the issues that made the implementation of the PSCM run relatively slow. It reformulates some of the issues within the PSCM without actually removing them, and hence changes the way in which models are implemented but we are not aware of a model that has been fundamentally influenced by this change. Starting with version 7.0.0 of Soar, all implementation is performed using the NNPSCM; in later releases of version 6.2, you can choose which version you require (NNPSCM or non-NNPSCM) when you build the executable image for Soar. The easiest way to illustrate the NNPSCM is to look at the differences between it and the PCSCM.

What are the differences between the two?

The NNPSCM and the PSCM can be compared and contrasted in the following ways:

  1. The nature of problem space functions for NNPSCM and PSCM remain essentially the same as those described in Newell, A., Yost, G.R., Laird, J.E., Rosenbloom, P.S., & Altmann, E. (1991). Formulating the problem space computational model. In R.F. Rashid (Ed.), Carnegie-Mellon Computer Science: A 25-Year Commemorative (255-293). Reading, MA: ACM-Press (Addison-Wesley).
  2. The goal state from the PSCM now simply becomes just another state, rather than being treated as a separate, special state.
  3. The need to select between problem spaces in the NNPSCM does not require any decision making process. The problem space is simply formulated as an attribute of the state. It can be assigned in a lightweight way using an elaboration rule, or it can be deliberately assigned by an operator application. Currently, this is left up to programmer or modeler.
  4. Models implemented using NNPSCM are generally faster than their PSCM equivalents, becuase less decision cycles are required. Less DCs are required because there is no need to decide between problem spaces, and, in later versions, states.
  5. Using the NNPSCM is presumed to allow better inter-domain, and inter-problem-space transfer of learning to take place.
  6. The use of the NNPSCM should help in the resolution and understanding of the issues involved in external interaction.

The differences may become more evident if we look at code examples (written using Soar version 6.2.5) for the farmer, wolf, goat, and cabbage problem that comes as a demo program in the Soar distribution.

PSCM Code

(sp farmer*propose*operator*move-with
     (goal <g> ^problem-space <p>
                     ^state <s>)
     (<p> ^name farmer)
     (<s> ^holds <h1> <h2>)
     (<h1> ^farner <f> ^at <i>)
     (<h2> ^<< wolf goat cabbage >> <value>
                 ^at <i>)
     (<i> ^opposite-of <j>)
     -->
     (<g> ^operator <o>)
     (<o> ^name move-with
                ^object <value>
                ^from <i>
                ^to <j>))
 

NNPSCM Code

(sp farmer*propose*move-with
(state <s> ^problem-space <p>) ; goal <g> has disappeared
(<p> ^name farmer)             ;<p> is added with d DC
       (<s> ^holds <h1> <h2>)
       (<h1> ^farner <f> ^at <i>)
       (<h2> ^<< wolf goat cabbage >> <value>
                 ^at <i>)
       (<i> ^opposite-of <j>)
       -->
       (<s> ^operator <o>)
       (<o> ^name move-with
                 ^object <value>
                 ^from <i>
                 ^to <j>))
 

On the face of it, there do not appear to be many differences, but when you look at the output trace, the consistency of the operator use versus including state and problem space assignment intervening, and the improvement in speed become more apparent:

PSCM Trace

0: ==>G: G1
1:    P: P1 (farmer)
2:    S: S1
3:    ==>G: G3 (operator tie)
4:       P: P2 (selection)
5:       S: S2
6:       O: O8 (evaluate-object O1 (move-alone))
7:       ==>G: G4 (operator no-change)
8:          P: P1 (farmer)
9:          S: S3
10:          O: C2 (move-alone)
 

NNPSCM Trace

0:==>S: S1
1:   ==>S: S2 (operator tie)
2:      O: O8 (evaluate-object O1 (move-alone)
3:      ==>S: S3 (operator no-change)
4:         O: C2 (move-alone)
 

Back to Table of Contents

(T6) How does Soar 7 differ from Soar 6?

(T6-1) Question from Monica Weiland [monica_weiland@chiinc.com]

Basically, the Soar kernel architecture in Soar 7 is the same as what is in Soar 6, with additional bug fixes, and changes to the timers to be more accurate and informative when the 'stats' cmd is issued. There were also changes to using multiple agents and the NNPSCM is the only PSCM model supported (in 6, both NNPSCM (no explicit problem space slot) and the PSCM (explicit problem space slot) were supported). The advantages of Soar7 include all the user extensions that can be done by using Tcl for the user interface.

In the Soar distribution there is a tool for converting from Soar 6 format productions to Soar 7. It was written by Doug Pearson and it's called convert (written in C). I don't know if it is included in the Mac distribution, but I would assume it is. It does a good job of converting productions; most applications run after being processed by this routine. If Monica has the SimTime productions, she should be able to convert to Soar 7. If she has trouble with the conversions, she can contact me and I'll help her figure them out.

Answer from: "Karen J. Coulter" [kcoulter@eecs.umich.edu]
Date: June 9, 1997.

There are also some notes available noting some explicet changes in the command set that were presented as part of a talk at the Soar 15th workshop. These notes are out of date, but not so out of date to be useless. The directory where to find commands1.ps.Z and commands2.ps.Z.

(T6-2) Question from Tony Hirst

In general, what does just using a ^problem-space.name flag buy you apart from providing a conventional label within which to enable operator proposition? Is there a strong/formal way in which the problem-space elaboration was intended to be used (for example, we might encapsulate state required within the problem space by copying only those state <s> elaborations necessary for use in that problem space onto ^problem-space <p> (though this incurs an overhead that the rather more general:

<s> ^problem-space (<p> ^name whatever)
-->
<p> ^pstate <s>
 

avoids); prodns inside the problem space may then make changes to stuff dangling off <p> (or ^problem-space.pstate ) rather than explicitly to <s> (even though it's the same stuff... the point is that changes are forced to be made ostensibly within the problem space)). Problem specific elaborations should also be made to <p> (<ps>) rather than <s> by explicitly making changes to either ^top-state <ts> or <p> (^problem-space.pstate <ps>), rather than <s>, we are forced to think about and state the context of the state changes we're making.

Finally, is there a convention for naming problem spaces within subgoal spaces (e.g., if operator.name thing reaches an impasse an forces a subgoal, should the subgoal be elaborated with problem-space.name thing, or an arbitrary name?)

Answer from Randy Jones

My opinion is that the ^problem-space flag is an anachronism that should be discarded, especially for non-trivial Soar programs. The flag originally arose from Newell and Simon's problem-space hypothesis, and the notion that people tend to employ specific sets of methods and goals for specific types of problems. What this "flag-based" representation neglects, however, is the potential for sharing methods and goals across types of problems that we might normally view as being in distinct problem spaces. In TacAir-Soar, for example, we have *many* operators that can apply in a variety of different states, independent of the problem-space flag on that state. In general, (and again in my opinion), operators should be sensitive to patterns of data represented on the "current state", rather than being a slave to a single, discrete, problem-space flag. This allows the use of operators to transfer across problem spaces in useful, and sometimes surprising ways. Under this view, problem spaces "emerge" from patterns of data, rather than being defined by a single flag.

Answer from Richard Lewis, Date: February 10, 1999

While I agree with much of what Randy says, I wouldn't be too quick to discard the use of a problem-space flag. The problem-space flag permits the agent to decide (based on some knowledge) to solve this problem in some particular way, then ti change its decision later and attempt a different way, etc. It is an additional layer of deliberate control that allows the agent to "hold in place" the outcome of some decision and use that decision to guide problem solving behavior over a period of time that extends beyond a single decision cycle. Thus, the agent is not just slave to whatever immediate associations come to mind.

What I am really advocating is a view that keeps a mix of the data-driven, opportunistic style that Randy describes, along with the ability to exert more control over some extended periods of time. Such a mix may hinge in part on using the problem space flag in ways that we haven't usually done in the past: as search control rather than generator. There's a sense in which this kind of mix can't be discarded as long as it is architecturally possible, the system is learning, and we can't see any clear reasons why the agent in principle can't arrive, via learning, at a point where it behaves in such a way.

Answer from John Laird, Date: February 10, 1999

On the ^problem-space.name issue:

In earlier versions of Soar, the problem space was selected just like the operator, and thus was open to preferences. However, for the reasons Randy mentioned (problem spaces may be more emergent from many properties of the state than just a specific symbol) we abandoned the selection of the problem space. For many tasks, having a problem space symbol might be a good way to discriminate during operator selection. The convention that I've adopted is to copy the name of a super-operator to be the name of the state created below it. This doesn't cover tie impasses or state no-change, but works very well for operator no-changes.

Back to Table of Contents

(T7) What does using a ^problem-space.name flag buys you apart from providing a conventional label within which to enable operator proposition?

From Randy Jones:

My opinion is that the ^problem-space flag is an anachronism that should be discarded, especially for non-trivial Soar programs.  The flag originally arose from Newell and Simon's problem-space hypothesis, and the notion that people tend to employ specific sets of methods and goals for specific types of problems.  What this "flag-based" representation neglects, however, is the potential for sharing methods and goals across types of problems that we might normally view as being in distinct problem spaces.  In TacAir-Soar, for example, we have *many* operators that can apply in a variety of different states, independent of the problem-space flag on that state.  In general (and again in my opinion), operators should be sensitive to patterns of data represented on the "current state", rather than being a slave to a single, discrete, problem-space flag.  This allows the use of operators to transfer across problem spaces in useful, and sometimes surprising, ways.  Under this view, problem spaces "emerge" from patterns of data, rather than being defined by a single flag.

From Richard Lewis:

While I agree with much of what Randy says, I wouldn't be too quick to discard the use of a problem-space flag.  The problem-space flag permits the agent to decide (based on some knowledge) to solve its problem in some particular way, then to change its decision later and attempt a different way, etc. It is an additional layer of deliberate control that allows the agent to 'hold in place' the outcome of some decision and use that decision to guide problem solving behavior over a period of time that extends beyond a single decision cycle.  Thus, the agent is not just slave to whatever immediate associations come to mind. What I'm really advocating is a view that keeps a mix of the data-driven, opportunistic style that Randy describes, along with the ability to exert more control over some extended periods of time.  Such a mix may hinge in part on using the problem space flag in ways that we haven't usually done in the past: as search control rather than generator.  There's a sense in which this kind of mix can't be discarded as long as it is architecturally possible, the system is learning, and we can't see any clear reasons why the agent in principle can't arrive, via learning, at a point where it behaves in such a way.

From John Laird:

I agree with just about everything Randy said. On the ^problem-space.name issue - in earlier versions of Soar, the problem space was selected just like the operator, and thus was open to preferences. However, for the reasons Randy mentioned (problem spaces may be more emergent from many properties of the state than just a specific symbol) we abandoned the selection of the problem space.  For many tasks, having a problem space symbol might be a good way to discriminate during operator selection.  The convention that I've adopted is to copy the name of a super-operator to be the name of the state created below it. This doesn't cover tie impasses or state no-change, but works very well for operator no-changes.

Back to Table of Contents

Section 3: Programming Questions

(P1) How can I make my life easier when programming in Soar?

There are a number of ways to make your life easier when programming in Soar. Some simple high level considerations are:

  • Use a programming tool, such as Visual Soar or Herbal (explained below)
  • Use the Soar debugger or the TSI
  • Re-use existing code
  • Cut and paste productions and code
  • Work mainly on the top level problem space, using incremental problem space expansion
  • Use the integrated Emacs environment, SDE, or one of the visual editors
  • Turn chunking (the learning mechanism) off
  • Use the Tcl/Tk to write simulations for the model to talk to, rather than use external simulations

ViSoar

Visual Soar: It is a development environment to help users create an agent under Soar architecture.

The Tcl/Tk Soar Interface (TSI) is part of Soar 7 and 8.

Herbal: It is a high-level behavior represention language.

A Brief History of Soar Interfaces

The first Soar interface was probably the command line from OPS5. One of the first Soar graphical interfaces was written by Amy Unruh and ran on TI lisp machines. Brian Milnes also wrote a graphical interface that ran in Common lisp under X windows. Blake Ward probably wrote the first Emacs mode for Soar. Frank Ritter revised this, and then Mike Hucka revised it, and then Frank revised it, and this went on for a while until it went to Mike and stayed at Michigan. While it was with Frank there was a submode for writing TAQL code (Ritter, 1991b). Various reports were included in the Soar Workshop Proceedings. There was a manual (Ritter, Hucka, & McGinnis, 1992). These were fairly widely used systems, maybe 1/2 of the Soar users used them at the time. This mode is still available.

Frank Ritter wrote a graphic user interface for Soar, the Developmental Soar Interface, or DSI, in Common Lisp using Garnet. This was reported in his thesis (Ritter, 1993; Ritter & Larkin, 1994) and at CHI (Ritter, 1991a). It was used to generate the initial polygons for the Soar video (Lehman, Newell, Newell, Altmann, Ritter, & McGinnis, 1994). This interface probably had about 10 users at the most, and was abandoned when Soar was implemented in C.

The Tcl/Tk Soar Interface (TSI) is a successor semi-graphical interface started around 1996 taking advantage of including Tcl/Tk with Soar (Ritter, Jones, & Baxter, 1998). Numerous people have now contributed to it. It is currently being developed at Michigan.

In 1995, a rationalised list of commands aliases was proposed for the command line (Nichols & Ritter, 1995). These were used in Soar7 and I believe in Soar 8. An unpublished study supported the results that even novices could profit from aliases.

New interfaces to Soar include a revised version of the TSI (version 3, 6/00), which includes viewers for working memory tree, production match, and chunks (contact Karen Coulter (kcoulter@eecs.umich.edu) and/or Mazin Assanie (mazina@eecs.umich.edu)). A Soar debugger to provide greater control over breakpoints, etc. is also in the works (contact Glenn Taylor, glenn@soartech.com). Visual Soar is an environment in Java to help make sure that when writing Soar programs that all attribute names are correct, and to cut and paste and reuse attribute names and sets of names. Laird, Jones, and Bauman at Michigan is working on this effort. A related effort by Tony Hirst is ongoing at the Open University (a.j.hirst@open.ac.uk).

References

Lehman, J. F., Newell, A., Newell, P., Altmann, E., Ritter, F., & McGinnis, T. (1994). The Soar Video. 11 min. video, The Soar Group, Carnegie-Mellon University.

Nichols, S., & Ritter, F. E. (1995). Theoretically motivated tool for automatically generating command aliases. In CHI '95, Human Factors in Computer Systems. 393-400. New York, NY: ACM.

Ritter, F. E. (1991a). How the Soar interface uses Garnet. Video (2 min.) shown at the Garnet user interface development environment special interest subgroup meeting at the 1991 Human Factors in Computing Systems Conference (CHI'91).

Ritter, F. E. (1991b). TAQL-mode Manual. The Soar group.

Ritter, F. E. (1993). TBPA: A methodology and software environment for testing process models' sequential predictions with protocols (Technical Report No. CMU-CS-93-101). School of Computer Science, Carnegie Mellon University, Pittsburgh, PA.

* Ritter, F. E., & Larkin, J. H. (1994). Using process models to summarize sequences of human actions. Human-Computer Interaction, 9(3), 345-383.

Ritter, F. E., Hucka, M., & McGinnis, T. F. (1992). Soar-mode Manual (Tech. No. CMU-CS-92-205). School of Computer Science, Carnegie-Mellon University.

Ritter, F. E., Jones, R. M., & Baxter, G. D. (1998). Reusable models and graphical interfaces: Realising the potential of a unified theory of cognition. In U. Schmid, J. Krems, & F. Wysotzki (Eds.), Mind modeling - A cognitive science approach to reasoning, learning and discovery. 83-109. Lengerich, Germany: Pabst Scientific Publishing.

Back to Table of Contents

(P2) Are there any guidelines on how to name productions?

Productions will load as long as their names are taken from a set of legal characters, essentially alphanumerics and "-" and "*". Names consisting only of numerics are not allowed.

Soar programmers tend to adopt a convention whereby the name of a production describes what the rule does, and where it should apply. Typically, the conventions suggest that names have the following general form:

 
problem-space-name*state-name*operator-name*action

How you choose your naming convention is probably less important than the fact that you do use one.

Note that, to name working memory elements, Soar uses single alphabetic character followed by a number, such as p3. If you name a production this way it will not be printable. (It is also poor style.)

Bob Marinier stated some tips for naming productions as follows.

Back to Table of Contents

(P3) Why did I learn a chunk there?

Soar generally learns a chunk when a result is created in a superstate by a production which tests part of the current subgoal.

e.g., the production:

sp {create*chunk1
   (state ^superstate)
   -->
   (^score 10)}
 

creates a preference for the attribute "score" with value 10.

That mechanism seems simple enough. Why then do you sometimes get chunks when you do not expect them? This is usually due to shared structure between a subgoal and a superstate. If there is an object in the subgoal which also appears in a superstate, then creating a preference for an attribute on that object, will lead to a chunk. These preferences in a superstate are often called "results" although you are free to generate any preference from any subgoal, so that term can be misleading.

For example, suppose that working memory currently looks like: 

(S1 ^type T1 ^name top ^superstate nil)
(T1 ^name boolean)
(S2 ^type T1 ^name subgoal ^superstate S1)
 

so S2 is the substate and S1 is the superstate for S2. T1 is being shared. In this case, the production:

sp {lead-to*chunk2
   (state <s> ^name subgoal)
   -->
   (<s> ^size 2)}
 

will create a chunk, even though it does not directly test the superstate. This is because T1 is shared between the subgoal and the superstate, so adding ^size to T1, adds a preference to the superstate.

What to do?

Often the solution is to create a copy of the object in the subgoal. So, instead of (S2 ^type T1) create (S2 ^type T2) and (T2 ^name boolean).

For example (in psuedo code),

sp {copy*superstate*type
   (state ^superstate)
   (^type)
   (^name)
   -->
   (^type)
   (^name)}
 

This will copy the ^type attribute to the subgoal and create a new identifier (T2) for it. Now you can freely modify T2 in the subgoal, without affecting the superstate.

Back to Table of Contents

(P4) Why didn't I learn a chunk there (or how can I avoid learning a chunk there)?

There are a number of situations where you can add something to the superstate and not get a chunk:

(1) Learning off

If you run Soar and type "learn -off" all learning is disabled. No chunks will be created when preferences are created in a superstate. Instead, Soar only creates a "justification". (See below for an explanation of these.)

You can type "learn" to see if learning is on or off, and "learn -on" will make sure it is turned on. Without this, you cannot learn anything.

(2) Chunk-free-problem-spaces

You can declare certain problem spaces as chunk-free and no chunks will be created in those spaces. The way to do this is changing right now (in Soar7) because we no longer have explicit problem spaces in Soar. If you want to turn off chunking like this, check the manual.

(3) Quiescence t

If your production tests ^quiescence t, it will not lead to a chunk. For example,

sp {lead-to*chunk1
   (state <s1> ^name subgoal ^superstate <s2>)
   -->
   (<s2> ^score 10)}
 

will create a chunk, whilst

sp {lead-to*no-chunk
   (state ^name subgoal ^superstate ^quiescence t)
   -->
   (^score 10)}
 

will not create a chunk (you just get a justification for ^score 10). You can read about the reasons for this in the Soar manual. You also do not get a chunk if a production in the backtrace for the chunk tested ^quiescence t:

For example,

sp {create*score
   (state ^name subgoal ^quiescence t)
   -->
   (^score 10)}
sp {now-expect-chunk*but-dont-get-one
   (state ^name subgoal ^score 10 ^superstate)
   -->
   (^score 10)}
 

The test for ^quiescence t is included in the conditions for why this chunk was created--so you get a justification, not a chunk.

A point to note is that having tested ^quiescence t, the effect of not learning chunks is applied recursively. If you had a production: 

sp {lead-to*second-chunk
   (state ^name medium-goal ^superstate)
   (^score 10)
   -->
   (^score-recorded yes)}
 

and you have a goal stack:

(S1 ^name top ^superstate nil)
(S2 ^name medium-goal ^superstate S1)
(S3 ^name subgoal ^superstate S2)
 

then if lead-to*chunk1 leads to ^score 10 being added to S2 and then lead-to*second-chunk fires and adds ^score-recorded yes to S1, you will get two chunks (one for each result). However, if you use lead-to*no-chunk instead, to add ^score 10 to S2, then lead-to*second-chunk will also not generate a chunk, even though it does not test ^quiescence t itself. That is because ^score 10 is a result created from testing quiescence.

Back to Table of Contents

(P5) What is a justification?

Any time a subgoal creates a preference in a superstate, a justification is always created, and a chunk will also be generated unless you have turned off learning in some manner (see above). If learning has been disabled, then you only get a justification. A justification is effectively an instantiated chunk, but without any chunk being created.

For example, let's say:

sp {lead-to*chunk1 (state ^name subgoal ^superstate) (^name top) --> (^score 10)} leads to the chunk:

sp {chunk-1
   :chunk
   (state ^name top)
   -->
   (^score 10)}
 

If working memory was:

(S1 ^name top ^superstate nil ^score 10)
(S2 ^name subgoal ^superstate S1)
 

then if you typed "preferences S1 score 1" you would see:

Preferences for S1 ^score:
acceptables:
10 +
From chunk-1
 

(The value is being supported by chunk-1, an instantiated production just like any other production in the system).

Now, if we changed the production to:

sp {create*no-chunk
   (state ^name subgoal ^superstate ^quiescence t)
   (^name top)
   -->
   ( ^score 10)}
 

We do not get a chunk anymore. We get justification-1. If you were to print justification-1 you would see:

sp {justification-1
   :justification ;not reloadable
   (S1 ^name top)
   -->
   (S1 ^score 10)}
 

This has the same form as chunk-1, except it is just an instantiation. It only exists to support the values in state S1. When S1 goes away (i.e., in this case when you do init-soar ) this justification will go away too. It is like a temporary chunk instantiation. Why have justifications? Well, if you now typed "preferences S1 score 1" you would see:

Preferences for S1 ^score:
acceptables:
10 +
From justification-1
 

Justification-1 is providing the support for the value 10. If the subgoal, S2, goes away, this justification is the only reason Soar retains the value 10 for this slot. If later, the ^name attribute of S1 changes to "driving" say, this justification will no longer match (because it requires ^name top) and the justification and the value will both retract.

Back to Table of Contents

(P6) How does Soar decide which conditions appear in a chunk?

Soar works out which conditions to put in a chunk by finding all the productions that led to the final result being created. It sees which of those productions tested parts of the superstate and collects all those conditions together.

For example:

(S1 ^name top ^size large ^color blue ^superstate nil)     ;# The superstate
---------------------------------                          ;# Conceptual boundary

(S2 ^superstate S1)                                        ;# Newly created subgoal.

sp {production0
   (state ^superstate nil)
   -->
   (^size large ^color blue ^name top)}

If we have:

sp {production1
   (state ^superstate)
   (^size large)
   -->
   (^there-is-a-big-thing yes)}
 

and

sp {production2
   (state ^superstate)
   (^color blue)
   -->
   (^there-is-a-blue-thing yes)}
 

and

sp {production3
   (state ^superstate)
   (^name top)
   -->
   (^the-superstate-has-name top)}
 

and

sp {production1*chunk
   (state ^there-is-a-big-thing yes
          ^there-is-a-blue-thing yes
          ^superstate)
   -->
   (^there-is-a-big-blue-thing yes)}
 
 

and working memory contains (S1 ^size large ^color blue) this will lead to the chunk:

sp {chunk-1
   :chunk
   (state ^size large ^color blue)
   -->
   (^there-is-a-big-blue-thing yes)}
 

The size condition is included because production1 tested the size in the superstate, created ^there-is-a-big-thing attribute and this lead to production1*chunk firing. Similarly, for the color condition (which was also tested in the superstate and lead to the result ^there-is-a-big-blue-thing yes). The important point is that ^name is not included. This is because even though it was tested by production3, it was not tested in production1*chunk and therefore the result did not depend on the name of the superstate.

Back to Table of Contents

(P7) Why does my chunk appear to have the wrong conditions?

See above for general description of how chunk conditions are computed. If you have just written a program and the chunks are not coming out correctly, then try using the "explain" tool.

So, using the example of how conditions in chunks are created (shown above), if the chunk is:

sp {chunk-1
   :chunk
   (state  ^size large ^color blue)
   -->
   (^there-is-a-big-blue-thing yes)}
 

and you type "explain chunk-1" you will get something like:

sp {chunk-1
   :chunk
   (state ^color blue ^size large)
   -->
   (^there-is-a-big-blue-thing yes +)}
   1 : (state ^color blue)              Ground : (S1 ^color blue)
   2 : (^size large)                    Ground : (S1 ^size large)
 

This shows a list of conditions for the chunk and which "ground" (i.e., superstate working memory element) they tested.

If you want further information about a particular condition you can then type: "explain chunk-1 2" (where 2 is the condition number -- in this case (<s1>; ^size large)) to get: 

Explanation of why condition (S1 ^size large) was included in chunk-1
Production production1 matched
     (S1 ^size large) which caused
production production1*chunk to match
     (S2 ^there-is-a-big-thing yes) which caused
A result to be generated.
 

This shows that ^size large was tested in the superstate by production1, which then created (S2 ^there-is-a-big-thing yes). This in turn caused the production production1*chunk to fire and create a result (in this case ^there-is-a-big-blue-thing yes) in the superstate, which leads to the chunk.

This tool should help you spot which production caused the unexpected addition of a condition, or why a particular condition did not show up in the chunk.

Back to Table of Contents

(P8) How is it possible for Soar to generate a duplicate chunk?

Question from Bill Kennedy:

If the new chunk is a duplicable, wouldn't the original have already fired? Is it the case that when all the applicable productions fire to resolve an impasse, the chunking then generalizing processes could build a chunk identical to one that already fired?

Answer from John Laird (Nov. 10, 2002):

Two similar results can be created during the same decision cycle, which in turn can lead to two identical chunks.

Also, it is possible to generate a result in a subgoal that is already created by a chunk if the result doesn't lead to progress in the problem solving - that is, the existence of the result from the chunk isn't tested in the subgoal (so the result is created even though it is essentially already there) and it doesn't resolve the impasse, etc. (so even after the result is created the impasse is still there).

Back to Table of Contents

(P9) What is all this support stuff about? (Or why do values keep vanishing?)

There are two forms of "support" for changes to working memory: o-support and i-support. O-support stands for "operator support" and means the preference behaves in a normal computer science fashion. If you create an o-supported preference ^color red, then the color will stay red until you change it.

How do you get an o-supported preference? The exact conditions for this may change, but the general rule of thumb is this:

"You get o-support if your production tests the ^operator attribute or creates structure on an operator"

(Specifically under Soar.7.0.0.beta this is o-support-mode 2 -- which is the mode some people recommend since they find it much easier to understand than o-support-mode 0 which is the current default).

e.g.,

sp {o-support
   (state ^operator)
   (^name set-color)
   -->
   (^color red)}
 

the ^color red value gets o-support.

I-support, which stands for "instantiation support", means the preference exists only as long as the production which created it still matches. You get i-supported productions when you do not test an operator:

e.g.,

sp {i-support
   (state ^object)
   (^next-to)
   -->
   (^near)}
 

In this case

^near
 

will get i-support. If obj1 ever ceases to be next to obj2, then this production will retract and the preference for

^near
 

will also retract. Usually this means the value for ^near disappears from working memory.

To change an o-supported value, you must explicitly remove the old value, e.g.,

^color red -  (the minus means reject the value red)
^color blue + (the plus means the value blue is acceptable)
 

while changing an i-supported value requires just that the production retracts. The use of i-support makes for less work and can be useful in certain cases, but it can also make debugging your program much harder and it is recommended that you keep its use as an optimization to a minimum. By default, when you do state elaboration you automatically get i-support, whereas applying, creating or modifying an operator as part of some state structure will lead to o-support.

(One point worth noting is that operator proposals are always i-supported, but once the operator has been chosen, it does not retract even after the operator proposal goes away, because it is given a special support, c-support for "context object support". This changes to be more dynamic in Soar 8.)

To tell if a preference has o-support or i-support, check the preferences on the attribute.

e.g., "pref s1 color" will give:

Preferences for S1 ^color:
 
acceptables:
  red + [O]
 

while "pref s1 near" gives:

Preferences for S1 ^near:
 
acceptables:
   O2 +
 

The presence or absence of the [O] shows whether the value has o-support or not.

Back to Table of Contents

(P10) When should I use o-support, and when i-support?

General information

Under normal usage, you probably will not have to explicitly choose between the two. By default, you will get o-support if you apply, modify or create an operator as part of some state structure; you will get i-support if all you do is elaborate the state in some way.

It, therefore, follows that by default, you should generally use operators to create and modify state structures whenever possible. This leads to persistent o-supported structures and makes the behaviour of your system much clearer.

I-support can be convenient occasionally, but should be limited to inferences that are always true. For example, if I know (O1 ^next-to O2), where O1 and O2 are objects then it is reasonable to have an i-supported production which infers that (O1 ^near O2). This is convenient because there might be a number of different cases for when an object is near another object. If you use i-supported productions for this, then whenever the reason (e.g. ^next-to O2) is removed, the inference (^near O2) will automatically retract.

Never mix the two for a single attribute. For example, do not have one production which creates ^size large using i-support and another that tests an operator and creates ^size medium using o-support. That is a recipe for disaster.

IE phase vs. PE phase

Robert Wray wrote (July 24, 2002):

IE instantiations indicate i-supported elaborations (IE) and PE instantiations are o-supported elaborations. The "P" is for persistent: "persistent elaborations".

The Soar 8 kernel makes a distinction between IE and PE in order to fire persistent elaborations in separate (super) phases from IEs. The general idea is:

while (!quiescence(all-productions))
   while (!quiescence(IE-productions))     //this is called
"mini-quiescence" in the kernel
        Preference Phase (IE only)
        WM Phase (IE only)
   Preference Phase (IE only)
   WM Phase (PE only)
 

Other tips

Note that there are several kinds that have been used. See the manual for your version. John Laird (larid@umich.edu) provided some useful tips (Sep. 9, 2003).

Back to Table of Contents

(P11) Why does the value go away when the subgoal terminates?

A common problem is creating a result in a superstate (e.g., ^size large) and then when the subgoal terminates, the value retracts. Why does this happen? The reason is that once the subgoal has terminated the preference in the superstate is supported by the chunk or justification that was formed when the preference was first created.

This chunk/justification may have different support than the support the preference had from the subgoal. It is quite common for an operator in a subgoal to create a result in the superstate which only has i-support (even though it is created by an operator). This is because the conditions in the chunk/justification do not include a test for the super-operator. Therefore, the chunk has i-support and may retract, taking the result with it.

NOTE: Even if you are not learning chunks, you are still learning justifications (see above) and the support, for working memory elements created as results from a subgoal, depends on the conditions in those justifications.

Back to Table of Contents

(P12) What's the general method for debugging a Soar program?

The main tools that you need to use are the commands below. You apply them where the behaviour is odd, and use them to understand what is going on. Personally I (FER), prefer the Tcl/Tk interface for debugging because many of these commands become mouse clicks on displays.

print Prints out a value in working memory.

print -stack (pgs in earlier versions of Soar) Prints out the current goal stack: e.g., : ==>S: S1 : ==>S: S2 (state no-change)

matches (ms in earlier versions of Soar) Shows you which productions will fire on the next elaboration cycle.

matches <prod_name> Shows you which conditions in a given production matched and which did not. This is very important for finding out why a production did or did not fire.

e.g., soar> matches production1*chunk >>>> (state ^there-is-a-blue-thing yes) (^there-is-a-big-thing yes) (^superstate) 0 complete matches. This shows that the first condition did not match.

preferences <id> <attribute> 1

(The 1 is used to request a bit more detail.)
 This command shows the preferences for a given
 attribute and which productions created the
 preferences. A very common use is
 
 
  pref operator 1
 
 which shows the preferences for the operator
 slot in the current state. (You can always
 use to refer to the current state).
 

Glenn Taylor mentioned that the Visual Soar has made some strides in minimizing user errors like typos, providing the closest thing to a type-checker for an untyped language. There is something older called ViSoar, which could be used to analyze productions in order to find some typos as well. Visual Soar may contain much of the functionality of ViSoar. There is also a run-time debugger (called SDB) and structure visualizer available through the Soar webpages, written in Tcl, so is platform-independent, though is not part of the Soar 8 distribution. Tcl Pro comes with a debugger. It may be also useful to debug Soar.

Back to Table of Contents

(P13) How can I find out which productions are responsible for a WME?

Use

preferences 1
 

Or

preferences -names
 

(They both mean the same thing.)

This shows the values for the attribute and which production created them. For example:

(S1 ^type T1) (T1 ^name boolean) pref T1 name 1

will show the name of the production which created the ^name attribute within object T1.

Back to Table of Contents

(P14) What's an attribute impasse, and how can I detect them?

Attribute impasses occur if you have two values proposed for the same slot.

e.g.,