Pattern-Directed Inference Systems

1. Pattern-Directed Inference Systems Algorithms and Data Structures II Academic Year 2002-03

2. 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

3. 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.

4. PDIS • Assertions, pattern matching and unification • Pattern-based retrieval • Rules • Pattern-Directed Inference Systems (PDIS) in general

5. 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

6. 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

7. Building a rule engine module-by-module Fact database Build simple and stable, then extend module by module

8. Assertions and pattern matching Outline What are assertions? Pattern-based matching & unification Pattern-based retrieval

9. 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

10. 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

11. 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

12. Pattern Matching & Unification (1) (Has-Value (gain ?amp) ?beta) (Has-Value (gain Amplifier32) 1000) unify assuming the bindings ?amp = Amplifier32 ?beta = 1000

13. 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 …)))

14. 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.

15. (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)))

16. Building a rule engine module-by-module Fact database Build simple and stable, then extend module by module Pattern matcher -------------------Pattern unifier

17. 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)

18. 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

19. 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)))) . . .

20. 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)))) . . .

21. 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)))) . . .

22. From User Assertion Database Rule Database Queue Simplest PDIS architecture:

23. 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

24. 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?

25. Possible filters (1) • Discrimination trees • Pluses: • General over all patterns • Time efficient • Minuses: • Complex bookkeeping • Inefficient use of space

26. 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

27. 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

28. 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 ?)

29. Winner: first indexing • Simplest to implement • For small systems, almost as efficient as discrimination trees

30. 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

31. 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

32. 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

33. 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

34. 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)))

35. 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))

36. 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

37. 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.

38. (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))

39. 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…

40. 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.

41. Application • Using the FTRE to build a theorem prover • The KM* Natural Deduction System • Assignment • Extending KM*

42. 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)

43. 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

44. 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

45. Elimination rules • AND • OR • NOT • IMPLIES • IFF

46. Not Elimination i (not (not P)) P (NE i) (rule (not (not ?p)) (assert! ?p))

47. AND Elimination i (and P Q) P (AE i) Q (AE i)

48. OR Elimination i (or P Q) j (implies P R) k (implies Q R) R (OE i j k)

49. Conditional Elimination i (implies P Q) j P Q (CE i j)

50. Biconditional Elimination i (iff P Q) (implies P Q) (BE i) (implies Q P) (BE i)