# Tackling the Partner Units Configuration Problem.

**ABSTRACT** The Partner Units Problem is a specific type of configuration problem with important applications in the area of surveillance and security. In this work we show that a special case of the problem, that is of great interest to our partners in industry, can directly be tackled via a structural problem decompostion method. Combining these theoretical insights with general purpose AI techniques such as constraint satisfaction and SAT solving proves to be particularly effective in practice.

**0**Bookmarks

**·**

**45**Views

- [Show abstract] [Hide abstract]

**ABSTRACT:**Factorised databases are relational databases that use compact factorised representations at the physical layer to reduce data redundancy and boost query performance. This paper introduces FDB, an in-memory query engine for select-project-join queries on factorised databases. Key components of FDB are novel algorithms for query optimisation and evaluation that exploit the succinctness brought by data factorisation. Experiments show that for data sets with many-to-many relationships FDB can outperform relational engines by orders of magnitude.03/2012; - [Show abstract] [Hide abstract]

**ABSTRACT:**FDB is an in-memory query engine for factorised databases, which are relational databases that use compact factorised representations at the physical layer to reduce data redundancy and boost query performance. We demonstrate FDB using real data sets from IMDB, DBLP, and the NELL repository of facts learned from Web pages. The users can inspect factorisations as well as plans used by FDB to compute factorised results of select-project-join queries on factorised databases.Proceedings of the VLDB Endowment. 08/2012; 5(12):1950-1953.

Page 1

Computing Science

TACKLING THE PARTNER UNITS CONFIGURATION PROBLEM

Markus Aschinger, Conrad Drescher, Gerhard Friedrich, Georg Gottlob,

Peter Jeavons, Anna Ryabokon, Evgenij Thorstensen

CS-RR-10-28

?

Oxford University Computing Laboratory

Wolfson Building, Parks Road, Oxford OX1 3QD

Page 2

Tackling the Partner Units Configuration Problem∗

Markus Aschinger†, Conrad Drescher‡, Gerhard Friedrich§, Georg Gottlob¶, Peter

Jeavons?, Anna Ryabokon∗∗, Evgenij Thorstensen††

Abstract

The Partner Units Problem is a type of configuration problem, that frequently occurs in in-

dustry. Unfortunately, it can be shown that in the general case (the optimization version of) the

problem is intractable. In this technical report we identify a tractable class of problem instances

that can be solved by a novel algorithm exploiting the notion of a path decomposition. We also

present and evaluate encodings for the general version of the problem in the optimization frame-

works of answer set programming, propositional satisfiability testing, constraint solving, and

integer programming.

Keywords: Configuration, structural decomposition methods, constraint optimisation, SAT solv-

ing, integer programming, answer set programming

∗Further copies of this Research Report may be obtained from the Librarian, Oxford University Com-

puting Laboratory, Computing Science, Wolfson Building, Parks Road, Oxford OX1 3QD, England (Tele-

phone: +44-1865-273837, Email: library@comlab.ox.ac.uk).

†Computing Laboratory, University of Oxford

‡Computing Laboratory, University of Oxford

§Institut f¨ ur Angewandte Informatik, Alpen-Adria-Universit¨ at Klagenfurt

¶Computing Laboratory, University of Oxford, Oxford Man Institute of Quantitative Finance

?Computing Laboratory, University of Oxford

∗∗Institut f¨ ur Angewandte Informatik, Alpen-Adria-Universit¨ at Klagenfurt

††Computing Laboratory, University of Oxford

Page 3

1 Introduction

The Partner Units Problem (PUP) has recently been proposed as a new benchmark configuration

problem [8]. It captures the essence of a specific type of configuration problem that frequently

occurs in industry.

Informally the PUP can be described as follows: Consider a set of sensors that are grouped

into zones. A zone may contain many sensors, and a sensor may be attached to more than one

zone. The PUP then consists of connecting the sensors and zones to control units, where each

control unit can be connected to the same fixed maximum number UnitCap of zones and sensors.1

Moreover, if a sensor is attached to a zone, but the sensor and the zone are assigned to different

control units, then the two control units in question have to be (directly) connected. However, a

control unit cannot be connected to more than InterUnitCap other control units (the partner units).

For an application scenario consider e.g. a museum where we want to keep track of the num-

ber of visitors that populate certain parts (zones) of the building. To this end the doors leading

from one zone to another are equipped with sensors. To keep track of the visitors the zones and

