Presentation is loading. Please wait.

Presentation is loading. Please wait.

Computational Logic in IMPACT and in Agent Systems Jürgen Dix The University of Manchester (University of Maryland) 1.

Similar presentations


Presentation on theme: "Computational Logic in IMPACT and in Agent Systems Jürgen Dix The University of Manchester (University of Maryland) 1."— Presentation transcript:

1 Computational Logic in IMPACT and in Agent Systems Jürgen Dix The University of Manchester (University of Maryland) 1

2 ESSLLI02, Trento, Italy16/8/2002 2 Overview Part I: A Bird’s Eye View on IMPACT Part II: Planning: IMPACT’ing SHOP Part III: Heavily Loaded Agents (Part VI: Regular Agents)

3 ESSLLI02, Trento, Italy16/8/2002 3 I.1 Agent Definitions Shoham’s definition- an agent is a program supporting: Ongoing execution, planning adaptiveness, autonomy reactivity, mobility, intelligence FIPA’s definition: speech, visual, I/O primitives Messaging languages DARPA’s definition: autonomous, adapt, cooperate These are “behavioral” definitions. IMPACT provides a “structural” def. formal models of the desired “behaviors” specified by Shoham, FIPA, DARPA.

4 ESSLLI02, Trento, Italy16/8/2002 4 I.2 Motivations Agents are for everyone! Agentize arbitrary Legacy Code. Knowledge is distributed and heterogenous. Code-Call mechanism. Agents act wrt a clearly articulated semantics. Agent Program wrt Status Sets (Agents Implementation should be feasible.) (Complexity Analysis, Regular Agents)

5 ESSLLI02, Trento, Italy16/8/2002 5 I.3 What is Legacy Code? Arbitrary Code S can be seen as a triple S=(T,F,C), with 1.T is the set of all data types managed by S 2.F is a set of predefined functions accessing the data objects 3. C is a set of type composition operations State of an agent : at any given point t in time, the state of an agent is the set O S (t) of objects from the types T, managed by its internal code. State Change: only when 1.an action is executed or 2.a message has been received from another agent.

6 ESSLLI02, Trento, Italy16/8/2002 6 Code Call: d:f( arg 1,…,arg k ). Code Call Atom: in( X,d:f( arg 1,…,arg k )). Execute function f defined in agent d on the specified arguments. Returns a set of objects. I.4 Data Access Succeeds if X is in the set of objects returned –in(X, Oracle:select( ‘depots.rel’,item,=,oxygen masks )). Find all tuples with item field equal to “oxygen masks” –in(X, Route:plan( ‘map1’,20,20,50,43 )). Find all routes returned by route planner between points (20,20) and (50,43) w.r.t. map1. –Route:plan( ‘map1’,20,20,50,43 ). –Oracle:select( ‘depots.rel’,item,=,oxygen masks )

7 ESSLLI02, Trento, Italy16/8/2002 7 I.5 Data Access: Code Call Conditions A conjunction of –code call atoms and –comparison atoms. in(X, Oracle:select( ‘depots.rel’,item,=,oxygen masks )) & X.qty > 1000 & in(Y,route:plan ( ‘map’,99.25,X.x,X.y )). The above says: find X,Y such that: –X is a tuple in an Oracle “depot” relation specifying a depot with over 1000 oxygen masks, and –Y is a route from the location of that depot to a location (99,25) where the entity requesting the oxygen masks is located.

8 ESSLLI02, Trento, Italy16/8/2002 8 I.6 Overall Architecture What is an agent doing? Computing its semantics and acting accordingly. Evaluate messages Execute Actions Compute Semantics

9 ESSLLI02, Trento, Italy16/8/2002 9 I.7 What is an Agent?  Agents are built on top of legacy or specialized software modules or systems.  They access data using API functions. Software module Implementation Interface/API

