Putting the JTMS to Work. Outline Interface between a JTMS and a rule engine Chronological Search...

Post on 12-Jan-2016

214 views 0 download

Transcript of Putting the JTMS to Work. Outline Interface between a JTMS and a rule engine Chronological Search...

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

InferenceEngine TMS

Problem Solver

Inferred assertion

s

Rules and assertion

s

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

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

TMS Node

TMS Node 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 <list of triggers> <body>)• Triggers are (<condition> <pattern>)• 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 <jtms> <handler> . <body>)

• We’ll see example with N-queens problem

Search Example: The N-Queens problem

Good solution Bad 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

0102030405060708090100

4 5 6 7 8

Chronological Search:Assumptions Explored

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

4 5 6 7 8

Dependency Directed Search:Time used

0

20

40

60

80

100

120

140

160

180

4 5 6 7 8

Dependency-Directed Search:Assumptions Explored

0

500

1000

1500

2000

2500

3000

4 5 6 7 8

Comparing the resultsTime in seconds

0

20

40

60

80

100

120

140

160

180

4 5 6 7 8

ChronoDDS

Comparing the resultsAssumptions Explored

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

4 5 6 7 8

ChronoDDS

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

dxxxex 63.0)7.1sin(2.342

JSAINT returns

2e x2

1.88cos(1.7x) 0.63x

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

vdv v 1

22

cg v dv c g v dv( ) ( )

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)

(x 5)dx

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

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