The study of sparse nonplanar graphs is receiving increasing attention in the last years. One objective of this research stream is to extend the rich set of results about planar graphs to wider families of graphs that can better model real-world problems (see, e.g., [DBLP:journals/algorithmica/Eppstein00, DBLP:conf/gis/Eppstein017, DBLP:journals/jea/EppsteinLS13, DBLP:journals/algorithmica/GrigorievB07, DBLP:journals/combinatorica/Grohe03]). Another objective is to create readable visualizations of nonplanar networks arising in various application scenarios (see, e.g., [DBLP:journals/tcs/DidimoEL11, DBLP:journals/vlc/HuangEH14]). Both these motivations are embraced by a recent research topic in graph drawing and topological graph theory, which generalizes the notion of graph planarity to beyond-planar graphs, informally defined as those graphs that can be drawn in the plane such that some prescribed edge crossing patterns are forbidden (see [DBLP:journals/jgaa/BekosKM18, DBLP:journals/csur/DidimoLM19, DBLP:journals/dagstuhl-reports/Hong0KP16, DBLP:journals/shonan-reports/HongT216] for surveys and reports).
One of the most studied families of sparse nonplanar graphs, whose definition naturally extends that of planar graphs, is the family of -planar graphs; refer to [DBLP:journals/csr/KobourovLM17] for a survey. A graph is -planar if it can be drawn in the plane such that each edge is crossed at most once. An -vertex -planar graph has edges [DBLP:journals/combinatorica/PachT97], separators and hence treewidth [DBLP:journals/siamdm/DujmovicEW17, DBLP:journals/algorithmica/GrigorievB07], and stack and queue number [DBLP:journals/corr/AlamBK15, DBLP:journals/algorithmica/BekosBKR17, DBLP:journals/corr/abs-1904-04791].
Despite these (and other) similarities with planar graphs, recognizing whether a graph is -planar is an NP-complete problem, in contrast with the well-known efficient algorithms for testing planarity. A first proof was by Grigoriev and Boadlander [DBLP:journals/algorithmica/GrigorievB07], and was based on a reduction from the 3-partition problem. Another independent proof was later given by Korzhik and Mohar [KM13], who used a reduction from the 3-coloring problem for planar graphs. The recognition problem for -planar graphs is NP-complete even for graphs with bounded bandwidth, pathwidth, or treewidth [DBLP:journals/jgaa/BannisterCE18]; for graphs obtained from planar graphs by adding a single edge [DBLP:journals/siamcomp/CabelloM13]; and for graphs that come with a fixed rotation system [DBLP:journals/jgaa/AuerBGR15]. The problem becomes fixed-parameter tractable when parameterized by vertex-cover number, cyclomatic number, or tree-depth [DBLP:journals/jgaa/BannisterCE18]. Polynomial-time testing algorithms have been designed only for subfamilies of -planar graphs (see, e.g., [DBLP:journals/algorithmica/AuerBBGHNR16, DBLP:journals/algorithmica/Brandenburg18, DBLP:journals/algorithmica/Brandenburg19, DBLP:journals/algorithmica/HongEKLSS15] and refer to [DBLP:journals/csur/DidimoLM19, DBLP:journals/csr/KobourovLM17] for additional references and results).
As witnessed by the above-mentioned literature, the problem of recognizing -planar graphs has been studied by several authors aimed at drawing clear bounds between tractable and intractable instances. Nevertheless, there is a lack of general algorithms that can be effectively implemented and adopted in applications. The research presented in this paper goes in the direction of filling this gap by investigating practical approaches and by providing indications for further advances. Our contribution can be summarized as follows.
We describe an easy to implement strategy based on a backtracking approach (Section 3). It takes as input a general graph and decides whether is -planar by exploring a search tree that encodes the space of candidate -planar embeddings for the graphs. If the test is positive, the algorithm returns a -planar embedding of (see, e.g., Fig. 1). We remark that several algorithms designed for -planar graphs assume that the input graph comes with a given -planar embedding (see, e.g., [DBLP:conf/gd/AlamBK13, DBLP:journals/tcs/BekosDLMM17, DBLP:journals/dcg/BiedlLM18, DBLP:journals/algorithmica/GiacomoDELMMW18, DBLP:conf/cocoon/HongELP12, DBLP:conf/gd/HongN16]), thus our algorithm can be used as a preliminary routine to compute such an embedding.
We report the results of an experimental study on a large set of instances with up to 50 vertices, taken from two well-established real-world graph benchmarks, the so-called Rome and North graphs [data, DBLP:journals/comgeo/WelzlBGLTTV97] (Section 4). The experiments indicate that while our approach can be successfully applied to the majority of instances with up to 30 vertices, more sophisticated techniques are needed to attack larger graphs. In terms of total number of edge crossings, our algorithm computes embeddings that on average contain no more than times the number of crossings of a state-of-the-art planarizer [DBLP:conf/gd/GutwengerM03], which is allowed to cross an edge more than once; see, e.g., Fig. 1.
As a byproduct of our experiments, we make publicly available [url] the solved instances of the Rome and North graphs, with a labeling that specifies whether each instance is -planar or not. An interesting finding is that the vast majority of the solved instances in these sets are -planar, which corroborates the interest on -planar graphs from an application perspective.
A drawing of a graph maps each vertex of to a point of the plane and each edge of to a Jordan arc connecting its two endpoints. We only consider simple drawings, where adjacent edges do not cross and where two independent edges cross at most in one of their interior points. A graph is planar if it admits a planar drawing, i.e., a crossing-free drawing. A planar drawing subdivides the plane into topologically connected regions, called faces. The unbounded region is the outer face. A planar embedding of is an equivalence class of planar drawings of with a homeomorphic set of faces and the same face as outer face. A plane graph is a graph with a given planar embedding. If is not planar, the planarization of a drawing of is a plane graph obtained by replacing every crossing point with a dummy vertex. An embedding of is an equivalence class of drawings of whose planarizations yield the same planar embedding.
A graph is -planar if it admits a -planar drawing, that is, a drawing where each edge is crossed at most once. A -planar embedding is the embedding induced by a -planar drawing. A -plane graph is a graph with a given -planar embedding. A kite is a -plane graph isomorphic to , in which the outer face is bounded by a cycle composed of four vertices and four crossing-free edges, called kite edges, while the remaining two edges cross (see, e.g., [DBLP:journals/jgaa/Brandenburg14, DBLP:journals/algorithmica/GiacomoDELMMW18]). Similarly to planar graphs, a graph is -planar if and only if all its subgraphs are -planar; also, the following property holds.
is -planar if and only if every biconnected component of is -planar. If is -planar, a -planar embedding of can be obtained in linear time by suitably merging the -planar embeddings of its biconnected components.
3 Algorithm Design
We call our -planarity testing and embedding algorithm 1PlanarTester. In the following we first give an overview of this algorithm and then describe its backtracking procedure in detail (Section 3.1). Finally, we describe some further optimizations made to speed-up the algorithm.
1PlanarTester takes as input a connected graph and works as follows. First, based on Property 1, it computes the biconnected components of and processes each of them independently. For each biconnected component , it executes some preliminary tests in order to verify whether can be immediately labeled as -planar or as not -planar. In the former case, 1PlanarTester processes the next biconnected component, while in the latter case it halts and returns that is not -planar. Namely, if is planar or it has less than vertices ( is -planar), then 1PlanarTester labels as -planar and computes a -planar embedding of . Otherwise, if , where and are the number of vertices and edges of , then 1PlanarTester labels as not -planar because it exceeds the maximum number of edges for a -planar graph [DBLP:journals/combinatorica/PachT97]. If none of these conditions applies, 1PlanarTester proceeds to the next step, which runs a backtracking procedure described in the following. The output of this step is a -planar embedding of , if it exists, or a negative answer. In the positive case, 1PlanarTester processes the next biconnected component, otherwise it halts and returns that is not -planar. At the end of this process, 1PlanarTester will either output an embedding for each biconnected component of , or it will return a component that is not -planar.
3.1 Backtracking Procedure
This procedure takes as input a biconnected graph with vertices and edges. We define as candidate solution for the -planarity testing problem on a set of pairs of crossing edges. Namely, let be the set of all (unordered) pairs of edges that can cross in some embedding of , i.e., the pairs such that and are independent (we only consider simple drawings). Let and observe that because . Let be any ordering of , and let denote the -th pair of edges in such an ordering. We encode a candidate solution by a binary array of length such that (resp. ) means that the two edges do not cross (resp. cross) in a -planar embedding of (if it exists). Refer to Fig. 2 for an illustration. We say that is a TRUE solution of if: (1) Each edge is crossed at most once, and (2) by replacing each crossing with a dummy vertex, the resulting graph is planar (see also Fig. 2). Otherwise we say that is a FALSE solution. Observe that Condition (2) is well defined because each edge is crossed at most once and hence we do not need to know the order of the crossings along the edges.
is -planar if and only if the set of candidate solutions contains a TRUE solution.
If is -planar, take a -planar drawing of . Consider a candidate solution such that (resp. ) if the two edges do not cross (resp. cross) in . Since each edge of is crossed at most once, Condition 1 holds. Also, the planarization of induces a planar embedding of the graph obtained by replacing each crossing with a dummy vertex. Hence Condition 2 holds.
Conversely, let be a TRUE solution. By Conditions 1 and 2, graph is planar and no two dummy vertices are adjacent. Let be a planar drawing of . Consider a dummy vertex of that corresponds to a crossing of two edges and of . In a clockwise visit of the neighbors of , starting from , the second vertex is either an end-vertex of or . In the first case we replace with a crossing between and (Fig. 3). In the second case, does not really correspond to a crossing, thus we just remove it and redraw and without crossings, as in Fig. 3. Applying this transformation to every dummy vertex of we obtain a -planar drawing of .
The backtracking procedure generates the set of candidate solutions incrementally, by computing a binary search tree as follows, see also Fig. 2. Each node of is equipped with an index and with an array of length that represents a partial candidate solution. Also, node has two children, and , such that , , for , , and . We say that an array extends if is associated with a node that is a descendant of in . The search tree is traversed following a top-down order of the nodes starting from the root. When visiting a node of , the backtracking procedure runs a routine called VerifyNode(,), whose pseudocode is described by Algorithm 1 (some lines of this routine will be explained in the next subsection). This routine returns one of three possible values: SOL, CUT, CNT. If the return value is SOL, is a TRUE solution (or can be extended to a TRUE solution) and the algorithm returns a -planar embedding of . If it is CUT, the algorithm will not visit the children of (i.e., the whole subtree of rooted at will be pruned) because is either a FALSE solution or it cannot be extended to a TRUE solution. If it is CNT, we cannot conclude anything about and the procedure adds the two children and of to the set of nodes to be visited.
To describe in detail the VerifyNode(,) routine, we need some definitions. An edge is crossed in if it is in a pair of edges , with , such that . An edge is saturated in if at least one of the following conditions applies: (a) is crossed in ; (b) the greatest index such that contains is smaller than ; (c) every pair of edges of that contains is such that the other edge of the pair is crossed in .
Let be a saturated edge in . Then is either crossed in or it is not crossed in every array that extends .
If Condition (a) holds the lemma follows, so assume that it does not hold. If Condition (b) holds, will never appear in a with , hence crosses in if and only if it crosses in . Finally, if Condition (c) holds then cannot cross any other edge, thus it is not crossed in any that extends .
First of all, the VerifyNode(,) routine verifies that there is no edge crossed twice in . Next, the routine computes the graph induced by the edges saturated in , and the graph obtained from by replacing each crossing with a dummy vertex. The following holds:
Let be an array that extends (possibly coinciding with ) and that is a TRUE solution. Then is planar.
If , the statement follows, because corresponds to by construction, and thus is planar by definition of TRUE solution. If , is a subgraph of by Lemma 2. Namely, only contains the edges saturated in , thus such edges either already cross in or cross neither in nor in . Since is planar, it follows that is also planar.
The routine verifies whether coincides with . This is the case if , but it may happen even if and all edges of are part of because are all saturated in . If coincides with , based on Lemma 3, the routine tests if is planar. In the positive case, it returns SOL and a -planar embedding of is obtained from a planar embedding of by replacing the dummy vertices with crossing points. In the negative case, the algorithm returns CUT because cannot be extended to a TRUE solution. If does not correspond to , then the algorithm computes an arbitrary extension of and verifies whether it is a TRUE solution. This corresponds to exploring a leaf of the subtree of rooted at . If such a leaf is a TRUE solution, a -planar embedding is computed and returned. Else CNT is returned and the traversal of continues.
Further Optimizations. The main issue for the scalability of our algorithm is the quadratic length of the arrays representing the candidate solutions of our problem, which implies that the size of the search tree is . In order to reduce the search space, we first test whether there exists a small subset of edges of , which we call skew edges, whose removal yields a planar graph, i.e., we test whether is a
-skew graph (see, e.g.,[DBLP:journals/siamcomp/CabelloM13, DBLP:conf/compgeom/ChimaniH16]). The size of can be set as a parameter of our algorithm. If this is the case, 1PlanarTester first executes the backtracking procedure by restricting the set of pairs of edges that can cross to those pairs that contain at least one skew edge. This reduces the length of a candidate solution to . If a solution exists, then has a -planar embedding with at most crossings. Otherwise, we cannot conclude that is not -planar because it may have a -planar embedding where 2 edges of cross each other, and hence we execute the standard backtracking procedure.
As a further optimization, we consider kite edges, defined as follows. An edge is a kite edge in if it is a kite edge with respect to a pair of edges that cross in . In the VerifyNode routine, we extend the definition of a saturated edge by adding a fourth condition: (d) is a kite edge in . In fact, an array that extends and in which a kite edge is crossed can be discarded by the routine (see Algorithm 1), because kite edges can always be redrawn without crossings. This allows us to increase the number of edges in
and hence to increase the probability thatcoincides with or that is not planar.
4 Implementation and Experimental Analysis
We implemented 1PlanarTester in the C# language. Our implementation exploits some planarity testing subroutines of the OGDF library [DBLP:reference/crc/ChimaniGJKKM13] (written in C++). We experimentally tuned the following parameters of our algorithm, which have an impact on the running time: (a) The strategy used to traverse the search tree ; (b) the size of the set of skew edges; (c) the probability that an arbitrary extension of a partial candidate solution is executed. Based on preliminary experiments, we chose the following settings. The search tree is traversed by a depth-first search, which guarantees that the space complexity of the algorithm is ; note that with a breadth-first-search the space requirement may be . We consider a set of skew edges of size one. The completion subroutine is executed with probability .
Experimental Goals. The experimental analysis has two main objectives:
Evaluating the running time of our algorithm and the size of the largest instances it can handle in a reasonable time. Moreover, for those instances that are -planar, we want to compare the total number of crossings produced by 1PlanarTester with respect to a state-of-the-art planarizer that is allowed to cross an edge more than once.
Labeling as -planar or not -planar the instances of well-established real-world graph benchmarks in graph drawing, namely the Rome and the North graphs [data, DBLP:journals/comgeo/WelzlBGLTTV97]. Our ultimate goal is to stimulate further practical research on beyond-planar graphs.
Experimental Setting. We ran the experiments on a set of computers with uniform hardware and software features, namely computers with 16 GB of RAM, an Intel i7 CPU, and the Windows 10 operating system. We used the Rome and the North graphs as benchmarks for answering both G1 and G2. We preliminary removed the planar instances from these two sets of graphs, as they are of no interest for us. Table 1 reports some information about the considered nonplanar instances grouped by size. The first columns contain the number of instances in each sample, the average density (i.e., the average ratio between number of edges and number of vertices), and the average number of biconnected components, called blocks (recall that the algorithm processes each block independently). We halted the computations that took more than 3 hours. As state-of-the-art planarizer, we used an implementation available in the OGDF library and discussed in [DBLP:conf/gd/GutwengerM03]
, which makes use of heuristics described in[DBLP:journals/algorithmica/GutwengerMW05, DBLP:journals/tcad/JayakumarTS89]. To give an idea of the experimental effort, we report that, by summing up the running time of all computers, the experiments took more than 800 hours (i.e., more than one month). The output of the experiments in terms of labeling of the instances as -planar or not -planar is publicly available [url].
Results and Discussion. Concerning G1, Table 1, Table 2, and Table 3 summarize the performance of 1PlanarTester in terms of number of solved instances, running time, and number of crossings, respectively. As it can be observed in the fifth and sixth columns of Table 1, our algorithm could solve a high percentage of instances up to 20 vertices (91.2% of Rome and 73.6% of North). For the larger instances up to 40 vertices, the North graphs become more challenging, with a percentage of solved instances that is stable around 39%. On the other hand, the percentage of solved instances on the Rome graphs is higher, namely above 69% for the instances with 21-30 vertices, and above 43% for the instances with 31-40 vertices. We also ran our algorithm on instances with 41 to 50 vertices. 1PlanarTester could solve 37.8% of these instances in the Rome set and 18.8% in the North set. The better performance of our algorithm on the Rome graphs is partly justified by their lower density with respect to the North graphs (see Table 1). Due to time constraints, we were able to process only a random subset of the non-planar instances with 31-50 vertices of the Rome set.
|Instances||Density||# Blocks||Number||%||-planar||Not -planar|
|Runtime (minutes)||Solved by||Types of Solutions||Types of Cuts|
About running time, Table 2
reports the average, maximum, and standard deviation over all solved instances in each sample (we recall that the unsolved instances are those that took more than three hours). On average, a computation took less than 4 minutes, while the slowest instance took about 115 minutes. The standard deviation is about one order of magnitude greater than the mean value, but still around a few minutes, which indicates that the running time of1PlanarTester on the solved instances is relatively stable. It is worth noting that the running time on the largest graphs with up to 50 vertices is negligible with respect to the other values reported in the table and also very stable. By inspecting the raw data, we could observe that this behavior is due to the fact that such instances have many blocks (see also Table 1), most of which are solved through preliminary tests (i.e., without entering the backtracking routine) or are solved by backtracking but are very small.
Table 2 also reports some statistics about the computations, which may help to better understand the conditions that mostly influence the behavior of the backtracking algorithm. The fifth column shows the percentage of instances for which the algorithm needed to run the backtracking procedure, i.e., those for which the preliminary tests did not suffice. Many of these instances are in the subsets Rome -, Rome -, and North -. The columns Types of Solutions report the distribution of the conditions that led to a positive instance during an execution of the backtracking algorithm: Satur means that a solution was found by edge saturation, i.e., the subgraph induced by the current partial solution coincides with and the graph was planar; Compl means that a solution was found by running the completion subroutine on and again was planar (refer to Algorithm 1). The data show that this second condition is much more frequent than the first one. We remark that in the set North - we only solved those instances that did not require the backtracking algorithm, thus in this case we have 0% both on Satur and on Compl. The columns Types of Cuts report the distribution of the cut conditions throughout a backtracking computation; they represent conditions that violate a valid solution: DEC represents a double edge crossing; KET represents a kite edge crossing; Nonplanar means that was nonplanar. We observe that the most frequent type of cuts is an edge crossed twice. Concerning the other two types, on the Rome set the Nonplanar condition is on average more frequent than the KEC condition, while we observe an inverse behavior on the North set. This seems to be partially related to the higher density of the North graphs, which intuitively yield a higher number of kite edges.
|Crossings per Graph||Crossing Ratio|
|1PlanarTester||OGDF||1PlanarTester / OGDF|
About the number of crossings, Table 3 reports the average, maximum, and standard deviation over all solved instances in each sample. Both 1PlanarTester and OGDF produced drawings with very few crossings on average. We observe that the North graphs yield more crossings than the Rome graphs, which still reflects the more challenging nature of the North set. Furthermore, the average over all ratios between the crossings made by 1PlanarTester and those made by the OGDF planarizer is below 1.78 (last column in the table). This indicates that, on the solved instances, restricting the number of crossings per edge does not affect too much the total number of crossings.
Concerning G2, Table 1 reports the percentage of solved instances divided by -planar and not -planar. We recall that we removed all planar graphs from our benchmarks. All solved instances in the Rome set are -planar, while the North graphs contain a percentage of non--planar instances varying between 11% and 43% over the different samples. The fact that in both sets the percentage of -planar graphs is greater than the percentage of not -planar graphs may also suggest that the unsolved instances are more likely to be not -planar. To substantiate this hypothesis, we ran our algorithm on some graphs that are not -planar but become -planar after removing a few edges; these graphs have been generated by using minimal non-1-planar graphs described in [KM13]. The algorithm could not solve any of these instances within three hours, which confirms that our backtracking routine is not very effective on graphs having this kind of structure.
5 Conclusions and Future Research Directions
We investigated the feasibility of a practical algorithm for 1-planarity testing and embedding. Our contribution provides initial indications that may stimulate further research on the design of more sophisticated approaches for the -planarity testing problem. Among the many directions that can be explored to improve the efficiency we suggest the following:
A bottleneck of our algorithm is its encoding scheme. One can try to reduce this size to , by using a balanced separating curves approach like that described in [DBLP:journals/jgaa/BannisterCE18]. This would allow us to treat larger instances, although it is unclear how to exploit this tool to design an encoding scheme that can be effectively integrated into a backtracking strategy.
More sophisticated rules can be studied to prune a subtree or to complete a partial solution during a backtracking execution. For example, can one use SPQR-trees to test different triconnected components independently and then merge them together?
One can study an ILP formulation for the problem. To this aim, the crossing minimization strategy in [DBLP:conf/esa/ChimaniMB08] may provide useful insights to compute crossing minimal 1-planar (or more in general -planar) embeddings.
A further research direction opened by our work is to extend our experiments to label a larger set of instances. For example, one could experimentally estimate the probability that a graph generated with a random or with a scale-free model is-planar. Finally, the recognition problem is NP-complete for other families of beyond-planar graphs, such as fan-planar graphs (see [DBLP:journals/algorithmica/BekosCGHK17, DBLP:journals/tcs/BinucciGDMPST15]), and hence it would be interesting to design practical recognition algorithms also for these families.
We thank Giuseppe Liotta for useful discussions.