The Reachability Problem for Petri Nets is Not Elementary (Extended Abstract)

Petri nets, also known as vector addition systems, are a long established and widely used model of concurrent processes. The complexity of their reachability problem is one of the most prominent open questions in the theory of verification. That the reachability problem is decidable was established by Mayr in his seminal STOC 1981 work, and the currently best upper bound is non-primitive recursive cubic-Ackermannian of Leroux and Schmitz from LICS 2015. We show that the reachability problem is not elementary. Until this work, the best lower bound has been exponential space, due to Lipton in 1976.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

09/19/2018

The Reachability Problem for Petri Nets is Not Elementary

Petri nets, also known as vector addition systems, are a long establishe...
04/26/2021

The Reachability Problem for Petri Nets is Not Primitive Recursive

We present a way to lift up the Tower complexity lower bound of the reac...
10/15/2020

Directed Reachability for Infinite-State Systems

Numerous tasks in program analysis and synthesis reduce to deciding reac...
09/14/2021

Coverability, Termination, and Finiteness in Recursive Petri Nets

In the early two-thousands, Recursive Petri nets have been introduced in...
03/20/2019

Reachability in Vector Addition Systems is Primitive-Recursive in Fixed Dimension

The reachability problem in vector addition systems is a central questio...
11/13/2020

Reachability in two-parametric timed automata with one parameter is EXPSPACE-complete

Parametric timed automata (PTA) are an extension of timed automata in wh...
06/10/2020

Checking marking reachability with the state equation in Petri net subclasses

Although decidable, the marking reachability problem for Petri nets is w...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Petri nets [16], also known as vector addition systems [6], [4, cf. Section 5.1], [5], are a long established model of concurrency with extensive applications in modelling and analysis of hardware, software, chemical, biological and business processes.

The central algorithmic problem for Petri nets is reachability: whether from the given initial configuration there exists a sequence of valid execution steps that reaches the given final configuration. It is one of the most well-known problems in theoretical computer science, and has had an interesting history over the past half a century.

The late 1970s and the early 1980s saw the initial burst of activity. After an incomplete proof by Sacerdote and Tenney [18], decidability was established by Mayr [14, 15], whose proof was then simplified by Kosaraju [7]. Building on the further progress made by Lambert in the 1990s [8], substantial progress over the past ten years has been made by Leroux, culminating in the joint work with Schmitz [11] that provides the first upper bound on the complexity, namely membership in fast-growing class  [20].

In contrast, since Lipton’s landmark result over 40 years ago that the reachability problem requires exponential space [13], there has been virtually no progress on lower bounds. Moreover, it became common in the community to conjecture that the problem is ExpSpace-complete.

Main Result and Its Significance.

We show that the reachability problem is not elementary, more precisely that it is hard for the class Tower of all decision problems that are solvable in time or space bounded by a tower of exponentials whose height is an elementary function of the input size [20, Section 2.3]. We see this result as important for several reasons:

  • It shatters the conjecture of ExpSpace-completeness, establishing that the reachability problem is much harder than the coverability (i.e., state reachability) problem; the latter is also ubiquitous but has been known to be ExpSpace-complete since the late 1970s [13, 17].

  • It narrows significantly the gap to the upper bound; in fact, there has been recent progress towards improving the latter to membership in  [21], the smallest class in the fast-growing hierarchy that contains non-primitive recursive problems.

  • It implies that a plethora of problems from formal languages, logic, concurrent systems, process calculi and other areas, that are known to admit reductions from the Petri nets reachability problem, are also not elementary; for a comprehensive listing of such problems, we refer to Schmitz’s recent survey [19].

  • It makes obsolete the non-elementary lower bounds for the reachability problems for two key extensions of Petri nets: branching vector addition systems [9] and pushdown vector addition systems [10].

Key Ideas and Their Presentation.

