tr tabling presentation_2010_09

Transaction Logic Implementation Tabled T R Summary

Tabling for Transaction Logic

Paul Fodor Michael Kifer

State University of New York at Stony BrookStony Brook, NY 11794, U.S.A

12th International ACM SIGPLAN Symposium on Principlesand Practice of Declarative Programming,

Hagenberg, Austria


Overview Tabling for Transaction Logic

Transaction Logic is a logic for representing proceduralknowledge

Applications in logic programming, databases, AI planning,workflows, Web services, security policies, reasoning aboutactions

Implementations (Flora2, Toronto TR)Problem with existing implementations:

Not logically complete due to the inherent difficulty andtime/space complexity (analogous to the difference betweenplain Prolog and Datalog)

Solution:Tabling for a logically complete evaluation strategy forTransaction Logic


Outline

Overview of Transaction LogicTabling Transaction Logic

Proof theory with tablingSoundness and completeness resultsTermination

Difficulties with implementing tablingState copying, comparison (time, space issues)Solutions: logs vs. full state materialization, various datastructures (tries, balanced trees), table skipping

Experimental resultsConclusions and future work


Transaction Logic

Logic for programming state-changing actions andreasoning about their effectsElementary state transitions

insert/1 and delete/1 specify basic updates of the currentstate of the databasehave both a truth value and a side effect on the database

Connectives: classical logical connectives (∧, ∨, not ) andadditional connectives (⊗, ⊕, ♦, �, |)φ : −γ define γ to be an execution of φ; (Hornφ⊗ ψ means: execute φ, then execute ψ; Serial TR)


Transaction Logic

A formula φ in Transaction Logic is a transaction and has atruth value over execution paths (sequences of states)

s1 s2 s3 sn-1 snsn-2

States: s1 (initial state), . . . , sn (final state)Semantics: φ executes along π iff φ is true on πProof theory: executes φ along π as it proves φ


Transaction Logic Example 1

Consuming paths (reachability in the graph by traversingedges and then swallowing them):

reach(X ,Y ) : −reach(X ,Z )⊗ edge(Z ,Y )⊗ delete(edge(Z ,Y )).reach(X ,X ).

edge/2 is a binary fluentreach/2 is a binary actiondelete(edge(N,M)) is the action of deleting the edge(N,M)



Hamiltonian cycle (visits each vertex exactly once,Hamiltonian cycles are detected by swallowing the alreadytraversed vertexes):

hCycle(Start ,Start) : − notvertex(X ).hCycle(Start ,X ) : −

edge(X ,Y )⊗ vertex(Y )⊗delete(vertex(Y ))⊗ insert(mark(X ,Y ))⊗hCycle(Start ,Y )⊗ insert(vertex(Y )).

reach(X ,X ).

edge, vertex and mark are fluentsinsert(mark(X ,Y )) denotes the action of insertingmark(X,Y) in the statedelete(edge(N,M)) is the action of deleting the edge(N,M)



hCycle(Start ,Start) : − notvertex(X ).hCycle(Start ,X ) : −

edge(X ,Y )⊗ vertex(Y )⊗delete(vertex(Y ))⊗ insert(mark(X ,Y ))⊗hCycle(Start ,Y )⊗ insert(vertex(Y )).

reach(X ,X ).

The second rule does the searchMany possible ways to failOnly few succeed

The changes are backtrackable



Planning for building pyramids of blocks (actions: pickup,putdown, recursive stack, unstack):

stack(0, Block).stack(N, X) : − N > 0⊗ move(Y , X)⊗ stack(N − 1, Y )

⊗on(Y , X).stack(N, X) : − N > 0⊗ on(Y , X)⊗ unstack(Y )

⊗stack(N, X).unstack(X) : − on(Y , X)⊗ unstack(Y )⊗ unstack(X).unstack(X) : − isclear(X) ∧ on(X , table).unstack(X) : − (isclear(X) ∧ on(X , Y ) ∧ Y 6= table)

⊗move(X , table).unstack(X) : − on(Y , X)⊗ unstack(Y )⊗ unstack(X).move(X , Y ) : − X 6= Y ⊗ pickup(X)⊗ putdown(X , Y ).pickup(X) : − clear(X)⊗ on(X , Y )

⊗delete(on(X , Y ))⊗ insert(clear(Y )).putdown(X , Y ) : − clear(Y )⊗ not on(X , Z1)

⊗not on(Z2, X)⊗ delete(clear(Y ))⊗insert(on(X , Y )).


Serial-Horn transaction logic

