1 / 93

Pattern-Directed Inference Systems

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

sereno
Download Presentation

Pattern-Directed Inference Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related