The proof of our main result involves a few ideas that we regard as worth singling out, and we have strived to organise the paper so that they are presented clearly.

  • At the centre of our construction is an identity of the form , where , , and are certain positive integers bounded exponentially in , and such that and . Thus for any , we have a product of exponential powers of fractions greater than  which reduces to a single fraction, where the numerator and the denominator of each of those fractions are bounded exponentially. The details are in Section 4.

  • We develop the idea of implementing the identity by Petri nets, where a counter is multiplied approximately by the left-hand side and the accuracy of the result is checked using the right-hand side, to obtain gadgets that, assuming they can zero test counters bounded exponentially in  (no zero tests are a priori permitted in Petri nets), guarantee to compute exactly a doubly exponential number  as well as pairs of arbitrarily large numbers whose ratio is that . This is presented in Section 5.

  • We find a way to use together with a pair of sufficiently large numbers whose ratio is that to simulate zero tests of counters bounded by . This allows us to link the gadgets into chains of arbitrary length , so that we bootstrap from not having any zero tests to being able to simulate accurately zero tests of counters that are bounded by the tower of exponentials of height . Some of the pieces for that are developed in Section 3, and everything is assembled in Section 6.

Having recalled that the coverability problem is in ExpSpace, it is not surprising that the underlying theme in all the key ideas here is that executions of the Petri nets we build are not constrained to be correct until the very end. In other words, bad nondeterministic choices may cause inaccuracies in computations, but our construction is such that as soon as that happens, a witness will remain and make reaching the final configuration impossible.

We also remark that the size of the Petri nets produced by our main construction is linear. A straightforward modification would show that there exists a small constant  such that, for any , the reachability problem for vector addition systems whose dimension (i.e., the number of counters) is is -ExpSpace-hard.

2 Counter Programs

Proving the main result of this paper, namely that solving the Petri nets reachability problem requires a tower of exponentials of time and space, involves some intricate programming. For ease of presentation, instead of working directly with Petri nets or vector addition systems, our primary language will be imperative programs that operate on variables (also called counters) that range over the naturals (i.e. the nonnegative integers). Such a program is a sequence of commands, each of which is of one of the following four types:

(increment variable )
(decrement variable )
goto or (jump to either line  or line )
test (continue if variable  is zero),

except that the last command is of the form:

halt if (terminate provided all the listed variables are zero).

We use a shorthand halt when no variable is required to be zero at termination.

To illustrate how the available commands can be used to express further constructs, addition and substraction of a natural constant can be written as consecutive increments and decrements (respectively). As another illustration, conditional jumps if then goto else goto which feature in common definitions of Minsky machines can be written as:

1:goto 2 or 3
2:test goto
3:goto ,

where goto is a shorthand for the deterministic jump goto or .

We emphasise that variables are not permitted to have negative values. In the example we have just seen, that is why the first two commands in line 3 work as a non-zero test.

Two more remarks may be useful. Firstly, our notion of counter programs only serves as a convenient medium for presenting both Petri nets and Minsky machines, and the exact syntax is not important; we were inspired here by Esparza’s presentation [3, Section 7] of Lipton’s lower bound [13]. Secondly, although the halt if commands could be expressed by zero tests followed by just halt, having them as atomic will facilitate clarity. Namely, as already indicated, much of the work in this paper can be seen as developing gadgets and mechanisms for eliminating zero tests of tower-bounded counters; however, zero tests that are at termination both do not need to be eliminated (since they can be enforced by the final configurations in the Petri nets reachability problem) and will play a key role in our construction.

Runs and Computed Relations.

A run of a program from an initial valuation of all its variables is halted if it has successfully executed its halt command (which is necessarily the program’s last); otherwise, the run is either partial or infinite. Observe that, due to a decrement that would cause a counter to become negative, or due to an unsuccesful zero test, or due to an unsuccessful terminal check for zero, a partial run may be maximal because it is blocked from further execution. Moreover, due to nondeterministic jumps, the same program from the same initial valuation may have various runs in each of the three categories: halted runs, maximal partial runs, and infinite runs. We are mostly going to be interested in final variable valuations that are reached by halted runs.