sensors are attached to control units; the adjacency constraints on the control units ensure that

communication between control units can be kept simple.

It is worth emphasizing that the PUP is not limited to this application domain: It occurs when-

ever sensors that are grouped into zones have to be attached to control units, and communication

between units should be kept simple like e.g. intelligent traffic management, or surveillance and

security applications. The PUP is used as a novel benchmark instance at the 2011 answer set

programming competition [1].

Figure 1 shows a PUP instance and a solution for the case UnitCap = InterUnitCap = 2 —

six sensors (left) and six zones (right) which are completely inter-connected are partitioned into

units (shown as squares) respecting the adjacency constraints. Note that for the given parameters

this is a maximal solvable instance; it is not possible to connect a new zone or sensor to any of

the existing ones.

In this technical report we will show that the case where InterUnitCap = 2 and UnitCap = k

for some fixed k is tractable by giving a specialized NLOGSPACE algorithm that is based on the

notion of a path decomposition. While already this case is of great importance for our partners in

industry, the general case is quite interesting in its own right: Consider e.g. a grid of rooms, where

every room is accessible from each neighboring room, and all the doors are fitted with a sensor.

Moreover, there are doors to the outside on two sides of the building; the respective instance is

shown in figure 2 with rooms as black squares, and doors as cyan circles. It is not hard to see that

this instance is unsolvable for InterUnitCap = 2 and UnitCap = 2, whereas it is easily solved

for InterUnitCap = 4 and UnitCap = 2: Every room goes on a distinct unit, together with the

sensors to the west and to the north; the connections between units correspond to those between

rooms. Clearly this solution is optimal in the sense of using the least possible number of units.

In this work we hence also present encodings in the optimization frameworks of answer set

programming, constraint satisfaction, SAT-solving, and integer programming that can be used to

solve the general version of the PUP. We also show how to adapt these encodings to the special

case InterUnitCap = 2. For both cases we evaluate the performance.

1For ease of presentation and without loss of generality we assume that UnitCap is the same for zones and sensors.

1

Page 4

Figure 1: Solving a K6,6Partner Units Instance — Partitioning Sensors and Zones into Units on

a Circular Unit Layout

Figure 2: A Grid-like PUP Instance

The remainder of this technical report is organized as follows:

• In section 2 we give the basic formal definitions, and identify general properties of the PUP.

• In section 3 we establish our recent tractability results for the case InterUnitCap = 2.

• In section 4 we present problem models in the frameworks of answer set programming,

propositional satisfiability testing, integer programming, and constraint solving. These

problem models can be used for arbitrary values of InterUnitCap, but we also show how

they can be adapted to the special case of InterUnitCap = 2.

• In section 5 we evaluate the performance.

• In section 6 we conclude.

2

Page 5

2 Formal Definition of the Partner Units Problem and Basic Facts

In this section we present the basic formal definitions of the PUP, some basic properties of PUP

instances that affect the existence, shape, or size of solutions, as well as basic complexity results.

2.1 Formal definition

Formally, the PUP consists of partitioning the vertices of a bipartite graph G = (V1,V2,E) into a

set U of bags such that each bag

• contains at most UnitCap vertices from V1and at most UnitCap vertices from V2; and

• has at most InterUnitCap adjacent bags, where the bags U1and U2are adjacent whenever

Vi∈ U1and Vj∈ U2and (Vi,Vj) ∈ E.

To every solution of the PUP we can associate a solution graph. For this we associate to every

bag Ui∈ U a vertex VUi. Then the solution graph G∗has the vertex set V1∪V2∪{VUi| Ui∈ U}

and the set of edges {(V,VUi) | V ∈ Ui∧ Ui∈ U} ∪ {(VUi,VUj) | Uiand Ujare adjacent.}. In

the following we will refer to the subgraph of the solution graph induced by the vUias the unit

graph.

The following are the two most important reasoning tasks for the PUP: Decide whether there

is a solution, and find an optimal solution, that is, one that uses the minimal number of control

units. We are especially interested in the latter problem. For this we consider the corresponding

decision problem: Is there a solution with a specified number of units? The rationale behind the

optimization criterion is that (a) units are expensive, and (b) connections are cheap.

2.2 The Partner Units Problem is Intractable

By a reduction from BINPACKING it can be shown that the optimization version of the PUP is

intractable when InterUnitCap = 0, and UnitCap is part of the input. Observe that clearly the

PUP is in NP (cf. also section 4).

