1 / 49

Putting the JTMS to Work

Putting the JTMS to Work. Outline. Interface between a JTMS and a rule engine Chronological Search versus Dependency Directed Search: A Playoff Using a TMS in a problem solver: JSAINT design issues. Problem Solver. Inference Engine. TMS. TMS acts as substrate to inference engine.

jessamine-frye
Download Presentation

Putting the JTMS to Work

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. Putting the JTMS to Work

  2. Outline • Interface between a JTMS and a rule engine • Chronological Search versus Dependency Directed Search: A Playoff • Using a TMS in a problem solver: JSAINT design issues

  3. Problem Solver Inference Engine TMS TMS acts as substrate to inference engine Rules and assertions Inferred assertions The dependency-network of the TMS provides a substrate for the inference engine, making it more efficient. Let’s take a closer look...

  4. Inference Engine services • Provides reference mechanism • e.g., assertions, pattern matching • Provides procedures • e.g., rules • Provides control strategy

  5. TMS services • Provides cache for inferences • Nodes for assertions, justifications for relationships between beliefs • Maintains consistent set of beliefs • Derives consequences of assumptions & premises based on dependency network • When assumptions are retracted, their consequences are retracted • Provides explanations for belief • e.g., chains of well-founded support • Detects contradictory beliefs • Based on contradiction nodes, explicit dependencies

  6. referent Datum datum-tms-node datum-lisp-form tms-node-datum get-tms-node TMS Node view-node Each engine datum is mapped to a particular TMS node (HUMAN ROBBIE)

  7. Storing facts in the JTRE requires more bookkeeping • To store a fact in the JTRE • Index it under DBClass (just like FTRE) • Also: Find or create link between lisp form of assertion and TMS node • Datum class struct • Lisp form • Link to TMS node • Backpointer to DBClass

  8. FTRE -> JTRE • FTRE’s assert! • Place facts directly in the database of facts (local or global) • JTRE’s assert! • Place facts in database, and set up appropriate node in TMS • Mark as assumption if needed. • In fact, assert! becomes family of related functions

  9. Justifying assertions in terms of other beliefs • (assert! <fact> (<informant> . <antecedents>))installs a justification • (assert! <fact> <Anything else>)makes a premise • (assume! <fact> <reason>) makes an assumption • rassume!, rassert! as before • retract! disables an assumption • (contradiction <fact>)installs a contradiction

  10. Create datum & tms node Handle bookkeeping of dependencies, based on justification JTRE assert! (defun assert! (fact just &optional (*JTRE* *JTRE*) &aux datum node) "Assert fact into the JTRE." (setq datum (referent fact t);; Create datum if needed, node (datum-tms-node datum));; with corresponding node. (unless (listp just) (setq just (list just))) (debugging-jtre "~% Asserting ~A via ~A." fact just) (justify-node (car just) node (mapcar #'(lambda (f) (datum-tms-node (referent f t))) (cdr just))) datum)

  11. TMS Node TMS Node TMS Node TMS Node Justification structure • ID, a unique number • Informant, a symbol description • Consequent, node it supports • Antecedents, nodes that support it.

  12. Justify-node • Build a justification object linking the given antecedent nodes to the consequent node. • Check justification links • If consequent now IN, label IN • Propagate IN-ness

  13. Queries concerning Belief States • in? • out? • why? • assumptions-of • fetch • wfs

  14. Tying rule execution to belief states • (rule <list of triggers> <body>) • Triggers are (<condition> <pattern>) • Types of conditions • :IN • :OUT • :INTERN • Trigger options • :VAR • :TEST

  15. Examples of rules (rule ((:in (implies ?p ?q) :var ?f1) (:in ?p))(rassert! ?q (CE ?f1 ?p))) (rule ((:in (show ?p) :var ?f1) :test (not (logical-connective? ?p)))(rassert! ((show ?p) Indirect-Proof :PRIORITY Low) (BC-IP ?f1)))

  16. When do rules fire? • Normally, when triggers match, body is queued and executed • What if trigger becomes OUT after body is queued? • Solution: local execution queues on each TMS node

  17. Node structure • (defstruct (tms-node (:PRINT-FUNCTION print-tms-node)) • (index 0) ;; Unique identifier for node. • (datum nil) ;; Pointer to fact node represents • (label :OUT) ;; :IN=believed, :OUT=disbelieved • (support nil) ;; Current justification • (justs nil) ;; Possible justifications • (consequences nil) ;; Justifications it supports. • (contradictory? nil) ;; Flag marking it as contradictory • (assumption? nil) ;; Flag marking it as an assumption. • (in-rules nil) ;; Rules triggered when node goes in • (out-rules nil) ;; Rules triggered when node goes out • (jtms nil)) ;; The JTMS in which node appears. • When node becomes :IN or :OUT, items on local queue are eval’ed

  18. Handling Contradictions • (with-contradiction-handler<jtms> <handler> . <body>) • We’ll see example with N-queens problem

  19. Search Example: The N-Queens problem Good solution Bad solution

  20. Chronological Search solution • Given NxN board • Create a choice set for placing a queen in each column • Unleash rules that detect captures • Systematically search all combinations of choices

  21. Dependency Directed Search Solution • Like chronological search solution, but • When inconsistent combination found, assert negation of queen statement. (Creating a nogood) • When searching, check for a nogood before trying an assumption.

  22. Dependency-driven search • Requirements • Choice sets, as before • Use dependency network to create nogoods, which should allow us to detect bad choices faster • How about dependency-driven backtracking? • Not yet, but soon...

  23. Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? Choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice)))))))

  24. Basic algorithm Record the solution when choice sets exhausted. (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice)))))))

  25. Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) Iterate through the choices in the choice set

  26. Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) If nogood is retrieved first, don’t attempt...

  27. Basic algorithm (defun dds (choice-sets) (cond ((null choice-sets) (record-solution)) (t (dolist (choice (car choice-sets)) (unless (nogood? choice) (while-assuming choice (if (consistent?) (dds (rest choice-sets)) (record-nogood choice))))))) Otherwise, try assuming each choice and calling dds recursively to get rest. Inconsistent entries saved as nogood.

  28. Real version of ddsearch more complex • Creates specialized contradiction handler for each assumption which stores the value of that assumption • Probably slows down the system • Still, faster than FTRE for large problems

  29. Chronological Search:Time required • IBM RT, Model 125, 16MB RAM, Lucid CL

  30. Chronological Search:Assumptions Explored

  31. Dependency Directed Search:Time used

  32. Dependency-Directed Search:Assumptions Explored

  33. Comparing the resultsTime in seconds

  34. Comparing the resultsAssumptions Explored

  35. Implications • Neither strategy changes the exponential nature of the problem • Dependency-directed search requires extra overhead per state explored • The overhead of dependency-directed search pays off on large problems when the cost of exploring a set of assumptions is high

  36. Justification-based Truth Maintenance Systems Building JSAINT

  37. JSAINT: Its task • Input: An indefinite integration problem • Output: An expression representing the answer JSAINT returns

  38. How SAINT Worked 1. Is problem a standard form? If so, substitute & return answer 2. Find potentially applicable transformations. For each transformation, create the subproblem of solving the transformed problem. • SAINT used 26 standard forms, 18 transformations • Also used many special-purpose procedures

  39. Knowledge about Integration • Standard formsTransformations

  40. Integration Operators • Provide direct solutions to simple problems(analogously to SAINT’s standard forms ) • Suggests ways of decomposing problems into simpler problems

  41. Representations • Mathematics is the easy partis represented as (integral (+ x 5) x)

  42. Issues in JSAINT design • Explicit representation of control knowledge • Suggestions Architecture • Special-purpose higher-level languages • Explanation generation

  43. Issue 1: Explicit representation of control knowledge • The use of show assertions in KM* is only the beginning! • Recording control decisions as assertions enables • Control knowledge to be expressed via rules • keeping track of what is still interesting via the TMS • Explaining control decisions • Provides grist for debugging and learning • Key part of JSAINT design is a control vocabulary

  44. The natural history of a problem New problem P P expanded (expanded P) (open P) (relevant P) P failed (expanded P) (open P) (relevant P) (failed P) Parent no longer open P solved (expanded P) (open P) (relevant P) (expanded P) (open P) (relevant P) (solved P) (solution-of P solution)

  45. Representing Goals • JSAINT uses the form of the goal itself(integrate (integral (+ x 5) x)) • Advantage: Easy to recognize recurring subproblems • Actually an AND/OR graph rather than an AND/OR tree • Alternative: Reify goals(goal GOAL86)(GOAL86 form-of (try (risch-algorithm (integrate (integral foo)))))

  46. Success or failure of problems (solved <P>) is believed exactly when problem P has been solved (failed <P>)is believed exactly when P cannot be solved by JSAINT given what it knows. (solution-of <P> <A>)holds exactly when A is the result of solving problem P

  47. Representing progress (expanded P)is believed exactly when work has begun on P (open P)is believed exactly when P has been expanded but is not yet solved or known to be unsolvable. (relevant P)is believed exactly when P is still potentially relevant to solving the original problem.

  48. Issue 2: Control via suggestions • Problem: Local methods cannot detect loops, combinatorial explosions • Solution: Decompose problem-solving operations into two kinds: • Local operations for “obvious” tasks, making relevant suggestions • Global operations for choosing what to do • Suggestions Architecture is a very useful way to organize problem solvers

  49. Homework 4 • Chapter 8 (page 258): Problem 1. (a) Problem 4 • Submit as :ASN 4 • Due: Feb. 1, 2001 before class

More Related