CPI 101: Meeting 9 Rule-Based Languages Pat Langley School of Computing and Informatics Arizona State University Tempe, Arizona USA Traditional Programming Languages Most languages for creating computer programs taught in computer science courses emphasize: procedural character of routine behavior activities that occur in fixed orders repetitive steps that use iteration relatively inflexible behaviors This is fine for some forms of routine activity, but they can be awkward for many others. Note that conditional statements provide the source of flexibility in traditional languages. Rule-Based Languages An important alternative, rule-based programming languages: specify behavior entirely in terms of if-then rules emphasize the conditional nature of behavior often utilize list structures and pattern matching support coding of highly flexible behaviors Rule-based formalisms have many practical applications, but they come originally from studies of human thinking. Within artificial intelligence and cognitive science, they are sometimes called production systems. Rules in Everyday Life Many of our routine activities involve following rules: Driving a vehicle Solving puzzles Playing sports Getting degrees Talking with others Filing taxes Encoding such activities is generally much easier in rule-based programming languages. A Sample Application: TurboTax Expert Systems TurboTax is an example of an expert system, a program that: incorporates substantial knowledge about some area usually encodes expertise as a set of if-then rules operates by matching rules against facts or beliefs may interact with the user by asking questions Such systems have seen wide application in business, but they are seldom taught in computer science courses. Early expert systems were build by hand, but increasingly they are created through machine learning. Another Application: Organizing Weddings Overview of a Procedural Program Stored Program (steps, loops) Stored Program Interpreter Program Variables (counters, results) Overview of a Production System Knowledge Base (if-then rules) Recognize-Act Interpreter Working Memory (beliefs and goals) Representing Rules A production system stores domain knowledge as rules that have: A condition side With one or more conditions that must match That share pattern-match variables across conditions Action sides With one or more actions that alter memory That share pattern-match variables with conditions Each rule specifies the actions to take when all of its generalized conditions hold. These can match against and modify the environment or memory. A Sample Rule-Based Program If you want to subtract Row2 from Row1, and ColumnX is the rightmost unprocessed column, Then process ColumnX. If you want to subtract Row2 from Row1, and you want to process ColumnY, and Num1 is in Row1 and ColumnY, and Num2 is in Row2 and ColumnY, and Num1 is greater than Num2, and Row3 is just below Row2, Then write the difference between Num1 and Num2 in ColumnY and Row3. A Sample Rule-Based Program (cont.) If you want to subtract Row2 from Row1, and you want to process ColumnY, and Num1 is in Row1 and ColumnY, and Num2 is in Row2 and ColumnY, and Num2 is greater than Num1, and ColumnZ is just left of ColumnY, Then borrow from ColumnZ to ColumnY. If you want to borrow from ColumnZ to ColumnY, and Num3 is in topmost Row and ColumnZ, and ColumnZ has not been decremented, and Num3 is greater than zero, Then take the difference of Num3 and 1 in Row and ColumnZ, and mark ColumnZ as decremented. A Sample Rule-Based Program (cont.) ((subtract ?row2 ?row1) (rightmost-unprocessed ?columnX) => (process ?columnX)) ((subtract ?row1 ?row2) (process ?columnY) (in ?num1 ?row1 ?columnY) (in ?num2 ?row2 ?columnY) (*greater ?num1 ?num2) (below ?row3 ?row2) => (*add (in (*diff ?num1 ?num2) ?row3 ?columnY))) A Sample Rule-Based Program (cont.) ((subtract ?row1 ?row2) (process ?columnX) (in ?num1 ?row1 ?columnY) (in ?num2 ?row2 ?columnY) (*greater ?num2 ?num1) (left-of ?columnZ ?columnY) => (borrow ?columnZ ?columnY)) ((borrow ?columnZ ?columnY) (in ?num3 ?row ?columnZ) (topmost ?row) (*not (decremented ?columnZ)) (*greater ?num3 0) => (*add (in (*diff ?num3 1) ?row ?columnZ)) (*add (decremented ?columnZ))) Representing Beliefs and Goals Rather than storing changing content in traditional variables, most production systems: retain a set of beliefs and goals encoded as symbolic list structures in a short-term or working memory that changes as the program runs This representation is based on theories of how people encode the content of their short-term memories. They were designed to support symbolic processing rather than numeric algorithms. Sample Beliefs and Goals Our rule-based subtraction program would contain elements like: (topmost row1) (below row2 row1) (below row3 row2) (left-of column2 column1) (processed column1) (borrow column2) (in 5 row1 column1) (in 7 row2 column1) (in 3 row1 column2) (in 1 row2 column2) (in 8 row1 column3) (decremented column2) These list structures change over time as the program runs. They are much richer than standard variables, but they also rely on more powerful ways to access them. Interpreting Rule-Based Programs A production system operates in successive recognize-act cycles: find all ways that each rule’s condition side matches against the contents of working memory select one or more of the matched rule instances to execute instantiate and carry out the actions of the selected matches These actions change the state of working memory, possibly letting different rules match on the next cycle. This process continues until no rules match or the selected rule executes the halt action. Interpreting Rule-Based Programs To find all ways that a rule matches against working memory, a production system: matches each condition against each working memory element binds its pattern-match variables to corresponding parts checks to see if the different conditions bind consistently checks to ensure that no negated conditions are matched Note that the same rule can match against working memory in more than one way. Each set of consistent bindings is an instantiation of the rule. Interpreting Rule-Based Programs A production system selects among rule instantiations to execute one or more on each cycle. For this, it uses conflict-resolution heuristics that, e.g., prefer: instantiations that match against more recent elements instantiations that match against more specific sets of elements production rules that have more conditions production rules that were added earlier Different languages use alternative selection strategies that may produce different behavior for the same content. Modeling Human Cognition Production systems are often used to model high-level cognition in people because: They support mental activities that make humans unique They combine parallel retrieval with sequential decisions They balance stimulus-driven and goal-driven behavior They offer the right level of analysis for many symbolic tasks Their modular representation supports key forms of learning Some production system languages like Soar, ACT-R, and EPIC are associated with theories of the human cognitive architecture. These make claims about the representations and processes that support mental abilities. Subroutines and Recursion with Rules Although production systems focus on conditional behavior, they also support subroutines and recursion. If you want to subtract Row2 from Row1, and you want to process ColumnY, and Num1 is in Row1 and ColumnY, and Num2 is in Row2 and ColumnY, and Num2 is greater than Num1, and ColumnZ is just left of ColumnY, Then borrow from ColumnZ to ColumnY. If you want to borrow from ColumnZ to ColumnY, and Num3 is in topmost Row and ColumnZ, and ColumnZ has not been decremented, and Num3 is zero, and ColumnX is to just left of ColumnZ, Then borrow from ColumnX to ColumnZ. They achieve this by placing goals in working memory that cause other rules to match or the same rules to match differently. History of Rule-Based Programming Production systems have a long history in AI and cognitive science: Allen Newell (1967) proposes production systems as models of human cognition Donald Waterman (1970) develops the first running production system (for learning to play poker) Charles Forgy (1976) releases OPS, the first widely used production system language John Anderson (1976) introduces the ACT cognitive architecture John McDermott (1980) develops R1, an expert system for computer configuration John Laird (1983) develops the Soar cognitive architecture Since then, production systems have seen wide use for models of human cognition and commercial applications. Soar Technology’s Intelligent Agent for Flight Training Carnegie Learning’s Algebra Tutor Backward-Chaining Approaches Production systems carry out forward chaining, but other methods: start with a generalized goal or query find rules with left-hand sides that unify with that goal chain off each of the subgoals in their right-hand sides return bindings upward when reaching terminal nodes This technique generates not only answers to queries, but also proofs for why they hold. Such backward-chaining methods emphasize inference rather than action; they are similar to relational databases. PROLOG is a well-known language that supports backward chaining over first-order logical rules. Summary Rule-based programs provide an important alternative to more traditional procedural languages that: specify behavior entirely in terms of if-then rules match or unify these rules against list structures in memory carry out actions or draw inferences based on these matches provide greater modularity than procedural languages Rule-based programs are commonly used to develop expert systems, which underlie many business applications. Production systems are often used to model high-level cognition and explain important aspects of human behavior.