Theorem 2.1 (Intractability of the PUOP). The PUOP is NP-complete when InterUnitCap = 0,

and UnitCap is part of the input.

Proof. We reduce from BINPACKING, given as items S1,...,Sn, binsize b and number of bins k.

We make a PUOP instance by creating for every i a biclique with Sizones and Sisensors, setting

UnitCap = b and InterUnitCap = 0. A packing with k of fewer bins exists iff there exists a

solution to the PUOP with k or fewer units. Finally note that BINPACKING remains NP-complete

when all the numbers are expressed in unary [9].

Observe that for practical applications the value of UnitCap will not be arbitrary.

3

Page 6

2.3 Forbidden Subgraphs of the PUP

It is also not hard to show the following:

Lemma 2.2 (Forbidden Subgraphs of the PUP). A PUP instance has no solution if it contains

K1,nor Kn,1as a subgraph, where n = ((InterUnitCap + 1) ∗ UnitCap) + 1.

Proof. Assume some sensor S has n neighbors, and is assigned to some unit U in a solution.

There can be at most InterUnitCap neighbors Unbof U, each with at most UnitCap zones at-

tached. Hence one of the neighbors of S has to be on a unit different from U and all of the Unb.

Contradiction.

2.4

K-regular Graphs

Next let us discuss the connection between most general solutions to the PUP and k-regular unit

graphs: A graph is k-regular if every vertex has exactly k neighbors. Having k-regular unit graphs

in solutions means that we are exploiting the InterUnitCap capacity for connections between units

to the fullest. In a sense k-regular unit graphs thus are most general solutions.

In the case where k = 2, there is exactly one k-regular graph, the cycle; we exploit this fact in

section 3. In the case where k is odd, k-regular unit graphs only exist if there is an even number

of units (”hand-shaking lemma”). Moreover, for k > 2 the number of distinct most general unit

graphs grows rapidly: E.g. for k = 4 there are six distinct graphs on eight vertices, and 8037418

on sixteen vertices; for twenty vertices not all distinct graphs have been constructed [16]. It can

be shown that all these solution topologies can be forced:

Observation 1 (PUP Instances and k-regular Graphs). For every k-regular graph Gkthere exists

a PUP instance G with InterUnitCap = k such that in every solution of G the unit graph is Gk.

Proof. Construct the instance G as follows:

1) First connect 2 ∗ UnitCap vertices (i.e. sensors and zones) to each node in Gk. Let the set

of all sensors (zones) be V1(V2).

2) The instance G contains all edges (v1,v2), where v1∈ V1and v2∈ V2are connected to

either the same or adjacent nodes in Gk.

We show that every solution is isomorphic to Gk. We consider two cases:

• 0 ≤ InterUnitCap ≤ 1: The result is immediate.

• k > 1: Let U0be a node in Gkwith neighbors, and let Uj: 1 ≤ j ≤ k be the neighbors.

Denote by VUi

an optimal solution for G. We need to show two things: (1) For each 0 ≤ i ≤ k both VUi

and VUi

are connected in G then their units are connected in G?

following: Consider a path of three units U1,U2,U3. Consider the instance constructed by

applying steps 1) and 2) to this path. Any solution for this instance has three units. Here

1and VUi

2the sensors and zones created in G for Ui: 0 ≤ i ≤ k. Let G?

kbe

1

2are on the same unit in G?

k. (2) For 0 ≤ i < j ≤ k if VUi

1∪ VUi

2and VUj

1

∪ VUj

2

k. Both (1) and (2) follow from the

4

Page 7

we consider only solutions where the unit graphs are paths, say U4,U5,U6. The sensors

and zones originally attached to the middle unit U2have to be on the middle unit U5—

otherwise their 2 ∗ UnitCap neighbors won’t fit. Moreover, the sensors and zones from U1

have to be on the same unit, either U4or U6; the sensors and zones from U3are on the unit

at the other end of the path. With the exception of the cycle of length two, all k-regular unit

graphs are composed from such path segments of length three. As every “end” of a path

segment is the “middle” of another path segment we did not consider cyclic solutions for

the path segments. Conditions (1) and (2) are now easily seen to hold.

Hence, if InterUnitCap > 2, and there are no restrictions on the solution topology in the

application domain, then it is practically not feasible to iteratively try all most general solution

topologies. The solution topology will have to be inferred instead.

2.5 An Upper Bound on the Number of Units

