A Fast Algorithm For Finding Hamilton Cycles

Transcription

1 A Fast Algorithm For Finding Hamilton Cycles by Andrew Chalaturnyk A thesis presented to the University of Manitoba in partial fulfillment of the requirements for the degree of Masters of Science in Computer Science Winnipeg, Manitoba, Canada Summer 2008 c Andrew Chalaturnyk 2008

2 Abstract This thesis is concerned with an algorithmic study of the Hamilton cycle problem. Determining if a graph is Hamiltonian is well known to be an NP -Complete problem, so a single most efficient algorithm is not known. Improvements to the understanding of any single NP -Complete problem may also be of interest to other NP -Complete problems. However, it is an important problem and creating an algorithm which is efficient for many families of graphs is desirable. The majority of the work described within starts with an exhaustive backtracking search, called the Multi-Path method and explores two main areas: Creating an algorithm based upon the method which is both efficient in time and memory when implemented in code. Developing a pruning condition based upon separating sets that may be found during the execution of the method in order to maximize the amount of pruning possible. Both of these areas represent a significant evolution of previous work done with the method. The resulting algorithm is extremely fast and requires only O(n + ε) space in memory, where n is the number of vertices and ε is the number of edges. Additionally a class of graphs based on the Meredith graph is described. These graphs have a property which significantly affects the performance of the multi-path method. The insights that follow from this property lead to a reduction technique that further improves the algorithm in a significant way when determining if graphs ii

3 Abstract iii are non-hamiltonian. Further directions for study along the lines pursued by these insights is discussed. Testing of the algorithm is performed on a family of graphs known as knight s move graphs, which are known to be difficult for algorithms dealing with Hamilton cycles.

4 Contents Title Page Abstract Table of Contents i ii iv 1 Introduction 1 2 Graph Theory Concepts Basic Terminology Graphical Representation Paths and Cycles Connectivity Bipartitions Isomorphism The Multi-Path Method An Exhaustive Search Incident Edges about v Limiting Edges Multi-Path Method Simplifying the Search Reducing G Removal of Branching Edges The Search Space Example: Petersen Graph Considerations for Algorithm Design Data Structures Adjacency Matrix and Lists Degree Values and Virtual Edges Segment and Cycle Storage Reducing Time and Space Overhead iv

5 Contents v 5.3 Detecting Stopping Conditions Tracking Forced Vertices Designing the Multi-Path Algorithm Efficient Reduction and Recovery Extending Segments Managing Removed Edges Unwinding Segments and Restoring State Vertex Selection Navigating the Search Space using a Turing Machine State of the Tape Edges from E(S) Status Flags represented by the Bit-Field Moving Read/Write Head Moving Right Moving Left Switching Directions Implementation of the Multi-Path Algorithm Data Graph State Removed Edges Tape State Code Running the Turing Machine Extending Segments and Branching Restoring State and Removing Branching Edges Pruning Algorithm Pruning Mechanism Testing for Separating Sets Overview of Previous Test Increasing ω(g r K) K Reducing the Frequency of Testing Top Down vs. Bottom Up Testing Testing at the Extremities of the Search Space Ensuring a Full Climb up the Search Tree Implementation Data Structures Code

6 Contents vi 10 Reduction Technique Hamiltonian Subgraphs Half-Bipartite Structures Finding Reducible Complete Half-Bipartite Structures Reducing G False positives: an Unwanted Side Effect of Reduction Analysis and Verification Verification Analysis Knight s Move Graphs Complete Graphs Reduction Technique on the Meredith Graph Further Work Multi-Path Algorithm A Closer Examination of Vertex Order Algorithm for Directed Graphs Fine Tuning for the TSP A Work-Stealing Parallel Implementation Pruning Algorithm Constructing Components for Better Separating Sets Reduction Technique Finding More Reducible Subgraphs Reconstructing Hamilton Cycles in G α A Multi-Path Code 99 A.1 Data Types A.2 Extending Segments A.2.1 Support Routines for Extending Segments A.2.2 Main Routine for Extending Segments A.3 Extending Branches A.4 Restoring Graph B Pruning Algorithm 115 B.1 Data Types B.2 Depth First Search (DFS) B.2.1 Main DFS algorithm B.2.2 Routine for calculating Component / Separating Set differences. 119 B.3 Turing Machine for Pruning Condition B.3.1 Pruning B.3.2 Main Turing Machine Code

7 Chapter 1 Introduction This thesis describes work that improves and extends upon an algorithm for finding Hamilton cycles in graphs. Named for Sir William Rowan Hamilton, the popularity of the problem of finding Hamilton cycles originates from the Icosian Game invented by Hamilton. The object of the game is to find a continuous route along the edges of a dodecahedron that visit all of its corners exactly once and ends at the starting corner. A graph can be visualized as a collection of points, or vertices, connected by lines, or edges. A cycle is a walk along a path of edges visiting vertices until ending at the originating vertex. A Hamilton cycle is a cycle that visits every vertex in a graph exactly once. The difficulty of finding Hamilton cycles increases with the number of vertices in a graph. Not all graphs contain a Hamilton cycle, and those that do are referred to as Hamiltonian graphs. Determining if a graph is Hamiltonian can take an extremely long time. In the broad field of Computer Science the problem of determining if a graph is 1

8 Chapter 1: Introduction 2 Hamiltonian is known to be in the class of NP-complete problems. Simply put, the time it takes to solve NP-complete problems can rise exponentially with the problem size. Another NP-complete problem very closely related is the Traveling Salesman Problem. The nature of the Hamilton Cycle problem is such that no single most efficient algorithm is known [Van98]. In [Van98], Vandegriend provides a survey of different Hamiltonian algorithms and the problems encountered that can cause extreme slowdowns during algorithm execution. Any improvements that can be made to speed up solutions to both determining if a graph is Hamiltonian and finding Hamiltonian cycles are of interest. Also, because

9 Chapter 1: Introduction 3 of the complexity of the problem, improvements may reveal more insight into the qualities of graphs that make them Hamiltonian. Due to the nature of NP-complete problems, all problems in the class NP may benefit from improvements or insights found. The multi-path method introduced by Rubin [Rub74] and Christofides [Chr75] is an exhaustive search for all possible Hamilton cycles that can be found within a graph. The work by Kocay [Koc92], implements the method with an algorithm that overlays additional pruning capabilities into the search. Under certain conditions the improvements in [Koc92] can allow for significant pruning of the search tree generated by the multi-path algorithm. This thesis extends and improves on the work in [Koc92] with two major improvements and introduces a method for dealing with certain special graphs that can lead to exponential increases in the performance of the algorithm. As with the work from [Koc92], the work described here is for finding Hamilton cycles in undirected simple graphs. The first of the improvements is to the design and implementation of the algorithm in [Koc92]. These improvements result in reduced runtime and decreased memory use and are significant code optimizations. The memory reduction is by an order of magnitude in terms of the number of vertices in the graph. The runtime improvement is linear with respect to the complexity and size of the graph. The second of the improvements is to the scope and frequency of the pruning enhancement from [Koc92]. The new method focuses on a recursive graph reduction technique that can be ap-

10 Chapter 1: Introduction 4 plied repeatedly to graphs that contain subgraphs with a certain interesting property. The contents of this thesis is organized in the following way: Chapter 2 introduces and describes common graph theory concepts that are used throughout this work. Chapters 3 and 4 introduce and describe the multi-path method in detail. Chapter 5 discusses algorithm details with respect to the required data structures needed for the new multi-path algorithm and compares against those needed by the previous algorithm from [Koc92]. Chapters 6, 7 and 8 describe the new multi-path algorithm and its improvements over its predecessor from [Koc92]. Chapter 9 introduces the pruning technique and describes the improvements to it from [Koc92]. Chapter 10 introduces the reduction technique and shows how it can be used to speed up detection of certain non-hamiltonian graphs. Chapter 11 discusses how the work for this thesis was verified and provides some analysis of the improvements introduced. Chapter 12 discusses some further directions research into this problem could take, based upon the work provided by this thesis.

11 Chapter 2 Graph Theory Concepts 2.1 Basic Terminology A graph G is composed of a set V (G) of vertices and a set E(G) of edges. It is assumed that n = V (G) and ε = E(G). Every edge e E(G) is composed of a set e = {u, v} where u, v V (G). In undirected graphs, edges are unordered pairs of vertices. In directed graphs, edges or arcs are ordered pairs of vertices. Simple graphs do not allow edges to repeat and the vertices in an edge must be distinct. Only simple graphs are considered here. The edges from E(G) which contain v are said to be incident to v. The two vertices incident to an edge are said to be adjacent. Given the graph G and two vertices u and v from V (G), u v means that u and v are adjacent. u v indicates that u and v are not adjacent. 5

12 Chapter 2: Graph Theory Concepts 6 Figure 2.1: Three drawings of the Petersen graph. 2.2 Graphical Representation As an abstraction, a graph G is represented mathematically as composed of two sets V (G) and E(G). Visually this can be represented as a collection of points, V (G), connected by lines, E(G). The co-ordinates of the points or the shape of the lines do not matter. The same graph G can therefore be represented visually by an infinite number of drawings. Depending on the drawing, different attributes of a graph may become more apparent to the observer. For instance the drawing on the right hand side of figure 2.1 suggests that there may be a Hamilton cycle in the Petersen graph. While the Petersen graph is not Hamiltonian, using the same graphical orientation of fitting adjacent vertices around a circle is a useful representation to help in finding Hamilton cycles in relatively small graphs using simple observation. 2.3 Paths and Cycles A path in G is defined to be an ordered sequence of distinct vertices such that every vertex in the sequence is adjacent to the vertex that immediately precedes it and adjacent to the vertex that immediately follows it. This can be written as

13 Chapter 2: Graph Theory Concepts 7 u 1 u 2 u k, where u 1 through u k are all distinct vertices from V (G). A cycle in the G is defined as a path in G that terminates on the starting vertex. The number of edges in a cycle is equal to the number of vertices. 2.4 Connectivity Figure 2.2: Example of a graph with a separating set. If a path exists between two distinct vertices, v, u V (G), they are called connected. A graph G is connected if every pair of distinct vertices from V (G) is connected. A component in G is a maximal subgraph of G that is connected. A graph with more than one component is called disconnected. In a connected graph G, a separating set is a set of vertices from G that when

14 Chapter 2: Graph Theory Concepts 8 removed, disconnects G. A separating set, K, with m = K, is called minimum when there is no other separating set in G smaller than m. A cutpoint in G is a single vertex from G that forms a separating set in G. 2.5 Bipartitions A bipartition exists in a graph G, if V (G) can be divided into two distinct sets, A and B, where A B = and A B = V (G), and no two vertices from the same set are adjacent. A graph with a bipartition is referred to as bipartite. 2.6 Isomorphism An isomorphism is a one-to-one mapping between vertices of two graphs that preserves the connections, or edges, between vertices. If an isomorphism exists, the two graphs are said to be isomorphic. The three drawings of the Petersen graph in figure 2.1 are isomorphic to each other.

15 Chapter 3 The Multi-Path Method This chapter describes the multi-path method for finding Hamilton cycles. While it was originally proposed by Rubin in [Rub74], the description of the multi-path method within this chapter is a synthesis of the descriptions from [Koc92, Chr75] as well as the work described by this thesis. To facilitate understanding of both the multi-path method and the enhancements to it some preliminary ground must be covered. Section 3.1 describes a truly exhaustive method of finding Hamilton cycles. Sections 3.2 and 3.3 describe two improvements that can be used to reduce the amount of search required and section 3.4 combines the results of the improvements to describe the multi-path method. Finally in section 3.5, a few refinements that appear in [Koc92] are described and added to the method. Assume that all graphs G to be considered are non-trivial with respect to the Hamilton Cycle problem, implying that all vertices in any graph will be at least of degree three. 9

16 Chapter 3: The Multi-Path Method 10 The algorithms described in this chapter are partial algorithms used as a tool to convey general information about the multi-path method. Procedures that are not fully defined can be implicitly understood given their names and context of use. Each undefined procedure is assumed to be implementable by some algorithm with a polynomial overhead in time and space. 3.1 An Exhaustive Search By definition all vertices from V (G) must be part of any Hamilton cycle of G. The edges that make up any Hamilton cycle are what must be varied. One method to determine if a graph is Hamiltonian is to generate all combinations of n edges from E(G) until a Hamilton cycle is found or until no combinations are left. In the worst case, the number of edge combinations to try is ( ε n). The order in which edges are chosen with this method is not restricted by the order in which they would be traversed in a Hamilton cycle. When testing if the chosen edges form a Hamilton cycle the correct traversal order will implicitly be found. Let S be the subgraph of G describing a partial Hamilton cycle formed by choosing m edges, m < n, to be on the Hamilton cycle. S forms a subgraph in G, with E(S) and V (S) its edges and vertices. Obviously m = E(S). When m = n we have a candidate subgraph that will form a cycle iff G is Hamiltonian. Algorithm briefly describes a recursive procedure for generating and testing all possible combinations of edges up to the first Hamilton cycle found. The algorithm works by recursively fixing an edge within S and attempting all

17 Chapter 3: The Multi-Path Method 11 possible edge combinations for the remaining n m positions to be filled with the current edges available. IsCycle verifies if E(S) describes a Hamilton cycle and ChooseEdge returns some unspecified edge from the remaining edges at the current depth in the search space. The recursive nature of the procedure allows for the search space of the algorithm to be modeled as a tree. In this case the depth is bounded by n and the number of leaves is bounded by ( ε n). Each node in the search tree represents this fixed position in S and the branches represent the current edge in that position. Algorithm 3.1.1: HCEdges( n, E, S ) All parameters passed by value. comment: Initially n = V (G), E = E(G) and S is empty. result = true G is Hamiltonian if E(S) = n then return (IsCycle(S)) while E = e ChooseEdge(E) do E E e if HCEdges( n, E, S + e ) then return ( true ) return ( false ) This type of algorithm is referred to as a backtracking algorithm. The ability to return to a specific spot while searching and ensuring that all possible permutations of decisions are attempted from that point characterize these kind of algorithms.

18 Chapter 3: The Multi-Path Method Incident Edges about v Algorithm blindly generates edge combinations. If instead the focus is now placed on vertices, a significant fact emerges. All possible edge combinations about v V (G) use one of the deg(v) edges incident to v. There are up to ( ) deg(v) 2 ways of selecting pairs of incident edges in any possible cycle about v. Algorithm is a modification of algorithm to instead use vertices chosen by ChooseVertex, in the selection of edges. These vertices are referred to as anchor points. Instead of branching out with all remaining edges at the current spot in the search space, only edges incident to the anchor vertex v are chosen for branches. Similar to ChooseEdge from the previous algorithm, ChooseVertexEdge returns some unspecified edge incident to v from the remaining edges at the current depth in the search space. Algorithm 3.2.1: HCVertexEdges( n, V, E, S ) All parameters passed by value. comment: Initially n = V (G), V = V (G), E = E(G) and S is empty. result = true G is Hamiltonian if E(S) = n then return ( IsCycle(S) ) v ChooseVertex(V) if v V (S) then V V v while deg(e, v) 0 e b ChooseVertexEdge( v, E ) do E E e b if HCVertexEdges( n, V, E, S + e b ) then return ( true ) return ( false )

19 Chapter 3: The Multi-Path Method 13 As seen in the algorithm a given vertex may be chosen twice when descending towards a leaf in the search space. This allows for the ( ) deg(v) 2 possible edge pairs about v to be explored iteratively and dramatically reduces the breadth of the search tree by limiting the total number of leaves while not removing any possible Hamilton cycle that could be found. The order and manner in which ChooseVertex picks vertices in V will be discussed later in section Limiting Edges Edge choices from E(G) can be limited based on the edges already chosen. For any v in a cycle, only two edges incident to v may be used and deg(v) = 2 with respect to the subgraph the cycle defines in G. Definition (segment). A segment is a path in G. Segments do not overlap or share endpoints with other segments. Let S i be a subgraph in G defined by some segment and let S = S 1... S k be the k segments formed from E(S). V ex (S) denotes the external vertices, or segment endpoints, and V in (S) denotes the internal degree 2 vertices with respect to S. As in the previous section, m = E(S). When adding another edge to S the choice of e m+1 E(G) is now limited to the edges of E(G V in (S)), as no more edges incident to the internal vertices in S can be chosen and still satisfy the degree 2 restriction. Inductively it can be seen when m starts at 0 and approaches n, only two edges

20 Chapter 3: The Multi-Path Method 14 incident to a given v V (G) can ever be in E(S). The main idea of the multi-path method is to construct a Hamilton cycle by piecing together the disjoint segments formed by the edges in S. 3.4 Multi-Path Method The multi-path method uses the two ideas from sections 3.2 and 3.3 to dramatically reduce the search space of algorithms and The selection of a new edge will eventually cause a chain reaction as each new v V in (S) may induce conditions that require unchosen additions to E(S). Let the vertex and edge sets for the derived graph M be: V (M) = V (G) V in (S) (3.1) E(M) = E E(G V in (S)) (3.2) Where E is the set of edges remaining in G to be selected for E(S). More on E will be described later in this section. For now, assume that E has been inherited from the parent node in the search space. E(M) represents the remaining edges available that may be added to E(S) at the point in the search space it is defined. Deriving M may result in one or more vertices in V (M) that no longer have any choice in what edges are placed into E(S), leading to the following definitions: Definition (forced vertex). A forced vertex is a vertex v V (M) where deg(v) = 2 when v V (S) or deg(v) = 1 when v V ex (S).