We regard a run as complete if and only if it is halted and its initial valuation assigns zero to every variable. Let be some (not necessarily all) of the variables in the program. We say that the relation computed in by a program is the set of all tuples such that the program has a complete run whose final valuation assigns to every variable  the natural number .

Example 1.

Consider the following program, where is a natural constant:

1:
2:goto 6 or 3
3:
4:
5:goto 2
6:halt if .

It repeats the block of three commands in lines 34 some number of times chosen nondeterministically (possibly zero, possibly infinite) and then halts provided counter  is zero. Replacing the two jumps by more readable syntactic sugar, we may write this code as:

loop
     
     
halt if .

It is easy to see that the relation computed in is the set with the single tuple . ∎

Example 2.

We shall need to reason about properties of variable valuations at certain points in programs. As an example which will be useful later for eliminating zero tests of bounded counters, consider a fixed positive integer  and assume that

(1)

holds in a run at the entry to (i.e., just before executing) the program fragment

loop
     
     
.

The number of times the loop has been iterated by a run that also exits (i.e., completes executing) the program fragment is nondeterministic, so let us denote it by . It is easy to see that property (1) necessarily also holds at the exit, since:

  • the sum is maintained by each iteration of the loop,

  • we have that , and

  • counters and have been decreased by and (respectively).

Continuing the example, if we additionally assume that the exit variable valuation satisfies , then we deduce that:

  • necessarily ,

  • also held at the entry, and

  • and at the entry, and their values at the exit are swapped.

We have thus seen two small arguments, one based on propagating properties of variable valuations forwards through executions of program fragments, and the other backwards. Both kinds will feature in the sequel. ∎

Petri Nets Reachability Problem.

It is well known that Petri nets [16], vector addition systems [6], and vector addition systems with states [4, cf. Section 5.1], [5] are alternative presentations of the same model of concurrent processes, in the sense that between each pair there exist straightforward translations that run in polynomial time and preserve the reachability problem; for further details, see e.g. Schmitz’s recent survey [19, Section 2.1].

Since counter programs with no zero tests can be seen as linear presentations of vector addition systems with states, where the latter are required to start with all vector components zero and to finish with vector components zero as specified by the halt command, the Petri nets reachability problem can be stated as:

Input

A counter program with no zero test commands.

Question

Does it have a complete run?

We remark that restricting further to programs where no counter is required to be zero finally (i.e., where the last command is just halt) turns this problem into the Petri nets coverability problem. In the terminology of vector addition systems with states, the latter problem is concerned with reachability of just a state, with no requirement on the final vector components. Lipton’s ExpSpace lower bound [13] (cf. also Esparza’s presentation [3, Section 7]) holds already for the coverability problem, which is in fact ExpSpace-complete [17].

A Tower-Complete Problem.

We say that a counter  is bounded by in a program if and only if is always at most in every run with all counters initially zero.

To prove that the Petri nets reachability problem is not elementary, we shall provide a linear-time reduction from the following restriction of the halting problem, which is complete for the class Tower of all decision problems that are solvable in time or space bounded by a tower of exponentials whose height is an elementary function of the input size [20, Section 2.3].

Input

A counter program of size , all of whose counters are bounded by

Question

Does it have a complete run?

For confirming that this problem is Tower-complete, we refer to [20, Section 4.1] and [20, Section 4.2] for the robustness of the class with respect to the choices of the fast-growing function hierarchy (here the Ackermann hierarchy) and of the computational model (here counter programs, which are essentially nondeterministic Minsky machines), respectively.

3 Eliminating Zero Tests of Bounded Counters

Programs that contain test commands only for counters  that are bounded by can be seen as being in between Petri nets (the extreme case where , i.e. there are no zero tests) and nondeterministic Minsky machines (the extreme case where , i.e. unrestricted zero tests). In this section, assuming is such that a certain Petri net gadget exists, we define a special operator that transforms any program that zero tests only counters bounded by and composes it with the gadget, to obtain an equivalent program with no zero tests. The rest of the paper will then provide a construction of the required Petri net gadgets for that are towers of exponentials.

Construction.