10 ESSLLI02, Trento, Italy16/8/2002 10 I.7 What is an Agent? msg box Agent state (distributed) Implementation Interface/API  There is a message box with suitable functionality.  Code manipulates data structures, the contents of which (including msgbox ) describe the agent’s state.

11 ESSLLI02, Trento, Italy16/8/2002 11 I.7 What is an Agent? Actions msg box Agent state (distributed) Implementation Interface/API  Agents have available actions to change the state.  Actions are declaratively described through add/delete lists containing code call conditions. They are implemented through software code.

12 ESSLLI02, Trento, Italy16/8/2002 12 I.7 What is an Agent? Agent Program Actions msg box Agent state (distributed) Implementation Interface/API  Agents have an “agent program” encoding the agent’s operating principles  The program consists of rules that are declarative and can be easily written or modified.

13 ESSLLI02, Trento, Italy16/8/2002 13 I.7 What is an Agent? Integrity Constraints Action Constraints Agent Program Actions msg box Agent state (distributed) Implementation Interface/API  Integrity Constraints (to preserve properties of the state)  Action constraints (to ensure actions do not interfere)

14 ESSLLI02, Trento, Italy16/8/2002 14 I.7 What is an Agent? Agent Program Actions msg box Agent state (distributed) Implementation Interface/API  Based on semantics and current state, actions are executed.  These actions change its own state and other agents states as well. Actions Integrity Constraints Action Constraints Semantics

15 ESSLLI02, Trento, Italy16/8/2002 15 I.8 Agent Program (1) Set of rules of the form Op a( arg1,…,argn ) & Op 1 a 1 ( ) & … & Opa n ( ) Op is a “deontic modality” and is either –P - permitted –O - obligatory –Do - do –F – forbidden If code call condition is true and the deontic modalities in the rule body are true, then Op a( arg1,…,argn ) is true.

16 ESSLLI02, Trento, Italy16/8/2002 16 I.8 Agent Program (2) Most important part of the agent. Agent program rules must be carefully crafted to avoid inconsistencies. IMPACT provides facilities to create such rules. A class of programs is defined that can be efficiently implemented: Regular Agents. EXAMPLE: O processRequest(Msg.ID,Agent)  in(Msg,msgbox:getAllMsg()), =(Agent,Msg.Source) F maintainCourse(NoGo,Route,Loc)  in(NoGo,msgbox:getNoGo(Msg.ID)), in(Loc,autoPilot:getLoc()), in(Route,autoPilot:getRoute()), O processRequest(Msg. ID ), Do adjustCourse( NoGo,Route,Loc)

17 ESSLLI02, Trento, Italy16/8/2002 17 II.1 Evacuation Operations Situation: People need to be evacuated Send a Special Operations Force (SOF) team Task: Plan routes and means of transportation to be used by the team Problems: Plan editing, bookkeeping Access to planning knowledge needed information is  heterogeneous,  time-sensitive and  geographically distributed –Weather conditions –Transportation resources –Status of evacuees, current threats

18 ESSLLI02, Trento, Italy16/8/2002 18 II.2 How Can IMPACT Help? SHOP provides: –Scalable, high performance planning system –Generate and evaluate plans IMPACT provides: –Access to distributed,heterogeneous data sources –Seamless interoperability between different software capabilities –Ability to coordinate multiple agents Integrate SHOP into IMPACT, so that SHOP can utilize IMPACT’s capabilities during planning

19 ESSLLI02, Trento, Italy16/8/2002 19 Preconditions: Airport available? Weather ok for Plane? Subtasks:... … methods … Fixed Wings Helicopters Select transportation means Select helicopters Select area (A) Deploy sec. force (F,A,H) Embark sec. force(F,H) Fly(H,A) Disembark (F,H,A) Position security force (F,A)... Preconditions: Helicopters available? Weather ok for Helis? Subtasks: Select area Deploy security force … II.3 (HTN) Planning Use methods to decompose tasks –Each method may have preconditions (e.g., helicopters available) –Need to resolve interactions (e.g., deploy security force first) –If necessary, backtrack and try other methods