In this section we address the question of how many units are necessary (or sufficient, respec-

tively) for finding a solution for a PUP instance G = (V1,V2,E). These bounds are useful in that

they help to limit the depth of iterative deepening search: For finding optimal solutions in most

problem models introduced in the sequel we first try to find a solution with lb units; if that fails

increase lb by one. Clearly this has the effect that the first solution found will be optimal.

Clearly the number of units in a solution is bounded from below by lb = ?max(|V1|,|V2|)

then at least every unit but one is filled to the maximum. For the upper bound we start with the

simple observation that ub = |V1|+|V2| certainly is always enough — otherwise there would be

empty units in the solution. Next we observe that if there are multiple connected components in

the instance, each with upper bound ubi, then we can safely set ub =?ubi.

UnitCap > 1 and InterUnitCap = 2. The instance depicted in figure 3 shows that this ub does not

hold for UnitCap = 1 and InterUnitCap = 2. It is constructed starting from the solution shown,

using the same construction as in the proof of observation 1. Intuitively, it enforces a “hole” in

the units on the left-hand side that can not be closed without violating one of the partner unit

constraints.

UnitCap

? —

Next we are going to show that the stronger upper bound ub = max(|V1|,|V2|) holds if

Proposition 2.3 (Upper Bound for UnitCap > 1 and InterUnitCap = 2). For a PUP-instance

G = (V1,V2,E) with UnitCap > 1 and InterUnitCap = 2 there exists a solution if and only if

there exists a solution that uses at most ub = max(|V1|,|V2|) units.

Proof. Let n = max(|V1|,|V2|), i.e. the upper bound to be proved. Assume there is a solution

with m = n + o units. We need to show that then there are at least o pairs of connected units

that can be merged. Without loss of generality we may assume that |V1| = |V2| and UnitCap = 2

— if this does not hold the number of mergeable pairs of units can only be greater. We may

also assume that the solution is cyclic. A pair of adjacent units can be merged if the sum of the

respective sensors and zones respects UnitCap.

Wedistinguishthefivetypesofsolutionbuildingblocksdepictedinfigure4. Letxidenotethe

number of units of type i in the solution. In general we have that m = 3x1+3x2+3x3+2x4+x5.

5

Page 8

Figure 3: An instance requiring more than max(|V1|,|V2|) units

In the simplest case the solution contains only Type 4 and Type 5 units, i.e. x4= 2o and x5=

n−o. Here alternatingly picking edges on the cycle yields ?m

The maximum number of non-mergeable units is reached for maximum values of x1. W.l.o.g. we

assume that x2= x3= x5= 0, i.e. n − o mod 3 = 0, and consequently have that x1= n − o

and x4= 2o. The key observation is that for every ”full” unit we introduce two mergeable units.

The number of ”full” units is given byn−o

from being mergeable is then given byn−o

3

−1, i.e. less than the number of units introduced due

to full units.

2? pairs of units that can be merged.

3, and the total number of units that can be blocked

Figure 4: The different types of solution building-blocks for UnitCap = 2

6

Page 9

Note that this upper bound is not tight — by doing a proper case analysis it is certainly

possible to obtain an upper bound that depends on the value of UnitCap, and takes into account

the possibility of merging more than two units at a time.

2.6 Symmetry breaking

If we don’t use iterative deepening search then in some problem models there might be empty

units. Here we can do symmetry breaking by demanding that whenever unit j has a sensor or

zone assigned to it, then every unit j?< j also has some sensor or zone assigned to it.

We can also rule out a quarter of the connections between sensors (or alternatively, zones)

and units immediately. Consider sensors and units: Sensor 1 must be somewhere, so it might as

well be on unit 1. Sensor 2 can either be on unit 1 or on a new unit, let’s say 2. Unfortunately,

we cannot do the same for zones (or for sensors if we do zones), since the edges may disallow a

zone and a sensor on the same unit.

3 The Case of InterUnitCap = 2

We now turn to the announced special Partner Units Problem where the number of neighbors of

any given unit in a solution is bounded by 2, i.e. InterUnitCap = 2. This version of the PUP—

the SPUP—, which is of high industrial relevance, can be tackled directly. We will do this by

giving an algorithm that decides the SPUP in NLOGSPACE by exploiting the notion of a path

decomposition of a given graph.

For ease of presentation in the sequel we make the simplifying assumption that the underlying

bipartite graph is connected. This does not affect solutions of the SPUDP and the SPUSP, where