Suppose that:

  • is a positive integer;

  • is a gadget for ratio , i.e. a program with no zero tests and such that the relation it computes in counters is

  • is a program that zero tests only counters bounded by .

Example 3.

As an example to be used later, when is sufficiently small to write consecutive increments explicitly, it is very easy to code a gadget for ratio :

   set to constant
loop
     
halt. ∎

Under the stated assumptions, we now define a construction of a program without zero tests. The idea is to supplement each zero tested counter  of by a new counter  and to ensure that the invariant is maintained, so that zero tests of can be replaced by loops that times increment and then times decrement . Counter  provided by is employed to initialise each complement counter , whereas counters and are used to ensure that if is zero at the end of the run then all the loops in the simulations of the zero tests iterated times as required. Concretely, the program is constructed as follows:

  1. variables are renamed if necessary so that no variable occurs in both and ;

  2. letting , …, be the counters that are zero tested in , new counters , …, are introduced and the following code is inserted at the beginning of :

    loop
         
         

    (we shall show that complete runs necessarily iterate this loop times, i.e. until counter  becomes zero);

  3. every command in is replaced by two commands

    ;
  4. every command in is replaced by two commands

    ;
  5. every test command in is replaced by the following code:

    loop
         
         
    loop
         
         

    (we shall show that complete runs necessarily iterate each of the two loops times, i.e. they check that equals through checking that equals by transferring from to and then back);

  6. letting (respectively, ) be the counters that are required to be zero at termination of (respectively, ), the code of consists of the code of concatenated with the code of modified as stated, both without their halt commands, and ending with the command

    halt if .

We remark that simulating zero tests of counters bounded by some using transfers from and to their complements is a well-known technique that can be found already in Lipton [13]; the novelty here is the cumulative verification of such simulations, through decreasing appropriately the two counters and whose ratio is , and checking that is zero finally.

Correctness.

The next proposition states that the construction of is correct in the sense that its computed relations in counters of are the same as those of . (We shall treat any renamings of variables in step (i) of the construction as implicit.) In one direction, the proof proceeds by observing that can simulate faithfully any complete run of . In the other direction we argue that although some of the loops introduced in step (v) may iterate fewer than times and hence erroneously validate a zero test, the ways in which counters and are set up by and used in the construction ensure that no such run can continue to a complete one. Informally, as soon as a loop in a simulation of a zero test iterates fewer than times, the equality turns into the strict inequality which remains for the rest of the run, preventing counter  from reaching zero.

Proposition 1.

For every valuation of counters of , it occurs after a complete run of if and only if it occurs after a complete run of .

Proof.

The ‘if’ direction is straightforward: from a complete run of with a total of zero tests, obtain a complete run of with the same final valuation of counters of by

  • running to termination with , , and all of equal to , where the latter variables will remain untouched for the rest of the run and hence satisfy the requirement to be zero finally (cf. step (vi) of the construction),

  • iterating the loop in step (ii) times to initialise each complement counter to , which also subtracts and from and (respectively), decreases to , and

  • in place of every zero test in , iterating both loops in step (v) times, which subtracts and from and (respectively), eventually decreasing them both to .

For the ‘only if’ direction, consider a complete run of . Extracting from it a complete run of with the same final valuation of counters of is easy once we show that, for each simulation of a test command by the code in step (v) of the construction, the values of at the start and at the finish of the code are .

Firstly, by step (vi) and the fact that counters are not used after its termination, we have that the values of , and that have been provided by satisfy and . After the code in step (ii) we therefore have that for all . Recalling the reasoning in Example 2 in Section 2 and arguing forwards through the run, we infer that

is an invariant that is maintained by the rest of the run.

Now, due to step (vi) again, is zero finally, and so the inequality is finally an equality. Therefore, is zero finally as well. Recalling again the reasoning in Example 2 in Section 2 and arguing backwards through the run, we conclude that in fact has been maintained and that, for each simulation of a test command, each of the two loops has been iterated exactly times, and hence the values of at its start and at its finish have been . Also, the loop introduced in step (ii) has been iterated times, and is zero finally. ∎

