This tutorial will help you understand how operators are chosen and how they apply. It also explains how to look at operators and associated information within NL-Soar.

Note: This tutorial assumes you know how to run NL-Soar and are familiar with the operator types. More detailed information on operators is also available from Soar documentation.

Operators carry out an identifiable quantity of processing for some task. In NL-Soar operators constitute the basic building blocks of all aspects of language modeling: performing lexical access, building syntactic and semantic structure, and many other tasks. These operators and their functions are described elsewhere; this is meant to provide more information of a general nature about operators.

The basic decision cycle in NL-Soar involves operators; it includes:

proposing appropriate operators

selecting the best operator

implementing the operator

terminating the operator

We will look at each of these phases in the decision cycle in a little more detail

Operators are proposed when the conditions are appropriate for application of the operator. For example, in NL-Soar, if we have a preposition followed by a noun phrase (as in "he drove across town.", it might be appropriate to attach them together. This type of work is performed by an operator (specifically, a u-constructor). If there is an operator readily available to do the task, that operator will fire. If there is no operator available to perform this operation, NL-Soar will try to learn what is necessary to attach these two pieces together. This may involve checking that the two pieces obey word-order restrictions, that they haven't already been attached somewhere else, and that other grammar rules allow for the joining of these two pieces.

Often several operators might be appropriate at a given moment, but in Soar only one operator can fire at a time. The choice of which operator should fire when several are possible is based on a system of preferences: the operator with the highest preference will fire when possible. Preferences are assigned by the system's productions (or, alternatively, the system can learn preferences). It is possible to see the preferences for NL-Soar operators (and, for that matter, for other objects) by doing the following:

Stop the system at a point where you know a decision about which operator to select will take place. One good point is when a new state has been created. For example, in the following trace, the system has been stopped after a new state has been created and an operator proposed:

    52:       O: O30 (learn-language)

    53:       ==>S: S70 (operator no-change)
    54:          O: O45 (install-initial-state)
    55:          O: O42 (u-constructor594)
    56:          ==>S: S84 (operator no-change)
    57:             ==>S: S85 (state no-change)
    58:                O: O52 generate-operator(link(bark.i--comp-->bark.v)

Use the preferences command (or shorter substrings of the command name), giving the state number and the attribute you wish to see described (in this case, operator since that's what we want to see):
    pref s85 operator 1The last parameter sets a level of verbosity for the preferences command.

You will see several lines of output including which operators are acceptable, which are indifferent in their preferences, which are worse than others, and which have the worst (lowest) preferences of all.

Operator implementations involve carrying out the work that the operator is designed to do. If the operator is already available due to learning, this involves firing the associated chunks (and perhaps performing some deliberation). If, on the other hand, an operator must be created on-the-fly, this probably will involve subgoaling, or at least firing of some other operators (or productions) in a goal-directed sequence.

Once the operator has fired completely, it must be explicitly terminated in Soar 7.3, the version of Soar used in NL-Soar. This involves reconsidering it after having satisfied the precondition(s) identified when the operator was originally selected. With these goals satisfied, the reconsider phase will cause the operator to disappear since it has achieved its purpose.