A Problem-Solver for Making Advice Operational

One problem with taking advice arises when the advice is expressed in terms of data or actions unavailable to the advicetaker. For example. in the card game Hearts, the advice “don’t lead a suit in which some opponent has no cards left” is nonoperational because players cannot see their opponents’ cards. Operationalization is the process of converting such advice into an executable (perhaps heuristic) procedure. This paper describes an interactive system, called BAR. that operationalizes advice by applying a series of program transformations. By awMw different transformation sequences, BAR can operationalize the same advice in very different ways. BAR uses means-ends analysis and planning in an abstraction space. Rather than using a hand-coded difference table, BAR analyzes the transformations to identify transformation sequences that might help solve a given problem. Thus new transformations can be added without modifying the problem-solver itself. Although user intervention is required to select among alternative plans, BAR reduces the number of alternatives by lo3 compared to an earlier operationalizer. 1. Int reduction Many tasks that are onerous to program seem much easier to specify in terms of a body of advice. Examples include air traffic control (“keep planes three miles apart”), factory scheduling (“minimize re-tooling”), document preparation (“place a figure on the page that mentions it”)* and computer dating (*.no incestuous matches”). The idea of the advice-taking machine has been around for some time [McCarthy 681: in this paradigm, the machme accepts advice for how to perform a task and converts it into an effective procedure. [Hayes-Roth 811 explores this paradigm in some depth. showing how advice provided by an expert tutor could be refined by experience. Several hard problems must be solved to achieve the ambitrous long-term goal of a general advice-taker. One problem is to translate advice expressed imprecisely in natural language into a precise machine representation of its meaning. Another problem ‘This research was supported by DARPA Contract MDA.903.81-C-0335. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies. either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. I am grateful to my dissertation committee (Rick Hayes-Roth. Allen Newell, Jaime Carbonell. and Bob Balzer) for manifold contributions to this research. to my ISI colleagues for their intellectual influence, and to Don Cohen and Bill Swartout for improvmg this paper. is to combine different, possibly conflicting pieces of advice. This paper focusses on a third problem: taking advice that is non-operational, i.e.. expressed In terms of data or actlons unavailable to the machine, and transforming it into a procedure executable using only the available operations This process is called operational/zat/on [Mostow 811 [Diettench et al 821. Operationalization cannot be studied in a vacuum: one must look at how advice IS operationalrzed in the context of a particular task. ideally one that is easy to model but retains the essential properties of advice-based tasks. i.e., that no simple. economlcal algorithm is known (this rules out tasks like sorting). but good performance can be attained by following known advice (this rules out tasks like earthquake prediction). A task like air traffic control has both properties but is inconvenient to model. This paper uses the card game Hearts as its example domain, and is based on two programs, called FOO and BAR. that accept Hearts advice, encoded in a suitable internal representation. and operatlonalize it by applying a series of program transformations. FOO [Mostow 811 was used to operationalize 13 pieces of advice for Hearts and a music composition task, including*: “Avoid taking a trick with points” non-operational because a Hearts player cannot simply refuse to take points “Flush out the Queen of spades” one player cannot choose the card played by another “Don’t lead a high card in a suit where some opponent is void [has no cards left]” a player may not peek at opponents’ cards By applying different sequences of transformations. the same piece of advice was operatronalized in different ways. Thus “avoid taking points” was operationalized both as “play a low card” and as a heuristic search procedure that enumerates possible sequences of play for a trick to determine whether playing a given card mrght lead to taking points [Mostow 821. “Flush the Queen” was operationallzed as a plan to keep leading spades until whoever has the Queen IS forced to play it. The problem of deciding whether some oppgnent is void in a given suit was operationalized In two ways. One way is to check if someone failed to follow suit earlier when that suit was led Another is to 2 These preces of advice were operatlonallzed independently of each other, but in fact they interact For example, the reason for flushing out the Queen of spades IS to make someone else take It. Leadmg the Kmg or Ace of spades might help flush out the Queen at the cost of takmg it. which would vlolate the advice to avoid taking points. 279 From: AAAI-83 Proceedings. Copyright ©1983, AAAI (www.aaai.org). All rights reserved.