20 ESSLLI02, Trento, Italy16/8/2002 20 II. 4 How to Agentize SHOP [D et al., CLIMA 2000] [D et al., Annals of Math & AI, 2002] First, extend SHOP’s methods and operators to incorporate code calls –An agentized method is an expression of the form (:AgentMeth h  t ) where  h (the method’s head) is a compound task,   (the method’s preconditions) is a code call condition  t is a task list –An agentized operator is an expression of the form ( :AgentOp h  add  del ) where  h (the hea d) is a primitive task   add and  del are code call conditions  The set of variables in  add and  del is a subset of the set of variables in h

21 ESSLLI02, Trento, Italy16/8/2002 21 II.6 The A-SHOP Algorithm Theorem: Let D be a set of agentized methods and operators.If the add/delete- lists are strongly safe, then A-SHOP is sound and complete. (1) every plan returned by A-SHOP is correct; (2) A-SHOP is guaranteed to find a plan if it exists.

22 ESSLLI02, Trento, Italy16/8/2002 22 II.7 Experimental Scenario Conditions: Each phase: several possible routes Short routes more likely to have hostiles Longer routes may take too long Potential means of transportation: Fixed Wing Aircraft Airplanes Rotor Aircraft: Helicopters Land Vehicles: Jeeps etc According to doctrine the route will include: Assembly Point (AP) Phase 1 Prov. Headquarters (HQ) Phase 2 Interm. Staging Base (ISB) Phase 3 NEO Site (NEO) Phase 4 Safe Haven (SH)

23 ESSLLI02, Trento, Italy16/8/2002 23 II. 8 Implementing A-SHOP Agents that are part of A-SHOP –Shop: receives requests to create plans, and does task decomposition to create those plans –CodeCallConditions: checks code-call conditions for the Shop agent –Monitor: checks individual code calls within a code-call condition, and maintains changes to states made by the Shop agent’s operators Agents external to A-SHOP –Customer: represents the user who invokes A-SHOP –PPT: IMPACT agent invoked by A-SHOP to generate a PowerPoint document containing the final plan

24 ESSLLI02, Trento, Italy16/8/2002 24 II. 8 Info-Sources for A-SHOP Information sources: –Transport Authority: maintains information about assets available at different locations –Weather Authority: maintains information about weather conditions –Airport Authority: maintains information about assets available at different locations Other information sources –Situation: maintains information gathered during planning –Math: do mathematical calculations needed during planning A-SHOP generates agents on-the-fly.

25 ESSLLI02, Trento, Italy16/8/2002 25 II. 9 Results (Memoization)

26 ESSLLI02, Trento, Italy16/8/2002 26 II.9 Results New optimizations: Most time is spent to evaluate code call conditions (network time) rather than for the planning itself. More specifically: How can a set of code call conditions processed more efficiently?

27 ESSLLI02, Trento, Italy16/8/2002 27 III. Heavily Loaded Agents Problem: ccc1: in( X,spatial:range( T 1,40,50,25 )) ccc2: in( Z,spatial:range( T 2,40,50,50 )) (spatial:range( T 1,x,y,z ) gives all points in T 1 that are at most z units away from (x,y) ) Given a set of ccc’s (requests). Instead of executing them one-at-a-time, find more efficient procedures. Clearly, ccc1 is a subset of ccc2 if T 1 =T 2.

28 ESSLLI02, Trento, Italy16/8/2002 28 III.1 The very idea Input from the agent developer : She knows under which conditions which inclusions hold. Definition of a language for expressing these inclusions: These statements, invariants, will be used as axioms from which new invariants can be deduced. Distinguish Development/Deployment time: Algorithms for compiling invariants at development time can be more costly than those used at deployment time. We try to merge the requests by detecting commonalities between them.

