245 Views

Download Presentation
## Pattern-Directed Inference Systems

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**Pattern-Directed Inference Systems**Algorithms and Data Structures II Academic Year 2002-03**Previous Lectures**• (Classical) Problem Solving • Separation of problem space and search engine • Characterization of problem space • Pluggable search engines • Implementations for different search problems, e.g. a subway planning problem**Moving from (Classical) Problem Solvers to Pattern-Directed**Inference systems • Operators == rules. • State == database of asserted facts about objects of discourse. • Search engine handles rule-firing.**PDIS**• Assertions, pattern matching and unification • Pattern-based retrieval • Rules • Pattern-Directed Inference Systems (PDIS) in general**Design Methodology**• Build simple and stable, then extend module-by-module • In these lectures, we’ll start with a few very simple systems, and replace them one module at a time. • This is a good design methodology in general. • Write routines at a task level, and hide dependant-structure bookkeeping • BPS program modules highly interdependent (rule-system/database) • Information must be propagated across consistently • Main routines should hide this propagation**and rule**Fast (open-coded) unifier Building a rule engine module-by-module Fact database Rule Engine Pattern unifier Build simple and stable, then extend module by module Pattern matcher -------------------Pattern unifier**Building a rule engine module-by-module**Fact database Build simple and stable, then extend module by module**Assertions and pattern matching**Outline What are assertions? Pattern-based matching & unification Pattern-based retrieval**Assertions**• List-based symbolic representations • (this statement is false) • (implies (greeted mary john) . (knows mary john)) • (connected-to thigh-bone knee-bone) • In this class, does not presume either predicate calculus or frames • Uses patterns as the basis of category-based reasoning • Select categories via patterns • Instantiate new instances of a category by pattern substitution**Advantages of assertions**• Easily composible • Expression of sets via patterns • (on ?x table) : Everything on table. • (block ?x) : Everything that is a block. • Disadvantages • hard to represent levels of belief or relative merit • Alternatives possible**Using pattern matching and unification with assertions**• Pattern matching vs. unification • Unification has variables in both pattern and datum • Symmetric operation? Associative? • Many different unifier flavors • Basic algorithm: • tree-walk the pattern and datum • look up and store variables in bindings dictionary as needed**Pattern Matching & Unification (1)**(Has-Value (gain ?amp) ?beta) (Has-Value (gain Amplifier32) 1000) unify assuming the bindings ?amp = Amplifier32 ?beta = 1000**Pattern Matching & Unification (2)**(Mystical ?agent (friend ?x)) (Mystical ?x ?agent ) don’t unify because the bindings ?agent = (friend ?x) ?x = ?agent would result in the infinite expression ?x = (friend (friend (friend …)))**TRE Unify Function**• For matching • ?x : Matches symbol, binding to pattern var X • No optional filter field in pattern. • No segment variables. • Matcher returns either a set of bindings (as an alist) or :FAIL. • For substitution of matched patterns • sublis function for instantiating matched patterns.**(F)TRE Unify Function**(defun unify (a b &optional (bindings nil)) (cond ((equal a b) bindings) ((variable? a) (unify-variable a b bindings)) ((variable? b) (unify-variable b a bindings)) ((or (not (listp a)) (not (listp b))) :FAIL) ((not (eq :FAIL (setf bindings (unify (first a)(rest b) bindings)))) (unify (rest a) (rest b) bindings)) (t :FAIL)))**Building a rule engine module-by-module**Fact database Build simple and stable, then extend module by module Pattern matcher -------------------Pattern unifier**Summary and Observations**• Unifier algorithm • treewalk pattern and datum • when variable found, do bookkeeping on binding dictionary • fail when conflicting bindings or structural (list to symbol) mismatches • Use of a filter test • Treewalks on fixed patterns can be precompiled (see FTRE)**The rest**• Pattern-Directed Inference systems • Pattern-based retrieval • Creating rules • Creating TRE, a Tiny Rule Engine • Creating FTRE • Open-coded unification • Rules with tests and rlet • Application: KM*, a natural deduction method**PDIS Systems**B A Database: (on blockA table) (on blockB blockA) (red blockB) (white blockA) . . . . . . Rules: (rule (red ?bl) (small ?b1)) (rule (on ?b1 ?b2) (rule (on ?b2 table) (assert! (tower ?b1 ?b2)))) . . .**PDIS Systems**B A Database: (on blockA table) (on blockB blockA) (red blockB) (white blockA) . . . . . . Rules: (rule (red ?bl) (small ?b1)) (rule (on ?b1 ?b2) (rule (on ?b2 table) (assert! (tower ?b1 ?b2)))) . . .**PDIS Systems**B A Database: (on blockA table) (on blockB blockA) (red blockB) (white blockA) (small blockB) . . . . Rules: (rule (red ?bl) (small ?b1)) (rule (on ?b1 ?b2) (rule (on ?b2 table) (assert! (tower ?b1 ?b2)))) . . .**From**User Assertion Database Rule Database Queue Simplest PDIS architecture:**How do we choose which rules to run against which**assertions? • Given a rule trigger, which assertions in the database might match it? • Given an assertion in the database, which rules might be applicable • Basic problem: Pattern-based retrieval**Pattern-based retrieval**• Task: Given a pattern, return matching patterns from large set of assertions • Naïve approach: run unify between pattern and each datum • Too expensive! • Two-stage approach: cheap filter for plausible candidates, followed by unify • Much better! But which filter?**Possible filters (1)**• Discrimination trees • Pluses: • General over all patterns • Time efficient • Minuses: • Complex bookkeeping • Inefficient use of space**Possible filters (2)**• First (or class) indexing • Store rule by first symbol in trigger • Store assertion by first symbol in list • Pluses: • Simple and efficient (time and space) • Minuses: • Can’t handle patterns with variable as first symbol • May store many items under single index • One fix: • CADR (or SECOND) indices for entries that contain many items**Possible filters (3)**• Generalized hashing • Multiple hash tables, for indices such as: • First of expression • CADR of expression • Number of items in expression • Retrieve all entries, take intersection • Pluses: • Works on all patterns • Minuses • Really inefficient (time and space) • Seldom used**Example of indexing using discrimination tree (from Norvig,**1992) 1. (p a b) 2. (p a c) 3. (p a ?x) 4. (p b c) 5. (p b (f c)) 6. (p a (f . ?x)) A (p a b) (p a c) (p a ?) (p a (f . ?)) P (p a b) (p a c) (p a ?) (p b c) (p b (f c)) (p a (f . ?)) ? (p b (f .?)) C (p b (f c)) F (p b (f c)) (p a (f . ?)) B (p b c) (p b (f c)) B (p a b) C (p a c) (p b c) ? (p a ?)**Winner: first indexing**• Simplest to implement • For small systems, almost as efficient as discrimination trees**Designing the Tiny Rule Engine (TRE)**• Requirements • Pattern matcher, • Matches against a pattern • Can instantiate a particular pattern using a set of bindings • Database of current assertions • Database of current rules • Control mechanism for running rules on assertions**The main interface for TRE**• *TRE*, the global variable for the default TRE • dynamically-bound special variable (remember earlier explanation) • (assert! <assertion> *tre*) • Stores fact in the database • (fetch <pattern> *tre*) • Retrieves a fact from the database**Implementing the database**• Create DBClass struct, which represents a single class index • assert! <assertion>: • Store in database by dbclass • fetch <pattern> • Retrieve by dbclass • Unify pattern with retrieved candidates**From**User Assertion Database Rule Database Queue Choosing when to running rules • General heuristic: run rules whenever you can • Therefore, each rule runs one time on each assertion**Pattern-match trigger against database.**When match succeeds, evaluate body of rule. Rules can create other rules. Making rules for the TRE • Rule form: (rule (apple ?apple) (assert! `(edible ,?apple))) (rule (apple ?apple) (rule (red ?apple) (assert! `(jonathan ,?apple)))**Properties of rules**• Indefinite extent: Once spawned, a rule lives forever. • Example:(assert! ‘(on a b), (assert! ‘(on b c))yields same result as(assert! ‘(on a b)), <N random assertions>, (assert! ‘(on b c)) • Order-independence: An often useful property • Results are the same no matter when you add the same set of assertions and rules • Example:(assert! ‘(on a b)), (assert! ‘(on b c))yields same result as(assert! ‘(on b c)), (assert! ‘(on a b))**Design Constraints on TRE**• Order-independence => restrictions • All rules are executed eventually. • No deletion • Evil: Using fetch in the body of a rule. • Order-independence => freedom • We can execute rules in any order. • We can interleave adding assertions and triggering rules as convenient**Rule struct in TRE**(defstruct (rule (:PRINT-FUNCTION rule-print-procedure)) counter ;Integer to provide unique "name" Dbclass ;Dbclass it is linked to. trigger ;pattern it runs on. body ;code to be evaluated in local env. environment) ;binding environment.**(rule (apple ?apple)**(rule (red ?apple) (assert! `(jonathan ,?apple))) Store rule: trigger: (apple ?apple) body: (rule (red ?apple) (assert! `(jonathan ,?apple))) *env*: NIL (Assert! ‘(apple apple-23)): triggers rule. Pushed onto queue: bindings: ((?apple . apple-23)) body: (rule (red ?apple) (assert! ‘(jonathan ,?apple))) When run-rules called, pops from queue. *env* == bindings. Store rule: trigger: (red apple-23) body: (assert! `(jonathan apple-23)) *env*: ((?apple . Apple-23))**How good is TRE’s rule mechanism?**• Advantages • Simple to implement • Pattern match single trigger • Treat rule body as evaluable function • Rewrite bindings as let statement • Flexible • Disadvantages • Slow (due to eval and unify) • Overly flexible • Rule body could be anything, i.e., Quicken, Spreadsheet, Ham sandwich…**Summary**• Building the TRE module by module • Unifier • Creating a unifier from a pattern matcher • Database • Doing first-indexing via DB-Classes • Alternatives: CADR indexing, discrimination trees • Rule engine • Agenda queue for firing new rules, adding new facts.**Application**• Using the FTRE to build a theorem prover • The KM* Natural Deduction System • Assignment • Extending KM***Example: Natural deduction of logical proofs**• A proof is a set of numbered lines • Each line has the form<line number> <statement> <justification> • Example:27 (implies P Q) asn28 P given29 Q (CE 27 28)**Example: Natural deduction of logical proofs**• Kalish & Montegue: a set of heuristics for doing logical proofs • Introduction rules • not introduction, and introduction, or introduction, conditional introduction, biconditional introduction • Elimination rules • not elimination, and elimination, or elimination, conditional elimination and biconditional elimination**Kalish & Montegue (cont.)**• Organized along five the different operators: • NOT, AND, OR, IMPLIES (->), and IFF (<=>). • Rules can either eliminate operators or introduce new operators • Elimination rules are simple • Introduction rules are require more control knowledge--cannot be used randomly**Elimination rules**• AND • OR • NOT • IMPLIES • IFF**Not Elimination**i (not (not P)) P (NE i) (rule (not (not ?p)) (assert! ?p))**AND Elimination**i (and P Q) P (AE i) Q (AE i)**OR Elimination**i (or P Q) j (implies P R) k (implies Q R) R (OE i j k)**Conditional Elimination**i (implies P Q) j P Q (CE i j)**Biconditional Elimination**i (iff P Q) (implies P Q) (BE i) (implies Q P) (BE i)