1 / 51

Computational Logic in IMPACT and in Agent Systems

Computational Logic in IMPACT and in Agent Systems. Jürgen Dix The University of Manchester (University of Maryland). 1. 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).

muniya
Download Presentation

Computational Logic in IMPACT and in Agent 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. Computational Logic in IMPACT and in Agent Systems Jürgen Dix The University of Manchester (University of Maryland) 1

  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) 16/8/2002

  3. 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. I.1 Agent Definitions 16/8/2002

  4. I.2 Motivations • Agents are for everyone!Agentizearbitrary 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) 16/8/2002

  5. Arbitrary Code S can be seen as a triple S=(T,F,C), with T is the set of alldata typesmanaged byS Fis a set ofpredefined functionsaccessing the data objects Cis a set oftype composition operations State of an agent: at any given point t in time, the state of an agent is the set OS(t) of objects from the types T , managed by its internal code. State Change: only when an action is executed or a message has been received from another agent. I.3 What is Legacy Code? 16/8/2002

  6. I.4 Data Access • Code Call:d:f(arg1,…,argk). • Code Call Atom: in(X,d:f(arg1,…,argk)). Execute function f defined in agent d on the specified arguments.Returns a set of objects. • Route:plan( ‘map1’,20,20,50,43). • Oracle:select( ‘depots.rel’,item,=,oxygen masks) 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. 16/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. 16/8/2002

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

  9. Interface/API Implementation 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 16/8/2002

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

  11. Interface/API Implementation I.7 What is an Agent? Actions msg box Agent state (distributed) • 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. 16/8/2002

  12. Interface/API Implementation I.7 What is an Agent? Agent Program Actions msg box Agent state (distributed) • 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. 16/8/2002

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

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

  15. I.8 Agent Program (1) • Set of rules of the form Opa(arg1,…,argn)<--- <code call condition> &Op1a1(<args>) & … & Opan(<args>) • 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 Opa(arg1,…,argn) is true. 16/8/2002

  16. 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: OprocessRequest(Msg.ID,Agent)  in(Msg,msgbox:getAllMsg()), =(Agent,Msg.Source) FmaintainCourse(NoGo,Route,Loc)  in(NoGo,msgbox:getNoGo(Msg.ID)), in(Loc,autoPilot:getLoc()), in(Route,autoPilot:getRoute()), OprocessRequest(Msg.ID), DoadjustCourse(NoGo,Route,Loc) I.8 Agent Program (2) 16/8/2002

  17. 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 II.1 Evacuation Operations 16/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 16/8/2002

  19. 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) • . . . … methods … Helicopters Fixed Wings • Preconditions: • • Helicopters • available? • • Weather ok • for Helis? • Subtasks: • Select area • Deploy security • force • … Preconditions: • Airport available? • Weather ok for Plane? Subtasks: . . . 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 16/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 hct) where • h(the method’s head) is a compound task, • c(the method’s preconditions) is a code call condition • tis a task list • An agentized operator is an expression of the form (:AgentOphcadd cdel) where • h(the head) is a primitive task • cadd and cdel are code call conditions • The set of variables in cadd and cdel is a subset of the set of variables in h 16/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-SHOPis sound and complete. (1) every plan returned byA-SHOPis correct; (2) A-SHOPis guaranteedto find a plan if it exists. 16/8/2002

  22. II.7 Experimental Scenario According to doctrinethe 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) 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 16/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 16/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. 16/8/2002

  25. II. 9 Results (Memoization) 16/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? 16/8/2002

  27. III. Heavily Loaded Agents • Problem: ccc1: in(X,spatial:range(T1,40,50,25)) ccc2: in(Z,spatial:range(T2,40,50,50)) 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 T1 =T2. (spatial:range(T1,x,y,z)gives all points inT1 that are at most z units away from (x,y)) 16/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. 16/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 t1op t2 ) • iei are invariant expressions (unions/intersections strongly safe ccc’s) ic  (ie1subsetie2 ) T=T’ and X=X’ and Y=Y’ and Rad<Rad’  in(Z,spatial:range(T,X,Y,Rad)) subset in(W,spatial:range(T’,X’,Y’,Rad’)) 16/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. 16/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 maps.t. a<y<b. 16/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). 16/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: 16/8/2002

  34. III.7 Results • Spatial domain:the classical method competes only beyond 70% sharingfactor. • Relational domain: the classical method competes only beyond 40% sharingfactor. 16/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. 16/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. 16/8/2002

  37. Publications: Defeasible ReasoningTCS 02 (D et al.) Super Logic ProgramsACM 02 (Brass/D/Prz) Meta-Agent ProgramsJLP 00 (D/VS/Pick) Temporal Agent Programs AIJ 01 (D/Kraus/VS) Probabilistic Agent ProgramsACM 00 (D/Nanni/VS) Heavily Loaded Agents subm. (D/Ozcan/VS) Impacting SHOP: PlanningAMAI 02 (D/Munoz/Nau) Heterogenous Agent Systems MIT Press 2000(D et al.) Agents dealing with time and Uncertainty subm. (D/Kraus/VS) References 16/8/2002

  38. 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). IV. Algorithms 16/8/2002

  39. EXAMPLE: Consider the following two non ground rules: FmaintainCourse(NoGo,Route,Loc) ccc1 , Do action1 OmaintainCourse(NoGo,Route,Loc) ccc2 , F action2, Both can be conflict-free (depending on ccc1, ccc2 being true in the state) or not. Two ground rulesHead1Body1Head2Body2conflict in a state iff the heads of the two rules conflict, and ccc’s in the bodies of the rules are truein 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. IV.1 Conflict freedom 16/8/2002

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

  41. 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). IV. Algorithms 16/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, ifP1,P2,Vehicle, Goal are given: Reorder the ccc! 16/8/2002

  43. 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) .) IV.2 Strong safety 16/8/2002

  44. 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 IV.2 Example/Performance of (strong) safety 0.046 20 conj. 16/8/2002

  45. 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). IV. Algorithms 16/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. 16/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. 0.26sec Number of rules: 200 16/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 datacomplexity of computing the above rational status set is polynomial. 16/8/2002

  49. 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). IV. Algorithms 16/8/2002

  50. 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. IV.5 Boundedness 16/8/2002

More Related