Serial goals: (∃)β1 ⊗ β2 ⊗ 2 . . .⊗ βn

A serial-Horn rule is a statement of the form

h : − b1 ⊗ b2 ⊗ . . .⊗ bn. (1)

h is an atomic formulab1, ..., bn are literals.A literal is either an atomic formula or a negated fluent ofthe form not fModels - mappings from paths to classical modelsMP |= (∃)β1 ⊗ β2 ⊗ 2 . . .⊗ βn

Executional entailmentP,D0,D1, . . . ,Dn |= (∃)β1 ⊗ β2 ⊗ 2 . . .⊗ βn


Serial-Horn transaction logic

SLD-like resolution proof strategyPath F I aims to prove statements of the form (sequent)P,D --- Dn ` (∃)β1 ⊗ β2 ⊗ 2 . . .⊗ βn

An inference succeeds if and only if it finds an execution forthe transaction on a sequence of database statesD0, . . . ,Dn


Path FI proof theory for serial-Horn transaction logic

Axioms: P,D --- Dn ` ( )Inference Rules: In Rules 1–3 below, σ is a substitution, a and b are atomic formulas, and φ and rest

are serial goals.1. Applying transaction definitions:

Suppose a← φ is a rule in P whose variables have been renamed apart so thatthe rule shares no variables with b ⊗ rest . If a and b unify with a most generalunifier σ, then

P,D --- Dn ` (∃) (φ⊗ rest)σP,D --- Dn ` (∃) (b ⊗ rest)

2. Querying the database:If b is a fluent literal, bσ and rest σ share no variables, and bσ is true in thedatabase state D then

P,D --- Dn ` (∃) rest σP,D --- Dn ` (∃) (b ⊗ rest)

3. Performing elementary updates:If bσ and rest σ share no variables, and b σ is an elementary action that changesstate D1 to state D2 then

P,D2 --- Dn ` (∃) rest σP,D1 --- Dn ` (∃) (b ⊗ rest)


Path FI proof theory for serial-Horn transaction logic

No particular way of applying the inference rules.If these rules are applied in the forward direction, then allexecution paths will be enumerated, but undirected,exhaustive and implementational impracticalBackward direction (the usual SLD resolution withleft-to-right literal selection): goal-directed search, efficient,BUT incomplete (similarly to Prolog)


Consuming Paths Tabling Example

reach(X ,Y ) : −reach(X ,Z )⊗ edge(Z ,Y )⊗ delete(edge(Z ,Y )).reach(X ,X ).

Initial state:a

c

b

d

Query: reach(a,X ) for all X reachable from a and returnstates

reach(a,Z),edge(Z,Y),delete(edge(Z,Y)) s02:

reach(a,X) s01:

[X/Z]

Infinite derivation branch


Tabled Transaction Logic

Tabling in DatalogMemoize callsRemember answers

Major differences from tabling Datalog:Memoize the database states in which the calls were madeRemember result states created by execution of calls



Algorithm:On calling a subgoal to a tabled predicate in a state, checkif this is the first occurrence of this call in that state:If the call is new, save (goal , state) in a global table, andcontinue using normal clause resolution to computeanswers and the result database states for the subgoal

The computed (answer , result − state) pairs are recorded inthe answer table created for the (goal, state) pair

If the call is not new and a pair (goal , state) exists in thetable, the answers to the call are returned directly from theanswer table for (goal , state)



A tabled goal dominates another in tabled resolution ifthe two goals are variants of each other (variant tabling)the first goal subsumes the second (subsumptive tabling)


Modified proof theory for tabling for serial-Horntransaction logic

1a. Applying transaction definitions for tabled predicates:Suppose b ⊗ rest is a goal for a program P where b is a call to a tabled predicateencountered for the first time at state D (i.e., no dominating pair (c,D) is in the tablespace). Let a← φ be a rule in P whose variables have been renamed apart fromb ⊗ rest (i.e., the rule shares no variables with the goal) and suppose that a and bunify with the mgu σ. Then:


and the pair (b,D) is added to the table space. When the sequentP,D --- D′ ` (∃) (φσ)γ, for some substitution γ, is derived, the answer (bγ,D′) isadded to the answer table associated with the table entry (b,D).

1b. Returning answers from answer tables:Suppose b ⊗ rest is a goal call to program P at state D, b’s predicate symbol isdeclared as tabled, and let there be a dominating pair (c,D) in the table space.Suppose that the answer table for (c,D) has an entry (a,D′) and a and b unify withmgu σ. Then:

P,D′ --- Dn ` (∃) (rest)σP,D --- Dn ` (∃) (b ⊗ rest)

1c. Applying transaction definitions for non-tabled predicates:Let a← φ be a rule in P and a’s predicate symbol is not tabled. Assume that thisrule’s variables have been renamed apart from b ⊗ rest and that a and b unify withmgu σ. Then




reach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Step 1:

reach(a,Z),edge(Z,Y),del.edge(Z,Y) s02:

reach(a,X) s01:

[X/Z]

States: {s0}Solution table:

Call,Initial state Answer-unification > Final statereach(a, X) in s0 {}

Lookup table:

Node Call Index in Solution table (Answer)2 reach(a, X) in s0 0



reach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Step 2:


reach(a,X) s01:

[X/Z]

[] s0

[X/a]

States: {s0}Solution table:

Call,Initial state Answer-unifications > Final statesreach(a, X) in s0 {reach(a, a) > s0}

Lookup table:



Consuming Paths Tabling Examplereach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Steps 3,4 and 5:


reach(a,X) s01:

[X/Z]

[] s0

[X/a]

edge(a,Y),del.edge(a,Y) s0

[Z/a]>s0

[Y/b] [Y/c]

del.edge(a,b) s0 del.edge(a,c) s0

[] s1 [] s2a

c

b

d

a

c

b

d

a

c

b

d

States: {s0, s1 = {edge(a, c), edge(b, a), edge(b, d)}, s2 = {edge(a, b), edge(b, a), edge(b, d)} }Solution table:

Call,Initial state Answer-unifications > Final statesreach(a, X) in s0 {reach(a, a) > s0, reach(a, b) > s1, reach(a, c) > s2}

Lookup table:Node Call Index in Solution table (Answer)

2 reach(a, X) in s0 1


Consuming Paths Tabling Examplereach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Steps 6,7 and 8:


reach(a,X) s01:

[X/Z]

[] s0

[X/a]


[Z/a]>s0

[Y/b] [Y/c]


[] s1 [] s2

edge(b,Y),del.edge(b,Y) s1

[Z/b]>s1

[Y/a] [Y/c]

del.edge(b,a) s1 del.edge(b,c) s1

[] s3 [] s4

a

c

b

d

a

c

b

d

a

c

b

d

States: {s0, s1, s2, s3 = {edge(a, c), edge(b, d)}, s4 = {edge(a, c), edge(b, a)} }Solution table:

Call,Initial state Answer-unifications > Final statesreach(a, X) in s0 {reach(a, a) > s0, reach(a, b) > s1, reach(a, c) > s2,

reach(a, a) > s3, reach(a, d) > s4}Lookup table:




Steps 9-15:


reach(a,X) s01:

[X/Z]

[] s0

[X/a]


[Z/a]>s0

[Y/b] [Y/c]


[] s1 [] s2


[Z/b]>s1

[Y/a]

del.edge(b,a) s1

[] s3

edge(c,Y),del.edge(c,Y) s2

[Z/c]>s2

[Y/c]

del.edge(b,c) s1

[] s4

fail


[Z/a]>s3

[Y/c]

del.edge(a,c) s3

[] s5


reach(a,X) s01:

[X/Z]

[] s0

[X/a]


[Z/a]>s0

[Y/b] [Y/c]


[] s1 [] s2


[Z/b]>s1

[Y/a]

del.edge(b,a) s1

[] s3

edge(c,Y),del.edge(c,Y) s2[Z/c]>s2

[Y/d]

del.edge(b,d) s1

[] s4

fail

edge(a,Y),del.edge(a,Y) s3[Z/a]>s3

[Y/c]

del.edge(a,c) s3

[] s5

edge(d,Y),del.edge(d,Y)[Z/d]>s4

fail

edge(c,Y),del.edge(c,Y)[Z/c]>s5

fail

Call,Initial state Answer-unifications > Final statesreach(a, X) in s0 {reach(a, a) > s0, reach(a, b) > s1, reach(a, c) > s2,

reach(a, c) > s5, reach(a, a) > s3, reach(a, d) > s4}




Call,Initial state Answer-unifications > Final statesreach(a,X ) in s0 {reach(a,a) > s0, reach(a,b) > s1,

reach(a, c) > s2, reach(a, c) > s5,reach(a,a) > s3, reach(a,d) > s4}

Finds all solutions (answer substitutions and return states)The tabling algorithm terminatesDoes not repeat inferences


Tabling serial-Horn transaction logic

The tabled proof theory is sound and completeCompleteness in the sense that:

it guarantees that all final states will be foundit does not guarantee that all execution paths will be found

Finding all execution paths is what we wanted to avoid: therecan be an infinite number of ways to reach a final state



The number of final states is often finite (finite number ofpossible graphs, planning)Termination:

If φ is a serial-Horn goal andall proofs of P,D --- |= (∃)φ addressed by the proof theorymention only a finite number of database states and afinite number of goals andall recursive predicates in P are marked as tabledThen the tabling proof theory finds one or more proofs ofP,D --- |= (∃)φ and terminates.If there exists a proof of the executional entailmentP,D, ...,D′ |= (∃)φ using the proof theory then there is atabled deduction that finds an execution of (∃)φ that startsat D and ends at D′


Implementation Tabled T R Issues

The transactional semantics of actionsTabling of database states:

Time - operations:Copying of states: once tabled the contents of that statemust stay immutableComparison of states:- for tabled transactions, check whether a goal/state pair isalready tabled- newly created states need to be compared with othertabled states to determine if it is a genuinely new state or not

Space - duplication of information in states


Space optimizations

Changes (logs) << StatesDifferential logs: (InitialState, (InsertLog,DeleteLog))

saves spacereduces the amount of time for copying statestrade-off between the decreasing cost of storing and copying

Various forms of compressionFactoring: facts stored separately and shared usingpointersSharing of logs using tries: high degree of sharingTable skipping: only the states associated with certaintabled subgoals are stored and indexed for queryingDouble-differential logs: when table-skipping is used, onlychanges relative to the previous saved state are kept, notrelative to the initial state

main change logresidual change log


Time optimizations

State comparison:Most state comparisons fail - determine that quickly via anincremental hash functionCompare the rest in linear time using triesSeparate state repository for the calls and states

Data structures for queryingseparate query data structures from logstrade-off of update vs. query time

Copying of statestable skipping and factoring


Evaluation for 6 implementations

Common features:Data compression via factoringDifferential logsState comparison via incremental hash functions and triesfor the main differential logs (linear comparison)


Evaluation for 6 implementations

Implementation 1: no table skipping, logs are ordered listsImplementation 2: logs are ordered lists (optimal copyingand sharing in state tries) and query tries (to speed upquerying)Implementations 3a and 3b: use table skipping (reducethe number of tabled states, no state copying orcomparison for execution of non-tabled actions), usesorted lists to represent logs, 3a uses single differentiallogs, 3b uses double differential logsImplementations 4a and 4b: use table skipping, use triesto represent logs, 4a uses single differential logs, 4b usesdouble differential logs


Performance evaluation - Consuming paths

: −tr_table(reach/2).reach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Times for finding consuming paths in graphs:Graph size 100 250 350

# of Solutions 5050 31375 61425

CPU Mem. CPU Mem. CPU Mem.

1 0.128 806 1.544 4843 3.940 9473

2 0.212 5538 2.292 66413 5.996 173389

3a 0.136 807 1.540 4843 3.924 9473

3b 0.152 806 1.672 4843 4.608 9473

4a 0.224 10325 2.796 128434 7.880 337070

4b 0.204 5538 2.128 66413 5.680 172976

Using table skipping, double differential, tries slightlyslower for small problems (few updates between tabledcalls)


Performance evaluation - Consuming paths

: −tr_table(reach/2).reach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).

Numbers of tabled states and state comparisons for findingconsuming paths in graphs:

Graph size 100 250 350

States Comp. States Comp. States Comp.

1 5051 5050 31376 31375 61426 61425

2 5051 5050 31376 31375 61426 61425

3a 5051 5050 31376 31375 61426 61425

3b 5051 5050 31376 31375 61426 61425

4a 5051 5050 31376 31375 61426 61425

4b 5051 5050 31376 31375 61426 61425


Performance evaluation - 10 Consuming paths in 10graphs

: −tr_table(reach/2).reach(X , Y ) : −reach(X , Z )⊗

edge1(Z , Y )⊗ delete(edge1(Z , Y ))⊗. . .edge10(Z , Y )⊗ delete(edge10(Z , Y )).

reach(X , X).

Time and space for building 10 consuming paths in 10graphs

Graph size 100 200 250


1 6.236 4580 47.642 18219 92.425 28881

2 8.568 371762 M.Err. M.Err. M.Err. M.Err.

3a 4.796 2533 37.182 10066 71.840 15620

3b 4.024 2533 30.073 10065 58.083 15620

4a 1.780 77873 13.536 596734 25.929 1155434

4b 1.292 39744 8.564 301429 16.325 582398

Table skipping, tries for storing logs, double differentialhelps 4b wins for multiple updates between tabled calls


Performance evaluation - Hamiltonian Cycles

hCycle(Start, Start) : − notvertex(X).hCycle(Start, X) : −

edge(X , Y )⊗ vertex(Y )⊗delete(vertex(Y ))⊗ insert(mark(X , Y ))⊗hCycle(Start, Y )⊗ insert(vertex(Y )).

reach(X , X).

Times for finding Hamiltonian cycles in graphs:Graph size 50 150 200

# of Solutions 50 150 200


1 0.252 2412 8.392 51543 23.405 118248

2 0.244 6111 4.144 132082 9.148 303932

3a 0.164 2362 3.956 51091 10.100 118566

3b 0.236 7337 5.644 187927 13.968 442537

4a 0.300 15284 6.852 330211 16.105 755352

4b 0.300 15446 5.696 379042 12.584 885453

Separate query data structures for efficient querying andupdatingDouble differential (3b, 4b) reduces number ofcomparisons


Performance evaluation - Hamiltonian Cycles

hCycle(Start, Start) : − notvertex(X).hCycle(Start, X) : −

edge(X , Y )⊗ vertex(Y )⊗delete(vertex(Y ))⊗ insert(mark(X , Y ))⊗hCycle(Start, Y )⊗ insert(vertex(Y )).

reach(X , X).

Tabled states and state comparisons for findingHamiltonian cycles:

Graph size 50 150

States Comp. States Comp.

1 7403 7500 67203 67500

2 7403 7500 67203 67500

3a 4903 5051 44703 45151

3b 4903 5000 44703 45000

4a 4903 5051 44703 45151

4b 4903 5000 44703 45000


Performance evaluation - 10 graphs HamiltonianCycles

hCycle(Start, Start) : − notvertex1(X) ∧ . . . ∧ notvertex10(X).hCycle(Start, X) : −

edge1(X , Y )⊗ . . .⊗ edge10(X , Y )⊗ vertex1(Y )⊗ . . .⊗ vertex10(Y )⊗delete(vertex1(Y ))⊗ insert(mark1(X , Y ))⊗ . . .⊗hCycle(Start, Y )⊗ insert(vertex1(Y ))⊗ . . .⊗ insert(vertex10(Y )).

reach(X , X).

Times for finding 10 Hamiltonian cycles in 10 graphs:Graph size 50 150

CPU Mem. CPU Mem.

1 4.912 164777 M.Err. M.Err.

2 6.052 424113 M.Err. M.Err.

3a 3.076 9878 86.505 255174

3b 4.340 14854 105.814 391963

4a 1.656 58959 M.Err. M.Err.

4b 1.356 46072 27.4210 1228925

4b scales better: table skipping, double differential


Performance evaluation - Blocks World

stack(0, Block).stack(N, X) : − N > 0⊗ move(Y , X)⊗ stack(N − 1, Y )

⊗on(Y , X).stack(N, X) : − N > 0⊗ on(Y , X)⊗ unstack(Y )

⊗stack(N, X).unstack(X) : − on(Y , X)⊗ unstack(Y )⊗ unstack(X).unstack(X) : − isclear(X) ∧ on(X , table).unstack(X) : − (isclear(X) ∧ on(X , Y ) ∧ Y 6= table)

⊗move(X , table).unstack(X) : − on(Y , X)⊗ unstack(Y )⊗ unstack(X).

Numbers of tabled states and state comparisons forbuilding pyramids in blocks worlds

Blocks 5 6 7States Comp. States Comp. States Comp.

1 1546 4210 13327 42792 130922 480326

2 1546 4210 13327 42792 130922 480326

3a 501 9767 4051 107882 37633 1364911

3b 501 1300 4051 13020 37633 144354

4a 501 9767 4051 107882 37633 1364911

4b 501 1300 4051 13020 37633 144354

Finds one way to build every possible pyramid of Nblocks


Summary

Adapted tabling from ordinary logic programs toTransaction Logic

Complete in the sense that finds all final statesExpensive to implementProposed optimizations for time and space consumption

Interpreter in XSB PrologOptimizations and comparison

Future Work:Better data structure for storing states using B+ trees(efficient copying and sharing)Extend tabling to Concurrent Transaction Logic (interleavedactions)Lift well-founded model semantics from classical LP toTransaction Logic

tr tabling presentation_2010_09

Documents