tr tabling presentation_2010_09
DESCRIPTION
Transaction Logic tabling,Paul Fodor, Michael Kifer,PPDP 2010TRANSCRIPT
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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 Implementation Tabled T R Summary
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 Implementation Tabled T R Summary
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 Implementation Tabled T R Summary
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)
Transaction Logic Implementation Tabled T R Summary
Transaction Logic Example 2
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)
Transaction Logic Implementation Tabled T R Summary
Transaction Logic Example 2
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
Transaction Logic Implementation Tabled T R Summary
Transaction Logic Example 3
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 )).
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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)
Transaction Logic Implementation Tabled T R Summary
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)
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
Tabled Transaction Logic
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)
Transaction Logic Implementation Tabled T R Summary
Tabled Transaction Logic
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)
Transaction Logic Implementation Tabled T R Summary
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:
P,D --- Dn ` (∃) (φ⊗ rest)σP,D --- Dn ` (∃) (b ⊗ rest)
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
P,D --- Dn ` (∃) (φ⊗ rest)σP,D --- Dn ` (∃) (b ⊗ rest)
Transaction Logic Implementation Tabled T R Summary
Consuming Paths Tabling Example
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
Transaction Logic Implementation Tabled T R Summary
Consuming Paths Tabling Example
reach(X , Y ) : −reach(X , Z )⊗ edge(Z , Y )⊗ delete(edge(Z , Y )).reach(X , X).
Step 2:
reach(a,Z),edge(Z,Y),del.edge(Z,Y) s02:
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:
Node Call Index in Solution table (Answer)2 reach(a, X) in s0 0
Transaction Logic Implementation Tabled T R Summary
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,Z),edge(Z,Y),del.edge(Z,Y) s02:
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
Transaction Logic Implementation Tabled T R Summary
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,Z),edge(Z,Y),del.edge(Z,Y) s02:
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 [] 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:
Node Call Index in Solution table (Answer)2 reach(a, X) in s0 2
Transaction Logic Implementation Tabled T R Summary
Consuming Paths Tabling Example
Steps 9-15:
reach(a,Z),edge(Z,Y),del.edge(Z,Y) s02:
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 [] s2
edge(b,Y),del.edge(b,Y) s1
[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
edge(a,Y),del.edge(a,Y) s3
[Z/a]>s3
[Y/c]
del.edge(a,c) s3
[] s5
reach(a,Z),edge(Z,Y),del.edge(Z,Y) s02:
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 [] s2
edge(b,Y),del.edge(b,Y) s1
[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}
Node Call Index in Solution table (Answer)2 reach(a, X) in s0 6
Transaction Logic Implementation Tabled T R Summary
Consuming Paths Tabling Example
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
Tabled Transaction Logic
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′
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
Evaluation for 6 implementations
Common features:Data compression via factoringDifferential logsState comparison via incremental hash functions and triesfor the main differential logs (linear comparison)
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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)
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
CPU Mem. CPU Mem. CPU Mem.
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
Transaction Logic Implementation Tabled T R Summary
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
CPU Mem. CPU Mem. CPU Mem.
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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
Transaction Logic Implementation Tabled T R Summary
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