the connected components can be tackled independently. For optimal solutions, however, the

connected components of an underlying graph will have to be considered simultaneously; cf. the

discussion in section 3.4.

3.1 Path Decompositions

As already stated our algorithm exploits the notion of a path decomposition of a certain width.

We next recall the respective definitions; we assume the reader is familiar with the basic notions

from graph theory.

A path decomposition of a graph G = (V,E) is a pair (P,χ) such that P is a simple path

— i.e. P does not contain cycles. The function χ associates to every vertex W of the path P a

subset B ⊆ V such that

(1) for every vertex V in V there is a vertex W on P with V ∈ χ(W);

(2) for every edge (V1,V2) in E there is a vertex W with {V1,V2} ⊆ χ(w); and

(3) for every vertex V in V the set {W | V ∈ χ(W)} induces a subpath of P.

Condition (3) is called the connectedness condition. The subsets B associated with the path

verticesarecalledbags. ThewidthofapathdecompositionismaxW(|χ(W)−1|). Thepathwidth

pw(G) of a graph is the minimum width over all its path decompositions.

7

Page 10

3.2Basic Properties of the SPUP

We proceed by identifying basic properties of the SPUP. The key observation is that the units

and their interconnections form a special kind of unit graph in any solution: either a simple

path, or a simple cycle. This holds because each unit is connected to at most two partner units.

Moreover, cycles are more general unit graphs than paths: Every solution can be extended to a

cyclic solution; hence in the sequel we only consider cyclic solutions.

Exploiting this observation, we can transform the SPUP into the problem of finding a suitable

path decomposition of the zones-and-sensors-graph G:

Theorem 3.1 (SPUP is Path-Decomposable). Assume a SPUP instance given by a graph G =

(V1,V2,E) is solvable with a solution graph G∗with |U| = n. Let f be the unit function that

associates vertices from G to U. Then there is a path decomposition (P,χ) of G of pathwidth

≤ (3 ∗ 2 ∗ UnitCap) − 1, with the following special properties:

(a) The length of P is n − 1; P = W1,...Wn−1.

(b) There are sets S1⊆ V1, S2⊆ V2with |Si| ≤ UnitCap such that S1∪ S2are in every bag

of the path decomposition.

(c) Apart from S1∪ S2each bag contains at most 2 ∗ UnitCap elements from V1(or V2,

respectively).

(d) For any vertex V ∈ V1∪ V2all neighbors of V appear in three consecutive bags of the

path decomposition (assuming the first and last bag to be connected).

(e) For each bag χ(Wi) of it holds χ(Wi) = f−1(U1) ∪ f−1(Ui) ∪ f−1(Ui+1) for 1 ≤ i ≤

n − 1.

(f) S1= f−1(U1) ∩ V1and S2= f−1(U1) ∩ V2.

Proof. If G is solvable then there is a solution G∗whose unit graph is a cycle U1,...,Un,U1.

Consider the path decomposition (P = W1,...,Wn−1,χ) where χ(wi) = f−1(U1)∪f−1(Ui)∪

f−1(Ui+1). This is indeed a path decomposition:

• Every edge (V1,V2) is in some bag. Assume V1and V2are assigned to two different

connected units Uiand Ui+1. Then {V1,V2} ⊆ χ(Wi).

• The connectedness condition is satisfied: For the vertices connected to unit U1the induced

subgraph is P. All other vertices occur in at most two consecutive bags.

• Every bag contains ≤ (3 ∗ 2 ∗ UnitCap) elements; hence pw(G) ≤ (3 ∗ 2 ∗ UnitCap) − 1.

An optimal path decomposition of the complete bipartite graph Kn,nwith n = 3 ∗ UnitCap has

width (3 ∗ 2 ∗ UnitCap) − 1; cf. figure 1. Hence the bound is tight. The conditions (a − f) are

easily seen to hold for the path decomposition constructed above.

8

Page 11

Intuitively, the vertices in the sets S1and S2from condition (b) above are those that close the

cycle (i.e. that are connected to unit U1). These have to be in every bag as some of their neighbors

might only appear on the last unit Un. If all neighbors of S1and S2already appear in U1∪ U2

then we need consider only paths as unit graphs instead of cycles, and the pathwidth is hence

decreased by 2 ∗ UnitCap.

3.3An Algorithm for the SPUP

By Theorem 3.1 we know that if a SPUP instance is solvable then there is a path decomposition