21 Chapter 3: The Multi-Path Method 15 Definition (forced edge). An forced edge is an edge e E(M) where v e and v is a forced vertex. Forced vertices must be added to V in (S). These additions are accomplished by adding forced edges one at a time to E(S). The chain reaction occurs when the two vertices incident to a forced edge both belong to V ex (S). In this situation either a cycle is found or two segments are forced to merge. The two vertices incident to the forced edge that caused two segments to merge are called junction vertices and now belong to V in (S). Any edges not in E(S) that are incident to the junction vertices must be removed from M and may result in one or more additional forced vertices. Definition (consistent). M is said to be consistent if for all v M, deg(v) > 1 when v V ex (S) and deg(v) > 2 when v V ex (S). The chain reaction continues until M stabilizes and is found to be consistent or until a stop condition occurs. A stop condition can occur in three situations: Stop Condition (1A). v V ex (S) and deg(m, v) = 0 Stop Condition (1B). v V ex (S) and deg(m, v) = 1 Stop Condition (2). For some segment S i S there exists a forced edge, e E(M), such that the addition of e to S i would form a cycle. In this case if m = n a Hamilton cycle has been found. If m < n no Hamilton cycle can exist in the current S.

22 Chapter 3: The Multi-Path Method 16 After each change to S a stop condition may occur in M. Algorithm describes this process of forcing edges into S and testing for a stop condition. Algorithm 3.4.1: ForceEdges( G, V, E, S ) All parameters passed by value. comment: Returns the set { V, E, S, stop } where stop is a boolean flag indicating a stop condition. E M E(G V in (S)) E V M V (G) V in (S) while not IsConsistent(V ex (S), E M ) S S + GetForcedEdge(V ex (S), E M ) E do M E(G V in (S)) E V M V (G) V in (S) if IsStopCondition(S, E M ) then return ( {,,, true } ) V V V M E E M return ( { V, E, S, false } ) Now that the process of forcing edges into S has been described, the rest of the method follows the same design as algorithm Using the first improvement from section 3.2, an anchor point v is chosen from V (M) and a single edge, e b, incident to v is selected from E(M) and added to E(S). This edge is referred to as a branching edge, and is a reflection of one of the two locations in the search space where choice is allowed in the algorithm. The other being the selection of anchor points. The overall shape and size of the search space is controlled by these choices. After removing e b, M may no longer be consistent and have edges to be forced into

23 Chapter 3: The Multi-Path Method 17 S, ultimately reducing the number of anchor points and branching edges to choose from. Algorithm describes the multi-path method using the ideas given so far. As previously mentioned and used in the previous algorithms, E represents the edges remaining in G that can be chosen for S. Edges are removed from E in two ways. The first is by the G V in (S) reduction. The second is by removal of branching edges, e b, that have had all possible combinations of E(S) attempted for the current location in the search space. Once a branching edge has been used, no more cycles can be found that contain that edge when continuing to search at the current depth in the search tree. Algorithm 3.4.2: HCMultiPath( G, V, E, S ) All parameters passed by value. comment: Initially V = V (G), E = E(G) and S is empty. result = true G is Hamiltonian { V, E, S, stop } ForceEdges( G, V, E, S ) if stop then return ( IsEqual( V (G), E(S) ) ) v ChooseVertex(V) while deg(e, v) 0 e b ChooseVertexEdge( v, E ) do E E e b if HCMultiPath( G, V, E, S + e b ) then return ( true ) return ( false ) As can be seen from the use of the stop conditions, no IsCycle test is required with the multi-path method. This follows from the inductive reasoning provided at the end of section 3.3. If the algorithm ever allows E(S) to contain n edges, a

24 Chapter 3: The Multi-Path Method 18 Hamilton cycle will be found. Taken together, both of the improvements reduce the total breadth and average depth of the search space. This is one of the major benefits of the multi-path method. 3.5 Simplifying the Search A couple of minor improvements to the multi-path method are now described that focus on simplifying movement through the search space. Both of these improvements are used by [Koc92]. Section introduces a reduction that can be applied to G in order to direct the path through the search space more efficiently. Section removes redundant recursive calls to the multi-path method at a given node in the search space. Algorithms and reflect these improvements, and are the basis for the multi-path algorithm developed and presented later on in this work Reducing G At any given node in the search space there is the original graph G, the set S of segments derived from the m edges selected so far and the derived graph M as described by equations 3.1 and 3.2. A reduced graph G SE defined by M and S may be defined for any point in the search space.

25 Chapter 3: The Multi-Path Method 19 V (G SE ) = V (M) (3.3) E(G SE ) = E(M) + E v (S) (3.4) E v (S) is a set of virtual edges created to connect the segment endpoints in M. Each virtual edge represents a single segment from S at the current point in the search space. Let the edge {u,v} E v (S) be a virtual edge representing the segment S i S, then u, v V ex (S i ). Virtual edges may be thought of as the connections between unsearched sections of the graph. They may not be forced and can not be chosen for any E(S) as they already represent the edges that make up the segments already contained by S. Edges from M may be referred to as real edges. Real edges are what remains of the choices available to E(S) for any descendent point below the current in the search space. Due to equation 3.4 some of the conditions that define forced vertices, consistency and stop conditions can be simplified: Definition (forced vertex). A vertex v V (G SE ) where deg(v) = 2. Definition (consistent). G SE is said to be consistent if for all v V (G SE ), deg(v) > 2. Stop Condition (1). v V (G SE ) such that deg(v) = 1. In algorithms and 3.5.2, the variable G represents the reduced graph G SE.

26 Chapter 3: The Multi-Path Method 20 Ensuring a Simple Graph A consequence of introducing the virtual edges from E v (S) in the forming of G SE is the potential for a virtual and a real edge to share the same endpoints. In this situation G SE would not represent a simple graph. With respect to G, the segment that the virtual edge represents and the real edge would form a cycle in G. As long as this cycle is not a Hamilton cycle, it is safe to remove the real edge, as any descendant point in the search space below the current one will never use the real edge in any Hamilton cycle found. In fact its removal would reduce the size of the tree formed below the current point in the search space. In algorithm it is to be assumed that ReduceGraph would ensure that a simple graph is returned, and any virtual edge takes precedence over a real edge Removal of Branching Edges As seen in algorithm 3.4.2, once a branching edge, e b, has been attempted, it is removed for the remaining branches at the current level in the search space. Since all edge combinations that may exist at that point in the search space which contain that branching edge will have been attempted, it must be removed. This removal may cause an inconsistent G SE. In this case the multi-path method as currently defined, will fail at the first call to ForceEdges for each recursive call to the multi-path method on the remaining branches. It would instead be better to detect if G SE is inconsistent once the recursive call to the multi-path method returns for that branching edge. In algorithm 3.5.2, the

27 Chapter 3: The Multi-Path Method 21 addition of a call to ForceEdges from within the while loop reflects this improvement. Algorithm 3.5.1: ForceEdges( G, S ) All parameters passed by value. comment: Returns the set { G, S, stop } where stop is a boolean flag indicating a stop condition. G ReduceGraph( G, S ) if IsStopCondition( G, S ) then return ( {,, true } ) while not IsConsistent(G) S S + GetForcedEdge(G) do G ReduceGraph( G, S ) if IsStopCondition( G, S ) then return ( {,, true } ) return ( { G, S, false } ) Algorithm 3.5.2: MultiPath( n, G, S ) All parameters passed by value. comment: Initially G = G, and S is empty. result = true G is Hamiltonian { G, S, stop } ForceEdges( G, S ) if stop then return ( n = E(S) ) v ChooseVertex(V (G)) while deg(v) 0 e b ChooseVertexEdge( v, E(G) ) G G e b do if MultiPath( n, G, S + e b ) then return ( true ) { G, S, stop } ForceEdges( G, S ) if stop then return ( n = E(S) ) return ( false )

28 Chapter 4 The Search Space To provide context on where the improvements described in this thesis are focused, this chapter illustrates the search space of the multi-path method. The search trees used to describe the search space are assumed to be traversed in a depth first, left to right manner and are a reflection of the route generated by algorithm A hypothetical example of a search tree is presented in figure 4.1. The larger circular nodes represent the anchor points chosen and the smaller solid points represent vertices removed from G and placed into V in (S). The small diamond shaped leaves of the search tree represent the occurrence of a stopping condition. Anchor points that exist close to the extremities of the search tree are referred to as leaf nodes. A leaf node is an anchor point in the tree that only contains leaves as descendants. The edges joining points in the search tree do not correspond to edges added to E(S). The dashed edges between points in the tree do however indicate that a 22

29 Chapter 4: The Search Space 23 branching edge was chosen at that point in the search space. The rightmost solid edge descending out of an anchor point in the search tree represents an inconsistent state occurring due to the removal of a branching edge from G. 4.1 Example: Petersen Graph The search tree for the non-hamiltonian Petersen graph is shown in this example. This graph is used as an example because it terminates after only finding six stopping conditions. Figure 4.2 represents the search tree for the Petersen graph. The labeled vertices on the drawing of the Petersen graph correspond to the labels on the search tree. In the case of the Petersen graph, each of the six leaves terminate with stop condition 1 being encountered. Table 4.1 describes the state of E(S) at each of the six leaves in the search tree moving from left to right. Note how the branching edges correspond to the anchor points from the tree, and how E(S) behaves like a stack when moving between the branching edges. In figure 4.3 the state of G is represented for each stable state after the branching edge has been added to E(S) for each branching edge down to the leftmost leaf. Note stop condition 1 is detected for vertex 4 after branching edge {2,3} has been added. Also note that virtual edge {8,9}, requires the removal of the corresponding real edge, leading to the addition of vertex 7 to V in (S). As a comparison to the first method presented for finding Hamilton cycles, this

30 Chapter 4: The Search Space 24 Table 4.1: E(S) at the leaves of search tree for the Petersen graph. Branching edges are bold. Edge # {1,3} {1,3} {1,3} {1,3} {1,7} {1,7} 2 {1,7} {1,7} {1,10} {1,10} {1,10} {1,10} 3 {9,10} {9,10} {7,8} {7,8} {2,3} {2,3} 4 {6,10} {6,10} {4,7} {4,7} {3,5} {3,5} 5 {2,3} {3,5} {2,3} {3,5} {2,4} {2,9} 6 {5,6} {2,4} {5,6} {2,4} {8,9} {4,7} 7 {5,8} {2,9} {5,8} {2,9} {9,10} {4,6} 8 {7,8} {5,6} {2,4} {9,10} {4,7} {5,6} example of the multi-path method only generates 6 leaves, using only 5 points where a branching is directly controlled by the algorithm. The first method would have generated ( 15 10), or 3003 leaves, and many more branchings would have to be controlled directly by the algorithm.

31 Chapter 4: The Search Space 25 Figure 4.1: Hypothetical search tree generated during the search for Hamilton cycles for some unknown graph using the Multi-Path method. Typically the tree generated would be extremely large and would not be practical to display.

32 Chapter 4: The Search Space Figure 4.2: Full search tree of the multi-path method for the Petersen graph Figure 4.3: State of G after each branching edge down to the leftmost leaf.

33 Chapter 5 Considerations for Algorithm Design Before progressing further with the design of the multi-path algorithm, some considerations with respect to data structures and implementation details for [Koc92] must first be mentioned. The implementation for [Koc92] is similar to what has already been introduced for the multi-path method in algorithms and It is a recursive procedure that can be configured to either stop at the first Hamilton cycle found, or to visit each possible Hamilton cycle by examining the entire search space. If a Hamilton cycle is treated as a stopping condition for a branch instead of a stopping condition for the algorithm, this visiting operation is possible in the multipath method. 27

34 Chapter 5: Considerations for Algorithm Design Data Structures If each vertex is labeled with a positive integer value, it can be used both as an identifier and as an index in lookup tables, arrays and other data structures. The special identifier of 0 is reserved, and can have specific meaning depending on use. Typically this use will result in the 0 th entry from any table/array to be used either as a temporary store or go unused. Entries in a table/array structure that use the 0 value in an entry where a vertex identifier is expected typically mean the indexed value does not belong to a set tracked by the structure Adjacency Matrix and Lists Two ways to store the edges of a graph are by using either a matrix, refered to as an adjacency matrix, or a linked list construct, called an adjacency list. An adjacency matrix is an n x n data structure that uses the index of two vertices to determine the existence of an edge. An adjacency matrix however has two main drawbacks: it is slow to determine all of the edges incident to a given vertex and it takes O(n 2 ) of memory to store. A linked list has the drawback of not being able to quickly test if two vertices are adjacent. The adjacency list for a given vertex must be scanned until the other vertex is encountered. The benefit of an adjacency list is when the traversal of all edges of a given vertex is all that is required. Additionally with adjacency lists, the entire graph is stored in O(ε) space. In [Koc92] both of these structures are used, however as will be shown in later

35 Chapter 5: Considerations for Algorithm Design 29 chapters, there is need only for the adjacency lists Degree Values and Virtual Edges Storing the current degree value in a lookup table/array is extremely useful, as it avoids the overhead of recalculating them. Depending on the data structure used to represent edges, the time overhead of recalculating is at least O(deg(v)). A lookup table reduces this to O(1). The tradeoff here is that more memory is required to store the degree value of each vertex. One very useful aspect of maintaining the degree array, is that it becomes trivial to test if a vertex is still within the current G, as it must have a non-zero value in the array. With respect to the multi-path method, the extra virtual edge that may exist for any vertex can be stored using an array of vertices. At any point in the search space, the state of E v (S) can be reflected by an array with either a 0 value for vertices not in S or a vertex value for the other end point of a virtual edge. As will be seen later, this way of representing the virtual edge is preferable to inserting a new edge into an adjacency list Segment and Cycle Storage One result of the work done in this thesis, is that it is unnecessary to store the current segments and partial cycles during the running of the algorithm. Instead only directly maintaining the stack of edges in E(S) is necessary, as both segment and cycles can be directly derived from the contents of E(S).

36 Chapter 5: Considerations for Algorithm Design 30 However, in [Koc92] maintaining them is an integral part of the algorithm. To this effect a single array of vertices is used for segments and two arrays of vertices are used to track the current partial and potential Hamilton cycle. For the segments, a merge-find like structure is maintained in the array. More on the merge-find structure can be found in [Wei95]. For the partial Hamilton cycle, the two arrays use the entries to point to the vertices to the left and to the right of a given vertex. 5.2 Reducing Time and Space Overhead As noted in the header comments for each of the previous algorithms described, procedure arguments are passed by value. The overhead required to pass variables by value increases the memory requirements by an order of magnitude. Additionally, passing by value implies that time must be spent copying data. The expected overhead of copying would be in the range of O(n + ε) per branching edge in the search space. To limit the time and space penalties of copying by value, [Koc92] uses an inplace reduction on G. This means that a reference to the attributes in G is available at all points during the running of the algorithm and the original state of G is not known until the algorithm finishes. Only the current reduction of G is known and is equivalent to that given by equation 3.4. This in-place reduction is referred to as G r. To accomplish this in-place reduction, there must be a way to reverse changes to G r at each point in the search space, so as to ensure that the state of the data for each function call is equivalent to that of the pass by value model. The method used

37 Chapter 5: Considerations for Algorithm Design 31 to restore G r for the work described in this thesis can be found in the next chapter and differs from the way it is done in [Koc92]. One of these differences is in the extent of removing the pass by value data. While limiting the expense of retaining a complete copy of the graph state per node, in [Koc92] there is still a memory overhead of O(n 2 ) consisting of degree information and segment information. This is the remaining data that is still passed by value during branching operations, with O(n) cost in time and space for each node. Without the in-place reduction, memory overhead would be O(n 3 ) in space. This remaining overhead is eliminated by the work described in this thesis and the entire state of the algorithm only requires O(n + ε) in space to function. 5.3 Detecting Stopping Conditions The detection of a stopping condition has very little overhead. The algorithm forces edges into E(S) one at a time, and a stopping condition can be detected while dealing with each edge. Assume the current forced edge is e. The second stopping condition is easy to detect by simply checking segment membership of each of the two vertices incident to e. If both vertices belong to the same segment, a cycle is forced and a stop flag is raised. This can be done with an time overhead of just O(1). The first stopping condition has slightly more overhead than the second. A forced vertex never has any more edges to remove from G r, but the other vertex v incident to e may already be an endpoint for another segment. In this case, v must be added to V in (S) and all remaining edges incident to v must be removed from G r. The other

38 Chapter 5: Considerations for Algorithm Design 32 vertices incident to each of these removed edges must have their degree values reduced by one. If the degree value for any of these vertices is reduced to one, a stopping condition has occurred. The overhead here is just O(deg(v)), per non forced vertex pushed into V in (S). 5.4 Tracking Forced Vertices Instead of scanning each vertex in G r for forced vertices each time the ForceEdges method is called, it is possible to record the current forced edges in a list for quick referencing later. As mentioned with detecting stopping conditions, changes to S all occur one edge at a time. When removing the edges incident to each new vertex in V in (S), the changes to the degree values for the other vertex can also be used to detect when a vertex has become forced. Each of these vertices can be added to a list for later processing. The list construct used in [Koc92] is a queue. In the implementation for the multi-path algorithm for this thesis a stack is used instead. A stack was chosen because by marking the beginning of the stack with a 0 value and not using it, no length variable is needed. A pointer to the current position is all that is required when a stack is used in this way. As the order in which forced edges is unimportant with respect to the final consistent G r, any abstract data type for managing list addition and removal can be used here. The order in which forced vertices are removed from the list becomes important when trying to detect stopping conditions sooner and more sophisticated structures

39 Chapter 5: Considerations for Algorithm Design 33 could be used to enable this, however this is beyond the scope of the work done here and further work could yield some interesting results.

40 Chapter 6 Designing the Multi-Path Algorithm Algorithms and used to describe the multi-path method are enough to provide a broad recipe on how to go about creating a complete multi-path algorithm. This chapter is focused on fully developing the key aspects of the algorithm with respect to efficiently managing G r and S, as well as the selection of anchor points. The implementation of the multi-path algorithm resulting from the work described in this thesis was developed incrementally, as a series of refinements and data structure changes, each of which brought an increase in efficiency and speed. By studying the effects of each of the changes on various graphs, the techniques were continually improved, and new approaches suggested themselves. This chapter and the next represents the finalization of the work in this thesis on the stand alone portion of the multi-path algorithm. Recall that G r was introduced in the previous chapter as a representation of G 34

