IMPACT Agent Implementation
Jürgen Dix
University of Maryland/ University of Koblenz
joint work with
Thomas Eiter (TU Vienna),
VS Subrahmanian (Maryland)
1
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).

1999 IMPACT Workshop
2
1 Conflict freedom

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.
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.
1999 IMPACT Workshop
3
Conflict freedom performance

1. Sufficient Condition:
0.008 sec
Even for many actions,
it is fast.

2. Sufficient Condition:
0.02 sec
Even for many arguments,
it is fast.
1999 IMPACT Workshop
4
Algorithms

Compile time


check syntax
check regularity
– 1 conflict freedom
– 2 strong safety
– 3 deontic stratification

Run-time

compute status set.

trigger actions.
incrementally compute
status set (algorithm
developed, not implemented).

– 4 boundedness:
unfold out agent
program.
Compute initial status set.
•

1999 IMPACT Workshop
5
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!
1999 IMPACT Workshop
6
2 Strong safety

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) .)
1999 IMPACT Workshop
7
Example/Performance of
(strong) safety


EXAMPLE:
Code call condition ccc with up
to 20 conjuncts.
0.046
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.
1999 IMPACT Workshop
8
Algorithms

Compile time


check syntax
check regularity
– 1 conflict freedom
– 2 strong safety
– 3 deontic stratification

Run-time

compute status set.

trigger actions.
incrementally compute
status set (algorithm
developed, not implemented).

– 4 boundedness:
unfold out agent
program.
Compute initial status set.
•

1999 IMPACT Workshop
9
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.
1999 IMPACT Workshop
1
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
1999 IMPACT Workshop
1
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 data complexity of computing the above rational
status set is polynomial (under appropriate assumptions).
1999 IMPACT Workshop
1
Algorithms

Compile time


check syntax
check regularity
– 1 conflict freedom
– 2 strong safety
– 3 deontic stratification

Run-time

compute status set.

trigger actions.
incrementally compute
status set (algorithm
developed, not implemented).

– 4 boundedness:
•

unfold out agent
program.
Compute initial status set.
1999 IMPACT Workshop
1
4 Boundedness
Consider the program

Do com(Loc)  Do some(P), ccc1
Do some(P)  Do else(Loc), ccc2
Do else(P)  ccc3

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.
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.
1999 IMPACT Workshop
1
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)
1999 IMPACT Workshop
1
Status Set Computation


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.



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
a feasible status set S[t] at
time t
a set of changes at time t
and returns as output,
This algorithm has been
implemented and performs well.
 Status Set: 39 sec

We have developed an
incremental algorithm that
takes as input:


a feasible status set S[t+1]
which incorporates the
changes.
Not yet implemented, but we
expect to decrease even the
network time.
1999 IMPACT Workshop
1
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?
1999 IMPACT Workshop
1