with specific properties. But we still need an algorithm for finding such suitable path decompo-

sitions. Many algorithms for finding path decompositions of bounded width have been proposed

in the literature. But, for the SPUP we want to find path decompositions with specific properties:

• The paths should be short (the number of bags reflects the number of units); and hence,

• The bags should be rather full (in ”good” solutions the units will be filled up).

• The construction of the bags must be interleaved with checking the additional constraints.

Below we introduce an algorithm that fits the bill; it is inspired by the algorithm for finding

hypertree decompositions from [12]. This non-deterministic algorithm does the following: The

bags on the path decomposition are guessed. The initial bag partitions the graph into a set of

remaining components that are recursively processed simultaneously. A single bag suffices to

remember which part of the graph has already been processed; the bag separates the processed

part of the graph from the remaining components. Consequently, all we have to store is the

current bag and the remaining components. It turns out that for this we only need logarithmic

space, and thus the algorithm runs in NLOGSPACE, and hence in polynomial time [4].

In addition to the bags the unit function is guessed, too. According to condition (d) from

above all neighbors of any vertex in G occur in three consecutive bags in the path decomposition.

Hence, for checking locally that the unit function is correct it suffices to remember three bags at

each step.

Due to the different roles played by the units that make up a bag, the DECIDESPUP algorithm

operates at the level of units rather than bags.

DECIDESPUP(G)

1Guess disjoint non-empty U1,U2⊆ V(G)

with |Ui∩ V1| ≤ UnitCap ≥ |Ui∩ V2|

2

CR← G \ (U1∪ U2)

3

if DECIDESPUP (CR,?U1,U2?,?U1,U2?)

4

then ACCEPT

5

else REJECT

9

Page 12

DECIDESPUP(CR,?U1,U2?,?Ui−1,Ui?)

1

if CR= ∅

2

then

3

if ∀V ∈ U1nb(V ) ⊆ U1∪ U2∪ Uiand

∀V ∈ Uinb(V ) ⊆ Ui−1∪ Ui∪ U1

4

then ACCEPT

5

else REJECT

6

else

7

with |Ui+1∩ V1| ≤ UnitCap ≥ |Ui+1∩ V2|

8For V ∈ Uicheck nb(V ) ⊆ (Ui−1∪ Ui∪ Ui+1)

9

C?

10DECIDESPUP (C?

Guess non-empty Ui+1⊆ V(?CR)

R← (CR\ Ui+1)

R,?U1,U2?,?Ui,Ui+1?)

Upon initialization (l. 1–5) the first two units are guessed as subsets of the vertices of the

input G (l. 1). Throughout a run of the algorithm the remaining components are stored in CR(l.

2). We then proceed to the recursive case (l. 3–5).

While recursively processing G (l. 1–10) we consider two cases: (1) If there are no remaining

components (l. 1) we check the termination condition in l. 3. The neighbors of U1have to appear

somewhere on the first, second, or last unit, while the neighbors of the last unit have to appear

somewhere on the second-to-last, last, or first unit. Hence we store U1and U2, as well as a a

“predecessor” unit Ui−1and a “middle” unit Uithroughout a run of the algorithm; upon termi-

nation Ui−1is the second-to-last, and Uiis the last unit in the cycle. The recursive procedure is

first called with Ui−1= U1and Ui= U2, and at each step the contents of the current bag is given

by the union of U1with Ui−1∪ Ui. (2) Otherwise, a “successor” unit Ui+1is guessed (l. 7). In a

solution, all neighbors of vertices assigned to Uiare guaranteed to appear in Ui−1∪Ui∪Ui+1—

this is checked in l. 8. For Ui−1this will already have been established (if i > 2), and hence in

the next step Uiand Ui+1together with U1are again a proper separator. In l. 9 the vertices just

assigned to Ui+1are deleted from the remaining components, and in l. 10 the same procedure is

called recursively.

Using this algorithm we can show the following:

Theorem 3.2 (Tractability of SPUDP). The decision problem for the SPUP is solvable by the

algorithm DECIDESPUP in NLOGSPACE for InterUnitCap = 2 and any given fixed value of

UnitCap.

Proof. First observe that if the algorithm accepts then there is a solution for the SPUP; moreover,

if there is a solution of the SPUP, this clearly can be guessed. We still have to show that the

workspace required by DECIDESPUP is logarithmic in the size of the input. The size of the

currently retained units is bounded; hence these can be stored in logarithmic space. Moreover,