41 Chapter 6: Designing the Multi-Path Algorithm 35 from algorithm 3.5.1, with the difference being that it is the continuously changing instance of the original graph G that is not passed by value during the execution of the multi-path algorithm. As mentioned in the last chapter, passing by value increases both time and space overhead to the algorithm that would be best left avoided if possible. In order to design an algorithm that completely removes the pass by value requirements of movement between consistent states of G r, the first section of this chapter is concerned with the mechanics of changes to S and G r during movement up and down the search space of the multi-path algorithm. This also includes an improved algorithm for creating and extending the segments in S over the one used in [Koc92]. The final section of this chapter deals with the order in which anchor points are chosen. This can have a profound effect on the shape and size of the search space to be navigated by the algorithm. 6.1 Efficient Reduction and Recovery The reduction and recovery of G r between branching edges in the search space consumes the majority of the time spent running the algorithm. The improvements described in this section attempt to reduce the internal changes that are required when transforming a graph from one state to another, while additionally removing the remaining pass by value requirements from [Koc92]. By changing how edges are added to S it is possible to reverse the changes to G r as well as restore the data structures storing segment and degree information, subsequently reducing the memory footprint required by this portion of the algorithm

42 Chapter 6: Designing the Multi-Path Algorithm 36 by a factor of n. This results in a memory footprint of O(n+ε) for the entire algorithm. Additionally the total time overhead of managing G r is reduced to O( S), where S is the number of edges added to E(S) between branching edges. This is instead of the O(n + S) from the previous version. Section describes a different way of creating and extending segments in S that improves on what has been used previously. The improvement here over [Koc92] is difficult to quantify as it is heavily dependent on the structure of the graphs searched, however at worst it will be equivalent in steps required. Section describes how removed edges from G r are managed, and section describes how the state of G r is restored. The process of restoring G r used here is the reason for the O( S) claim Extending Segments Up to this point changes to segments in S occur one edge at a time. In this way there are three possible results when adding a forced or branching edge to E(S); either a segment is created or extended, or two segments will be merged into a single segment. Each time E(S), E v (S) and G r must be updated to reflect the new reduction. The process is repeated until no more forced edges remain in G r. Extending Segments from Forced Vertices via Paths The new approach changes focus from single edges to paths that can be extended from forced vertices in G r. Extending segments using a branching edge and its corresponding anchor point is a special case of this approach and is described at the end of

43 Chapter 6: Designing the Multi-Path Algorithm 37 P u P v e S i 1 u v e S i+1 v e S i G r Figure 6.1: Segments S i 1, S i, and S i+1 before extension of Si via forced vertex v. Forced vertices are represented by the solid symbols. The virtual edge {u,v} representing S i is labeled with a e S i and the other virtual edges are labeled likewise. this section. Let v be the next forced vertex to be processed. If v is the endpoint of some segment, S i S, virtual edge {u,v} represents this segment. Let P v be the first path to be extended into G r that originates at v. The first edge in P v is the real edge, {v,v }. This edge is added to E(S). Let P u be the second path to be extended into G r that originates at v, but proceeds in the opposite direction. If v is the endpoint of a segment, let the first edge in P u be the virtual edge {u,v}. If v is not the endpoint of a segment, let the first edge in P u be the real edge {u,v}, and ensure it is added to E(S). Initially let u = u. During the growth of P v and P u, the shared endpoint v remains fixed, while v and u are updated to indicate the new endpoints. Figure 6.1 illustrates this initial configuration on a cross section of an example G r. The goal is to form a new segment, Si, represented by the following: S i = P u + P v (6.1)

44 Chapter 6: Designing the Multi-Path Algorithm 38 Path Growth P u P v u 7 e S i u v 1 e S i+1 8 v e Si G r Figure 6.2: Example of extension of paths P u and P v from forced vertex v. The numbers represent the order in which the associated edges have been added to the paths during the extension. For real edges, the relative ordering represents the order in which they were added to E(S). Definition (locally consistent). A segment S k S is locally consistent if for all w V ex (S k ), deg(g r, w) > 2. Initially focus is centered on the growth of P v. The value of v and the edges that make up P v change under the following two conditions: 1. v collides with another segment. The corresponding segment is absorbed by the growing path and v changes to the other endpoint of that segment. 2. v is a forced vertex. Let e be the other edge incident to v. e must be added to the path as well as E(S). v changes to the other endpoint of e. Once P v can longer be extended, focus switches to the growth of P u with the same two conditions for growth applied to endpoint u. If an edge from E v (S) is to be added to a path due to condition 1, the segment it represents is now absorbed by the new segment, Si. This is instead of the merging

45 Chapter 6: Designing the Multi-Path Algorithm 39 metaphor. At the endpoint where a collision has occurred, all non-path real edges in E(G r ) which are incident to that endpoint must be removed. This is illustrated in figure 6.2, just after edges 1 and 5 are processed. The removal of non-segment edges may cause the first stopping condition to occur or induce new forced vertices. If one of the current u or v become a forced vertex due to a segment collision, the growth of the other path must resume after growth stops for the current path. This can repeatedly occur at multiple points during the growth of both paths causing the focus of growth to alternate between P u and P v repeatedly. Figure 6.2 illustrates this when edges 1 and 5 have been added and the subsequent non-segment edges have been removed. After edge 1 is added, u becomes forced, allowing P u to grow. During the growth of P u, once edge 7 has been added, focus must switch back to P v in order to add edge 8. Path growth stops once G r becomes locally consistent with respect to u and v. At this point it is important to ensure that the new segment represented by a virtual edge {u,v } would not turn G r into a multi-graph. In order to ensure that no real edge {u,v } exists in G r, the adjacency list of one of u or v must be scanned for the other potential endpoint. The adjacency list for the vertex with the lower degree value is chosen. If an edge is found, it must be completely removed as per section The removal of that edge may cause a locally inconsistent G r at one or both u and v and the paths must continue to grow as before. Once a locally consistent G r is reached and is ensured to be a simple graph, the

46 Chapter 6: Designing the Multi-Path Algorithm 40 new segment S i can now be defined and a virtual edge can be created in E v (S). Figure 6.3 illustrates the new virtual edge that represents S i. u e S i v G r Figure 6.3: Si after extension of S i. Segments S i 1 and S i+1 have been absorbed during the extension of segment S i from the previous figure 6.2. The process of extending segments is repeated for the next forced vertex remaining in G r until no more forced vertices remain and a consistent G r is reached, or until a stopping condition is encountered. Stopping Conditions P u P v u 5 4 u 2 v 1 3 v w G r Figure 6.4: Example of stopping condition 1. The removal of non-path edges when extending a segment from v eventually causes vertex w to be reduced to a degree of 1. As briefly mentioned earlier and as illustrated in figure 6.4, the first stopping condition is encountered while removing edges.

47 Chapter 6: Designing the Multi-Path Algorithm 41 The detection of the second and most important stopping condition is simplified quite nicely here. If during a path extension the two paths are forced to collide, or u = v, a cycle will have been found. Figure 6.5 illustrates this condition when edge 9 is traversed. P u P v u u 2 v v 9 G r Figure 6.5: Example of stopping condition 2. Attempting to extend P v with edge 9 leads to u = v. Extending Segments from Anchor Points When an anchor point, v, is selected during the descent down the search space, a branching edge is chosen incident to v. In this and the previous work, the branching edge is the first one encountered in the adjacency list for v. Let the branching edge, e b, be the edge {v,v }. In order to use the method of extending segments, there are two cases in regards to v that must be considered. The first case is that no segment is currently incident to v. In this case P u will initially be empty and u = v. P v and v are initialized using e b and e b is then added to E(S). The growth of P v, if required, can now start as described for forced vertices. If during the growth of P v, v becomes forced, then as previously described, the focus

48 Chapter 6: Designing the Multi-Path Algorithm 42 of growth will alternate to P u once P v stops growing. The second case is when v is already a segment endpoint. In this case, all of the real edges but e b that are incident to v are removed from G r. This removal converts v into a vertex of degree 2 and it can be treated the same as a forced vertex. P v and P u can now be initialized as such, with v being the first vertex to be considered so as to ensure that e b is in the correct position within E(S). Improvements over Previous Work Three key aspects are improved on by this approach to creating and extending segments over what was done previously. The first is that forced vertices can be processed when they are encountered by the path endpoints rather then through the previous approach of dealing with a single forced vertex at a time. This requires a constant change in focus which creates many redundant segments, that otherwise would be avoided using the new method. The redundant segment creation is the second aspect that is improved upon, as less redundant segments will be created. The redundant segments cannot be completely avoided with this method because the extension of one segment may still cause a chain reaction that impacts another segment created during the same inconsistent state of G r. The third aspect is the avoidance of using an adjacency matrix for detecting if the new virtual edge {u,v } would create a multi-graph. This is what allows for the O(n + ε) total space overhead for the algorithm. The time saving of not managing an adjacency matrix to reflect the current state

49 Chapter 6: Designing the Multi-Path Algorithm 43 of G r though-out the entire search space seems to offset the expense of scanning the adjacency list. More analysis could be done to prove this point Managing Removed Edges There are two ways edges can be removed from G r during the execution of the algorithm. The first is a partial removal that takes advantage of the fact that one endpoint of the edge will have been removed from G r and placed in V in (S). This is what occurs when non-segment edges are removed due to a segment collision. The second is a complete removal of an edge which occurs when both endpoints of the edge remain in G r. This is what occurs with the endpoints of branching edges and with the endpoints of real edges that have been superseded by virtual edges. Partially Removing Edges from G r Let w be the endpoint that is the target of a segment collision. The vertex w must be added to V in (S) and each of the non-segment real edges incident to w must be removed. Since G r is where the active searching occurs during the multi-path method, the removed edges only have to appear missing from G r. From the perspective of V in (S), each of the real edges incident to w can remain attached. To accomplish this partial removal of an edge, G is treated as if it were a directed graph from the perspective of the vertices in V in (S) and as an undirected graph from the perspective of G r. When using adjacency lists to represent the edges in a graph, this ability to switch perspectives between directed and undirected graphs comes

50 Chapter 6: Designing the Multi-Path Algorithm 44 naturally, as each vertex in the graph must have its own adjacency list. Recall that G r is the continuously modified instance of G for the current location in the search space. When the undirected G is initially defined in memory by the data structures representing it, each edge is actually represented by two arcs. This is one arc pointing out of the adjacency list for each of the two vertices incident to it. For each non-segment real edge, e w, incident to w, only the other endpoint of e w needs to have its corresponding arc removed from its adjacency list. The only time a segment edge must be partially removed is when the other vertex which is incident to that the edge is to be the new endpoint of the fully extended segment. This is because the other vertex incident to the segment edge must remain in G r. The elegance of this approach of removing only one arc is that half of the work of removing, and subsequently restoring, an edge is required and the adjacency list of w contains a complete record of what edges were incident to it at the time it was removed from G r. This is extremely useful for the recovery of G r during ascent up the search space. More on this is discussed in section Figure 6.6 is an illustration of the results of using this method of partially removing edges from G r, for some segment, S i S. Note how the edges in E(S) that are not incident to a segment endpoint do not even have to be removed from G r using this approach. Completely Removing Edges from G r Unfortunately only detaching the inactive portion of the graph does not work with branching edges and real edges that have been superseded by virtual edges. A way

51 Chapter 6: Designing the Multi-Path Algorithm 45 V in (S i ) V in (S S i ) e S i G r Figure 6.6: Example of the partial removal of edges from G r. Focus is provided for some segment, S i S. The thicker lines represent edges in E(S i ). Arcs shown in the diagram represent the remaining arcs for the detached vertices of G contained by V in (S). to manage completely removed edges must be determined. In [Koc92] all edges to be removed are completely removed from G and stored in a list of removed edges. There is a list of removed edges associated with each consistent state of G r up the search tree. During ascent up the search space, once the state returns to the branching edge of an anchor point, the removed edges contained by the list for that consistent state are restored and the branching edge is removed and stored in the list of edges previous to the current one. The latest branching edge will be restored once the current anchor point has been exhausted and the state returns to the consistent state one level above the current one. In essence this is a stack of lists, that are removed and added in the same manner that branching edges in E(S) are. In [Koc92] this stack of lists is implicitly maintained by the recursive nature of the algorithm.

52 Chapter 6: Designing the Multi-Path Algorithm 46 This same method of managing removed edges is used in the same manner here for the fully removed edges. However the stack of lists must be directly managed by the algorithm, as will be made more apparent by the next chapter Unwinding Segments and Restoring State Now that extending segments and managing the removed edges from G r have been discussed, a way to restore G r to a previous state must be introduced. In order to restore G r without relying on any pass by value data, the adjacency lists, virtual edge array and degree array must have some way to be systematically restored. Restoring the Adjacency Lists and the Degree Array for G r Let G P r represent the consistent state of G r that is to be restored and is some point above the current one in the search space. This corresponds to the closest branching edge when treating E(S) like a stack. By restoring the edges to G r in the reverse order in which they were removed from G r, and by restoring any partially removed edges associated with the incident vertices of each edge, G r can be incrementally restored towards G P r. More on how the edges can be processed in this reversed order will be provided in the next chapter. Let e ={u,v} be the latest segment edge added to E(S). Without loss of generality, assume that u was removed from G r and added to V in (S). All of the arcs, except for the arc with target v, listed in the adjacency list for u point to vertices still in G r that have had the corresponding edge for that arc partially removed. Generally at the time of restoring e, only one of u or v will have partially removed

53 Chapter 6: Designing the Multi-Path Algorithm 47 edges to be restored. The exception to this is for branching edges that join two segments together. Restoring the degree array to the correct state is trivial. The initial degree value of any removed vertex must be 2. This is due to the vertex being part of the potential Hamilton cycle in V in (S). For each arc a from the adjacency lists of u or v that represents a partially removed edge, the corresponding opposite pointing arc is a. The target vertex of a must have a restored to its adjacency list. During this restoration the target vertices of both a and a must have their degree entries incremented by one each. Additionally if a vertex from e represents a segment endpoint, the endpoint still in G r must have an arc restored to its adjacency list with no corresponding change to the degree entries. Knowledge about e with respect whether or not it is contains a segment endpoint is explained in the next chapter. Each e from S is processed in this way up to the first branching edge encountered in E(S). Once this branching edge is reached, the list of completely removed edges associated with that level in the search space can be restored to the adjacency lists along with the degree values of V (G r ) for the endpoints of those edges. Since the edges here are represented by two arcs that are to be restored, the target vertex of each arc is used to increment the corresponding entry in the degree array by 1 each.

54 Chapter 6: Designing the Multi-Path Algorithm 48 Restoring the Virtual Edges Array The virtual edge array is slightly trickier. Let EV be the virtual edges array for G r, where the entries in the array correctly represent E v (S) for all vertices not in V in (S) for the current location in the search space. The remaining entries in EV reflect the prior states of E v (S) in the levels above the current one in the search space. By taking advantage of the fact that segments are now unwound in the reverse order in which they are created, the older entries in EV that represent vertices in V in (S) can be used to restore EV to the correct previous state of E v (S) before the segments were created or extended. Let w, z be the endpoints of a new virtual edge representing a segment S i that is about to created by the path extension algorithm from section Let w be the vertex that is the origin of the the two paths that were grown to find the segment. If w was not originally a segment endpoint then EV [w ] and EV [z ] prior to the new segments creation, were equal to zero. After the segment is finalized, EV [w ] = z and EV [z ] = w. When restoring E v (S) to its previous state all that needs to be done is setting both EV [w ] and EV [z ] back to zero. If w was a segment endpoint, let this segment, S i, be represented by virtual edge {w,z}. If w w and z z, both w and z will both have been added to V in (S). Additionally the entries for w and z in EV will not be changed, as two new entries are to be made for w and z. In this case when reversing changes to G r, all that needs to be done is setting the entries EV [w ] and EV [z ] to zero. Endpoints w and z will already reflect the correct values in EV for segment S i.

55 Chapter 6: Designing the Multi-Path Algorithm 49 Without loss of generality, let w w and z = z. In this case only w will be added to V in (S) and the entry EV [z] will be updated to point to w, leaving the entry EV [w] its previous value of z. When reversing changes to G r for segment S i, this unchanged entry EV [w] is used to restore the value of EV [z] and EV [w ] will be set to zero. More explicitly EV [EV [w]] = w and EV [z ] = 0 when restoring the old virtual edge. Now that EV is explained in terms of restoring previous states of E v (S) a way to know when to use which form of restoring EV needs to be found. Let e E(S) be the segment edge about to be restored as per the order explained in section 7.2. If information about how that edge was removed from G r is maintained, a decision can be made on what endpoint of e needs to have its value in EV restored and in what way. Section 7.3 will provide details on how and what information is stored for each e E(S). If it is found that a vertex x e is a segment endpoint when e E(S), the restoration of e to G r will remove that status and x will no longer be on a segment. In this case EV [x] is set to zero. Otherwise EV [EV [x]] = x is used for all other cases, even when EV [x] is zero, as the 0 th entry goes unused by G r. 6.2 Vertex Selection Selecting the next anchor point at each point in the search space where G r is consistent has been modified from that used in [Koc92]. Previously after each consistent state resulting from the selection of a branching edge, a vertex with the largest degree in G r was chosen as the next anchor point. This can be done with an O(n) time scan

