Impasse-Driven Control in Soar

If the decision phase doesn't have sufficient preference information to select among the actions of the productions which fired in the elaboration phase, it results in an impasse. Impasses occur when there is a lack of applicable knowledge in the current problem space, so they, in a sense, signal that problem solving needs to take place. This problem solving proceeds in the form of an automatically generated subgoal. Soar has four type of impasses:

• tie: this arises when there is a collections of equally eligible objects competing for a particular context slot. For example, in the Waterjug problem there may arise acceptable preferences for operators to "fill jug A" and "fill jug B":

  (o023 ^name fill-A +)
  (o023 ^name fill-B +) 

• conflict: this arises when two or more objects are better than one another, and they are not dominated by a third. For example:

  (o023 ^action fill-A > fill-B)
  (o023 ^action fill-B > fill-A)
  

• constraint-failure: this arises if there is more than one required preference for an attribute. It can also happen if there is a required and prohibit preference for an attribute. For example:

  (a023 ^action fill-A !)
  (a023 ^action fill-A ~)

  -- or --

  (a023 ^action fill-A !)
  (a023 ^action fill-B !)
  

• no-change: this arises when the elaboration phase runs to quiescence without suggesting any change to the context.

Go to a discussion of this property for multiple architectures.

Current Location: Soar - Properties - Impasse-Driven Control

Go to NEXT page.