the currently retained units separate the part of the input graph that has already been processed

from the remaining components. Hence we only have to represent the remaining components.

At each step their number is bounded by 2 ∗ 2 ∗ UnitCap: For the current units Ui−1and Ui

there can be at most 2 ∗ UnitCap neighbors not yet assigned; in the worst case these can all

10

Page 13

belong to different connected components. Each of the remaining connected components can be

represented by a single vertex; hence we can get by with logarithmic space.

3.3.1 Answer Extraction

For actually obtaining a solution to a SPUP instance we face the following problem: In general

it is not possible to remember the contents of all the bags in logarithmic space. Theoretically

this problem can be solved as follows: On a first accepting run of DECIDESPUP we clearly can

remember the first bag’s contents in logarithmic space. We can then run DECIDESPUP again with

a fixed first bag, and so forth. Hence the following holds:

Theorem 3.3 (Tractability of SPUSP). The problem of finding a solution to the SPUP is solvable

in NLOGSPACE for InterUnitCap = 2 and any given fixed value of UnitCap.

Note that the problem of answer extraction disappears when actually implementing the non-

deterministic algorithm on a deterministic computer; cf. Section 3.5.

3.3.2 Towards an Efficient Algorithm

We next make a number of observations that can be exploited to turn DECIDESPUP into a prac-

tically efficient algorithm.

Guiding the Guessing

At most UnitCap neighbors of sensors and zones on the first unit can be assigned to the last unit.

Hence the following holds:2

Not all zones and sensors assigned to units have to be chosen randomly.

|nbs(U1) \ (U1∪ U2)| ≤ UnitCap ≥ |nbz(U1) \ (U1∪ U2)|.

Moreover, the neighbors of U1not assigned to U1or U2may only be guessed in the last step,

where the number of unprocessed sensors (or zones) is at most UnitCap.

Starting from i ≥ 2 we have the stronger:

(nbs(Ui) \ (Ui∪ Ui−1)) ⊆ Ui+1⊇ (nbz(Ui) \ (Ui∪ Ui−1)).

FindingOptimalSolutionsFirst

compositions with filled-up bags, and the number of units used in the solution of a SPUP instance

G = (V1,V2,E) is bounded by lb = ?max(|V1|,|V2|)

from above. Hence we can apply iterative deepening search: First, try to find a solution with lb

units; if that fails increase lb by one; hence the first solution found will be optimal. This yields

the following:

Corollary 3.4 (Tractability of SPUOP). On connected input graphs the SPUOP is solvable in

NLOGSPACE.

Nextrecallthat“good”solutionscorrespondtoshortpathde-

UnitCap

? from below and by ub = max(|V1|,|V2|)

Note that branch-and-bound-search (on the number of units used) can not be used: E.g. a

K6,6graph does not admit solutions with more than three units.

2We denote by nbs(U) (nbz(U)) the set of sensors (zones) that are adjacent in the input graph to zones (sensors)

assigned to U.

11

Page 14

Symmetry Breaking

Butwithcyclesforunitgraphstherearetwotypesofrotationalsymmetry: Forasolutionwithunit

graph VU1,...,VUn,VU1there is (1) a solution VU2,...,VUn,VU1,VU2, etc.; in addition there also

is (2) the solution VU1,VUn,VUn−1,...,VU2,VU1. We can break these symmetries by stipulating

that

We already observed that cycles are more general unit graphs than paths.

• the first sensor is assigned to unit U1; and

• the second sensor appears somewhere on the first half of the cycle.

3.4

SPUOP and Multiple Connected Components

Next let us discuss the problem of finding optimal solutions when the input graph consists of more

than one connected component. Here, part of the problem is that any two connected components

may either have to be assigned to the same, or to two distinct unit graph(s). A priori it is unclear

which of the two choices leads to better results. E.g. if we assume that UnitCap = 2 then two

K3,3should be placed on one cyclic unit graph, while a K6,6must stand alone. We leave the

complexity of the SPUOP on arbitrary input graphs as an open problem — but we are able to

show the following:

Theorem 3.5 (Tractability of SPUOP on Multiple Connected Components). For InterUnitCap =

2 and any given value of UnitCap the optimization problem for the SPUP on multiple connected

components is solvable in NLOGSPACE if there are only logarithmically many connected com-

ponents in the input graph.

Proof. (Sketch) Let a graph with c connected components be given as the union?

ranges from 1 to c. Set V1=?