56 Chapter 6: Designing the Multi-Path Algorithm 50 of the vertices in G r. The new algorithm has been modified to only select new anchor points once the latest anchor point chosen has been added to V in (S). This is accomplished by branching edges off of the latest anchor point until it is removed from G r. With respect to the search tree this appears as the same anchor point appearing up to two times in a row during the descent towards a leaf. In this way a static list of vertices can be provided to control the order of anchor point selection. As will be seen in the analysis done in chapter 11, by instead providing a presorted list of vertices in descending order with respect to degree, smaller search trees are generated, subsequently reducing the time to exhaustively search the entire space. By default the implementation uses this ordering. Other presorted lists are possible as well and can sometimes yield better results than what the default provides. For example, analysis of the results for the knight s graph k7x4 show a remarkable speedup when using a presorted list based on an ascending degree sequence. Finding new heuristics for vertex selection based on this static list has a lot of room for new discoveries and suggestions for further study is mentioned in chapter 12.

57 Chapter 7 Navigating the Search Space using a Turing Machine As briefly mentioned in section 4.1 and emphasized in figure 7.1, E(S) can be treated as a stack of edges, where edges are removed until a branching edge is encountered and added until a stopping condition occurs. This is to be expected due to the recursive nature of the algorithm. A drawback of using recursion is that making the algorithm re-enterable is difficult. It would be nice to remove the direct recursion and be able to leave and enter the algorithm at any point in the search space. This has applications from easier check-pointing of code that can run for long periods of time, with the full exploration of the search space one Hamilton cycle at a time, and with performance gains due to having no recursive calls of the algorithm. This chapter describes a way of modeling the navigation of the search space using a Turing machine to describe the movement up and down the search tree. 51

58 Chapter 7: Navigating the Search Space using a Turing Machine {1, 7} {1, 3} E(S) 4 {2, 3} {2, 3} {2, 4} Leaf# Figure 7.1: Changes to E(S) from leaf to leaf based on the search tree for the Petersen graph. The state of G r always returns to that of the latest branching edge added to E(S). The Turing machine is a very abstract notion from computer science that can be used to model any algorithm. The use of a Turing machine here to model the movement through the search space is used as a tool in order to help understand the manipulation of E(S) as a stack of edges and does not exactly match the full definition of a Turing machine. More on Turing machines can be found in work by Linz in [Lin01].

59 Chapter 7: Navigating the Search Space using a Turing Machine 53 R/W Head Terminate Machine Hamilton Cycle Figure 7.2: Tape for the Multi-Path Turing Machine. 7.1 State of the Tape A proper Turing Machine consists of a set of tapes and a read/write head for each tape. Each tape can have an infinite number of positions, called cells, to the left and right of each read/write head. Movement of the read/write heads of the Turing machine is controlled via a set of rules that solely depend upon the state of the current cell positions. The Turing machine described here uses one tape and one read/write head. The tape is only n+2 cells in length. For the usage here, the contents of the tape cells and the movement of the read/write head differ significantly with the formal definition of a Turing machine. There are two entries per cell on the tape, one of which is an arc representing an edge from E(S) and the other a bit-field representing a finite number of states. The Turing Machine used here, models the recursive nature of the algorithm by tracking the the current state of E(S) within its cells and the current position in the search space by the location of the read/write head. The movement of the read/write head to the right tracks the descent into the search space while movement to the left tracks ascent. The bit-fields stored in the cells contain information on how to restore

60 Chapter 7: Navigating the Search Space using a Turing Machine 54 each cell s edge to the graph during ascent. The two cells on the endpoints of the tape do not have edges set and only have a single bit permanently set in their bit-fields. A illustration of the tape for this Turing Machine can be found in figure 7.2. On the leftmost cell of the tape, a termination bit is set. If the read/write head ever makes it to this cell and reads this termination bit, the entire search space will have been exhausted. On the rightmost cell of the tape, a Hamilton cycle bit is set. If the read/write head reads this bit, a Hamilton Cycle will have been found. The edges found in the cells between the endpoints are all of the edges in E(S) that make up the Hamilton cycle. If the read/write head is not at either endpoint, the current state of E(S) is reflected by the edges found in the cells from the left most endpoint up to and including the current cell pointed to by the read/write head. The starting point of the Turing machine is the left most cell on the tape and is the only time the machine can be in that position without terminating. The use of a Turing machine here differs significantly with the formal definition of a Turing machine in the way the read/write head moves. Movement of the read/write head to the right is not controlled by the state of the cells in the tape, but by the state of G r.

61 Chapter 7: Navigating the Search Space using a Turing Machine Edges from E(S) The arcs stored in each cell that represent the edges from E(S) come from the adjacency list of the path endpoint u or v of the growing segment in S at the time the edge was added to S. With the exception of the case when a branching edge is added to S as a stand alone segment, each of these arcs always point to a forced vertex added to V in (S) at the time the edge was added to E(S). Additionally if a segment collision occurred when adding an edge the source vertex of the arc stored will be the point of collision. In this way when moving to the left, each vertex and any partially removed edges can be restored in the reverse order in which they were removed from G r. 7.3 Status Flags represented by the Bit-Field The following flags and their meanings are represented by the bit-field entries of each cell: HC TERMINATE The search space has been exhausted, stop searching for a Hamilton cycle in the current graph. HC HAMILTONIAN A Hamilton cycle has been found. HC ENDPOINT The source vertex of the corresponding arc stored in the current cell is a segment endpoint. HC FORCED The target vertex of the corresponding arc stored in the current cell is a forced vertex. HC FORCED DEG2 The arc stored in the current cell is also the adjacency list of arcs representing partially removed edges into the source vertex of the arc. This source vertex is a junction point of two merged segments. HC ANCHOR POINT The target of the arc stored in the current cell is an anchor point. Additionally the arc represents a branching edge in E(S).

62 Chapter 7: Navigating the Search Space using a Turing Machine 56 HC ANCHOR EXTEND Can only be set if HC ANCHOR POINT is set. Set if the anchor point is already the endpoint of a segment. HC FLIP SOURCE Can only be set if HC ANCHOR POINT is set. The arc must be reversed when interpreting the anchor point. The source vertex of the arc is the anchor point rather then the target. 7.4 Moving Read/Write Head Moving Right Moving the read/write head to the right implies descent down the search space. The status and edge information is never read while moving to the right, only written. Control of the movement of the head to the right is controlled by the selection of branching edges off of anchor points, and the forced edges due to an inconsistent G r. Movement to the right stops when one of the two stopping conditions is encountered. Typically movement to the right involves selecting an anchor point, choosing a branching edge off that point, forcing any edges from an inconsistent G r into E(S) and then if necessary choosing another branching edge off the same anchor point. This is repeated until a stopping condition occurs Moving Left Moving the read/write head to the left implies ascent up the search tree and recovery of G r to a previous state. In this case the read/write head only reads the tape one cell at a time, restoring the state of G r based on the instructions in the

63 Chapter 7: Navigating the Search Space using a Turing Machine 57 status flags set in the bit field and the edge provided. Movement to the left stops if the Termination flag is encountered or the closest branching edge is encountered Switching Directions If a branching edge is encountered during movement to the left, all remaining edges that have been removed and associated with that branching edge are restored and the branching edge is then removed. Movement can now begin to the right. At this point if G r is no longer consistent after the removal of the branching edge, forced edges are placed onto the tape until the graph is consistent. This process of changing directions from left to right is referred to as rotating the anchor point.

64 Chapter 8 Implementation of the Multi-Path Algorithm The ideas from the previous chapters can now be put together and expressed as a complete algorithm. To accomplish this, source code from the implementation of the algorithm is provided within this chapter and in the later appendices. The language used is the c programming language. The only code missing are the routines for loading graphs, and those for allocating, initializing and freeing data structures. 8.1 Data All of the data types used are found in Appendix A.1. The HCStateRef type references a state structure storing the current state of the search space. This includes the attributes of G r, the removed edges and the tape of the Turing Machine. Let s 58

65 Chapter 8: Implementation of the Multi-Path Algorithm 59 be a reference to a variable of type HCStateRef and be the current instance of the search space for some graph G Graph State The current graph state is maintained via three variables in s. These are an array of adjacency lists s adjlist, a degree array s degree and a virtual edges array s virtualedge. Each of these arrays are of length n + 1, so that they can be indexed by the n vertices from V (G). An adjacency list is defined by type VArc. It is a doubly linked list of structures representing arcs in G. Each list, a, is null terminated in the forward direction (via a next) and circularly linked in the backwards direction (via a prev). There is also a target vertex (via a target) and a cross reference to the opposite pointing arc (via a cross). When adding arcs to an adjacency list, the arc being added is always inserted to the top of the list Removed Edges The removed edges from G r are maintained by a stack of adjacency lists. Each null terminated list contains arcs from different vertices. Since removal of arcs from each list occurs all at once, there is no need to maintain the circular back reference, prev. When restoring each arc to its corresponding adjacency list, the cross reference, cross, is used to determine the correct source vertex. A pointer to the correct adjacency list in the stack is maintained by the algorithm

66 Chapter 8: Implementation of the Multi-Path Algorithm 60 in the following way: 1. The pointer is moved upwards after restoring the completely removed edges it points to. The branching edge that was just exhausted for that point in the search space is then fully removed from G r and placed into the list the pointer now references. 2. The pointer is moved downwards just before branching starts for some edge. This list the pointer now references will contain all arcs from any fully removed real edges from G r up to the next anchor point in the search space Tape State The structure storing the tape for the Turing machine is an array of type HCTape. The origin of the tape is stored in s origin and the current position of the read/write head is stored in s pos. Each entry of the tape contains an arc of type VArc representing an edge in E(S) and a bit-field containing the status information. 8.2 Code The majority of the code for the implementation of the multi-path algorithm can be found in Appendix A. The source code that is listed here is sufficient to describe the overall use and structure of the program.

67 Chapter 8: Implementation of the Multi-Path Algorithm Running the Turing Machine The source code in listing 8.1 contains the implementation of runturingmachine. This top level procedure controls the overall movement of the read/write head while navigating the search space. Before first starting the Turing Machine, the tape must be initialized or primed. This simply means that the entries in the tape must be set to that of the first decent down the search space up to the first leaf, or stopping condition. The actual machine always starts at a leaf in the search. The reasoning for starting at a leaf is that if a Hamilton cycle is found, the machine will stop at a leaf with the read/write head ready to move to the left. If exploring the entire search space is required, it is then easy to just re-enter the machine. The function primetape initializes the tape to the first leaf in the search space. The function returns true only when runturingmachine can be entered. A false result is because either the first leaf represents a Hamilton cycle or a simple non-hamiltonian decision is detected such as a vertex with degree lower than 2. The source code in listing 8.2 describes the use of runturingmachine in finding and counting Hamilton cycles.

68 Chapter 8: Implementation of the Multi-Path Algorithm 62 Listing 8.1: The main Turing Machine method. / Run Turing Machine u n t i l a Hamilton c y c l e i s found o r s e a r c h s p a c e i s e x h a u s t e d. Ensure t h a t t a p e i s primed f i r s t b e f o r e c a l l i n g. R e t u r n s f a l s e when s e a r c h s p a c e e x h a u s t e d. / bool runturingmachine ( HCStateRef s ) { HCTape hx ; / r e a d / w r i t e head f o r t a p e / Vertex d2, x ; VArc L = s >a d j L i s t ; Vertex e = s >v i r t u aledge ; UInt d = s >degree ; Vertex nv = s >vertexorder ; / nv [ x ] r e f e r s to n e x t v e r t e x i n l i s t / s >f l a g s. ishamiltoncycle = f a l s e ; / t a p e head must be a t a l e a f i n s e a r c h space, move t a p e head l e f t to t h e c l o s e s t b r a n c h i n g edge / hx = unwindsearchedge (L, e, d, s >pos ) ; w h i l e (! ( hx >s t a t u s & HC TERMINATE) ) { / remove t h e e x h a u s t e d b r a n c h i n g edge and s w i t c h d i r e c t i o n s / x = rotateanchorpoint ( s, L, e, d, hx, &d2 ) ; / r e m oval o f b r a n c h i n g edge may have c r e a t e d an i n c o n s i s t e n t s t a t e / x = e n s u r e C o n s i s t e n t ( s, L, e, d, d2, x, nv ) ; i f ( x ) { / keep e x t e n d i n g b r a n c h i n g e d g e s from anchor p o i n t s / w h i l e ( extendanchor ( s, L, e, d, x ) ) { do x = nv [ x ] ; w h i l e (! d [ x ] ) ; } } } / s t o p p i n g c o n d i t i o n e n c o u n t e r e d ( a l e a f ), s t o p movement to t h e r i g h t / i f ( s >f l a g s. ishamiltoncycle ) r e t u r n true ; hx = unwindsearchedge (L, e, d, s >pos ) ; s >pos = hx ; r e t u r n f a l s e ; } / runturingmachine /

69 Chapter 8: Implementation of the Multi-Path Algorithm 63 Listing 8.2: Examples of using the Turing Machine to count Hamilton cycles. / Find t h e n e x t h a m i l t o n c y c l e i n t h e s e a r c h s p a c e f o r t h e graph r e f e r e n c e d i n s. R e t u r n s f a l s e when no Hamilton c y c l e found. / bool nexthamiltoncycle ( HCStateRef s ) { r e t u r n runturingmachine ( s ) ; } / n e x t H a m i l t o n C y c l e / / Find t h e f i r s t Hamilton c y c l e i n t h e s e a r c h s p a c e. R e t u r n s f a l s e when no Hamilton c y c l e found. / bool f i r s t H a m i l t o n C y c l e ( HCStateRef s ) { resetstateandrestoregraph ( s ) ; i f ( primetape ( s ) &&! runturingmachine ( s ) ) r e t u r n f a l s e ; s >f l a g s. ishamiltonian = s >f l a g s. ishamiltoncycle ; r e t u r n s >f l a g s. ishamiltoncycle ; } / f i r s t H a m i l t o n C y c l e / / Count a l l Hamilton c y c l e s i n s e a r c h s p a c e f o r graph r e f e r e n c e d i n s. / ULongLong hamiltoncycles ( HCStateRef s ) { ULongLong c = 0 ; i f ( f i r s t H a m i l t o n C y c l e ( s ) ) do { c++; } w h i l e ( nexthamiltoncycle ( s ) ) ; r e t u r n c ; } / h a m i l t o n C y c l e s / Extending Segments and Branching Segment extension can occur in two points in runturingmachine. Both methods ensureconsistent and extendanchor, found in Appendix A.3, call extendsegments,

70 Chapter 8: Implementation of the Multi-Path Algorithm 64 found in Appendix A.2.2. The complete implementation of the algorithm for segment extension discussed in section is contained within extendsegments. The first method in runturingmachine that can call extendsegments is ensure- Consistent. Just as its name would suggest, ensureconsistent ensures that the current state of G r is consistent after the removal of a branching edge. The second method appearing in runturingmachine that calls extendsegments is extendanchor. This procedure ensures that the anchor point, x, has been removed from G r by extending up to two branching edges off of it Restoring State and Removing Branching Edges The restoration of G r when ascending the search space is controlled by unwind- SearchEdge, found in Appendix A.4. This method starts at the location in the search space where a stopping condition has just occurred and unwinds the changes to G r one edge/arc at a time from the tape using the procedure unrollarc, also found in Appendix A.4. Once the closest branching edge, or the end of the tape has reached, unwindsearchedge returns that location to runturingmachine for use by rotateanchorpoint and ensureconsistent. The procedure rotateanchorpoint, found in Appendix A.3, removes this branching edge from G r and if necessary populates the stack of forced degree 2 vertices d2 to be later processed by extendsegments when ensuring that the graph state is consistent.

71 Chapter 9 Pruning Algorithm In any backtracking algorithm, if conditions exist that allow for entire branches of the search tree to be avoided with out affecting the outcome of the search, these conditions are referred to as pruning conditions. The pruning conditions used in [Koc92] center around a powerful lemma about Hamiltonian graphs. This lemma appears in Bondy and Murty [BM76]. Definition. The number of connected components in the graph G is ω(g). Lemma 1. Let K be a separating set of the graph G. If ω(g K) K > 0 then G is not Hamiltonian. Searching for the existence of separating sets with this property is difficult as it would involve enumerating over the power set for V (G) in some way. However, if one could be found with this property for some G SE while searching for a Hamilton cycle it may be possible to determine how far back in the search space the property holds and continue searching from that position onwards. The ability to prune back the search space given a separating set that satisfies lemma 1 is described in section

72 Chapter 9: Pruning Algorithm 66 Having a way to prune back the search space using separating sets is useless without first having a nice way to find them. Certain conditions exist that allow for relatively quick linear detection of separating sets. Both cut points and bipartitions can be detected in this way. Cut points automatically satisfy lemma 1, as each cut point taken individually results in two or more components. In a bipartite graph, if the two sets differ in length, the smaller of the sets can be chosen as a separating set that satisfies lemma 1. In [Koc92] a modified version of an algorithm by Hopcroft and Tarjan for finding cut points is used. It is a depth first traversal of the vertices in G r that includes bipartition testing in addition to finding cut-points. The approach used for pruning the search space has been improved upon in two ways in this thesis. First the scope of detecting cut points has been increased over the implementation for [Koc92]. The changes to the scope allow for the results from the bipartition condition to be compared against the results using cut points. By choosing the set that would return the largest difference that satisfies lemma 1 more pruning may be possible from that point in the search space. For the second improvement, the point in the search space where detection of separating sets occurs has been changed. This change ultimately reduces the overhead of detecting separating sets without missing any pruning opportunities that would be found using the method described in [Koc92]. Section 9.3 describe this improvement.

