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

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

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

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

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

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

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

Justifying assertions in terms of other beliefs (assert! (. )) installs a justification (assert! ) makes a premise (assume! ) makes an assumption rassume!, rassert! as before retract! disables an assumption (contradiction ) installs a contradiction

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) Create datum & tms node Handle bookkeeping of dependencies, based on justification

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

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

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

Tying rule execution to belief states (rule ) Triggers are ( ) Types of conditions –:IN –:OUT –:INTERN Trigger options –:VAR –:TEST

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

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

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

Handling Contradictions (with-contradiction-handler. ) We’ll see example with N-queens problem

Search Example: The N-Queens problem Good solutionBad solution

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

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.

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

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

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))))))) Record the solution when choice sets exhausted.

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

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

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.

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

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

Chronological Search: Assumptions Explored

Dependency Directed Search: Time used

Dependency-Directed Search: Assumptions Explored

Comparing the results Time in seconds

Comparing the results Assumptions Explored

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

Justification-based Truth Maintenance Systems Building JSAINT

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

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

Knowledge about Integration Standard forms Transformations

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

Representations Mathematics is the easy part is represented as (integral (+ x 5) x)

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

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

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

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

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

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.

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

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