1 Introduction
Dynamic Logic of Propositional Assignments, abbreviated , has recently been studied in [HerzigLMTIjcai11, BalbianiHerzigTroquardLics13] as an interesting alternative to Propositional Dynamic Logic () [Harel84]. In a series of papers, it was shown that is a useful tool to analyse various kinds of dynamic systems, such as normative systems [HerzigLMTIjcai11], fusion operators [HerzigEtalFoiks14], update and revision operators [HerzigEtalKr14], or the evolution of argumentation frameworks [DoutreEtalKr14]. While, in , one can write formulas of the form , meaning “after every possible execution of the abstract atomic program , formula is true”, in , one can write formulas of the form , meaning “after assigning the truth value of to true, formula is true”. The atomic program is an assignment that maps the propositional variable to true. In fact, the atomic programs of are sets of such assignments, that are viewed as partial functions from the set of propositional variables to . From these atomic programs, complex programs are built just as in . For example, one can write in the formula , which means “if is false then is true after its truth value be assigned to true”.
While the models of are transition systems, the models of are much smaller: valuations of classical propositional logic, i.e., nothing but sets of propositional variables. Due to that, enjoys some interesting metalogical properties that lacks, such as eliminability of the Kleene star, compactness and interpolation.
The complexity of the satisfiability problem in is the same as in : it is in EXPTIME for the full language and PSPACE complete for the starfree fragment. EXPTIME membership of the full language is proved by a polynomial embedding of into , and PSPACE membership of the starfree fragment of is proved via NPSPACE membership of its model checking problem, exploiting the fact that NPSPACE = PSPACE. However, these reductions lead to suboptimal theorem proving methods. Our aim in this paper is to define tableaux theorem proving procedures for that are both direct and more efficient.
The paper is organized as follows. We start by recalling (Section 2). Then, we provide a tableaux method for its starfree fragment (Section 3) and show an algorithm implementing it that works in polynomial space (Section 4). After that, we extend the tableaux method to the full language of (Section 5) and then show an algorithm implementing it and that works in time exponential (Section 6). Section 7 discusses some issues and concludes the paper.^{1}^{1}1Proofs of the important theorems are in the appendix.
2 Dynamic Logic of Propositional Assignments
2.1 Syntax
The vocabulary of contains a countable set of propositional variables. From this set, we build the set of propositional assignments, which are the atomic programs of the language. Each propositional assignment is a nonempty finite partial function from to .^{2}^{2}2We note that the original language in [BalbianiHerzigTroquardLics13] is slightly more restrictive: only assigns a single propositional variable. But, as shown in this paper, it does not change the known decidability and complexity results.
The language of is the the set of formulas defined by the BNF:
where ranges over and ranges over .
To ease notation and readability of programs, we write for and for . Moreover, we sometimes “forget” some parentheses and curly braces when writing propositional assignments. As a result, the formula is rather noted . In some places, we use the expression to talk economically about and at the same time.
The complex programs of are constructed as in Dynamic Propositional Logic () [HarelKozenTiuryn00]. As well as in , formulas of the form are read “after every possible execution of , is true”.
We also use the common abbreviations for the connectives , , , and . The formula abbreviates . The starfree fragment of is the fragment without the Kleene star operator and is noted .
The length of a formula or a program, given by the function , is the number of atoms and connectives in the formula or the program. Table 1 defines it formally.
The closure of is the set defined in Table 2. This is almost the same as the FisherLadner closure [Fischer_Ladner1979JCSS], which is used to show decidability and complexity results for . But since the atomic programs of are sets of assignments, there is a difference here in the definition of . It takes into account the assignments by adding the domain of the atomic program .
The extended closure of is the set containing and the negations of its formulas, i.e., . To ease notation, we sometimes use to denote the set of propositional variables occurring in , i.e. .
The lemma below can be proved with an easy induction on the length of formulas and programs.
Lemma 1


.

