Haven (graph theory)

Template:Short description In graph theory, a haven is a certain type of function on sets of vertices in an undirected graph. If a haven exists, it can be used by an evader to win a pursuit–evasion game on the graph, by consulting the function at each step of the game to determine a safe set of vertices to move into. Havens were first introduced by Template:Harvtxt as a tool for characterizing the treewidth of graphs. Their other applications include proving the existence of small separators on minor-closed families of graphs, and characterizing the ends and clique minors of infinite graphs.

Definition

If Template:Mvar is an undirected graph, and Template:Mvar is a set of vertices, then an Template:Mvar-flap is a nonempty connected component of the subgraph of Template:Mvar formed by deleting Template:Mvar. A haven of order Template:Mvar in Template:Mvar is a function Template:Math that assigns an Template:Mvar-flap Template:Math to every set Template:Mvar of fewer than Template:Mvar vertices. This function must also satisfy additional constraints which are given differently by different authors. The number Template:Mvar is called the order of the haven.

In the original definition of Seymour and Thomas, a haven is required to satisfy the property that every two flaps Template:Math and Template:Math must touch each other: either they share a common vertex or there exists an edge with one endpoint in each flap. In the definition used later by Alon, Seymour, and Thomas, havens are instead required to satisfy a weaker monotonicity property: if Template:Math, and both Template:Mvar and Template:Mvar have fewer than Template:Mvar vertices, then Template:Math. The touching property implies the monotonicity property, but not necessarily vice versa. However, it follows from the results of Seymour and Thomas that, in finite graphs, if a haven with the monotonicity property exists, then one with the same order and the touching property also exists.

A bramble of order four. A haven derived from this bramble maps every set Template:Mvar of three or fewer vertices to the unique connected component of Template:Math that includes at least one subgraph from the bramble.

Havens with the touching definition are closely related to brambles, families of connected subgraphs of a given graph that all touch each other. The order of a bramble is the minimum number of vertices needed in a set of vertices that hits all of the subgraphs in the family. The set of flaps Template:Math for a haven of order Template:Mvar (with the touching definition) forms a bramble of order at least Template:Mvar, because any set Template:Mvar of fewer than Template:Mvar vertices fails to hit the subgraph Template:Math. Conversely, from any bramble of order Template:Mvar, one may construct a haven of the same order, by defining Template:Math (for each choice of Template:Mvar) to be the Template:Mvar-flap that includes all of the subgraphs in the bramble that are disjoint from Template:Mvar. The requirement that the subgraphs in the bramble all touch each other can be used to show that this Template:Mvar-flap exists, and that all of the flaps Template:Math chosen in this way touch each other. Thus, a graph has a bramble of order Template:Mvar if and only if it has a haven of order Template:Mvar.

Example

As an example, let Template:Mvar be a nine-vertex grid graph. Define a haven of order 4 in Template:Mvar, mapping each set Template:Mvar of three or fewer vertices to an Template:Mvar-flap Template:Math, as follows:

• If there is a unique Template:Mvar-flap that is larger than any of the other Template:Mvar-flaps, let Template:Math be that unique large Template:Mvar-flap.
• Otherwise, choose Template:Math arbitrarily to be any Template:Mvar-flap.

It is straightforward to verify by a case analysis that this function Template:Math satisfies the required monotonicity property of a haven. If Template:Math and Template:Mvar has fewer than two vertices, or Template:Mvar has two vertices that are not the two neighbors of a corner vertex of the grid, then there is only one Template:Mvar-flap and it contains every Template:Mvar-flap. In the remaining case, Template:Mvar consists of the two neighbors of a corner vertex and has two Template:Mvar-flaps: one consisting of that corner vertex, and another (chosen as Template:Math) consisting of the six remaining vertices. No matter which vertex is added to Template:Mvar to form Template:Mvar, there will be a Template:Mvar-flap with at least four vertices, which must be the unique largest flap since it contains more than half of the vertices not in Template:Mvar. This large Template:Mvar-flap will be chosen as Template:Math and will be a subset of Template:Math. Thus in each case monotonicity holds.

Pursuit–evasion

Havens model a certain class of strategies for an evader in a pursuit–evasion game in which fewer than Template:Mvar pursuers attempt to capture a single evader, the pursuers and evader are both restricted to the vertices of a given undirected graph, and the positions of the pursuers and evader are known to both players. At each move of the game, a new pursuer may be added to an arbitrary vertex of the graph (as long as fewer than Template:Mvar pursuers are placed on the graph at any time) or one of the already-added pursuers may be removed from the graph. However, before a new pursuer is added, the evader is first informed of its new location and may move along the edges of the graph to any unoccupied vertex. While moving, the evader may not pass through any vertex that is already occupied by any of the pursuers.

If a Template:Mvar-haven (with the monotonicity property) exists, then the evader may avoid being captured indefinitely, and win the game, by always moving to a vertex of Template:Math where Template:Mvar is the set of vertices that will be occupied by pursuers at the end of the move. The monotonicity property of a haven guarantees that, when a new pursuer is added to a vertex of the graph, the vertices in Template:Math are always reachable from the current position of the evader.

For instance, an evader can win this game against three pursuers on a Template:Nowrap grid by following this strategy with the haven of order 4 described in the example. However, on the same graph, four pursuers can always capture the evader, by first moving onto three vertices that split the grid onto two three-vertex paths, then moving into the center of the path containing the evader, forcing the evader into one of the corner vertices, and finally removing one of the pursuers that is not adjacent to this corner and placing it onto the evader. Therefore, the Template:Nowrap grid can have no haven of order 5.

Havens with the touching property allow the evader to win the game against more powerful pursuers that may simultaneously jump from one set of occupied vertices to another.

Connections to treewidth, separators, and minors

Havens may be used to characterize the treewidth of graphs: a graph has a haven of order Template:Mvar if and only if it has treewidth at least Template:Math. A tree decomposition may be used to describe a winning strategy for the pursuers in the same pursuit–evasion game, so it is also true that a graph has a haven of order Template:Mvar if and only if the evader wins with best play against fewer than Template:Mvar pursuers. In games won by the evader, there is always an optimal strategy in the form described by a haven, and in games won by the pursuer, there is always an optimal strategy in the form described by a tree decomposition. For instance, because the Template:Nowrap grid has a haven of order 4, but does not have a haven of order 5, it must have treewidth exactly 3. The same min-max theorem can be generalized to infinite graphs of finite treewidth, with a definition of treewidth in which the underlying tree is required to be rayless (that is, having no ends).

Havens are also closely related to the existence of separators, small sets Template:Mvar of vertices in an Template:Mvar-vertex graph such that every Template:Mvar-flap has at most Template:Math vertices. If a graph Template:Mvar does not have a Template:Mvar-vertex separator, then every set Template:Mvar of at most Template:Mvar vertices has a (unique) Template:Mvar-flap with more than Template:Math vertices. In this case, Template:Mvar has a haven of order Template:Math, in which Template:Math is defined to be this unique large Template:Mvar-flap. That is, every graph has either a small separator or a haven of high order.

If a graph Template:Mvar has a haven of order Template:Mvar, with Template:Math for some integer Template:Mvar, then Template:Mvar must also have a complete graph Template:Mvar as a minor. In other words, the Hadwiger number of an Template:Mvar-vertex graph with a haven of order Template:Mvar is at least Template:Math. As a consequence, the Template:Mvar-minor-free graphs have treewidth less than Template:Math and separators of size less than Template:Math. More generally an Template:Tmath bound on treewidth and separator size holds for any nontrivial family of graphs that can be characterized by forbidden minors, because for any such family there is a constant Template:Mvar such that the family does not include Template:Mvar.

In infinite graphs

If a graph Template:Mvar contains a ray, a semi-infinite simple path with a starting vertex but no ending vertex, then it has a haven of order Template:Math: that is, a function Template:Mvar that maps each finite set Template:Mvar of vertices to an Template:Mvar-flap, satisfying the consistency condition for havens. Namely, define Template:Math to be the unique Template:Mvar-flap that contains infinitely many vertices of the ray. Thus, in the case of infinite graphs the connection between treewidth and havens breaks down: a single ray, despite itself being a tree, has havens of all finite orders and even more strongly a haven of order Template:Math. Two rays of an infinite graph are considered to be equivalent if there is no finite set of vertices that separates infinitely many vertices of one ray from infinitely many vertices of the other ray; this is an equivalence relation, and its equivalence classes are called ends of the graph.

The ends of any graph are in one-to-one correspondence with its havens of order Template:Math. For, every ray determines a haven, and every two equivalent rays determine the same haven. Conversely, every haven is determined by a ray in this way, as can be shown by the following case analysis:

• If the haven has the property that the intersection

  $S=\bigcap _X(\beta (X)\cup X)$

  (where the intersection ranges over all finite sets Template:Mvar) is itself an infinite set Template:Mvar, then every finite simple path that ends in a vertex of Template:Mvar can be extended to reach an additional vertex of Template:Mvar, and repeating this extension process produces a ray passing through infinitely many vertices of Template:Mvar. This ray determines the given haven.

• On the other hand, if Template:Mvar is finite, then (by working in the subgraph Template:Math)it can be assumed to be empty. In this case, for each finite set Template:Mvar of vertices there is a finite set Template:Mvar with the property that Template:Mvar is disjoint from $X_{i+1}\cup \beta (X_{i+1})$. If a robber follows the evasion strategy determined by the haven, and the police follow a strategy given by this sequence of sets, then the path followed by the robber forms a ray that determines the haven.

Thus, every equivalence class of rays defines a unique haven, and every haven is defined by an equivalence class of rays.

For any cardinal number $\kappa \ge {\mathrm{\aleph }}_1$, an infinite graph Template:Mvar has a haven of order Template:Mvar if and only if it has a clique minor of order Template:Mvar. That is, for uncountable cardinalities, the largest order of a haven in Template:Mvar is the Hadwiger number of Template:Mvar.