4 Small Products of Exponential Powers of Fractions

To construct gadgets for ratios that are towers of exponentials (cf. Section 6) and thereby obtain our main result, we shall show how to produce repeatedly from a gadget for ratio  a gadget for ratio exponential in  (cf. Section 5). The latter is the technical core of the paper, and is based on an identity involving exponential powers of fractions that we now present together with establishing some of its remarkable properties.

Key Definitions and Their Properties.

For any natural , let us define numbers , and , and for any , numbers , , , as follows:

(2)

Observe that all the numbers defined are bounded by an exponential in . Nevertheless, we prove that all of the fractions and are greater than , and that a certain product of the former fractions raised to powers exponential in equals the latter fraction:

Proposition 2.

For all natural , we have:

Proof.

The claimed equality is presentable as:

(3)

For convenience, decompose the fractions into simpler ones:

In particular, . Using the decomposition we easily prove the claimed equality (3), as it is the multiplication of equalities, for , of the following form:

Now we concentrate on the claimed inequalities. The inequalities and are immediate, as for . To show the remaining inequalities we need to prove:

(4)

Fix . As for , by induction on one shows ; therefore the left-hand side is dominated by:

It is thus sufficient to prove

(5)

For better readability we put and with this shorthands, the inequality (5) is rephrased as

(6)

By inspecting the expansion of the left-hand side we observe that the left-hand side is bounded by the sum of the first elements of a geometric progression, which, in turn, is bounded by the sum of the whole infinite one:

(7)

Thus, recalling the right-hand side of the inequality (6), it is sufficient to prove:

One readily verifies that the inequality holds as long as , which holds due to . The inequalities (4) are thus proved, and hence so is Proposition 2. ∎

The products of all the numerator powers and all the denominator powers in the identity of Proposition 2, which we now name, will be important in the sequel:

(8)

A property of the parameterised quantity  which is going to be central for exponentiating the ratios of gadgets (cf. Section 5) is that it is exponentially larger than all the numbers defined in (2), as witnessed by the following bounds:

Lemma 3.

For all natural  and , we have:

Proof.

We first show the inequalities . Proposition 2 gives us that , and that for all . It is easy to check that , and that , and for all . We are therefore left with needing to show . Observe that .

To obtain the explicit bounds, we estimate that

, and so . Finally, . ∎

We remark that the properties we have established in Proposition 2 and Lemma 3 are more important than the exact definition of the numbers and , and that our choice of the latter is not the only workable one.

An Exercise.

To prepare for the developments and arguments in the next section that are based on the definitions and observations in this one, we suggest an exercise that links the identity in the statement of Proposition 2 with counter programs.

Recall that complete runs of programs have initial valuations that assign zero to all variables. To initialise a variable to another value in a program , let us write for the program

that assigns the natural  to the variable  and then proceeds like .

Consider program  defined in Algorithm I, where the for and exactly loops, as well as the computations of the quantities enclosed in boxes, are macros that have the expected effects and that will be defined properly in Section 5. For any natural , the program does the following:

  • initialises and to some positive integer  chosen nondeterministically, which will be kept unchanged in counter  until the final loop;

  • in each iteration of the outer two main loops, uses counter  to attempt to multiply counter  by the fraction ;

  • by the final loop and the terminal check that counter is zero, halts provided the value of is at least (in which case it will be exactly ).

1:
2:loop
3:     
4:for  do
5:     loop exactly times
6:         loop
7:                        
8:         loop
9:                             
10:loop
11:     
12:halt if
Algorithm I Counter program .

The first and easier part of the exercise is to show that, for any positive  divisible by , there exists a complete run of that initialises and to , then multiplies exactly by all the powers of fractions on the left-hand side of the identity of Proposition 2, and finally checks that equals times the fraction on the right-hand side.