.
Intuitively, the set of execution traces of is the set of sequences of assignments that corresponds to all possible executions of program . The set corresponds to all possible executions of all programs in . These are defined by a mutual recursion, as displayed in Table 3. We use the symbol ‘’ to denote the empty sequence.
The length of execution traces, also given by the function , is just the number of atomic programs in it. That is: , and .
The lemma below can also be proved with an easy induction on the length of programs and formulas:
Lemma 2

If does not contain the Kleene star then , for all .

If then , for all .
Note, however, that each is infinite.
2.2 Semantics
A model is a set of propositional variables. When then is true, and when then is false.
The interpretation of an assignment is in terms of a model update. The update of a model by an assignment is the new model such that:
where we suppose that when is not in the domain of then equals . In particular, for the assignment we have . Given a sequence of assignments , for the sake of readability, we sometimes write instead of .
Formulas are interpreted as sets of models , while programs are interpreted by means of a (unique) relation between valuations . Just as in , the formal definition is by a mutual recursion. It is given in Table 4.
As usual, we also write to mean that . Moreover, given a formula , we say that is valid (noted ) if and only if , and we say that is satisfiable if and only if .
For example, the formulas , , , and are all valid.
2.3 Existing Proof Methods
We now recall the existing methods for both model checking and satisfiability checking in . They either use a nonelementary reduction to propositional logic or a quadratic embedding into . We then provide a linear reduction of satisfiability checking to model checking. This justifies our focus on a tableaux method for model checking in the rest of the paper. But first, let us recall some valid principles in .
Proposition 1 ([HerzigLMTIjcai11])
The following principles are valid in :








From infer
It follows from Proposition 1.1–1.6 plus the rule of substitution of valid equivalences that the starfree fragment of is reducible to propositional logic. This however fails to provide an efficient theorem proving method because the reduced formula might be exponentially longer than the original formula. In [BalbianiHerzigTroquardLics13], it is also shown that the Kleene star can be eliminated in , i.e., there is an algorithm that translates every formula in to an equivalent formula in . Such translation, however, also leads to much longer formulas. In fact, this is a nonelementary reduction because it starts from the innermost Kleene star operator.
Satisfiability checking in is shown to be in EXPTIME in [BalbianiHerzigTroquardLics13]. The proof is given via a translation to satisfiability checking in . For every formula , the translation returns a formula which is obtained by just replacing each assignment by an abstract program . To guarantee that the abstract programs behave the same way as the original assignment, the following set of formulas is also used:
Proposition 2 ([BalbianiHerzigTroquardLics13])
Let be the program . For every formula , is satisfiable if and only if
is satisfiable.
Note that, even though this reduction is polynomial, a quadratically longer formula is produced. Precisely, the size of is bounded by . Moreover, if we consider the starfree fragment of , this transformation is suboptimal, because of the Kleene star operator in .^{3}^{3}3For the starfree fragment, a transformation without the Kleene star operator is also possible. In this case, the program must be iterated up to , but this leads to an even longer formula.
If follows from the next result that satisfiability checking in can be linearly reduced to model checking in .
Proposition 3
Let a formula be given. Let . and let be the program . Formula is satisfiable if and only if for any model .
Proof
It suffices to see that the interpretation of the program relates all possible valuations in the vocabulary of , while leaving the other variables unchanged. ∎
The operation works as a master modality and thus works as its dual. Because it does not contain the Kleene star operator, the length of is bounded by . Also note that, in particular, is satisfiable if and only if satisfies . This means that the input for the model checking problem is also linear on the length of . Therefore, in order to perform satisfiability checking in , one could take advantage of an efficient algorithm for model checking in . This motivates the tableaux methods presented in the next section.
Before concluding this section, let us recall that, in , model checking has the same computational complexity as satisfiability checking. This follows from Proposition 3 above and Proposition 4 below.
Proposition 4 ([BalbianiHerzigTroquardLics13])
For every valuation and formula , if and only if the formula
is satisfiable.
3 A Tableaux Method for StarFree
In this section, we define a model checking procedure for the starfree fragment of using analytic tableaux. We start with some useful definitions.
A labeled formula is a pair , where is a (possibly empty) sequence of propositional assignments and . A branch is a set of labelled formulas.
Definition 1 (Tableau)
Let and . The initial branch for is the the set . A tableau for is a set of branches that satisfies one of the following two conditions:

, which is called the initial tableau for .

, where is a tableau for containing the branch and is a set of branches generated by one of the following tableau rules below:^{4}^{4}4Some of these rules are also presented in the more traditional numeratordenominator form in Table 10 of the Appendix.
 (R)

implies and .
 (R)

implies and .
 (R)

implies , and .
 (R)

implies and
.  (R)

implies and
.  (R)

implies , and .
 (R)

implies and .
 (R)

implies and .
 (R)

implies and .
 (R)

implies and .
 (R)

implies , and .
 (RP1)

for some and implies and
.  (RP2)

for some and implies and
.
The initial tableau corresponds to the input of the problem in the tableau. Rules R, R and R are the standard tableaux rules for Boolean connectives. RP1 and RP2 (propagation rules) propagate literals whose the truth value is not changed by assignments: if the model updated by satisfies and does not change the truth value of then the model updated by also satisfies . The other rules just reflect the semantic definition of the corresponding programs. For instance, for the rule R, if the model updated by the sequence of assignments satisfies then the model updated by the sequence satisfies . Note that they also correspond to the validities 1–6 in Proposition 1.
A branch is blatantly inconsistent if and only if contains both and , for some and . A branch is closed if and only if it is blatantly inconsistent. A tableau is closed if and only if all its branches are closed. A tableau is open if and only if it is not closed.
The idea is that, if there is a closed tableau for the input then . On the other hand, if there is no closed tableau for then .
Example 1
Table 5 shows how the method can be used to prove that the model does not satisfy the formula . In the table, lines 1–3 consist of the initial tableau for the input . Rule applications are indicated between parentheses on the left of each line. Line 4 is generated by the application of R to line 3. This generates two different branches. The rule applications continue until both branches are closed.
Example 2
Table 6 shows how the method can be used to prove that the model satisfy the formula . Note that RP2 is not applicable to the labelled formulas in lines 1 and 5 because . Thus, the branch on the right remains open, which means that .
In the sequel, we show the soundness of the method. The idea is to show that, if , then successive rule applications can never close the tableau. But first, a useful definition and a lemma are presented.
Definition 2 (Consistent Branch)
A branch is consistent if and only if for every .
Lemma 3 (Consistency Preservation)
For each tableau rule , if branch is consistent, then the set of branches generated by the application of to contains a consistent branch.
Theorem 3.1 (Soundness)
If then there is no closed tableau for .
We now address the completeness of the method. The idea is to show that, if the tableau remains open after all possible applications of the tableau rules, then . But first, some useful definitions are presented.
Definition 3 (Witness)
A witness to rule in branch is a labelled formula allowing the application of .
For example, is a witness to R, and is a witness to R. Moreover, the formula is a witness to RP1 in if there is a formula and .
Definition 4 (Saturated Tableau)
The label in the branch is saturated under the tableau rule if and only if for each witness to in , contains some generated by the application of to . The branch is saturated under the tableau rule if and only if all its labels are saturated. A branch is saturated if and only if it is saturated under all tableau rules. A tableau is saturated if and only if all its branches are saturated.
Theorem 3.2 (Completeness)
If there is no closed tableau for then .
4 An Optimal Procedure for StarFree
1:  input: 

2:  output: 
3:  begin 
4:  mcTableau 
5:  end 
6:  function mcTableau 
7:  begin 
8:  if contains an applicable witness to a rule then 
9:  the branch generated by the application of to using as witness 
10:  mark as ‘nonapplicable’ 
11:  return mcTableau 
12:  else if contains an applicable witness to a rule then 
13:  the set of branches generated by the application of to using as witness 
14:  mark as ‘nonapplicable’ 
15:  for each do 
16:  if mcTableau = true then 
17:  return true 
18:  end if 
19:  end for 
20:  return false 
21:  end if 
22:  while
there is an atomic program such that contains an applicable witness to rule , where or do 
23:  the branch generated by the application of to using as witness 
24:  mark as ‘nonapplicable’ 
25:  while
contains an applicable witness to rule , where or do 
26:  the branch generated by the application of to using as witness 
27:  mark as ‘nonapplicable’ 
28:  
29:  end while 
30:  while contains an applicable witness to rule 
31:  the branch generated by the application of to using as witness 
32:  mark as ‘nonapplicable’ 
33:  
34:  end while 
35:  if mcTableau = false then 
36:  return false 
37:  end if 
38:  end while 
39:  return true 
40:  end 
In this section we define an algorithm to check whether , for . Such an algorithm is displayed in Table 7. It implements the tableaux method using the recursive function mcTableau. It takes as argument a tableau branch and returns whether is consistent. When called with the initial tableau for it returns whether . The execution of mcTableau explores in a depthfirst manner a tree whose nodes are tableau branches and each child is generated by the application of a tableau rule to its parent.
The rules are applied in a specific order and, after the application of a rule, the witness is marked ‘nonapplicable’, thus avoiding an infinite loop. Lines 8–21 perform what is called ‘local saturation’. That is, only rules that do not create labelled formulas with different labels than that of the witness are applied. Its first part (lines 8–11) applies rules that do not create more than one branch in the tableau. Its second part (lines 12–21) apples rules that create more than one branch in the tableau. At the end of the local saturation, only witnesses to rules R, R remain. Note that no new label is created in the local saturation part, which means that there can be no witnesses to rules RP1 and RP2. Then, in lines 22–38 the algorithm performs what is called ‘successor creation’. First (line 22), it tests whether there is a successor to be created, i.e., if there is a witness to R or R. It creates the successor (line 23) and then marks the witness as ‘nonapplicable’ (line 24). After that (lines 25–34), it propagates the suitable formulas to the successor, as follows: assume that the witness is . Then, for every labelled formula and there must be a labelled formula in the successor. This is done in lines 25–29. And also, every labelled formula (resp. ) must be propagated, i.e., there must be a labelled formula (resp. ) in the successor . This is done in lines 30–34. The last part (lines 35–37) makes a recursive call to mcTableau with the . The current branch is considered satisfiable if all recursive calls return true.
This algorithm has two important features. First, its successor creation part guarantees that each time mcTableau is called with branch as argument, all the labelled formulas in have the same label. Second, the first feature implies that the list of successors created during successive recursive calls of mcTableau corresponds to one execution trace from input formula . These are the key arguments used in the proof of complexity result below.
Theorem 4.1 (Termination)
The algorithm in Table 7 halts for every input .
Theorem 4.2 (Complexity)
The amount of memory used by the algorithm in Table 7 is a polynomial function of the length of the input .
Therefore, the algorithm in Table 7 works in space polynomial in the length of the input. This is an optimal algorithm, given that the satisfiability problem in starfree is PSPACEcomplete [HerzigLMTIjcai11].
5 A Tableaux Method for Full
In this section, we define an extension of the tableaux method that also takes into account the Kleene star operator.
Definition 5 (Tableau)
The two rules above reflect the fix point property of Proposition 1.7. For instance, if the model then and also .
Definition 6 (Fulfillment)
An eventuality ) is fulfilled in a tableau branch if and only if there is a (possibly empty) execution trace such that .
Definition 7 (Closed Branch)
A branch is closed if and only if (1) is blatantly inconsistent or (2) is saturated and contains an unfulfilled eventuality.
Example 3
Table 8 shows how the method can be used to prove that model does not satisfy the formula . The leftmost branch is closed because it is blatantly inconsistent. In the branch of the middle, the same pattern will be repeated indefinitely. Thus, it is an infinite brunch, but it is saturated. Since the eventuality in line 3 is not fulfilled, it is also closed. The rightmost branch is analogous to the one in the middle.
If the input formula contains a subformula of the form , the method invariably creates tableaux with infinite branches that repeat the same pattern over and over again, as in Example 3. The repetition can be detected and it is possible to provide a terminating algorithm. This is presented in Section 6. Here, we show the correctness of the method presented so far.
Lemma 4 (Consistency Preservation)
For each tableau rule , if branch is consistent, then the set of branches generated by the application of to contains a consistent branch.
Theorem 5.1 (Soundness)
If then there is no closed tableau for .
Theorem 5.2 (Completeness)
If there is no closed tableau for then .
6 An EXPTIME Procedure for Full
In this section, we define a procedure to model check formulas in . As before, we define an algorithm. Here, it must detect the aforementioned repetitions of the applications of R in the tableau. This is done by performing equality tests. A label is said to be equal to a label if and only if the set of formulas labelled by and are the same. More formally we have:
Definition 8 (Equality)
Let and be two labels in the tableau . Label is equal to label (noted ) if and only if there are two branches such that .
An equality test between labels can prevent the tableau to enter in an infinite loop. Then one can try to provide an algorithm that is similar to the one in Section 4, by first adding rules R and R in their suitable places and the equality test just before the exploration of a new successor. Such an algorithm works, but is not optimal. For instance, the application of the method to the formula creates different successors from a single tableau branch. Then such a method may explore a tree whose the number of nodes is bounded by . However, satisfiability in is proven to be in EXPTIME.
A different technique than that in Section 4 must be employed in order to obtain a more efficient method for full . Such a technique is implemented in the algorithm of Table 9. It is somewhat similar to the algorithm in Section 4, but there are some important differences. The most important ones are the addition of the equality test in lines 17–19 and the fact that this algorithm now maintains the entire tableau in memory. It does not uses a recursive function anymore, for it now uses the tableau as the search tree. Once the initial tableau for is created in line 4, it enters a loop that finishes when is closed or saturated (recall that a branch is also considered to be closed if it is saturated and contains an unfulfilled eventuality). As before, there is a ‘local saturation’ part (lines 9–16) and a ‘successor creation’ part (lines 20–33). In lines 36–40, the algorithm tests whether is still open to return the right answer.
1:  input: 