73 Chapter 9: Pruning Algorithm Pruning Mechanism As already stated the pruning condition provided by lemma 1 can be used to avoid searching entire branches of the search space. This section describes the mechanism used to prune back the search space once a separating set has been found for some G r in the space. Let G k+1 r be a reference to some consistent G r in the search space for G. Assume that the graph G k+1 r has a detectable separating set K, with c = ω(g k+1 r K) K. Let c > 0, then lemma 1 is satisfied and G k+1 r is not Hamiltonian. No more search is possible at G k+1 r and movement up the search tree towards the closest anchor point must begin. Let K be a new separating set formed from all of the vertices from K and select vertices from V in (S) as they are restored to G r during the movement up the search tree. Recall from the previous work in this thesis, that vertices are restored to G r in the reverse order in which they were removed. Let v the next vertex to be restored to G r on the way up the search space. v is added to K so that no change could have occurred to the result of ω(g k+1 r After v is restored to G r, v can be added to K if ω(g k+1 r K). K) = ω(g r (K + v)). In this way the value of c will only decrease by 1 if v is added to K. Determining whether or not to add v to K so that the number of components remain unchanging is difficult to do optimally. However a heuristic proven in [Koc92] can be applied based on the knowledge of how each v was removed from G r. Essentially v is added to K when the restoration of v back into G r requires the restoration of non-segment edges. Special care must be taken for any v that represent past anchor points on the path up the root of the search tree. Vertices that were once

74 Chapter 9: Pruning Algorithm 68 anchor points must be added to K as they would involve the return of one or more branching edges. This process of selectively increasing K for each v restored to G r continues until c has been reduced to 0. G k r is the position of the closest anchor point at or above this point. The search for a Hamilton cycle must recommence at G k r. Figure 9.1 is an illustration of some hypothetical search space this process is applied to. 9.2 Testing for Separating Sets Overview of Previous Test As can be seen from the way the pruning condition climbs up the search space towards G k r, the largest possible value for c is desirable. Additionally as stated in the beginning of the chapter, the actual testing for a separating set must be reasonable in its overhead. To satisfy the latter, [Koc92] uses an O(n + ε) algorithm based on one developed by Hopcroft and Tarjan. If G r is connected at the time of testing the algorithm produces a value for c in one of two ways. The first is if a cut point is detected. In this case the value of c is set to be the number of components surrounding a single cut point reduced by one, as that is the length of the separating set. The choice of the single cut point is that of the lowest cut point in the first branch to contain a cut point in the depth first search. The second way c is found in a connected G r is if no cut point is found. In this case the entire graph will have been visited by the depth first search and a determination

75 Chapter 9: Pruning Algorithm 69 on whether or not G r is bipartite can be made. In this case if a bipartition is found, c is set to the absolute value of the difference of the two sets found. If G r is disconnected, the depth first search is repeatedly called until all vertices in G r have been visited. In this case c is set to the number of components visited. This is equal to the number of times the depth first search had to be called before all vertices were visited. Afterwords if c > 0 the multi-path algorithm can stop for G r and pruning can take place Increasing ω(g r K) K If no separating set is found by the depth first search then the worst case performance will have occurred in running the test. Typically this will be the case for the vast majority of the times testing occurs. Since pruning is the ultimate goal of the test, the algorithm for testing has been modified to always run in the worst case, but with the benefit of having a larger value of c for the pruning to take advantage of. This larger c is obtained in the following way: 1. All cut points are found in G r and the subsequent components are calculated during the traversal of the graph by the depth first search. 2. The bipartition condition test is always able to run to completion. If a bipartition is found the absolute value of the difference in set sizes is calculated. Of the two methods for finding components, the one that provides the largest value to c is chosen.

76 Chapter 9: Pruning Algorithm 70 At the time of testing, G r may be disconnected. In this case each component must be tested by the depth first search. A running total for c is calculated based upon the best choice returned for each running of the depth first search. If no cut points are found or no bipartition exists, c will always be able to be incremented by one for each component tested in the disconnected case. Ensuring a proper count for the separating set size The depth first search is always called on a consistent G r. However it may additionally be called after a branching edge has been attempted. The subsequent removal of the branching edge may have a subtle impact on the size of the separating set found by the pruning condition test. If the anchor point attached to that branching edge was not absorbed into V in (S) after the removal of the branching edge, it must be considered part of the separating set for G k r. This is taken into account by the implementation when returning the value of c for the pruning operation. 9.3 Reducing the Frequency of Testing Top Down vs. Bottom Up Testing The algorithm from [Koc92] uses the top down approach to test for separating sets. What this means is that just before each anchor point is explored and branching occurs, the test is run against the current consistent G r for that anchor point. By only having the tests occur on the extremities of the search space, significant speedups in terms of the time spent testing can be achieved.

77 Chapter 9: Pruning Algorithm 71 In order to only run the test at the extremities of the search space, it must be shown that no opportunities to prune the search space are missed with respect to the top down approach. Overlapping Components for G k+1 r and G k+2 r Lower instances of G r in the search space have at least as many components due to cut points as their predecessors, and those components that do exist, overlap. Assume G k+1 r is the point in the search space where a pruning opportunity would first be detected in the top down approach. Let G k+2 r be an instance of G r closer to the bottom of the search space that descends from G k+1 r. For the graph state at any position in the search tree, any descendant graph from that point will contain no new connectivity, as segment edges will only be replaced by virtual edges and non-segment edges will have been removed. Therefore E k+1 E k+2. Subsequently any cut point in G k+1 r will either still exist in G k+2 r, or be removed. If the cut point was removed, then more disconnected components will be detected in G k+2 r. Additionally no additional connectivity in the graph can be introduced between G k+1 r to G k+2 r. By this reasoning only more components could be created from G k+1 r to G k+2 r. Bipartitions in G k+1 r and G k+2 r With similar reasoning with respect to E, any bipartition that would be detected in G k+1 r will also appear in G k+2 r if no disconnection occurs in G r before then. Additionally due to the reduced edge count in G k+2 r, the chance of finding a

78 Chapter 9: Pruning Algorithm 72 bipartition is greater and the search becomes faster. This is also the case for cut points as well Testing at the Extremities of the Search Space The extremities of the search space for the purposes of this thesis is defined to be the locations of the leaf nodes in the search space. Recall that in chapter 4 leaf nodes were defined to be anchor points that only have leaves descending from them in the search tree. The following strategy for when to run the test has been adopted by the implementation for this thesis: The test for a separating set is run on the next consistent state found for G r after a leaf node has been detected. Determining where leaf nodes are in the search space is accomplished in the following way: 1. On the start of the Turing Machine a marker called low, that points to a cell on the tape is set to point to the leftmost cell on the tape. 2. If the Turing machine has been moving to the right and encounters a stopping condition, movement commences to the left and stops at a branching edge, this represents an anchor point in the search tree. If the low marker points at a cell to the left of the read/write head, it is updated to point to the current position of the read/write head. This represents the lowest anchor point in the tree so far. If the low marker points to the current position of the read/write head it means

79 Chapter 9: Pruning Algorithm 73 that the same anchor point previously marked is still the lowest point found so far. If the low marker points to a position to the right of the read/write head, it means that a leaf node has been reached, exhaustively searched and control is currently at the anchor point directly above where the leaf node was detected. A pruning flag can now be set. 3. If the pruning flag is set, when the next consistent state is reached the test for a separating set can be run, and the low marker can be reset to the leftmost position of the tape. Figure 9.2 demonstrates this with G A r being the point where a leaf node in the search has been detected. G k+2 r is the next consistent state after G A r Ensuring a Full Climb up the Search Tree Because the pruning mechanism is not optimal for a value of c, each position found up the search space by the pruning mechanism must be tested again when using the bottom up approach. To do this, the pruning flag is not reset after pruning has taken place, so on the next consistent state, the test for a separating set is repeated and further climbing can continue. It is not until the test for a separating set comes back with no sets found that the flag can be turned off.

80 Chapter 9: Pruning Algorithm Implementation The c source code that implements all of the pruning functionality discussed in this chapter is fully included in Appendix B Data Structures The data structures required to run the depth first search is listed and documented in appendix B.1. A reference to the state information required to run the DFS code is stored by the HCStateRef instance Code A modified version of the runturingmachine method called, runturingmachinewith- Pruning is listed in appendix B.3.2. Two extra methods along with the variables to control finding the leaf nodes in the search space have been introduced to runturingmachinewithpruning. The first method introduced is getcomponentdiff, found in appendix B.2.2. This method returns true if a separating set was found and returns the difference via the variable c. The second method introduced is prunesearchspace, based upon the pruning mechanism presented in section 9.1, given the current cell position on the tape and the argument c, unrolls the search state to the closest branching edge at or above where c becomes zero. This method is found in appendix B.3.1. The actual search for a separating set is performed by dfseparatingset, found in appendix B.2.1, and is used solely by getcomponentdiff.

81 Chapter 9: Pruning Algorithm 75 G k r G k+1 r Figure 9.1: Hypothetical search space with pruning opportunity. Consistent graphs G k r and G k+1 r are labeled. The smaller points between them represent the vertices that may make up the new separating set K. In this example a separating set has been discovered at G k+1 r that allows pruning up to G k r.

82 Chapter 9: Pruning Algorithm 76 G k 1 r G k r G k+1 r G k+2 r G A r Figure 9.2: Hypothetical search space with pruning opportunity. A leaf node has been detected at G A r. A test for a separating set will occur at G k+2 r and allow pruning all the way up to G k 1 r.

83 Chapter 10 Reduction Technique The previous work described in this thesis focused on general improvements to the multi-path algorithm that can benefit search with all graph types. In this chapter a family of graphs is introduced that severely impact the performance of the multi-path method, despite the improvements already made. A reduction technique is presented in this chapter that can be used to determine if a graph from this family is not Hamiltonian in an extremely short period of time. Further work is needed to use the technique in determining if a graph from this family is Hamiltonian and is discussed in chapter Hamiltonian Subgraphs Definition (external vertex). Let A be some subgraph of the graph G. A vertex v V (A) is said to be an external vertex of A if there exists an edge {u,v} E(G) such that u V (G A). 77

84 Chapter 10: Reduction Technique 78 Figure 10.1: The Meredith graph. The multi-path algorithm is severely impacted in performance while searching this graph. This impact is mostly due to the properties of the marked subgraphs. Definition (reducible subgraph). Let R be a subgraph from graph G. R is called a reducible subgraph if for any Hamilton cycle or path from G, a Hamilton path, P R, must exist between some external vertices from R, and P must be fully contained within the Hamilton cycle or path found in G. If a graph has a reducible subgraph, then it belongs to this family of graphs that can dramatically slow down the multi-path algorithm. From the perspective of the rest of the graph when searching for Hamilton cycles, a reducible subgraph must be entered, fully traversed, and then exited, much like a

85 Chapter 10: Reduction Technique 79 single vertex is. In figure 10.1 a representative of this family of graphs is shown. This graph, named the Meredith graph, contains ten reducible subgraphs that severely impact the performance of the multi-path algorithm. The reason for the dramatic effect on performance is that the multi-path algorithm does not know about reducible subgraphs nor does it attempt to find a Hamilton path in one first before searching the rest of a graph. Instead multiple segments can be formed going into and out the external vertices of the individual reducible subgraphs. This can occur at many points in the search space. The state of G r at each of these points needs to be exhaustively searched which represents an exponential period of time spent fruitlessly searching for a Hamilton cycle. The subgraphs found in the Meredith graph are a special case of reducible subgraphs. Called complete half-bipartite subgraphs, section details the specific reasons on why certain half-bipartite subgraphs are reducible. Section briefly describes a fairly simple method of finding complete half-bipartite reducible subgraphs in a graph such as the Meredith graph. Finally in section 10.2 a process of recursively using collections of disjoint reducible subgraphs to arrive at much a smaller reduced graph is described. These reduced graphs can then be used to determine if a graph from this family of reducible graphs is not Hamiltonian is a very short period of time.

86 Chapter 10: Reduction Technique Half-Bipartite Structures Definition (half-bipartite subgraph). Let B be some subgraph of graph G. P is the maximal subset of the internal vertices of B such that no two vertices from P share an edge. If P > 1 then B forms a half-bipartite subgraph in G. Lemma 2. Let P be the subset of internal vertices from a half-bipartite subgraph B G, with p = P and q = V (B) P. If p q then no Hamilton cycle can be found in G. Proof. Let x be the number of vertices from P visited by a path through B that starts and ends outside of P. Because vertices from V (B P ) can be connected, at least x + 1 vertices from V (B P ) must be used in that path as no two vertices from P are connected. If p > q this means that the number of unvisited vertices from V (B P ) will run out before those from P do. From the perspective of finding a Hamilton cycle in G, it becomes impossible to visit all of P, therefore G is not Hamiltonian. If p = q then a Hamilton cycle could be found in B, but in the process, detaching all of V (B P) from G with respect to finding a Hamilton cycle in G. Unless B = G, G is not Hamiltonian. Theorem Let P be the subset of internal vertices from a half-bipartite subgraph B, with p = P and q = V (B) P. If p = q 1 then B is a reducible subgraph. Proof. Let B be a half-bipartite subgraph of G as described above and assume that a single cycle segment has entered and left B without visiting all vertices.

87 Chapter 10: Reduction Technique 81 Then x visited vertices from P will be gone with respect to finding a Hamilton cycle in G and at least x+1 vertices gone from V (B P ), leaving a new half-bipartite subgraph with p = p x and q = q x 1. Since p = q 1, then by substitution p = q x 1 and p = q. By lemma 2 this new half-bipartite subgraph can not be used for any Hamilton cycle. Therefore any cycle segment passing through B must completely visit B before leaving. Therefore B is a reducible subgraph. Definition (complete half-bipartite subgraph). Let B be a half bipartite subgraph of G. If the subset P of internal vertices share an edge with each vertex from V (B P ), then B is a complete half-bipartite subgraph. Each of the subgraphs found in the Meredith graph form a complete bipartite graph with four external vertices in one of the bipartitions and 3 internal ones in the other. These sizes satisfy the requirements for being a reducible half-bipartite subgraph Finding Reducible Complete Half-Bipartite Structures Complete half bipartite subgraphs have the unique property that all of the vertices from P all share edges with the same set of vertices. A fairly efficient polynomial time utility for finding half-bipartite graphs based upon this property has been created for finding all of the reducible half bipartite subgraphs from a graph.

88 Chapter 10: Reduction Technique 82 The algorithm used to find the subgraphs is based on string comparisons of strings generated by listing all of the vertices adjacent to a given vertex in ascending order. By matching strings that repeat to the same half-bipartition, the set P can be generated for each half-bipartite subgraph in a graph. Past knowing these steps, the design and implementation of the algorithm that implement this idea of string matching is not discussed further as it is beyond the scope this work. The important points are that reducible complete half-bipartite subgraphs are detectable in polynomial time, and they can be used to generate a graph reduction as described in the next section Reducing G Let Z G be a collection of disjoint reducible subgraphs from G. A new reduced graph G can be formed from G and Z G by simply copying G into G and replacing each subgraph, R, by a single vertex v, in G and ensuring that all edges that connect to vertices from R are represented as edges incident to v, being sure to discard duplicate edges and loops. This new graph G can subsequently be scanned for its own collection, Z G, of disjoint reducible subgraphs and the process can be repeated for some new graph G, and so on. Let α be the number of times a reduction is performed in this way. The recursively reduced graph, G α, can then be searched with the multi-path algorithm with an exponential increase in performance.

89 Chapter 10: Reduction Technique 83 Theorem Let G α be the ultimate graph produced though a series of reductions using disjoint reducible subgraphs from each intermediate graph and the original graph G. If G α is non-hamiltonian, so too is G Proof. Let the series of graphs generated during the reduction of G towards G α be G 1,..., G α 1. Let G α be a non-hamiltonian graph. This means that no Hamilton cycle could be formed that enters or exits any of the subgraphs in G α 1. Even if Hamiltonian paths could be formed between two external vertices for any reducible subgraph in Z α 1 G, none of them could be used. Therefore Gα 1 is non-hamiltonian and by induction so is G. The use of this technique on the Meredith graph results in a search performed on the Petersen Graph. As shown in chapter 4, this graph is processed by the multipath with an extremely small search tree. As will be shown in section , simply running the algorithm on the original graph takes a very long time False positives: an Unwanted Side Effect of Reduction If G α is found to be Hamiltonian, there is no guarantee that G is as well. One of the reasons for this is similar to the proof given for theorem With any Hamilton cycle, C, from G α, the two edges incident to any v V (G α ) that represent a reducible subgraph, R G α 1, must reflect edges from E(G α 1 ) incident to two separate external vertices of R. In fact many combinations of external vertices are possible from R with a single pair of edges incident to v. If none of those combinations of external vertices have a Hamilton path in R, then C does not reflect a Hamilton cycle in G α 1.

90 Chapter 10: Reduction Technique 84 If this is the case for all C from G α, G α 1 is not Hamiltonian. The other reason why C may not reflect a Hamilton cycle in G α 1 is the case where the two edges incident to v only reflect a single external vertex, u, from R. This is caused because the reduction reduces all edges out of R to a single point. Two edges incident on u may connect outside of R in a way that is not done through any other points from R. Any Hamilton cycle for G α using such edges about v will not reflect a Hamilton cycle in G α 1.

91 Chapter 11 Analysis and Verification 11.1 Verification Verification of the implementation of the multi-path algorithm was performed in two main ways. The first was by comparing the Hamilton cycle counts generated by the implementation for [Koc92] and this thesis. The second was by repeatedly modifying the search space for the same Hamiltonian graph and comparing the Hamilton cycle counts. If the counts stayed the same after many modifications it was assumed that the algorithm was working properly. The search space was modified by randomly permuting the numerical labels of a graph s vertices and then sorting the adjacency lists in ascending order based upon the new labeling. These isomorphic graphs were then searched using a static vertex ordering of one through n. Many thousands of permutations were used on the same graph to verify that the cycle counts were unchanging and that the implementation done for this thesis is 85