The second part is to show the converse, i.e. that any complete run of the program  is of that form, in particular that the value to which counters and are set by the initial loop is necessarily divisible by . As a hint, we remark that this is the case because as soon as a multiplication of by a fraction does not complete accurately (i.e. either the first inner loop does not decrease to exactly zero, or the second inner loop does not decrease to exactly zero), it will not be possible to repair that error in the rest of the run, in the sense that the value of at the beginning of the final loop will necessarily be strictly smaller than and thus it will be impossible to complete the run. We also remark that this vitally depends on the fact that all the fractions are strictly greater than .

For readers interested in flat vector addition systems with states (for example, it is well known that two-dimensional VASS are flattable [12]), we additionally remark that, by inlining the two outer main loops in the program , we obtain a three-counter unary linear path scheme that has complete runs but of length at least exponential in the scheme’s size. It is then not difficult, employing some of the other ideas from this paper, to extend the construction to a reduction from the subset-sum problem and conclude that the reachability problem for unary flat VASS is NP-hard already for a small fixed dimension. Those observations resolve some of the main open questions left by the recent works of Blondin et al. [1] and Englert et al. [2].

5 Lifting Ratio Gadgets Exponentially

Building on the previous section which is the algebraic centre of the paper, we now develop the technical core by providing a way to exponentiate ratios of gadgets. More precisely, we liberalise the notion of gadget for a ratio from Section 3 by allowing them to zero test counters whose values do not exceed some bound. We then define and prove correct programs that, for any natural , zero test only counters bounded by and are gadgets for ratio (cf. (2) and (8) for the definitions of those quantities). Composing these programs using the operator from Section 3 with gadgets for ratio at least will hence produce gadgets for ratio , both without zero tests (cf. Proposition 1). Recalling Lemma 3, the exponentiation will be achieved since is indeed exponentially larger than .

As auxiliary building blocks for the main program, we are going to make use of programs that compute several exponentially bounded parameterised quantities. They may involve zero tests, but all their counters are also exponentially bounded.

Proposition 4.

There exist counter programs , …, such that:

  • they compute the functions , , , and , placing their outputs in counter , and preserving their inputs in counters and :

    for any natural  and computes in counters
    ;
  • the programs have all counters bounded by ;

  • the halt command of each program  does not require any counters to be zero.

Proof.

By routine programming of Minsky machines whose counters are bounded by and may be zero tested. ∎

The definition of our main program  in Algorithm II is presented at a high level for readability. It features a macro loop introduced earlier (cf. Section 2), and several new macros that we shall expand shortly. The latter include the boxes that contain values to be computed using the programs from Proposition 4.

We are going to be interested in complete runs of the programs , i.e. of program  with counter  initialised to number . In such a run, first counter  is initialised to , and counters , , and are set to some positive integer chosen nondeterministically. In the for loop, the program attempts to divide  by , multiply and by , and set  to , in which case we also have . (Cf. (8) for the definitions of quantities and .)

In order to confirm that indeed and (which is difficult since and are unbounded, and is exponentially larger than the bound on zero-testable counters), the last loop is used together with the requirement that is zero finally to verify that all the attempted multiplications and divisions have been accurate. It checks that is at least times , where the latter fraction equals by Proposition 2.

1:
2:loop
3:     
4:for  do
5:     loop exactly times
6:         loop
7:              
8:              loop at most times
9:                                          
10:         loop
11:                        
12:         loop
13:                        
14:         loop
15:              
16:              loop at most times
17:                                               
18:loop
19:     
20:halt if
Algorithm II Counter program .

We now proceed to expand the new macros that feature in Algorithm II. That is going to introduce a fixed number of further counters that may be zero tested but are bounded by . Whenever we use a program  from Proposition 4, we assume that the names of its counters do not clash with the rest of , except for counters and .

loop down body:

This macro is used intensively in other ones, for different counters , possibly with the empty body. Note that counter  is reset to zero by this loop.

loop
     body
     
test
for do body:

The for loop is easy to write by means of the down loop.

loop down
         save  in and
loop down
         restore  from 
loop down
     body
     
body
loop exactly times body:

We use the program  from Proposition 4.

loop down    reset every counter  of  except and 
   number  is computed in counter 
loop down
     body
:

To add to counter  one of the quantities , , or , we use the program  from Proposition 4 for (respectively).