29 ESSLLI02, Trento, Italy16/8/2002 29 III. 4 Main Definition Definition (Invariant) An invariant is an expression of the form where  ic is an invariant condition (conjunctions of t 1 op t 2 )  ie i are invariant expressions (unions/intersections strongly safe ccc’s) T=T’ and X=X’ and Y=Y’ and Rad { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/14/4229422/slides/slide_29.jpg", "name": "ESSLLI02, Trento, Italy16/8/2002 29 III.", "description": "4 Main Definition Definition (Invariant) An invariant is an expression of the form where  ic is an invariant condition (conjunctions of t 1 op t 2 )  ie i are invariant expressions (unions/intersections strongly safe ccc’s) T=T’ and X=X’ and Y=Y’ and Rad

30 ESSLLI02, Trento, Italy16/8/2002 30 III.2 Architecture Development Time: 1. Agent developer states set I of invariants. 2. Derive additional invariants (wrt implication check). Deployment Time:  Identify three relationships between ccc’s: 1. Identical ccc’s. 2. Implied ccc’s. 3. Overlapping ccc’s (neither 1. nor 2. but conjunction is consistent)  Based on the above and a cost model for ccc evaluations, we developed various merge-algorithms parameterized by heuristics.

31 ESSLLI02, Trento, Italy16/8/2002 31 III. 3 Example Overlapping ccc’s: ccc1: in( X,spatial:horizontal( map,100,200 )). ccc2: in( Z,spatial:horizontal( map,150, 250 )). Clearly, it is better to execute ccc3: in( X,spatial:horizontal( map,100,250 )), and then executing selections to get the results for ccc1 and ccc2. spatial:horizontal(map,a,b ) gives back all points (x,y) in map s.t. a { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/14/4229422/slides/slide_31.jpg", "name": "ESSLLI02, Trento, Italy16/8/2002 31 III.", "description": "3 Example Overlapping ccc’s: ccc1: in( X,spatial:horizontal( map,100,200 )). ccc2: in( Z,spatial:horizontal( map,150, 250 )). Clearly, it is better to execute ccc3: in( X,spatial:horizontal( map,100,250 )), and then executing selections to get the results for ccc1 and ccc2. spatial:horizontal(map,a,b ) gives back all points (x,y) in map s.t. a

32 ESSLLI02, Trento, Italy16/8/2002 32 III. 5 Results: Development Phase  Checking implication is  undecidable for arbitrary datatypes and  co-NP complete for finite domains.  Therefore: use an incomplete but sound algorithm (efficiency).

33 ESSLLI02, Trento, Italy16/8/2002 33 III. 6 Results: Deployment Phase  Checked against classical query optimization techniques (Sellis 1994): viewed as a state search problem and use A * algorithm.  We ran experiments on relational data and on a spatial database used in IMPACT:

34 ESSLLI02, Trento, Italy16/8/2002 34 III.7 Results  Spatial domain: the classical method competes only beyond 70% sharingfactor.  Re lational domain: the classical method competes only beyond 40% sharingfactor.

35 ESSLLI02, Trento, Italy16/8/2002 35 III. 8 Results  Our merge algorithms handle more than twice as many simultaneous ccc’s as A *.  They run 100-6000 times faster.  The cost of the execution plans is at most 5% more compared with A *.  Checking for overlapping ccc’s pays off.

36 ESSLLI02, Trento, Italy16/8/2002 36 Summary IMPACT: Is based on formal, mathematical methods (Computational Logic). Identifies efficiently implementable classes of programs. IMPACT’ing SHOP: Emphasis is put on building on top of legacy code and distributed heterogenous data, thus taking real applications seriously. Heavily Loaded Agents: Framework is detailed enough to formulate and attack general problems, but yet is not bound to IMPACT alone.

37 ESSLLI02, Trento, Italy16/8/2002 37 References Publications: Defeasible Reasoning TCS 02 (D et al.) Super Logic ProgramsACM 02 (Brass/D/Prz) Meta-Agent ProgramsJLP 00 (D/VS/Pick) Temporal Agent ProgramsAIJ 01 (D/Kraus/VS) Probabilistic Agent ProgramsACM 00 (D/Nanni/VS) Heavily Loaded Agents subm. (D/Ozcan/VS) Impacting SHOP: Planning AMAI 02 (D/Munoz/Nau) Heterogenous Agent Systems MIT Press 2000 (D et al.) Agents dealing with time and Uncertainty subm. (D/Kraus/VS)

38 ESSLLI02, Trento, Italy16/8/2002 38 IV. Algorithms Compile time –check syntax –check regularity 1 conflict freedom 2 strong safety 3 deontic stratification 4 boundedness: –unfold out agent program. –Compute initial status set. Run-time –compute status set. –trigger actions. –incrementally compute status set (algorithm developed, not implemented).

39 ESSLLI02, Trento, Italy16/8/2002 39 IV.1 Conflict freedom EXAMPLE: Consider the following two non ground rules:  F maintainCourse(NoGo,Rout e,Loc)  ccc 1, Do action1 O maintainCourse(NoGo,Rout e,Loc)  ccc 2, F action2,  Both can be conflict-free (depending on ccc 1, ccc 2 being true in the state) or not. Two ground rules Head1  Body1 Head2  Body2 conflict in a state iff –the heads of the two rules conflict, and –ccc’s in the bodies of the rules are true in the state, and –  deontically consistent status set that makes the action literals in the bodies true. THEOREM: Checking conflict freeness is undecidable. Developed 4 different sufficient conditions: if satisfied, they all guarantee that underlying set of rules is conflict free.

40 ESSLLI02, Trento, Italy16/8/2002 40 IV.3 Conflict freedom performance 1. Sufficient Condition: 2. Sufficient Condition: Even for many actions, it is fast. Even for many arguments, it is fast. 0.008 sec 0.02 sec

41 ESSLLI02, Trento, Italy16/8/2002 41 IV. Algorithms Compile time –check syntax –check regularity 1 conflict freedom 2 strong safety 3 deontic stratification 4 boundedness: –unfold out agent program. –Compute initial status set. Run-time –compute status set. –trigger actions. –incrementally compute status set (algorithm developed, not implemented).

42 ESSLLI02, Trento, Italy16/8/2002 42 IV.2 Safety Safety is a condition on code call conditions that ensures that the code call condition is evaluable. We developed a provably sound and complete algorithm for testing safety. EXAMPLE: The code call condition  in(RP, terrain:getPlan(P1,P2,Vehicle)) & in(RP’, terrain:getPlan(P2,P3,Vehicle)) & in(P3, coord:nextPoint(P1,P2,Goal)) is safe, if P1,P2,Vehicle, Goal are given: Reorder the ccc !

43 ESSLLI02, Trento, Italy16/8/2002 43 IV.2 Strong safety Strong safety requires not only that queries are executable, but that their evaluation terminates in finite time. The executable ccc in(X, math:geq(25)) & in(Y, math:square(X)) & Y < 2000 if executed left-to-right does not terminate. If reordered, it does: it is strongly safe. There is no finiteness- checking! Solution: Specifying an “infiniteness table” listing all code calls returning infinite answers. Developed a provably correct algorithm to polynomially check strong safety of a ccc. Table lists code calls and a binding pattern for the variables involved: math:geq(X) ($) math:fct(X,Y,Z) (X,$,Z)  Modification of the safety algorithm: Safety + Look-up in Table. (Linear in size(ccc) + linear in size(table).)

44 ESSLLI02, Trento, Italy16/8/2002 44 IV.2 Example/Performance of (strong) safety EXAMPLE: Code call condition ccc with up to 20 conjuncts. Each point in the graph (fixed # of conjuncts) is the result of: –do 1000 runs by varying # of arguments, # of variables (generate ccc randomly) and take the average run time. –Result: safe_ccc is extremely fast. Suggests that safety checking for programs containing 1000 rules can be done in 20-40 milliseconds 20 conj. 0.046

45 ESSLLI02, Trento, Italy16/8/2002 45 IV. Algorithms Compile time –check syntax –check regularity 1 conflict freedom 2 strong safety 3 deontic stratification 4 boundedness: –unfold out agent program. –Compute initial status set. Run-time –compute status set. –trigger actions. –incrementally compute status set (algorithm developed, not implemented).

46 ESSLLI02, Trento, Italy16/8/2002 46 IV.3 Deontic stratification This is a complex condition requiring that an action not be defined negatively in terms of itself. EXAMPLE:  Do compute(Loc)  ¬ Do compute(Loc), misc1  Do compute(Loc)  Do something(P), misc2 Do something(P)  ¬ Do compute(Loc), misc3  Do compute(Loc)  ¬ O compute(Loc), misc4  But the following is harmless: Do compute(Loc)  ¬ F compute(Loc), misc4  A deontically stratified program comes in finitely many strata, negative dependencies lead to strictly lower strata.

47 ESSLLI02, Trento, Italy16/8/2002 47 IV.3 Deontic stratification We developed a polynomial algorithm to evaluate deontic stratifiability. Graph based approach. Algorithm is provably correct and performs well. Performance results on the right. Number of rules: 200 0.26sec

48 ESSLLI02, Trento, Italy16/8/2002 48 A regular agent program is one that is: –1: conflict free –2: strongly safe –3: deontically stratifiable –4: unfoldable (see next slide) Regular agents require that all components of the agent satisfy an appropriate mix of the above conditions (e.g., integrity constraints must have strongly safe bodies, etc.). THEOREM: Every regular agent has a unique rational status set. THEOREM: The data complexity of computing the above rational status set is polynomial.

49 ESSLLI02, Trento, Italy16/8/2002 49 IV. Algorithms Compile time –check syntax –check regularity 1 conflict freedom 2 strong safety 3 deontic stratification 4 boundedness: –unfold out agent program. –Compute initial status set. Run-time –compute status set. –trigger actions. –incrementally compute status set (algorithm developed, not implemented).

50 ESSLLI02, Trento, Italy16/8/2002 50 IV.5 Boundedness  Consider the program Do com(Loc)  Do some(P), ccc1 Do some(P)  Do else(Loc),ccc2 Do else(P)  ccc3 and let ccc3 be false in the state. Instead of checking Do-actions at run-time we simplify the program at compile time into: Do com(Loc)  ccc3, ccc2, ccc1 Do some(P)  ccc3, ccc2 Do else(P)  ccc3 Replace successively in all rules the positive action atoms in the bodies.  Boundedness: If, eventually, all positive body atoms disappear: larger but simpler program. This is also undecidable in general. We developed a provably correct polynomial (under suitable conditions) algorithm to unfold agent programs.  Run-time Computation: Start with those rules whose bodies contain only ccc’s or negative action status atoms.

51 ESSLLI02, Trento, Italy16/8/2002 51 IV.6 Unfolding Performance No detailed study yet (not enough agent programs available, not clear how to vary large number of parameters). Sample Program: Logistics demo based on US Army War Reserves data. –Unfolding: 0.82 sec (17 rules transformed into 30) For regular agent programs, we have developed an algorithm that takes the result of the unfolding step as input, and produces as output, a rational status set. This algorithm has been implemented and performs well. –Status Set: 29 sec –Note : massive amounts of data resident in flat (unindexed) Oracle files were accessed and network time (24 sec) is included. –Status Set: 5 sec + 24 sec


Download ppt "Computational Logic in IMPACT and in Agent Systems Jürgen Dix The University of Manchester (University of Maryland) 1."

Similar presentations


Ads by Google