92 Chapter 11: Analysis and Verification 86 correct. In this way the subtle impact of the current anchor point on the size of the separating set while pruning was initially discovered and finally solved. The process of trying to discover where and why the Hamilton cycle counts differed led to many of the improvements introduced in this thesis Analysis All of the results listed in this section were generated by a PowerPC G5 running at 2.5 GHz. The operating system was Mac OS X (Tiger). While the machine was a 2 * Dual Core Machine (4 cores), only one core was used as the algorithm as implemented is purely a sequential one. A unix command line utility was written using the source code from within this thesis to run the implementation of the algorithm from this thesis. The previous version of the algorithm for [Koc92] was run from within a modified version of Groups and Graphs [gng]. This version was ported from CodeWarrior to the XCode programming environment in order to use the gcc compiler [ccg]. The version label of the compiler is powerpc-apple-darwin8-gcc All test data is based on object code generated using the same optimization parameters during compilation (gcc -fast -mcpu=g5 -mtune=g5). The source code of the implementation for this thesis should be fully portable across BSD, Linux and other Posix compliant operating environments. No endianness issues exist in the code and it should compile on most computing architectures. Essentially if gcc has been ported with the standard set of c libraries, it should compile

93 Chapter 11: Analysis and Verification 87 with little or no modification. The testing is broken up into three parts. The first, and most extensive part, demonstrates the performance of the new algorithm versus the old using a set of graphs known as knight s graphs, based upon the movement of knights on a variably sized chess board. As mentioned in [Van98], graphs of this type are suitable for comparative analysis of Hamilton cycle algorithms because they tend to be difficult to fully explore. These tests attempt to demonstrate the improvements brought on by the new segment extension algorithm, by the vertex selection modifications and the changes to the pruning algorithm. The second part of the test attempts to compare the two algorithm s performance against complete graphs. The characteristics of the complete graphs allow for an examination of the improvements brought by the removal of pass by value data. The final section of the analysis is based on the reduction algorithm and its use on the Meredith graph, or more specifically on what the consequences are of not using it are Knight s Move Graphs Table 11.1 introduces a set of the knight s graphs used for testing the implementations of the algorithm. Attributes such as number of vertices and edges along with the Hamilton cycle counts generated by the algorithms are listed. Table 11.2 lists the timing results for various parameters on the implementations of both versions of the algorithm and table 11.3 provides some ratios for comparing the performance of the algorithm based on the timings from table 11.2.

94 Chapter 11: Analysis and Verification 88 Table 11.1: Set of knight s move graphs used for primary test results. The Hamilton cycle counts found when exhaustive searching the entire search space for each graph is listed. Graph n ε Hamilton cycles kn kn kn4x kn5x kn5x kn6x kn6x kn7x Table 11.2: Times generated for the graphs from table Each of the times listed represent different algorithm parameters in use. All times listed are in seconds. Graph t old t desc t max t asc t bu t td kn kn kn4x kn5x kn5x kn6x kn6x kn7x The meanings of each of the timing parameters are the following: t old Represents timing results from the previous implementation from [Koc92] as implemented in [gng]. Recall that the previous algorithm used a dynamic ordering of vertices for anchor points based upon a maximum degree valued vertex. t desc Represents timing results that correspond to static orderings of the vertices with respect to a descending degree sequence. t asc Represents timing results that correspond to static orderings of the vertices with respect to an ascending degree sequence.

95 Chapter 11: Analysis and Verification 89 Table 11.3: Various ratio s of the timing results from table Graph t old /t desc t old /t max t max /t desc t asc /t desc t bu /t desc t td /t desc kn kn kn4x kn5x kn5x kn6x kn6x kn7x t max Represents timing results that correspond to a dynamic ordering of the vertices similar to the method used from [Koc92]. t td Represents timing results using the same vertex selection rules as t desc but with pruning enabled. The pruning used is an approximation of the top down approach used from [Koc92]. It is approximate in that the pruning tests are run after each anchor point is selected and just before extendanchor is run. The subtle difference being that in [Koc92] the top down pruning occurs after each consistent state is reached due to the selection of a single branching edge. t bu Represents timing results using the same vertex selection rules as t desc but with pruning enabled. The frequency of the pruning tests use the bottom up improvement introduced by this thesis. Unless otherwise specified none of the timing results have pruning enabled. The only timing results that use the previous algorithm from [Koc92] is the t old parameter.

96 Chapter 11: Analysis and Verification 90 Effects of Vertex Ordering In general when comparing the results using the ratios provided in Table 11.3, the changes to the algorithm show a substantial speed up over the previous algorithm from [Koc92]. The exception seems to be in the case when comparing the kn4x8 graph with the old algorithm when using the max degree approach in the new algorithm. One possibility here is that because the graph is not Hamiltonian and because the search happens so quickly, the number of branchings that occurs must be relatively few in number. This suggests that the faster sequential copies of the pass by value approach offsets the other gains of the new algorithm when using the max degree approach when a lower number of branches occur. More on this is explored in the second part of the analysis. One graph in particular seems to gain greatly by just using a descending degree sequence vs using the max degree approach. Graph kn7x4 has a great speedup over the original in this case. When removing the affects of the static orderings using t max, the speed up stays in line with the other graphs with larger search areas. By changing to an ascending degree sequence quite a few of the graphs show a speedup, particularly the kn7x4 graph, however the impact on the other graphs suggest that more than just degree values have an impact the size and shape of the search space. Pruning Algorithm The improvements brought by changing when to test for a pruning condition are made most apparent by the kn7x4 graph. Without the improvement, based on the

97 Chapter 11: Analysis and Verification 91 results shown, it could be assumed that little or no pruning actually takes place in this graph. But the 0.67 ratio for the t bu /t desc suggests that quite a bit of pruning occurs. In general the bottom up approach seems to provide quite a speed up compared to the top down approach. However the results for the kn5x8 graph suggest that in the cases where a smaller search space exists, a larger number of calls to the separating set test probably occur due to the nature of how the algorithm climbs up the tree in the bottom up approach Complete Graphs Table 11.4: Comparison of both multi-path Algorithms using no pruning and the default vertex orderings on a set of complete graphs. All times are in seconds. n ε t old t desc t old /t desc Table 11.4 contains the second set of comparative data of the two implementations based on tests of the complete graphs on 12 through 15 vertices. The meanings of the timing parameters t old and t desc are the same as in the previous section. Because of the high degree values of each of the vertices in the complete graph, the impact of the new segment extension algorithm is lessened. Additionally running the pruning algorithm on these graphs is pointless, as the majority of the leaves result in Hamilton cycles. Because of these factors, more emphasis can be placed upon the removal of the

98 Chapter 11: Analysis and Verification 92 pass by value data and the expected O(n) improvements per branching edge. As can be seen in the data provided, as the number of vertices increase so does the speedup. While it is impossible to test, theoretically it would be expected that this speedup would approach n for larger values of n. The initially lower speedup can partially be attributed to the differences in random memory movements vs fast sequential ones, since the new algorithm has more random memory reads and writes while restoring the graph states. As the number of vertices increase, the size of the O(n) sequential blocks used in the pass by value approach increase, and the benefit of the fast sequential copy of data loses ground to the lower O( S) random memory copies Reduction Technique on the Meredith Graph The Meredith graph is a non-hamiltonian graph that is extremely difficult for the multi-path algorithm to deal with. Much of the search space consists of multiple segments going into and out of individual half-bipartite subgraphs. This is what the reduction technique is meant to stop. Once the Meredith graph is reduced to the Petersen graph, the time spent running the multi-path algorithm (less than a second) is negligible compared to the original. While testing a previous version of the new algorithm, one that was closer to [Koc92] in performance, the algorithm spent over twenty five days running the algorithm before a power failure terminated the process. This was one of the prime motivations for moving towards an algorithm that could easily incorporate checkpointing. The new algorithm without pruning takes 11 days to exhaustively prove that the

99 Chapter 11: Analysis and Verification 93 Meredith graph is non-hamiltonian. With pruning enabled, this drops to only 4 days! Because of the variability in the speed up between graphs, it is hard to surmise what the actual runtime would be for the implementation from [Koc92]. However 4 days verses less than a second is a good indicator of how powerful the reduction technique could be when fully developed.

100 Chapter 12 Further Work During the course of developing the improvements described by this work many ideas of potential further study were envisioned with respect to the multi-path method, pruning the search space, and the reduction technique. A few of these ideas are listed here Multi-Path Algorithm A Closer Examination of Vertex Order A more extensive treatment of the static ordering of anchor point selection could allow for the identification of more properties of graphs and allow for further reductions in the size of the search space of the multi-path method. 94

101 Chapter 12: Further Work Algorithm for Directed Graphs The extension algorithm developed here could be adapted to work for directed graphs as most of the concepts carry over between graph types Fine Tuning for the TSP As seen with the explosive growth in time to exhaustively search complete graphs, it is still not very likely that an exhaustive approach to the Traveling Salesmen Problem, or TSP, will be forthcoming with the results given here. However the approximate results of the algorithms currently used by the TSP, could be used to seed the search space of the multi-path algorithm. In this way, by fixing certain segments and allowing others to change, a narrower area of the search space could be navigated and possible better solutions found A Work-Stealing Parallel Implementation Since most of the time searching is spent close to the right hand side of the tape when visualizing the search space with a Turing Machine, the left hand side of the tape could be used to offload work to parallel searches of the same graph. A parallel algorithm could be developed that uses the approach of stealing unsearched branching edges from anchor points located on the left hand side of the tape. These stolen branching edges can be safely removed from anchor points already within segments and passed to parallel searches that are initialized with the segment edges up to the location of the anchor point on the tape. In this way a good division

102 Chapter 12: Further Work 96 of the search tree may be achieved. The communications overhead of such an algorithm would be minimal and the execution would be extremely parallel, leading to potentially extremely good scaling characteristics Pruning Algorithm Constructing Components for Better Separating Sets The current mechanism for pruning back the search space approximates the changes to ω(g r K ) K. It would be nice to attempt to reconstruct the actual components of G r while pruning back the search space. This could allow for better detection of what vertices to add to K and even larger values of ω(g r K ) K as each new member of the separating set may actually disconnect two components joined via the segment the new member came from. By utilizing existing merge-find techniques for building up components, a method of creating a better separating set may be found Reduction Technique Finding More Reducible Subgraphs Finding reducible Complete Half-Bipartite Structures is a fairly limited endeavor for most graphs, especially when applied recursively as in the reduction technique. However reducible Half-Bipartite Structures that are not complete may occur with a

103 Chapter 12: Further Work 97 higher frequency, especially in reduced graphs. Strategies for finding them should be explored Reconstructing Hamilton Cycles in G α 1 The utility of the reduction technique is currently limited to quickly processing otherwise hard non-hamiltonian graphs. Since all Hamilton cycles in G α 1 must follow the route set out by Hamilton cycles in G α, a way to recursively reconstruct Hamilton cycles from G α up to G can probably be found and some work to that effect has already been started.

104 Bibliography [BM76] J. A. Bondy and U. S. R. Murty. Graph Theory With Applications. North Holland, [ccg] GNU C Compiler. [Chr75] Nicos Christofides. Graph Theory: An Algorithmic Approach. Academic Press Inc, [gng] Groups and Graphs. [Koc92] William Kocay. An extension of the multi-path algorithm for finding hamilton cycles. Discrete Mathematics, (101): , [Lin01] Peter Linz. An Introduction to Formal Languages and Automata. Jones and Bartlett Publishers, Inc., USA, [Rub74] Frank Rubin. A search procedure for hamilton paths and circuits. J. ACM, 21(4): , [Van98] Basil Vandegriend. Finding hamiltonian cycles: Algorithms, graphs and performance. Master s thesis, University of Alberta, [Wei95] Mark Allen Weiss. Data structures and algorithm analysis (2nd ed.). Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, USA,

105 Appendix A Multi-Path Code A.1 Data Types t y p e d e f s i g n e d i n t SInt ; t y p e d e f unsigned i n t UInt ; t y p e d e f i n t Vertex ; / Adjacency L i s t. / t y p e d e f s t r u c t v e r t e x a r c { Vertex t a r g e t ; / V e r t e x a d j a c e n t to c u r r e n t v e r t e x. / s t r u c t v e r t e x a r c next ; / Next a r c ( n u l l t e r m i n a t e d l i s t ). / s t r u c t v e r t e x a r c prev ; / P r e v i o u s a r c ( c i r c u l a r l i s t ). / s t r u c t v e r t e x a r c c r o s s ; / A d j a c e n t v e r t e x s l i s t. / } VArc ; / Graph I n f o r m a t i o n S t r u c t u r e Adapted from Groups and Graphs. / t y p e d e f s t r u c t graph { char name ; / Graph t i t l e. / UInt v e r t e x c o u n t ; / Number o f V e r t i c e s. / UInt edge count ; / Number o f e d g e s. / VArc a d j l i s t s ; / A r r a y o f a d j a c e n c y l i s t s. / bool adj matrix ; / Adjacency m a t r i x / UInt degree ; / d e g r e e l i s t / } GraphInfo ; / F l a g s c o n t r o l l i n g o v e r a l l s t a t e o f m u l t i path a l g o r i t h m / t y p e d e f s t r u c t h c f l a g s { bool usepruning ; bool pruneonce ; bool setpruningflags ; bool ishamiltonian ; bool ishamiltoncycle ; 99

106 Appendix A: Multi-Path Code 100 } HCFlags ; / Bit f i e l d r e f e r e n c e f o r edge s t a t u s s t o r e d i n t a p e e n t r i e s, t h e s t a t u s f l a g s i n code have m o s t l y same meaning to t h o s e found i n s e c t i o n The main d i f f e r e n c e s i s i f t h e anchor p o i n t i s t h e s o u r c e v e r t e x o f t h e b r a n c h i n g arc, t h e f l a g HC FLIP SOURCE i s used. / t y p e d e f enum { HC ENDPOINT = 1, HC ANCHOR POINT = 2, HC ANCHOR EXTEND = 4, HC FLIP SOURCE = 8, HC FORCED DEG2 = 16, HC FORCED = 32, HC HAMILTONIAN = 6 4, HC TERMINATE = 128 } HCArcStatus ; / S t o r a g e Type o f e n t r i e s f o r each p o s i t i o n i n Turing Machine / t y p e d e f s t r u c t hc tape { HCArcStatus s t a t u s ; VArc arc ; } HCTape ; / Multi Path S t a t e / s t r u c t h c s t a t e { HCFlags f l a g s ; GraphInfo graph ; / r e f e r e n c e to t a r g e t graph f o r s e a r c h / HCDFSRef d f s ; / s t a t e f o r p r u n i n g a l g o r i t h m / VArc a d j L i s t ; / a d j a c e n c y l i s t s f o r each v e r t e x / UInt vertexcount ; / i n i t i a l number o f v e r t i c e s i n graph / HCTape pos ; / c u r r e n t p o s i t i o n o f r e a d / w r i t e head / HCTape o r i g i n ; / s t a r t o f Tape f o r t u r i n g machine / UInt degree ; / c u r r e n t d e g r e e o f each v e r t e x / Vertex v i r t u a l E d g e ; / c u r r e n t v i r t u a l e d g e s / Vertex vertexorder ; / o r d e r f o r anchor p o i n t s e l e c t i o n / VArc removededges ; / c u r r e n t l i s t o f removed e d g e s / VArc removededgesstack ; / s t a c k o f l i s t s o f removed e d g e s / Vertex deg2stack ; / f o r c e d v e r t e x s t a c k / } ; t y p e d e f s t r u c t h c s t a t e HCStateRef ;

107 Appendix A: Multi-Path Code 101 A.2 Extending Segments A.2.1 Support Routines for Extending Segments / f i n d and remove a r c from a d j a c e n c y l i s t Lx / void removearc ( VArc Lx, VArc a ) { /... / } / i n s e r t a r c to t h e top o f a d j a c e n c y l i s t Lx / void i n s e r t A r c ( VArc Lx, VArc a ) { /... / } / Removes t h e b i t f l a g s t h a t i n d i c a t e an e n d p o i n t o f a segment. R e s t o r e s t h e incoming a r c a i f n e c e s s a r y. / void f i x I n A r c ( VArc L, VArc a, Vertex x, UInt kptr ) { UInt k = kptr ; i f ( k & (HC ENDPOINT ) ) { i n s e r t A r c ( L + x, a ) ; k &= HC ENDPOINT; kptr = k ; } } / f i x I n A r c / / Remove a l l but one o f t h e incoming a r c s o f t h e s o u r c e v e r t e x o f a r c a. The i n i t i a l incoming a r c ( a >c r o s s ) i s not removed. / bool removeforcedd2inarcs ( VArc L, VArc a, UInt d, Vertex d2ptr ) { Vertex y ; UInt dy ; Vertex d2 = d2ptr ; VArc p = a >prev ; do { y = p >t a r g e t ; dy = d [ y ] ; i f ( dy == 2 ) break ;

108 Appendix A: Multi-Path Code 102 i f ( dy == 2 ) (++d2 ) = y ; d [ y ] = dy ; removearc ( L + y, p >c r o s s ) ; p = p >prev ; } w h i l e ( a!= p ) ; i f ( a!= p ) { / deg 1 v e r t e x e n c o u n t e r e d / / r e s t o r e from a to n b e f o r e e x i t i n g / a = a >prev ; w h i l e ( a!= p ){ y = a >t a r g e t ; d [ y]++; i n s e r t A r c ( L + y, a >c r o s s ) ; a = a >prev ; } } r e t u r n true ; d2ptr = d2 ; r e t u r n f a l s e ; } / removeforcedd2inarcs / A.2.2 Main Routine for Extending Segments / Extend a l l segments f o r t h i s s t a t e o f t h e graph. The e x t e n t i o n o f t h e segment i s attempted from both s i d e s o f t h e segment u n t i l no f u r t h e r e x t e n t i o n p o s s i b l e w i t h c u r r e n t graph s t a t e. This p r o c e d u r e f o l l o w s t h e i n i t i a l v e c t o r p r o v i d e d by t h e a r c a and f o l l o w s t h e path u n t i l no d e g r e e 2 v e r t e x i s e n c o u n t e r e d o r u n t i l a c y c l e i s c r e a t e d by h i t t i n g v e r t e x z ( t h e o t h e r s i d e o f t h e segment ). When t h e e x t e n t i o n i n c u r r e n t d i r e c t i o n p r o v i d e d by a r c a can go no f u r t h e r, t h e e n d p o i n t z may have been r e d u c e d to d e g r e e 2. I n t h i s c a s e t h e new e n d p o i n t and z a r e swapped, a new i n i t i a l a r c i s chosen a t z and t h e p r o c e s s i s r e p e a t e d u n t i l s e a r c h t e r m i n a t e d o r u n t i l no f u r t h e r e x t e n t i o n p o s s i b l e from e t h e r s i d e o f t h e segment. Once a segment has been c o m p l e t e l y e x t e n d e d to i t s maximal l e n g t h w i t h i n i t s l o c a l domain, t h e p r o c e s s i s r e p e a t e d on a new segment u n t i l t h e d e g r e e 2

109 Appendix A: Multi-Path Code 103 s t a c k d2 i s r e d u c e d to 0. P r o c e d u r e r e t u r n s t r u e i f c u r r e n t s t a t e o f graph t e r m i n a t e s s e a r c h, i e. when a v e r t e x i s r e d u c e d to d e g r e e o f 1 o r a c y c l e i s f o r c e d. A c y c l e can o n l y be f o r c e d when t h e c u r r e n t segment e n c o u n t e r s i t s o t h e r e n d p o i n t w h i l e t r y i n g to e x t e n d. / bool extendsegments ( HCStateRef s, VArc a, Vertex z, UInt k, Vertex d2 ) { Vertex ex, x ; VArc c ; / c r o s s a r c d i r e c t e d a t c u r r e n t e n d p o i n t / UInt d = s >degree ; Vertex e = s >v i r t u a ledge ; VArc L = s >a d j L i s t ; HCTape hz = NULL; / t a p e p o s i t i o n f o r o t h e r e n d p o i n t / HCTape hx = s >pos ; / t a p e p o s i t i o n f o r c u r r e n t e n d p o i n t / extend segment : / attempt to t r a v e r s e a r c a / c = a >c r o s s ; x = a >t a r g e t ; / s t o r e c r o s s i n t a p e so t h a t i n n e g a t i v e d i r e c t i o n a r c t a r g e t a l w a y s p o i n t s a t a v e r t e x to be r e s t o r e d / hx++; hx >arc = c ; i f ( x == z ) { / a c y c l e i s f o r c e d / i f ( hz ) f i x I n A r c ( L, hz >arc, z, &hz >s t a t u s ) ; / r e s t o r e f o c a l p o i n t, no l o n g e r n e s s a r y to m a i n t a i n t a p e p o s i t i o n a t t h i s p o i n t / d [ c >t a r g e t ] = 2 ; s >pos = hx 1 ; / d e t e r m i n e i f c y c l e i s a Hamilton c y c l e / hx++; s >f l a g s. ishamiltoncycle = hx >s t a t u s == HC HAMILTONIAN;

110 Appendix A: Multi-Path Code 104 } r e t u r n f a l s e ; i f ( ( ex = e [ x ] ) ) { / a r c has c o l l i d e d w i t h a v i r t u a l edge / / attempt remove t h e t a r g e t o f a r c ( x ) from graph and c o n t i n u e to e x t e n d t h e segment. / i f ( d [ x ] > 2 ) { i f ( removeforcedd2inarcs ( L, c, d, &d2 ) ){ / e n s u r e t h a t segment e n d p o i n t i n f o removed and t h a t s o u r c e o f a r c a i s p l a c e d back on graph / } i f ( hz ) f i x I n A r c ( L, hz >arc, z, &hz >s t a t u s ) ; hx >s t a t u s = k ; s >pos = hx ; r e t u r n f a l s e ; } k = HC FORCED DEG2; hx >s t a t u s = k HC FORCED; d [ x ] = 0 ; i f ( d [ ex ]!= 2 ) { / The o t h e r s i d e o f o f v i r t u a l edge w i l l not a l l o w segment to c o n t i n u e i n c u r r e n t d i r e c t i o n / i f ( d [ z ]!= 2 ) { x = ex ; goto f i n i s h s e g m e n t ; } / O t h e r s i d e o f segment i s to be f o r c e d onto t h e c y c l e, grow segment i n t h e x >z d i r e c t i o n. Two p o s s i b l i t i e s on what a r c to e x t e n d a t z. The f i r s t i s t h a t z was a d e g r e e 2 v e r t e x not on a v i r t u a l edge. The L [ z ] a r c i s t h e a r c f i r s t used to e x t e n d segment towards c u r r e n t x. S i n c e L [ z ] i s o f d e g r e e 2 we know t h a t t h e p r e v i o u s a r c i s t h e o t h e r a r c p o i n t i n g out o f z. The second c a s e i s t h a t L [ z ] i s a l r e a d y on a v i r t u a l edge. I n

111 Appendix A: Multi-Path Code 105 t h i s c a s e L [ z ] w i l l o n l y have one a r c i n i t s l i s t and L [ z] > p r e v == L [ z ]. By c h o o s i n g L [ z] > p r e v i n both c a s e s an e x p e n s i v e branch i s a v o i d e d. The same r e a s o n i n g a p p l i e s whenever L [ z] > p r e v i s chosen when s w i t c h i n g e n d p o i n t s / a = L [ z] >prev ; d [ z ] = 0 ; i f ( hz ) f i x I n A r c ( L, hz >arc, z, &hz >s t a t u s ) ; z = ex ; hz = hx ; k = 0 ; } goto extend segment ; / c o n t i n u e growing segment i n t h e c u r r e n t d i r e c t i o n / k = 0 ; d [ ex ] = 0 ; a = L [ ex ] ; } goto extend segment ; i f ( d [ x ] == 2 ) { / x i s d e g r e e 2, add a r c and c o n t i n u e i n same d i r e c t i o n / hx >s t a t u s = k ; k = 0 ; d [ x ] = 0 ; } a = c >prev ; goto extend segment ; / Segment can not be e x t e n d e d f u r t h e r i n c u r r e n t d i r e c t i o n, remove a r c p o i n t i n g i n t o segment. / hx >s t a t u s = k HC ENDPOINT; removearc ( L + x, c ) ; i f ( d [ z ]!= 2 ) goto f i n i s h s e g m e n t ;

112 Appendix A: Multi-Path Code 106 a = L [ z] >prev ; i f ( hz ) f i x I n A r c ( L, hz >arc, z, &hz >s t a t u s ) ; d [ z ] = 0 ; z = x ; hz = hx ; k = 0 ; goto extend segment ; f i n i s h s e g m e n t : / A m u l t i g r a p h may have been c r e a t e d. Segment end p o i n t s x & z may be p h y s i c a l l y a d j a c e n t a l o n g w i t h t h e i r new v i r t u a l edge j o i n i n g them. Remove a c t u a l edge to t a k e away t h e m u l t i g r a p h s t a t u s. / i f ( d [ z ] < d [ x ] ) { a = L [ z ] ; w h i l e ( a && a >t a r g e t!= x ) a = a >next ; } e l s e { a = L [ x ] ; w h i l e ( a && a >t a r g e t!= z ) a = a >next ; } i f ( a ) { c = a >c r o s s ; removearc ( L + a >target, c ) ; removearc ( L + c >target, a ) ; a >next = s >removededges ; s >removededges = a ; i f ( d [ x ] == 2 ) { d [ z] ; d [ x ] = 0 ; } a = L [ x] >prev ; f i x I n A r c ( L, hx >arc, x, &hx >s t a t u s ) ; k = 0 ; goto extend segment ; i f ( d [ z ] == 2 ) { a = L [ z] >prev ; i f ( hz ) f i x I n A r c ( L, hz >arc, z, &hz >s t a t u s ) ; d [ z ] = 0 ;

113 Appendix A: Multi-Path Code 107 } hz = hx ; z = x ; k = 0 ; goto extend segment ; } / a new v i r t u a l edge has been c r e a t e d t h a t i s c o n s i s t a n t w i t h i n i t s l o c a l a r e a o f t h e graph ( i t s e n d p o i n t s ) / e [ z ] = x ; e [ x ] = z ; / check i f any more segments need to be grown / do x = d2 ; w h i l e ( x &&! d [ x ] ) ; i f ( x ) { / t h e r e i s a d e g r e e 2 v e r t e x s t i l l on t h e s t a c k, c r e a t e a new segment o r e n l a r g e an e x i s t i n g one / i f ( ( z = e [ x ] ) ) d [ x ] = 0 ; / e n l a r g e a segment / e l s e z = x ; / s t a r t s a new segment / a = L [ x ] ; hz = NULL; k = 0 ; } goto extend segment ; s >pos = hx ; r e t u r n true ; } / extendsegments / A.3 Extending Branches / The t a r g e t e d a r c r e p r e s e n t s a v e r t e x a l r e a d y on a segment e n d p o i n t and needs to have a l l incoming a r c s removed but t h e a r c o p p o s i t e to a. R e t u r n s updated s t a c k o f new f o r c e d v e r t i c e s t h a t a r e p a s s e d v i a d2. / Vertex removeinarcs ( VArc L, VArc a, UInt d, Vertex d2 ) { Vertex x ; VArc p = a >prev ;

114 Appendix A: Multi-Path Code 108 w h i l e ( p!= a ) { x = p >t a r g e t ; i f ( d [ x ] == 2 ) (++d2 ) = x ; removearc ( L + x, p >c r o s s ) ; p = p >prev ; } r e t u r n d2 ; } / r e m o v e I n A r c s / / Extend o r c r e a t e a segment and remove t h e v e r t e x x from t h e graph by marking one o r two a r c s e x t e n d i n g out o f i t as p i v o t a r c ( s ). The c a l l to extendanchor must o n l y be done w h i l e t h e graph i s i n a c o n s i s t a n t s t a t e. / bool extendanchor ( HCStateRef s, VArc L, Vertex e, UInt d, Vertex x ) { Vertex y, ex ; VArc a ; UInt k ; Vertex d2 = s >deg2stack ; i f ( ( ex = e [ x ] ) ) { / c a s e 1 : s o u r c e v e r t e x o f c u r r e n t a r c i s a l r e a d y on a v i r t u a l edge } and must be f o r c e d onto t h e p o t e n t i a l h a m i l t o n c y c l e / s >removededgesstack++ = s >removededges ; s >removededges = NULL; a = L [ x ] ; k = HC ANCHOR POINT HC ANCHOR EXTEND; d [ x ] = 0 ; r e t u r n extendsegments ( s, a, ex, k, removeinarcs ( L, a, d, d2 ) ) ; a = L [ x ] ; y = a >t a r g e t ; i f ( ( ex = e [ y ] ) ) { / c a s e 2 : same as f i r s t c a s e but o r i g i n f l i p p e d / k = HC ANCHOR POINT HC FLIP SOURCE HC ANCHOR EXTEND; a = a >c r o s s ;

115 Appendix A: Multi-Path Code 109 } s >removededgesstack++ = s >removededges ; s >removededges = NULL; d [ y ] = 0 ; i f (! extendsegments ( s, a, ex, k, removeinarcs ( L, a, d, d2 ) ) ) r e t u r n f a l s e ; i f (! d [ x ] ) r e t u r n true ; s >removededgesstack++ = s >removededges ; s >removededges = NULL; a = L [ x ] ; d [ x ] = 0 ; k = HC ANCHOR POINT HC ANCHOR EXTEND; r e t u r n extendsegments ( s, a, e [ x ], k, removeinarcs ( L, a, d, d2 ) ) ; / c a s e 3 : n e i t h e r t h e s o u r c e o r t h e t a r g e t o f t h e a r c i s on a v i r t u a l edge, s i m p l e j o i n them by a v i r t u a l edge and remove t h e two a r c s j o i n i n g them. / s >removededgesstack++ = s >removededges ; removearc ( L + y, a >c r o s s ) ; removearc ( L + x, a ) ; e [ x ] = y ; e [ y ] = x ; s >pos++; s >pos >arc = a >c r o s s ; s >pos >s t a t u s = HC ANCHOR POINT; s >removededgesstack++ = NULL; s >removededges = NULL; a = L [ x ] ; d [ x ] = 0 ; k = HC ANCHOR POINT HC ANCHOR EXTEND; r e t u r n extendsegments ( s, a, y, k, removeinarcs ( L, a, d, d2 ) ) ; } / extendanchor / / Removed e d g e s form a n u l l t e r m i n a t e d s i n g l y l i n k e d l i s t u s i n g t h e a >n e x t v a l u e o f each arc, s t a R e s t o r e each arc, u s i n g t h e a >c r o s s to f i n d out t h e o r i g i n. Ensure to update d e g r e e v a l u e s f o r ea

116 Appendix A: Multi-Path Code 110 void r e s t o r e E d g e s ( VArc L, VArc a, UInt d ) { Vertex u, v ; VArc n ; w h i l e ( a ) { n = a >next ; u = a >t a r g e t ; v = a >c r o s s >t a r g e t ; i n s e r t A r c (L + u, a >c r o s s ) ; i n s e r t A r c (L + v, a ) ; d [ u]++; d [ v]++; a = n ; } } / r e s t o r e E d g e s / / Remove branch a t hx. Return t h e anchor p o i n t t h a t t h e b r a n c h i n g edge was o f f o f. / Vertex rotateanchorpoint ( HCStateRef s, VArc L, Vertex e, UInt d, HCTape hx, Vertex d2ptr ) { Vertex d2 = s >deg2stack ; VArc a = hx >arc ; UInt k = hx >s t a t u s ; Vertex x = a >t a r g e t ; VArc c = a >c r o s s ; Vertex y = c >t a r g e t ; i f ( k & HC ANCHOR EXTEND ) { u n r o l l A r c ( L, e, d, a, k ) ; e [ e [ x ] ] = x ; d [ x ] = 2 + restoreinarcswithcount ( L, c, d ) ; removearc ( L + x, c ) ; removearc ( L + y, a ) ; } e l s e { } e [ x ] = 0 ; e [ y ] = 0 ; / R e s t o r e e d g e s removed d u r i n g p r e v i o u s branch /

117 Appendix A: Multi-Path Code 111 r e s t o r e E d g e s ( L, s >removededges, d ) ; / Remove t h e edge c u r r e n t anchor p o i n t r e p r e s e n t s and g i v e i t to t h e c l o s e s t p i v o t p o i n t to t h e l e f t to r e s t o r e. This i n d i c a t e s t h a t no more s e a r c h p o s s i b l e w i t h t h e edge i n q u e s t i o n. ( o r a t l e a s t u n t i l p i v o t p o i n t to t h e l e f t e n c o u n t e r e d. ) / a >next = s >removededgesstack ; s >removededges = a ; i f ( d [ y ] == 2 ) (++d2 ) = y ; i f ( d [ x ] == 2 ) (++d2 ) = x ; d2ptr = d2 ; s >pos = hx 1 ; i f ( k & HC FLIP SOURCE ) r e t u r n y ; r e t u r n x ; } / r o t a t e A n c h o r P o i n t / Vertex e n s u r e C o n s i s t e n t ( HCStateRef s, VArc L, Vertex e, UInt d, Vertex d2, Vertex x, Vertex nv ) { Vertex ey ; Vertex y = d2 ; / no v e r t i c e s have been f o r c e d, r e t u r n x as n e x t p i v o t p o i n t / i f (! y ) r e t u r n x ; / f o r c e d v e r t i c e s, e n s u r e graph i s c o n s i s t a n t / ey = e [ y ] ; i f ( ey ) d [ y ] = 0 ; e l s e ey = y ; i f (! extendsegments ( s, L [ y ], ey, 0, d2 ) ) r e t u r n 0 ; / x may have been a b s o r b e d by a segment, e n s u r e r e t u r n o f n e x t a v a i l a b l e p i v o t / i f (! d [ x ] ) { s >pos >s t a t u s = HC ANCHOR TYPE1; do x = nv [ x ] ; w h i l e (! d [ x ] ) ; }

118 Appendix A: Multi-Path Code 112 } r e t u r n x ; / I n i t i a l i z e t a p e to f i r s t l e a f i n s e a r c h s p a c e. R e t u r n s t r u e o n l y i f runturingmachine can be e n t e r e d. / s t a t i c Vertex primetape ( HCStateRef s, EList requirededges ) { UInt dx ; Vertex ex ; Vertex x = s >vertexcount + 1 ; VArc L = s >a d j L i s t ; Vertex e = s >v i r t u aledge ; UInt d = s >degree ; Vertex nv = s >vertexorder ; / nv [ x ] i s t h e n e x t v e r t e x a f t e r x / Vertex d2 = s >deg2stack ; / s t a c k o f f o r c e d v e r t i c e s, 0 means empty / / check f o r any d e g r e e 2 v e r t i c e s, o r s t o p c o n d i t i o n / w h i l e ( x ){ dx = d [ x ] ; i f ( dx < 2 ) r e t u r n f a l s e ; i f ( dx == 2 ) (++d2 ) = x ; } / f o r c e any d e g r e e 2 v e r t i c e s onto segments / x = d2 ; i f ( x ) { ex = e [ x ] ; i f ( ex ) d [ x ] = 0 ; e l s e ex = x ; } i f (! extendsegments ( s, L [ x ], ex, 0, d2 ) ) r e t u r n! s >f l a g s. ishamiltoncycle ; / r e p e a t e d l y p l a c e b r a n c h i n g e d g e s u n t i l s t o p c o n d i t i o n r e a c h e d / x = 0 ; do { do x = nv [ x ] ; w h i l e (! d [ x ] ) ; } w h i l e ( extendanchor ( s, L, e, d, x ) ) ; r e t u r n! s >f l a g s. ishamiltoncycle ; } / primetape /

119 Appendix A: Multi-Path Code 113 A.4 Restoring Graph s t a t i c i n l i n e UInt restoreinarcswithcount ( VArc L, VArc a, UInt d ) { Vertex v ; UInt c = 0 ; VArc p = a >prev ; w h i l e ( p!= a ) { v = p >t a r g e t ; i n s e r t A r c ( L + v, p >c r o s s ) ; d [ v]++; p = p >prev ; c++; } r e t u r n c ; } / r e s t o r e I n A r c s W i t h C o u n t / s t a t i c i n l i n e void u nrollarc ( VArc L, Vertex e, UInt d, VArc a, UInt k ) { Vertex x ; / R e s t o r e a r c : y< a x / i f ( k & HC ENDPOINT ) { x = a >c r o s s >t a r g e t ; i n s e r t A r c ( L + x, a ) ; e [ x ] = 0 ; } e l s e i f ( k & HC FORCED ) { x = a >c r o s s >t a r g e t ; e [ e [ x ] ] = x ; d [ x ] = ( k & HC FORCED DEG2)? restoreinarcswithcount ( L, a, d ) + 2 : 2 ; } } / u n r o l l A r c / s t a t i c i n l i n e HCTape unwindsearchedge ( VArc L, Vertex e, UInt d, HCTape hx ) { UInt k = hx >s t a t u s ; Vertex x ;

120 Appendix A: Multi-Path Code 114 VArc a ; / r o l l back graph s t a t e to c l o s e s t anchor p o i n t / w h i l e (! ( k & (HC ANCHOR POINT HC TERMINATE) ) ) { a = hx >arc ; x = a >t a r g e t ; / NEGATIVE DIRECTION / / r e s t o r e v e r t e x / u n r o l l A r c ( L, e, d, a, k ) ; d [ x ] = 2 ; e [ e [ x ] ] = x ; } / move t a p e head to t h e l e f t and r e s t a r t l o o p / hx ; k = hx >s t a t u s ; r e t u r n hx ; } / unwindsearchedge /

121 Appendix B Pruning Algorithm B.1 Data Types / S t r u c t u r e s t o r i n g DFS s t a t e i n f o r m a t i o n. This i s f o r a non r e c u r s i v e d f s a l g o r i t h m t h a t p r o c e s s e s t h e e n t i r e s t a c k m a n u a l l y. / s t r u c t dfs compbipt { /! A r r a y i n d e x e d by v e r t i c e s. I n d i c a t e s t r a v e r s a l number o f each i n d e x e d v e r t e x. / UInt v i s i t ; /! A r r a y i n d e x e d by v e r t i c e s. I n d i c t a t e s l o w e s t t r a v e r s a l v a l u e e n c o u n t e r d by t h e i n d e x e d v e r t e x d u r i n g t h e d f s. / UInt low ; /! A r r a y i n d e x e d by v e r t i c e s. A non z e r o v a l u e a t a v e r t e x s i n d e x i n d i c a t e s t h a t s a i d v e r t e x i s a c u t p o i n t. The v a l u e i n d i c a t e s t h e number o f p o t e n t i a l components s u r r o u n d i n g t h e i n d e x e d v e r t e x. / UInt components ; UInt branches ; /! A r r a y i n d e x e d by v e r t i c e s. C o n t a i n s b i p a r t i t e s e t membership f o r i n d e x e d v e r t i c e s. / SInt c o l o u r ; /! A r r a y i n d e x e d by v e r t i c e s. C o n t a i n s node p o i n t e r o f a v e r t e x s a r c p o i n t i n g to t h e r e t u r n v e r t e x f o r t h e non r e c u r s i v e d f s a l g o r i t h m. The d f s a l g o r i t h m i n d f s c c b u s e s t h e c i r c u l a r l y l i n k e d p r e v v a l u e o f a node to t r a v e r s e t h e t a r g e t graph. The v a l u e s t o r e d by t h e s t o p a r r a y i s used to s t o p i t e r a t i o n o v e r a v e r t e x and ascend back up t h e s e a r c h t r e e. / VArc i t e r a t o r ; 115

122 Appendix B: Pruning Algorithm 116 } ; Vertex p r e v i o u s ; UInt s t a t e S i z e ; / Number o f v e r t i c e s s t r u c t u r e a l l o c a t e d w i t h / B.2 Depth First Search (DFS) B.2.1 Main DFS algorithm /! I n i t i a l i z e d f s s t a t e f o r f i r s t c a l l to d f S e p a r a t i n g S e t \param s d f s s t a t e to be i n i t i a l i z e d / void i n i t D f S e p a r a t i n g S e t ( HCDFSRef d f s ) { memset ( dfs >v i s i t, 0, dfs >s t a t e S i z e s i z e o f ( UInt ) ) ; } / i n i t D f S e p a r a t i n g S e t / /! T r a v e r s e s graph i n a depth f i r s t s e a r c h, f i n d i n g components, c u t p o i n t s and b i p a r t i t i o n s. This non r e c u r s i v e v e r s i o n r e q u i r e s e n t i r e s t a c k to be a l l o c a t e d a t once. This i s h a n d l e d by allocdfs. P r i o r to t h e f i r s t c a l l to d f S e p a r a t i n g S e t f o r a t a r g e t graph, i n i t D f S e p a r a t i n g S e t must be c a l l e d. P r o c e d u r e may be c a l l e d r e p e a t e d l y u n t i l r e t u r n e d v a l u e e q u a l s number o f v e r t i c e s i n t a r g e t graph. This w i l l e n s u r e p r o p e r v a l u e s f o r t h e number o f components and c u t p o i n t s found i n t h e graph. / UInt d f S e p a r a t i n g S e t ( HCDFSRef dfs, VArc L, Vertex e, Vertex x, UInt pos, UInt d i f f, bool xinsep, bool hascutpoint ) { UInt lx, ly, bx, cmx ; SInt cx ; Vertex px ; Vertex p = dfs >p r e v i o u s ; VArc n = dfs >i t e r a t o r ; UInt b = dfs >branches ; SInt c = dfs >c o l o u r ; UInt l = dfs >low ;

123 Appendix B: Pruning Algorithm 117 UInt v = dfs >v i s i t ; bool bp = true ; Vertex y = x ; VArc a = NULL; UInt vy = 0 ; / t y p i c a l l y v i s i t o r d e r o f v [ y ] / UInt cd = 0 ; / o p t i m i z e d components c u t p o i n t s / UInt cp = 0 ; / c u t p o i n t s / UInt cm = d f s >components ; SInt bd = 0 ; / b i p a r t i t e d i f f e r e n c e / b [ 0 ] = 0 ; c [ 0 ] = 1 ; x = 0 ; l x = 0 ; f o r ( ; ; ) { w h i l e (! vy ) { / descend i n t o y / n [ x ] = a ; p [ y ] = x ; i f ( bp ) { / b i p a r t i t e so f a r, s e e i f y can be added to a s e t / cx = c [ x ] ; c [ y ] = cx ; bd += cx ; } x = y ; a = L [ x ] ; b [ x ] = 0 ; cm [ x ] = 0 ; l x = ++pos ; v [ x ] = l x ; l [ x ] = l x ; y = e [ x ] ; i f (! y ) { y = a >t a r g e t ; a = a >next ; } } vy = v [ y ] ; / e n s u r e t h a t y i t e r a t e s to u n v i s i t e d v e r t e x / px = p [ x ] ; cx = c [ x ] ; do {

124 Appendix B: Pruning Algorithm 118 i f ( px!= y ) { i f ( l x > vy ) l x = vy ; i f ( bp ) bp = cx!= c [ y ] ; } i f (! a ) { y = 0 ; break ; } y = a >t a r g e t ; a = a >next ; vy = v [ y ] ; } w h i l e ( vy ) ; l [ x ] = l x ; i f ( y ) c o n t i n u e ; / ascend out o f x / do { y = px ; cmx = cm [ x ] ; bx = b [ x ] ; i f (! y ) goto done ; l y = l [ y ] ; vy = v [ y ] ; i f ( bx ) { / update components c u t p o i n t s / cp++; i f (cmx>1) cd += (cmx 1 ) ; } i f ( l x == vy ) cm [ y]++; e l s e i f ( l x > vy && cmx == 1 ) cm [ y]++; / check f o r branch / i f ( l x >= vy ) b [ y]++; e l s e i f ( l y > l x ) l [ y ] = l y = l x ; x = y ; l x = l y ; a = n [ x ] ; px = p [ x ] ; } w h i l e (! a ) ; y = a >t a r g e t ;

125 Appendix B: Pruning Algorithm 119 } done : a = a >next ; vy = v [ y ] ; / update components c u t p o i n t s / i f ( bx > 1 ) cp++; i f ( cmx > 1 ) cd += (cmx 1 ) ; / r e t u r n maximum s e p a r a t i n g s e t found and e n s u r e x i s counted i n s e p a r a t i n g s e t i f r e q u i r e d / hascutpoint = cp > 0 ; i f (! cp &&! bp ) { d i f f = 0 ; r e t u r n pos ; } i f ( bp ) { i f ( xinsep && bd < 0 ) bd += 2 ; i f ( bd < 0 ) bd = bd ; } e l s e bd = 0 ; d i f f = ( ( UInt ) bd ) > cd? ( UInt ) bd : cd ; r e t u r n pos ; } / d f S e p a r a t i n g S e t / B.2.2 Routine for calculating Component / Separating Set differences. /! \ r e t u r n s t r u e i f a p r u n i n g c o n d i t i o n found. The d i f f e r e n c e i n t h e number o f components v s s e p a r a t i n g s e t i s r e t u r n e d i n c. The i n S e p S e t f l a g i n d i c a t e s t h a t x s h o u l d be c o n s i d e r e d a p a r t o f what e v e r s e p a r a t i n g s e t found. / bool getcomponentdiff ( HCDFSRef d f s, VArc L, Vertex e, UInt d, Vertex nv, Vertex x, SInt c, bool insepset ) { UInt v ; UInt pts = c ; UInt p = 0 ; UInt d i f f = 0 ; UInt t d i f f = 0 ;

126 Appendix B: Pruning Algorithm 120 bool cp = f a l s e ; i n i t D f S e p a r a t i n g S e t ( d f s ) ; p = d f S e p a r a t i n g S e t ( dfs, L, e, x, p, &d i f f, insepset, &cp ) ; i f ( p < pts ) { v = dfs >v i s i t ; t d i f f = 0 ; w h i l e ( v [ x ]! d [ x ] ) x = nv [ x ] ; w h i l e ( ( p = d f S e p a r a t i n g S e t ( dfs, L, e, x, p,& t d i f f, f a l s e,&cp ) ) < pts ) { d i f f += ( t d i f f >0)? t d i f f : 1 ; t d i f f = 0 ; w h i l e ( v [ x ]! d [ x ] ) x = nv [ x ] ; } } d i f f += ( t d i f f >0)? t d i f f : 1 ; cp = true ; c = d i f f ; r e t u r n cp d i f f > 0 ; } / getcomponentdiff / B.3 Turing Machine for Pruning Condition B.3.1 Pruning / r e t u r n t r u e i f unwound a l l t h e way back to i n i t i a l graph s t a t e / s t a t i c HCTape prunesearchspace ( HCStateRef s, SInt c ) { HCTape hx ; UInt d = s >degree ; Vertex e = s >v i r t u aledge ; VArc L = s >a d j L i s t ; HCTape stop = hx = s >pos ; UInt k = stop >s t a t u s ; w h i l e (! ( k & HC TERMINATE ) && ( c > 0) ) { i f ( k & HC ANCHOR TYPE1 ) c ; i f ( k & HC ANCHOR POINT ) c ; i f ( k & HC FORCED DEG2 ) c ; } stop ; k = stop >s t a t u s ;

127 Appendix B: Pruning Algorithm 121 } stop++; hx = unwindsearchedge ( L, e, d, hx ) ; w h i l e ( hx > stop ) { restoreanchorpoint ( s, L, e, d, hx ) ; hx = unwindsearchedge ( L, e, d, hx 1 ) ; } r e t u r n hx ; B.3.2 Main Turing Machine Code / Run Turing Machine u n t i l a Hamilton c y c l e i s found o r s e a r c h s p a c e i s e x h a u s t e d. Ensure t h a t t a p e i s primed f i r s t b e f o r e c a l l i n g. R e t u r n s f a l s e when s e a r c h s p a c e e x h a u s t e d. The v e r s i o n o f t h e Turing Machine f o r t h e Multi Path a l g o r i t h m t h a t implements t h e p r u n i n g a l g o r i t h m u s i n g t h e bottom up approach to t h e p r u n i n g. The l e a f node, o r l o w e s t anchor p o i n t, i s t r a c k e d u s i n g t h e l o w C e l l and h i g h C e l l v a r i a b l e s. The l o w C e l l v a r i a b l e i s updated to a l w a y s p o i n t to t h e l o w e s t b r a n c h i n g edge i n t h e t a p e. I f hx i s e v e r found to be h i g h e r up t h e s e a r c h s p a c e then l o w C e l l, an e x h u s t i v e l y s e a r c h e d l e a f node w i l l have been found. At t h i s p o i n t t h e prune f l a g can be s e t and a t e s t f o r a p r u n i n g c o n d i t i o n can o c c u r a t t h e n e x t c o n s i s t e n t s t a t e i n t h e s e a r c h s p a c e. One c a v i o t i s t h a t some l e a f nodes w i l l be m i s s e d when re e n t e r i n g t h e machine a f t e r f i n d i n g a Hamilton c y c l e. G e n e r a l l y t h e l e a f nodes c l o s e s t to t h e s t o p p i n g c o n d i t i o n t h a t found t h e Hamilton c y c l e a r e avoided, as no s e p a r a t i n g s e t i s l i k e l y to be found t h a t s a t i s f i e s t h e p r u n i n g lemma. / s t a t i c bool runturingmachinewithpruning ( HCStateRef s ) { Vertex d2, x1, x, v ; SInt c ; HCTape hx ; / r e a d / w r i t e head f o r t a p e / HCTape h i g h C e l l = s >o r i g i n ; / t r a c k s r e s e t p o i n t f o r l o w C e l l / HCTape lowcell = h i g h C e l l ; / t r a c k s l e a f node i n s e a r c h s p a c e / bool prune = f a l s e ; / i n d i c a t e s p r u n i n g s h o u l d o c c u r / UInt d = s >degree ; Vertex e = s >v i r t u a ledge ; Vertex nv = s >vertexorder ; VArc L = s >a d j L i s t ; s >f l a g s. ishamiltoncycle = f a l s e ;

128 Appendix B: Pruning Algorithm 122 / t a p e head must be a t a l e a f i n s e a r c h space, move t a p e head l e f t to t h e c l o s e s t b r a n c h i n g edge / hx = unwindsearchedge (L, e, d, s >pos ) ; w h i l e (! ( hx >s t a t u s & HC TERMINATE) ) { / remove t h e e x h a u s t e d b r a n c h i n g edge and s w i t c h d i r e c t i o n s / x1 = rotateanchorpoint ( s, L, e, d, hx, &d2 ) ; / r e m oval o f b r a n c h i n g edge may have c r e a t e d an i n c o n s i s t e n t s t a t e / x = e n s u r e C o n s i s t e n t ( s, L, e, d, d2, x1, nv ) ; i f ( x ){ i f ( prune ) { / r e s e t l e a f node / lowcell = h i g h C e l l ; / count c u r r e n t number o f v e r t i c e s l e f t i n r e d u c e d graph / c = 1 ; v = x ; w h i l e ( ( v = nv [ v ] ) ) i f ( d [ v ] ) c++; / g e t component d i f f e r e n c e from s e p a r a t i n g s e t t e s t Note t h a t x==x1 r e f e r s to a change i n anchor p o i n t s when c o n s i s t e n c y was e n s u r e d a f t e r t h e l a s t anchor p o i n t r o t a t i o n. The l a s t anchor p o i n t x1 was a b s o r b e d i n t o t h e p a r t i a l c y c l e found so f a r. This means t h a t when x and x1 a r e d i f f e r e n t, x does not have to be c o n s i d e r e d p a r t o f t h e s e p a r a t i n g s e t, as no b r a n c h i n g e d g e s w i l l have been removed from i t y e t. / i f ( getcomponentdiff ( s >dfs, L, e, d, nv, x,&c, x==x1 ) ){ / prune back t h e s e a r c h s p a c e as f a r as c l e t s us / hx = prunesearchspace ( s, c ) ; } / s t o p p e d a t an anchor p o i n t, keep t e s t i n g f o r p r u n i n g c o n d i t i o n u n t i l none a r e found / c o n t i n u e ; } / no more t e s t i n g needs to o c c u r f o r t h i s l e v e l / prune = f a l s e ;

129 Appendix B: Pruning Algorithm 123 } / keep e x t e n d i n g b r a n c h i n g e d g e s from anchor p o i n t s / w h i l e ( extendanchor ( s, L, e, d, x ) ){ do x = nv [ x ] ; w h i l e (! d [ x ] ) ; } / s t o p p i n g c o n d i t i o n e n c o u n t e r e d ( a l e a f ), s t o p movement to t h e r i g h t / i f ( s >f l a g s. ishamiltoncycle ) r e t u r n true ; hx = unwindsearchedge ( L, e, d, s >pos ) ; / e n s u r e t h a t l o w C e l l r e f e r s to t h e l o w e s t anchor p o i n t and check i f a l e a f node has been e x h a u s t e d. / i f ( hx > lowcell ) lowcell = hx ; e l s e prune = hx < lowcell ; } s >pos = hx ; r e t u r n f a l s e ; } / runturingmachinewithpruning /