2:  output: 
3:  begin 
4:  
5:  while is open and unsaturated do 
6:  pick an open and unsaturated branch 
7:  while is open and unsaturated do 
8:  pick an open unsaturated label of 
9:  if is an applicable witness to a rule then 
10:  the branch generated by the application of to using as witness 
11:  mark as ‘nonapplicable’ 
12:  
13:  else if is an applicable witness to a rule then 
14:  the branches generated by the application of to using as witness 
15:  mark as ‘nonapplicable’ 
16:  
17:  else if there is a label in such that then 
18:  mark all formulas in labelled by as ‘nonapplicable’ 
19:  if is closed then close branch end if 
20:  else if
there is an atomic program such that contains an applicable witness to rule , where or do 
21:  the branch generated by the application of to using as witness 
22:  mark as ‘nonapplicable’ 
23:  while
contains an applicable witness to rule , where or do 
24:  the branch generated by the application of to using as witness 
25:  mark as ‘nonapplicable’ 
26:  
27:  end while 
28:  while contains an applicable witness to rule 
29:  the branch generated by the application of to using as witness 
30:  mark as ‘nonapplicable’ 
31:  
32:  end while 
33:  
34:  end if 
35:  end while 
36:  end while 
37:  if is open then 
38:  return true 
39:  else 
40:  return false 
41:  end if 
42:  end 
Theorem 6.1 (Termination)
The algorithm in Table 9 halts for every input .
Theorem 6.2 (Complexity)
The amount of time used by the algorithm in Table 9 is an exponential function of the length of the input .
Thus, the algorithm in Table 9 works in time exponential on . This is as expected, given that the model checking problem in full
Comments
There are no comments yet.