bound we assume all components fit on a single unit graph; for the upper bound we consider the

c individual upper bounds separately.

Next observe that also in the case of multiple connected components a solution to the SPUP

gives rise to a path decomposition of a special form: Assume a SPUP instance given by a graph

G =?Giis solvable with a solution graph G∗consisting of m connected components, and

of Theorem 3.1, we obtain a single path decomposition of length n − m. Mutatis mutandis an

appropriate version of Theorem 3.1 is obtained.

Likewise the algorithm DECIDESPUP can be adjusted to guess appropriate path decomposi-

tions: We have to distinguish between remaining components that are currently being processed

and those that are still untouched. The key is then to ensure that a new “cyclic” segment of the

path decomposition may only be started if the set of remaining components that are still currently

being processed is empty; i.e. there are no unassigned neighboring sensors or zones left.

Observethatthetotalnumberofremainingconnectedcomponentsateachstepisnowbounded

by (4∗UnitCap) +c, where c is the number of connected components in the input graph. Hence

we stay within the logarithmic space bound if there are not more than logarithmically many con-

nected components in the input graph.

i=1..cGiof

bipartite graphs Gi= (V1,i,V2,i,Ei). The possible number of unit graphs in optimal solutions

? from below and ub =?

iV1,iand V2=?

iV2,i. The number of units used is bounded

imax(|V1,i|,|V2,i|) from above. For the lower

by lb = ?max(|V1|,|V2|)

UnitCap

using n units in total. By concatenating the path decompositions as constructed in the proof

12

Page 15

3.5Implementation

Weprototypicallyimplementedthe DECIDESPUP algorithminJava, replacingthenon-determinism

by a backtracking search mechanism. Our implementation can only handle connected input

graphs.

In [13] a deterministic backtracking version of the non-deterministic hypertree decomposition

algorithm from [12] is described, and the issues we face when making DECIDESPUP determin-

istic are very similar. To avoid repeated sub-computations we store pairs of bags and remaining

components that could not be decomposed:

Observation 2 (Avoidable Sub-Computations). Assume a pair of a bag B and a set of remaining

components CRcould not be decomposed by DECIDESPUP. If the same pair ?B,CR? occurs

again on a run of DECIDESPUP it also cannot be decomposed.

If we use iterative deepening search we also have to store the number of remaining units when

encountering a dead-end — it may be possible to decompose the remaining components using

more units. We don’t store successful pairs — the first such pair occurs when finding a solution.

It turns out that for identifying unsuccessful pairs of bags and remaining components it is

enough to store the bag plus the unassigned neighbors:

Lemma 3.6 (Identifying Remaining Components). Given the contents of a bag and the set of

currently unassigned neighbors at any step throughout a run of DECIDESPUP the remaining

components are uniquely determined.

Proof. Assume to the contrary that we have calls

1) DECIDESPUP(CR,?U1,U2?,?Ui−1,Ui?, and

2) DECIDESPUP(C?

R,?U1,U2?,?Ui−1,Ui?,

both with the same unassigned neighbors V (of U1and Ui).

First assume that we have different remaining connected components CRand C?

set of vertices. This immediately leads to a contradiction.

Next assume that there is a vertex V0∈ CRthat is not in C?

cannot be part of the current bag B = U1∪ Ui−1∪ Uias this is the same in the calls 1) and 2).

Hence assume that, in the run leading to the call 2), V0is assigned to Ujwhere j < (i − 1). We

know that there is a path V0,V1,...,Vnin CRleading from V0to some Vn∈ V such that none of

the Vi,0 ≤ i ≤ n is in B. Hence, in the run leading to the call 2), for one of the pairs Vi,Vi+1the

test nb(Vi) ⊆ (Uk−1∪ Uk∪ Uk+1) (k < i) must have failed.

Ron the same

R, and hence not in V. This V0

Asthereareonlypolynomiallymanypossiblepairsofcurrentbagsandunassignedneighbors,

and each of them is constructed at most once, the overall runtime of our implementation of the

DECIDESPUP algorithm is polynomial, too.

In order to detect no-good branches in the search tree early we implemented a form of two-

step forward-checking: We check whether there is enough space for the open neighbours of the

current unit on the current plus the next unit (step one), and do the same for the open neighbours

of these open neighbours (step two).

13

#### View other sources

#### Hide other sources

- Available from Markus Aschinger · Jun 10, 2014
- Available from cs.ox.ac.uk