loop down    reset every counter  of  except and 
   number  is computed in counter 
loop down
     
:

Subtracting is analogous, with the increment of replaced by decrement.

loop at most times body:

To express this construct, we employ the auxiliary counter to which the value of is transferred and then transferred back. Provided is zero at the start, the body is indeed performed at most times.

loop
     
loop
     
     body

At last, we turn to arguing the correctness. While reading the next lemma and its proof, we suggest comparing and contrasting with the exercise in Section 4, since program  (cf. Algorithm I) was obtained from program  essentially by removing counters , , and their primed counterparts.

Lemma 5.

For any natural , the program  computes in counters the relation

and zero tests only counters bounded by .

Proof.

The bound on the zero-tested counters is clear from the definition of  and Lemma 3.

In the rest of the proof, we shall be considering runs of whose initial valuation assigns zero to every variable, and which are either halted or blocked at the halt command because is not zero. In particular, any such run will have completed the outer two main loops (the for and exactly loops in Algorithm II). Hence, we can introduce the following notations for counter values during the iteration of the for loop () and the iteration of the exactly loop (), where is any of the counters , , , , , :

:

the final value of after lines 611;

:

the final value of after lines 1217.

It will also be convenient to write for the value of during the iteration of the for loop and at the start of the exactly loop. Observe that, for , we have . We emphasise that these notations are relative to the run under consideration, which for readability is not written explicitly.

The rest of the proof works for any natural  and consists of two parts, that establish the two inclusions between the relation computed by in counters and the relation in the statement of the lemma.

The first part, where we assume , and , and argue that the program  has a complete run whose final values of counters are exactly , is the easier part.

Claim 1.

For any divisible by , the program has a complete run which satisfies the equalities in Table 1.

Table 1: Equalities for counter values in complete runs of programs , for all and .
Proof of claim.

Such a run can be built by iterating each nondeterministic loop the maximum number of times. Namely, during iteration of the two outer main loops:

  • the loop at line 6 is iterated times and in each pass the loop at line 8 is iterated times;

  • the loop at line 10 is iterated times;

  • the loop at line 12 is iterated times;

  • the loop at line 14 is iterated times and in each pass the loop at line 16 is iterated times.

The divisibility of by ensures that all division in the statement of the claim yield integers.

To see that the run thus obtained can be completed, observe that from the equalities in Table 1 it follows that

In particular, at the start of final loop (at line 18), counter equals counter and hence has value (cf. Proposition 2), and counter has value . Iterating the final loop times therefore reduces (and ) to zero as required. ∎

To obtain as the final values of counters , we apply Claim 1 with .

We now turn to the remaining second part of the proof of the lemma, where we consider any complete run and need to show that the final values of counters satisfy , and .

Claim 2.

For all and , we have:

  • ;

  • if and only if ;

  • .

Proof of claim.

Straightforward calculation based on (cf. Proposition 2). ∎

Let denote the value of counters , , and at the start of the for loop.

Claim 3.

The equalities in Table 1 for the values of counters and are satisfied.

Proof of claim.

From Claim 2, we first deduce that at the start of the final loop (at line 18), counter has value at most . Since counter  has value at that point and the run is complete, it must actually be the case that the value of here equals . By Claim 2 again, we infer that for all and , we indeed have:

Claim 4.

We have that is divisible by and that the equalities in Table 1 for the values of counters , , and are satisfied.

Proof of claim.

That is divisible by will follow once we establish the equalities for the values of and , since they involve dividing by .

For the rest of the claim, we argue inductively, where the hypothesis is that the equalities for the values of , , and are satisfied for all indices and such that either , or and . Consequently, recalling Claim 3, we have that

(9)

Consider the iteration of the outer two main loops. We infer from Claim 3 that the commands in line 9 must have been performed times. Hence, as the values of counters and remain unchanged until line 10, using (9) we deduce that the commands in line 7 must have been performed times, and we have:

Also by Claim 3, the commands in line 17 must have been performed times. From what we have just shown, that number equals , and so we conclude that indeed: