IMPACT Agent Implementation

1. IMPACT Agent Implementation Jürgen Dix University of Maryland/ University of Koblenz joint work with Thomas Eiter (TU Vienna), VS Subrahmanian (Maryland) 1

2. 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). Algorithms

3. 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. 1 Conflict freedom

4. 1. Sufficient Condition: 2. Sufficient Condition: Conflict freedom performance 0.02 sec 0.008 sec Even for many actions, it is fast. Even for many arguments, it is fast.

5. 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). Algorithms

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

7. Strong safety requires not only that queries are executable, but that their evaluation terminates in finite time. The executable code call condition 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 in AgentDE “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) X>5 & Z<3 Modification of the safety algorithm: Safety + Look-up in Table. (Linear in size(ccc) + linear in size(table) .) 2 Strong safety

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

9. 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). Algorithms

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

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

12. Regular Agent • 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 (under appropriate assumptions).

13. 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). Algorithms

14. 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. 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. 4 Boundedness

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

16. 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: 39 sec Note: massive amounts of data resident in flat (unindexed) Oracle files were accessed and network time(33 sec) is included. Status Set: 6 sec + 33 sec We have developed an incremental algorithm that takes as input: a feasible status set S[t] at time t a set of changes at time t and returns as output, a feasible status set S[t+1] which incorporates the changes. Not yet implemented, but we expect to decrease even the network time. Status Set Computation

17. Research to be Performed • Optimized unfolding: once the table of (Op,Action,CCC) triples is constructed, we must create a CCC-evaluation plan that merges common parts of different triples in this table. • Caching strategies: if an agent has a cache of size S available to it, what views of remote data should be cached there so as to optimize run-time computation? • Cost-based feasible status sets: how can the algorithms for feasible status set computation be extended to compute status sets that optimize an objective function? How can we extend our implementation to support this?