diff --git a/.clang-format b/.clang-format index a4ce58c4..e73f6d56 100644 --- a/.clang-format +++ b/.clang-format @@ -1,5 +1,5 @@ BasedOnStyle: WebKit -Standard: Cpp11 +Standard: Cpp03 AlignAfterOpenBracket: false AlignEscapedNewlinesLeft: true AlwaysBreakAfterDefinitionReturnType: None @@ -13,4 +13,3 @@ SortIncludes: false AlignTrailingComments: false SpacesInAngles: true - diff --git a/.travis.yml b/.travis.yml index e1cab861..30ae1cdc 100644 --- a/.travis.yml +++ b/.travis.yml @@ -177,7 +177,7 @@ matrix: sources: - ubuntu-toolchain-r-test - llvm-toolchain-precise-3.7 - + # Fails to compile std lib headers (toolset issue): #- os: linux # env: TOOLSET=clang COMPILER=clang++-3.8 CXXSTD=03,11,14,1z diff --git a/README.md b/README.md index 7a4dc735..d63f5f40 100644 --- a/README.md +++ b/README.md @@ -18,24 +18,24 @@ There is no mailing-list specific to Boost Graph, although you can use the gener ## Development ## -Clone the whole boost project, which includes the individual Boost projects as submodules ([see boost+git doc](https://github.com/boostorg/boost/wiki/Getting-Started)): +Clone the whole boost project, which includes the individual Boost projects as submodules ([see boost+git doc](https://github.com/boostorg/boost/wiki/Getting-Started)): git clone https://github.com/boostorg/boost cd boost git submodule update --init -The Boost Graph Library is located in `libs/graph/`. +The Boost Graph Library is located in `libs/graph/`. Boost Graph Library is mostly made of headers but also contains some compiled components. Here are the build commands: - - ./bootstrap.sh <- compile b2 + + ./bootstrap.sh <- compile b2 ./b2 headers <- just installs headers ./b2 <- build compiled components **Note:** The Boost Graph Library cannot currently be built outside of Boost itself. ### Running tests ### -First, make sure you are in `libs/graph/test`. +First, make sure you are in `libs/graph/test`. You can either run all the 300+ tests listed in `Jamfile.v2` or run a single test: ../../../b2 <- run all tests diff --git a/doc/AStarHeuristic.html b/doc/AStarHeuristic.html index dbe2132d..b035a282 100644 --- a/doc/AStarHeuristic.html +++ b/doc/AStarHeuristic.html @@ -1,17 +1,17 @@ Boost Graph Library: AStarHeuristic - -C++ Boost + +C++ Boost
@@ -135,4 +135,4 @@ HREF="mailto:beevek@cs.rpi.edu">beevek@cs.rpi.edu) - + diff --git a/doc/AStarVisitor.html b/doc/AStarVisitor.html index ba4ac92e..bf11b9d9 100644 --- a/doc/AStarVisitor.html +++ b/doc/AStarVisitor.html @@ -1,17 +1,17 @@ Boost Graph Library: AStarVisitor - -C++ Boost + +C++ Boost
@@ -210,4 +210,4 @@ HREF="mailto:beevek@cs.rpi.edu">beevek@cs.rpi.edu) - + diff --git a/doc/AddEdgeVisitor.html b/doc/AddEdgeVisitor.html index 7f924d2e..3cbc4817 100644 --- a/doc/AddEdgeVisitor.html +++ b/doc/AddEdgeVisitor.html @@ -1,21 +1,21 @@ AddEdgeVisitor Concept - + -C++ Boost +C++ Boost
@@ -23,7 +23,7 @@ The AddEdgeVisitor concept exists to allow for some indirection in algorithms that modify graphs by adding edges. In such algorithms, it may be convenient -to perform additional operations (such as updating an edge index map) at +to perform additional operations (such as updating an edge index map) at points in the algorithm where an edge addition occurs. Replacing calls to to add_edge with calls to AddEdgeVisitor::visit_vertex_pair allows for such operations to be defined independently from the algorithm. @@ -38,8 +38,8 @@ allows for such operations to be defined independently from the algorithm. is a type that models the AddEdgeVisitor concept - - vis + + vis is an object of type Visitor @@ -48,15 +48,15 @@ allows for such operations to be defined independently from the algorithm. is the type of a graph - - u,v + + u,v are objects of type graph_traits<Graph>::vertex_descriptor - - e - is an object of type graph_traits<Graph>::edge_descriptor + + e + is an object of type graph_traits<Graph>::edge_descriptor @@ -66,7 +66,7 @@ allows for such operations to be defined independently from the algorithm. - + @@ -84,7 +84,7 @@ None NameExpressionReturn Type Description - + Add an Edge vis.visit_vertex_pair(u, v, g) void @@ -96,26 +96,26 @@ None

Models

-Two models of this concept are defined in the file +Two models of this concept are defined in the file add_edge_visitors.hpp: @@ -125,6 +125,6 @@ and update the edge index for the newly created edge.


Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) +aaron.windsor@gmail.com) diff --git a/doc/AdjacencyGraph.html b/doc/AdjacencyGraph.html index efe6a891..eb9a2033 100644 --- a/doc/AdjacencyGraph.html +++ b/doc/AdjacencyGraph.html @@ -1,17 +1,17 @@ AdjacencyGraph - -C++ Boost + +C++ Boost
@@ -164,4 +164,4 @@ experience with graph algorithm implementations. - + diff --git a/doc/AdjacencyMatrix.html b/doc/AdjacencyMatrix.html index e3c18250..a77a0aea 100644 --- a/doc/AdjacencyMatrix.html +++ b/doc/AdjacencyMatrix.html @@ -1,17 +1,17 @@ AdjacencyMatrix - -C++ Boost + +C++ Boost
@@ -100,4 +100,4 @@ The edge() function must return in constant time. - + diff --git a/doc/BFSVisitor.html b/doc/BFSVisitor.html index 1effc11c..1f4241f5 100644 --- a/doc/BFSVisitor.html +++ b/doc/BFSVisitor.html @@ -1,17 +1,17 @@ Boost Graph Library: BFSVisitor - -C++ Boost + +C++ Boost
@@ -142,7 +142,7 @@ edges for undirected graphs. This is invoked on the subset of non-tree edges whose target vertex is colored gray at the time of examination. The color gray indicates -that the vertex is currently in the queue. +that the vertex is currently in the queue. @@ -217,4 +217,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/BasicMatrix.html b/doc/BasicMatrix.html index 00ba171e..589bf599 100644 --- a/doc/BasicMatrix.html +++ b/doc/BasicMatrix.html @@ -1,17 +1,17 @@ BasicMatrix - -C++ Boost + +C++ Boost
@@ -78,11 +78,11 @@ Element access is constant time. void constraints() { V& elt = A[i][j]; const_constraints(A); - ignore_unused_variable_warning(elt); + ignore_unused_variable_warning(elt); } void const_constraints(const M& A) { const V& elt = A[i][j]; - ignore_unused_variable_warning(elt); + ignore_unused_variable_warning(elt); } M A; I i, j; @@ -100,4 +100,4 @@ HREF="mailto:jsiek@osl.iu.edu">jsiek@osl.iu.edu) - + diff --git a/doc/BellmanFordVisitor.html b/doc/BellmanFordVisitor.html index 30a896b1..37188e63 100644 --- a/doc/BellmanFordVisitor.html +++ b/doc/BellmanFordVisitor.html @@ -1,17 +1,17 @@ Boost Graph Library: Bellman Ford Visitor - -C++ Boost + +C++ Boost
@@ -181,4 +181,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/BidirectionalGraph.html b/doc/BidirectionalGraph.html index e5b551e0..f897c429 100644 --- a/doc/BidirectionalGraph.html +++ b/doc/BidirectionalGraph.html @@ -1,17 +1,17 @@ Bidirectional - -C++ Boost + +C++ Boost
@@ -177,4 +177,4 @@ undirected graphs). - + diff --git a/doc/Buffer.html b/doc/Buffer.html index 58dc0e71..cba8b457 100644 --- a/doc/Buffer.html +++ b/doc/Buffer.html @@ -1,7 +1,7 @@ Boost Graph Library: ColorValue Concept - -C++ Boost + +C++ Boost
@@ -105,4 +105,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/DFSVisitor.html b/doc/DFSVisitor.html index fb0bed6d..54483b9c 100644 --- a/doc/DFSVisitor.html +++ b/doc/DFSVisitor.html @@ -1,17 +1,17 @@ DFS Visitor - -C++ Boost + +C++ Boost
@@ -150,15 +150,15 @@ undirected graph this method is never called. -Finish Edge -vis.finish_edge(e, g) -void - -This is invoked on each non-tree edge as well as on each tree edge after -finish_vertex has been called on its target vertex. - - - +Finish Edge +vis.finish_edge(e, g) +void + +This is invoked on each non-tree edge as well as on each tree edge after +finish_vertex has been called on its target vertex. + + + Finish Vertex vis.finish_vertex(u, g) void @@ -218,4 +218,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/DijkstraVisitor.html b/doc/DijkstraVisitor.html index 43e82803..90d0fafd 100644 --- a/doc/DijkstraVisitor.html +++ b/doc/DijkstraVisitor.html @@ -1,17 +1,17 @@ Boost Graph Library: Dijkstra Visitor - -C++ Boost + +C++ Boost
@@ -219,4 +219,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/EdgeListGraph.html b/doc/EdgeListGraph.html index fc62539c..70c33ccd 100644 --- a/doc/EdgeListGraph.html +++ b/doc/EdgeListGraph.html @@ -1,17 +1,17 @@ EdgeListGraph - -C++ Boost + +C++ Boost
@@ -109,7 +109,7 @@ Return type: vertex_descriptor target(e, g) -Returns the vertex descriptor for +Returns the vertex descriptor for v of the edge (u,v) represented by e.
Return type: vertex_descriptor @@ -143,7 +143,7 @@ must all return in constant time. template <class G> struct EdgeListGraphConcept { - typedef typename boost::graph_traits<G>::edge_iterator + typedef typename boost::graph_traits<G>::edge_iterator edge_iterator; void constraints() { BOOST_CONCEPT_ASSERT(( GraphConcept<G> )); @@ -181,4 +181,4 @@ must all return in constant time. - + diff --git a/doc/EdgeMutableGraph.html b/doc/EdgeMutableGraph.html index 8429f0c5..59440665 100644 --- a/doc/EdgeMutableGraph.html +++ b/doc/EdgeMutableGraph.html @@ -1,17 +1,17 @@ Edge Mutable Graph - -C++ Boost + +C++ Boost
@@ -35,7 +35,7 @@ No additional associated types.

@@ -54,7 +54,7 @@ indicates which parameter the argument is for. Each of the named parameters is separated by a period, not a comma.

-  bool r = boost::bellman_ford_shortest_paths(g, int(N), 
+  bool r = boost::bellman_ford_shortest_paths(g, int(N),
      boost::weight_map(weight).
      distance_map(&distance[0]).
      predecessor_map(&parent[0]));
@@ -66,7 +66,7 @@ an call to bellman_ford_shortest_paths that is equivalent to
 the one above.
 
 
-  bool r = boost::bellman_ford_shortest_paths(g, int(N), 
+  bool r = boost::bellman_ford_shortest_paths(g, int(N),
      boost::predecessor_map(&parent[0]).
      distance_map(&distance[0]).
      weight_map(weight));
diff --git a/doc/bibliography.html b/doc/bibliography.html
index 4e59de85..b541abf6 100644
--- a/doc/bibliography.html
+++ b/doc/bibliography.html
@@ -1,17 +1,17 @@
 
 
 
 Boost Graph Library: Bibliography
- 
-C++ Boost 
+
+C++ Boost
 
 
@@ -264,7 +264,7 @@ SIAM Journal on Computing, 1(2):146-160, 1972

42
David Eppstein, Zvi Galil, and Giuseppe F. Italiano
Dynamic Graph Algorithms.
-Chapter 22, CRC Handbook of Algorithms and Theory of Computation, 1997. +Chapter 22, CRC Handbook of Algorithms and Theory of Computation, 1997.

43
E. Cuthill and J. McKee
@@ -330,7 +330,7 @@ BIT, 10, 1970, pp. 76-94.

54
Ulrik Brandes
-A +A Faster Algorithm for Betweenness Centrality
Journal of Mathematical Sociology 25 (2):163-177, 2001. @@ -347,7 +347,7 @@ Technical Report BN9/71, Stichting Mahtematisch Centrum, Amsterdam, 1971.

57
T. Kamada and S. Kawai
An algorithm for drawing general undirected graphs.
-Information Processing Letters, 31, pp. 7-15, 1989. +Information Processing Letters, 31, pp. 7-15, 1989.

58
T. Fruchterman and E. Reingold
@@ -454,7 +454,7 @@ Journal of the ACM (JACM), 23(2): 221-234, 1976. Proceedings of the First Annual ACM-SIAM Symposium on Discrete Algorithms, pp. 434-443, 1990. - +

@@ -464,4 +464,4 @@ Proceedings of the First Annual ACM-SIAM Symposium on Discrete Algorithms, pp. 4
- + diff --git a/doc/biconnected_components.html b/doc/biconnected_components.html index 298b7008..894e984c 100644 --- a/doc/biconnected_components.html +++ b/doc/biconnected_components.html @@ -1,21 +1,21 @@ Boost Graph Library: Biconnected Components and Articulation Points - -C++ Boost + +C++ Boost
@@ -25,7 +25,7 @@ biconnected_components -and +and articulation_points @@ -34,25 +34,25 @@ and template <typename Graph, typename ComponentMap, typename OutputIterator, typename P, typename T, typename R> std::pair<std::size_t, OutputIterator> -biconnected_components(const Graph& g, ComponentMap comp, OutputIterator out, +biconnected_components(const Graph& g, ComponentMap comp, OutputIterator out, const bgl_named_params<P, T, R>& params) template <typename Graph, typename ComponentMap, typename P, typename T, typename R> std::size_t -biconnected_components(const Graph& g, ComponentMap comp, +biconnected_components(const Graph& g, ComponentMap comp, const bgl_named_params<P, T, R>& params) -template <typename Graph, typename OutputIterator, +template <typename Graph, typename OutputIterator, typename P, typename T, typename R> -OutputIterator articulation_points(const Graph& g, OutputIterator out, +OutputIterator articulation_points(const Graph& g, OutputIterator out, const bgl_named_params<P, T, R>& params) // non-named parameter version template <typename Graph, typename ComponentMap, typename OutputIterator, typename DiscoverTimeMap, typename LowPointMap> std::pair<std::size_t, OutputIterator> -biconnected_components(const Graph& g, ComponentMap comp, OutputIterator out, +biconnected_components(const Graph& g, ComponentMap comp, OutputIterator out, DiscoverTimeMap discover_time, LowPointMap lowpt); template <typename Graph, typename ComponentMap, typename OutputIterator> @@ -142,10 +142,10 @@ points.

Named Parameters

-IN: vertex_index_map(VertexIndexMap i_map) +IN: vertex_index_map(VertexIndexMap i_map)
This maps each vertex to an integer in the range [0, - num_vertices(g)). The type + num_vertices(g)). The type VertexIndexMap must be a model of Readable Property Map. The value type of the map must be an integer type. The vertex descriptor type of the graph needs to be @@ -192,9 +192,9 @@ UTIL/OUT: lowpoint_map(LowPointMap lowpt) Python: Unsupported parameter.
-UTIL/OUT: predecessor_map(PredecessorMap p_map) +UTIL/OUT: predecessor_map(PredecessorMap p_map)
- The predecessor map records the depth first search tree. + The predecessor map records the depth first search tree. The PredecessorMap type must be a Read/Write @@ -241,7 +241,7 @@ articulation points of an undirected graph.

Notes

-

[1] +

[1] Since the visitor parameter is passed by value, if your visitor contains state then any changes to the state during the algorithm will be made to a copy of the visitor object, not the visitor object @@ -260,4 +260,4 @@ HREF="mailto:jsiek@osl.iu.edu">jsiek@osl.iu.edu)
- + diff --git a/doc/biconnected_components.w b/doc/biconnected_components.w index d2eb21ff..df6c3c2b 100644 --- a/doc/biconnected_components.w +++ b/doc/biconnected_components.w @@ -5,7 +5,7 @@ \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsthm} -\usepackage{latexsym} +\usepackage{latexsym} \usepackage{jweb} \usepackage{times} \usepackage{graphicx} @@ -358,7 +358,7 @@ int main() -% \paragraph{Definition.} A \emph{palm tree} $P$ is a directed graph that +% \paragraph{Definition.} A \emph{palm tree} $P$ is a directed graph that % consists of two disjoint sets of edges, denoted by $v \rightarrow w$ % and $v \backedge w$ respectively, with the following properties: diff --git a/doc/boyer_myrvold.html b/doc/boyer_myrvold.html index a2792a30..df4574f7 100644 --- a/doc/boyer_myrvold.html +++ b/doc/boyer_myrvold.html @@ -1,39 +1,39 @@ Boost Graph Library: Boyer-Myrvold Planarity Testing/Embedding - -C++ Boost + +C++ Boost

Boyer-Myrvold Planarity Testing/Embedding

-A graph is planar if it can -be drawn in two-dimensional space without any of its edges crossing. Such a -drawing of a planar graph is called a -plane drawing. Each +A graph is planar if it can +be drawn in two-dimensional space without any of its edges crossing. Such a +drawing of a planar graph is called a +plane drawing. Each plane drawing belongs to an equivalence class called a planar embedding -[1] that is defined by the clockwise ordering of adjacent -edges around each vertex in the graph. A planar embedding is a convenient -intermediate representation of an actual drawing of a planar graph, and many -planar graph drawing algorithms are formulated as functions mapping a planar +[1] that is defined by the clockwise ordering of adjacent +edges around each vertex in the graph. A planar embedding is a convenient +intermediate representation of an actual drawing of a planar graph, and many +planar graph drawing algorithms are formulated as functions mapping a planar embedding to a plane drawing.

-
A planar graph (top left), along with a planar -embedding of that graph (bottom left) can be used to create a plane drawing -(right) by embedding edges around each vertex in the order in which they +
A planar graph (top left), along with a planar +embedding of that graph (bottom left) can be used to create a plane drawing +(right) by embedding edges around each vertex in the order in which they appear in the planar embedding.
@@ -44,16 +44,16 @@ appear in the planar embedding.

-The function boyer_myrvold_planarity_test implements the planarity -testing/embedding algorithm of Boyer and Myrvold +The function boyer_myrvold_planarity_test implements the planarity +testing/embedding algorithm of Boyer and Myrvold [70]. -boyer_myrvold_planarity_test returns true if the input graph +boyer_myrvold_planarity_test returns true if the input graph is planar and false otherwise. As a side-effect of this test, a planar -embedding can be constructed if the graph is planar or a minimal set of edges -that form a Kuratowski +embedding can be constructed if the graph is planar or a minimal set of edges +that form a Kuratowski subgraph can be found if the graph is not planar. -boyer_myrvold_planarity_test uses named parameter arguments (courtesy -of the Boost.Parameter +boyer_myrvold_planarity_test uses named parameter arguments (courtesy +of the Boost.Parameter library) to specify what the function actually does. Some examples are:

    @@ -65,8 +65,8 @@ bool is_planar = boyer_myrvold_planarity_test(g);
  • Computing a planar embedding for a graph if it is planar, otherwise finding a set of edges that forms an obstructing Kuratowski subgraph:
    -if (boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g, 
    -                                 boyer_myrvold_params::embedding = embedding_pmap,  
    +if (boyer_myrvold_planarity_test(boyer_myrvold_params::graph = g,
    +                                 boyer_myrvold_params::embedding = embedding_pmap,
                                      boyer_myrvold_params::kuratowski_subgraph = out_itr
                                      )
         )
    @@ -81,81 +81,81 @@ else
     

-The parameters passed to boyer_myrvold_planarity_test in the examples -above do more than just carry the data structures used for input and output - -the algorithm is optimized at compile time based on which parameters are -present. A complete list of parameters accepted and their interactions are -described below. +The parameters passed to boyer_myrvold_planarity_test in the examples +above do more than just carry the data structures used for input and output - +the algorithm is optimized at compile time based on which parameters are +present. A complete list of parameters accepted and their interactions are +described below.

boyer_myrvold_planarity_test accepts as input any undirected graph, even those with self-loops and multiple edges. -However, many planar graph drawing algorithms make additional restrictions -on the structure of the input graph - for example, requiring that the input +However, many planar graph drawing algorithms make additional restrictions +on the structure of the input graph - for example, requiring that the input graph is connected, biconnected, or even maximal planar (triangulated.) -Fortunately, any planar graph on n vertices that lacks one of these -properties can be augmented with additional edges so that it satisfies that -property in O(n) time - the functions +Fortunately, any planar graph on n vertices that lacks one of these +properties can be augmented with additional edges so that it satisfies that +property in O(n) time - the functions make_connected, -make_biconnected_planar, -and make_maximal_planar -exist for this purpose. If the graph drawing algorithm you're using requires, -say, a biconnected graph, then you must make your input graph biconnected +make_biconnected_planar, +and make_maximal_planar +exist for this purpose. If the graph drawing algorithm you're using requires, +say, a biconnected graph, then you must make your input graph biconnected before passing it into boyer_myrvold_planarity_test so that the -computed planar embedding includes these additional edges. This may require -more than one call to boyer_myrvold_planarity_test depending on the -structure of the graph you begin with, since both -make_biconnected_planar and make_maximal_planar require a +computed planar embedding includes these additional edges. This may require +more than one call to boyer_myrvold_planarity_test depending on the +structure of the graph you begin with, since both +make_biconnected_planar and make_maximal_planar require a planar embedding of the existing graph as an input parameter.

The named parameters accepted by boyer_myrvold_planarity_test are:

    -
  • graph : The input graph - this is the only required +
  • graph : The input graph - this is the only required parameter. -
  • vertex_index_map : A mapping from vertices of the input -graph to indexes in the range [0..num_vertices(g)). If this parameter +
  • vertex_index_map : A mapping from vertices of the input +graph to indexes in the range [0..num_vertices(g)). If this parameter is not provided, the vertex index map is assumed to be available as an interior property of the graph, accessible by calling get(vertex_index, g).
  • edge_index_map: A mapping from the edges of the input graph -to indexes in the range [0..num_edges(g)). This parameter is only -needed if the kuratowski_subgraph argument is provided. If the +to indexes in the range [0..num_edges(g)). This parameter is only +needed if the kuratowski_subgraph argument is provided. If the kuratowski_subgraph argument is provided and this parameter is not -provided, the EdgeIndexMap is assumed to be available as an interior property +provided, the EdgeIndexMap is assumed to be available as an interior property accessible by calling get(edge_index, g). -
  • embedding : If the graph is planar, this will be populated -with a mapping from vertices to the clockwise order of neighbors in the planar +
  • embedding : If the graph is planar, this will be populated +with a mapping from vertices to the clockwise order of neighbors in the planar embedding.
  • kuratowski_subgraph : If the graph is not planar, a minimal -set of edges that form the obstructing Kuratowski subgraph will be written to +set of edges that form the obstructing Kuratowski subgraph will be written to this iterator.
-These named parameters all belong to the namespace -boyer_myrvold_params. See below for more information on the concepts -required for these arguments. +These named parameters all belong to the namespace +boyer_myrvold_params. See below for more information on the concepts +required for these arguments.

Verifying the output

Whether or not the input graph is planar, boyer_myrvold_planarity_test -can produce a certificate that can be automatically checked to verify that the -function is working properly. +can produce a certificate that can be automatically checked to verify that the +function is working properly.

If the graph is planar, a planar embedding can be produced. The -planar embedding can be verified by passing it to a plane drawing routine +planar embedding can be verified by passing it to a plane drawing routine (such as -chrobak_payne_straight_line_drawing) and using the function -is_straight_line_drawing +chrobak_payne_straight_line_drawing) and using the function +is_straight_line_drawing to verify that the resulting graph is planar.

-If the graph is not planar, a set of edges that forms a Kuratowski subgraph in -the original graph can be produced. This set of edges can be passed to the +If the graph is not planar, a set of edges that forms a Kuratowski subgraph in +the original graph can be produced. This set of edges can be passed to the function is_kuratowski_subgraph - to verify that they can be contracted into a K5 or -K3,3. boyer_myrvold_planarity_test chooses the set -of edges forming the Kuratowski subgraph in such a way that the contraction to -a K5 or K3,3 can be done by a simple -deterministic process which is described in the documentation to + to verify that they can be contracted into a K5 or +K3,3. boyer_myrvold_planarity_test chooses the set +of edges forming the Kuratowski subgraph in such a way that the contraction to +a K5 or K3,3 can be done by a simple +deterministic process which is described in the documentation to is_kuratowski_subgraph.

Where Defined

@@ -170,8 +170,8 @@ deterministic process which is described in the documentation to IN: Graph& g
-Any undirected graph. The graph type must be a model of -VertexAndEdgeListGraph and +Any undirected graph. The graph type must be a model of +VertexAndEdgeListGraph and IncidenceGraph.
@@ -184,7 +184,7 @@ Must model the PlanarEmbedding concept. IN OutputIterator kuratowski_subgraph
-An OutputIterator which accepts values of the type +An OutputIterator which accepts values of the type graph_traits<Graph>::edge_descriptor
@@ -192,7 +192,7 @@ IN VertexIndexMap vm
A Readable Property Map - that maps vertices from g to distinct integers in the range + that maps vertices from g to distinct integers in the range [0, num_vertices(g) )
Default: get(vertex_index,g)
@@ -201,21 +201,21 @@ IN EdgeIndexMap em
A Readable Property Map - that maps edges from g to distinct integers in the range + that maps edges from g to distinct integers in the range [0, num_edges(g) )
-Default: get(edge_index,g), but this parameter is only used if +Default: get(edge_index,g), but this parameter is only used if the kuratowski_subgraph_iterator is provided.

Complexity

-Assuming that both the vertex index and edge index supplied take time -O(1) to return an index and there are O(n) -total self-loops and parallel edges in the graph, most combinations of -arguments given to -boyer_myrvold_planarity_test result in an algorithm that runs in time -O(n) for a graph with n vertices and m edges. The only -exception is when Kuratowski subgraph isolation is requested for a dense graph +Assuming that both the vertex index and edge index supplied take time +O(1) to return an index and there are O(n) +total self-loops and parallel edges in the graph, most combinations of +arguments given to +boyer_myrvold_planarity_test result in an algorithm that runs in time +O(n) for a graph with n vertices and m edges. The only +exception is when Kuratowski subgraph isolation is requested for a dense graph (a graph with n = o(m)) - the running time will be O(n+m) [2]. @@ -224,9 +224,9 @@ exception is when Kuratowski subgraph isolation is requested for a dense graph

@@ -237,17 +237,17 @@ create a straight line drawing

Notes

-

[1] A planar embedding is also called a combinatorial +

[1] A planar embedding is also called a combinatorial embedding. -

[2] The algorithm can still be made to run in time O(n) -for this case, if needed. Euler's +

[2] The algorithm can still be made to run in time O(n) +for this case, if needed. Euler's formula implies that a planar graph with n vertices can have no more -than 3n - 6 edges, which means that any non-planar graph on n -vertices has a subgraph of only 3n - 5 edges that contains a Kuratowski -subgraph. So, if you need to find a Kuratowski subgraph of a graph with more -than 3n - 5 edges in time O(n), you can create a subgraph of the -original graph consisting of any arbitrary 3n - 5 edges and pass that +than 3n - 6 edges, which means that any non-planar graph on n +vertices has a subgraph of only 3n - 5 edges that contains a Kuratowski +subgraph. So, if you need to find a Kuratowski subgraph of a graph with more +than 3n - 5 edges in time O(n), you can create a subgraph of the +original graph consisting of any arbitrary 3n - 5 edges and pass that graph to boyer_myrvold_planarity_test. @@ -256,4 +256,4 @@ graph to boyer_myrvold_planarity_test. Copyright © 2007 Aaron Windsor ( aaron.windsor@gmail.com) - + diff --git a/doc/breadth_first_search.html b/doc/breadth_first_search.html index 000c13a5..0608fc9b 100644 --- a/doc/breadth_first_search.html +++ b/doc/breadth_first_search.html @@ -1,17 +1,17 @@ Boost Graph Library: Breadth-First Search - -C++ Boost + +C++ Boost
@@ -24,15 +24,15 @@

 // named parameter version
 template <class Graph, class P, class T, class R>
-void breadth_first_search(Graph& G, 
-  typename graph_traits<Graph>::vertex_descriptor s, 
+void breadth_first_search(Graph& G,
+  typename graph_traits<Graph>::vertex_descriptor s,
   const bgl_named_params<P, T, R>& params);
 
 // non-named parameter version
-template <class Graph, class Buffer, class BFSVisitor, 
+template <class Graph, class Buffer, class BFSVisitor,
 	  class ColorMap>
-void breadth_first_search(const Graph& g, 
-   typename graph_traits<Graph>::vertex_descriptor s, 
+void breadth_first_search(const Graph& g,
+   typename graph_traits<Graph>::vertex_descriptor s,
    Buffer& Q, BFSVisitor vis, ColorMap color);
 
@@ -70,25 +70,25 @@ BFS algorithm is a listed below.
 BFS(G, s)
   for each vertex u in V[G]
-    color[u] := WHITE 
-    d[u] := infinity 
-    p[u] := u 
+    color[u] := WHITE
+    d[u] := infinity
+    p[u] := u
   end for
-  color[s] := GRAY 
-  d[s] := 0 
+  color[s] := GRAY
+  d[s] := 0
   ENQUEUE(Q, s)
-  while (Q != Ø) 
+  while (Q != Ø)
     u := DEQUEUE(Q)
     for each vertex v in Adj[u]
       if (color[v] = WHITE)
-        color[v] := GRAY 
-        d[v] := d[u] + 1  
-        p[v] := u  
+        color[v] := GRAY
+        d[v] := d[u] + 1
+        p[v] := u
         ENQUEUE(Q, v)
       else
-        if (color[v] = GRAY) 
+        if (color[v] = GRAY)
           ...
-        else 
+        else
           ...
     end for
     color[u] := BLACK
@@ -99,29 +99,29 @@ BFS(G, s)
 
 
 
-initialize vertex u 
+initialize vertex u
 
 
 
 
 
 
-discover vertex s 
+discover vertex s
 
-examine vertex u 
+examine vertex u
 examine edge (u,v)
-(u,v) is a tree edge 
+(u,v) is a tree edge
 
 
 
-discover vertex v 
+discover vertex v
 (u,v) is a non-tree edge
 
-(u,v) has a gray target 
+(u,v) has a gray target
 
-(u,v) has a black target 
+(u,v) has a black target
 
-finish vertex u 
+finish vertex u
 
@@ -244,7 +244,7 @@ UTIL: buffer(Buffer& Q) Python: The buffer must derive from the Buffer type for the graph. -
+

@@ -252,7 +252,7 @@ Complexity

-The time complexity is O(E + V). +The time complexity is O(E + V).

@@ -260,13 +260,13 @@ The time complexity is O(E + V).

  • vis.initialize_vertex(v, g) is invoked on every vertex - before the start of the search. + before the start of the search.
  • vis.examine_vertex(u, g)r is invoked in each vertex as it is removed from the queue.
  • vis.examine_edge(e, g) is invoked on every out-edge - of each vertex immediately after the vertex is removed from the queue. + of each vertex immediately after the vertex is removed from the queue.
  • vis.tree_edge(e, g) is invoked (in addition to examine_edge()) if the edge is a tree edge. The @@ -275,20 +275,20 @@ The time complexity is O(E + V).
  • vis.discover_vertex(u, g) is invoked the first time the algorithm encounters vertex u. All vertices closer to the source vertex have been discovered, and vertices further from the - source have not yet been discovered. + source have not yet been discovered.
  • vis.non_tree_edge(e, g) is invoked (in addition to - examine_edge()) if the edge is not a tree edge. + examine_edge()) if the edge is not a tree edge.
  • vis.gray_target(e, g) is invoked (in addition to non_tree_edge()) if the target vertex is colored gray at the time of examination. The color gray indicates that - the vertex is currently in the queue. + the vertex is currently in the queue.
  • vis.black_target(e, g) is invoked (in addition to non_tree_edge()) if the target vertex is colored black at the time of examination. The color black indicates that the - vertex is no longer in the queue. + vertex is no longer in the queue.
  • vis.finish_vertex(u, g) is invoked after all of the out edges of u have been examined and all of the adjacent vertices @@ -319,7 +319,7 @@ to listS.

    Notes

    -

    [1] +

    [1] Since the visitor parameter is passed by value, if your visitor contains state then any changes to the state during the algorithm will be made to a copy of the visitor object, not the visitor object @@ -335,4 +335,4 @@ to listS. - + diff --git a/doc/breadth_first_visit.html b/doc/breadth_first_visit.html index 96bfc3a3..e3feaa92 100644 --- a/doc/breadth_first_visit.html +++ b/doc/breadth_first_visit.html @@ -1,17 +1,17 @@ Boost Graph Library: Breadth-First Visit - -C++ Boost + +C++ Boost
    @@ -22,14 +22,14 @@

       template <class IncidenceGraph, class P, class T, class R>
    -  void breadth_first_visit(IncidenceGraph& G, 
    -    typename graph_traits<IncidenceGraph>::vertex_descriptor s, 
    +  void breadth_first_visit(IncidenceGraph& G,
    +    typename graph_traits<IncidenceGraph>::vertex_descriptor s,
         const bgl_named_params<P, T, R>& params);
     
       template <class IncidenceGraph, class Buffer, class BFSVisitor, class ColorMap>
       void breadth_first_visit
    -    (const IncidenceGraph& g, 
    -     typename graph_traits<IncidenceGraph>::vertex_descriptor s, 
    +    (const IncidenceGraph& g,
    +     typename graph_traits<IncidenceGraph>::vertex_descriptor s,
          Buffer& Q, BFSVisitor vis, ColorMap color)
     
    @@ -110,7 +110,7 @@ UTIL: buffer(Buffer& Q) Python: The buffer must derive from the Buffer type for the graph. - +

    @@ -118,7 +118,7 @@ Complexity

    -The time complexity is O(E). +The time complexity is O(E).

    @@ -129,7 +129,7 @@ The time complexity is O(E). vertex as it is removed from the queue.

  • vis.examine_edge(e, g) is invoked on every out-edge - of each vertex immediately after the vertex is removed from the queue. + of each vertex immediately after the vertex is removed from the queue.
  • vis.tree_edge(e, g) is invoked (in addition to examine_edge()) if the edge is a tree edge. The @@ -138,20 +138,20 @@ The time complexity is O(E).
  • vis.discover_vertex(u, g) is invoked the first time the algorithm encounters vertex u. All vertices closer to the source vertex have been discovered, and vertices further from the - source have not yet been discovered. + source have not yet been discovered.
  • vis.non_tree_edge(e, g) is invoked (in addition to - examine_edge()) if the edge is not a tree edge. + examine_edge()) if the edge is not a tree edge.
  • vis.gray_target(e, g) is invoked (in addition to non_tree_edge()) if the target vertex is colored gray at the time of examination. The color gray indicates that - the vertex is currently in the queue. + the vertex is currently in the queue.
  • vis.black_target(e, g) is invoked (in addition to non_tree_edge()) if the target vertex is colored black at the time of examination. The color black indicates that the - vertex is no longer in the queue. + vertex is no longer in the queue.
  • vis.finish_vertex(u, g) is invoked after all of the out edges of u have been examined and all of the adjacent vertices @@ -167,7 +167,7 @@ The time complexity is O(E).

    Notes

    -

    [1] +

    [1] Since the visitor parameter is passed by value, if your visitor contains state then any changes to the state during the algorithm will be made to a copy of the visitor object, not the visitor object @@ -183,4 +183,4 @@ The time complexity is O(E). - + diff --git a/doc/challenge.html b/doc/challenge.html index 89a34dec..ba43bf65 100644 --- a/doc/challenge.html +++ b/doc/challenge.html @@ -1,17 +1,17 @@ Challenge - -C++ Boost + +C++ Boost
    @@ -43,12 +43,12 @@ review. The pending items are:

  • Construct a set of planar graph algorithms.
    • Is the graph planar?
    • -
    • "Walk around the block" and similar open and closed neighborhood -traversals. Note that edge traversals need to resolve to particular ends +
    • "Walk around the block" and similar open and closed neighborhood +traversals. Note that edge traversals need to resolve to particular ends and sides (see below), not just to the edge as a whole.
    • -
    • Given a point, find the nearest vertex, edge, or bounded polygon. +
    • Given a point, find the nearest vertex, edge, or bounded polygon. Again, edges are viewed as having left and right sides.
    • -
    • Given a line segment, find intersecting vertices, edges, or bounded +
    • Given a line segment, find intersecting vertices, edges, or bounded polygons.
    • Given a polygon, find intersecting whatever...
    • Various minimum bounding rectangle and clipping problems.
    • @@ -117,4 +117,4 @@ It is currently difficult to use from a C++ program. - + diff --git a/doc/circle_layout.html b/doc/circle_layout.html index e1b53935..57f91cb9 100644 --- a/doc/circle_layout.html +++ b/doc/circle_layout.html @@ -1,14 +1,14 @@ Function template circle_graph_layout
      boost.png (6897 bytes)HomeLibrariesPeopleFAQMore

      (Python)Function template circle_graph_layout

      boost::circle_graph_layout — Layout the graph with the vertices at the points of a regular n-polygon.

      Synopsis

      -template<typename VertexListGraph, typename PositionMap, typename Radius> 
      -  void circle_graph_layout(const VertexListGraph & g, PositionMap position, 
      -                           Radius radius);

      Where Defined

      boost/graph/circle_layout.hpp

      Description

      The distance from the center of the polygon to each point is determined by the radius parameter. The position parameter must be an Lvalue Property Map whose value type is a class type containing x and y members that will be set to the x and y coordinates. +template<typename VertexListGraph, typename PositionMap, typename Radius> +  void circle_graph_layout(const VertexListGraph & g, PositionMap position, +                           Radius radius);

Where Defined

boost/graph/circle_layout.hpp

Description

The distance from the center of the polygon to each point is determined by the radius parameter. The position parameter must be an Lvalue Property Map whose value type is a class type containing x and y members that will be set to the x and y coordinates.

Parameters

IN: const VertexListGraph& g diff --git a/doc/compressed_sparse_row.html b/doc/compressed_sparse_row.html index 9519f9b0..37ff8493 100644 --- a/doc/compressed_sparse_row.html +++ b/doc/compressed_sparse_row.html @@ -2,7 +2,7 @@ Boost Graph Library: Connected Components - -C++ Boost + +C++ Boost
@@ -154,4 +154,4 @@ undirected graph. - + diff --git a/doc/constructing_algorithms.html b/doc/constructing_algorithms.html index a7b7f4ca..d173ae19 100644 --- a/doc/constructing_algorithms.html +++ b/doc/constructing_algorithms.html @@ -1,17 +1,17 @@ Boost Graph Library: Constructing Graph Algorithms - -C++ Boost + +C++ Boost
@@ -113,7 +113,7 @@ color of all the vertices to "uncolored." namespace boost { template <class VertexListGraph, class Order, class Color> typename graph_traits<VertexListGraph>::vertices_size_type - sequential_vertex_color_ting(const VertexListGraph& G, + sequential_vertex_color_ting(const VertexListGraph& G, Order order, Color color) { typedef graph_traits<VertexListGraph> GraphTraits; @@ -127,27 +127,27 @@ namespace boost { BOOST_CONCEPT_ASSERT(( IntegerConcept<ColorType> )); BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept<Order, size_type> )); BOOST_STATIC_ASSERT((is_same<OrderType, vertex_descriptor>::value)); - + size_type max_color = 0; const size_type V = num_vertices(G); - std::vector<size_type> + std::vector<size_type> mark(V, numeric_limits_max(max_color)); - + typename GraphTraits::vertex_iterator v, vend; for (boost::tie(v, vend) = vertices(G); v != vend; ++v) color[*v] = V - 1; // which means "not colored" - + for (size_type i = 0; i < V; i++) { vertex_descriptor current = order[i]; // mark all the colors of the adjacent vertices typename GraphTraits::adjacency_iterator ai, aend; for (boost::tie(ai, aend) = adjacent_vertices(current, G); ai != aend; ++ai) - mark[color[*ai]] = i; + mark[color[*ai]] = i; // find the smallest color unused by the adjacent vertices size_type smallest_color = 0; - while (smallest_color < max_color && mark[smallest_color] == i) + while (smallest_color < max_color && mark[smallest_color] == i) ++smallest_color; // if all the colors are used up, increase the number of colors @@ -180,4 +180,4 @@ HREF="mailto:lums@osl.iu.edu">lums@osl.iu.edu) - + diff --git a/doc/copy_graph.html b/doc/copy_graph.html index 590429a0..76483bb4 100644 --- a/doc/copy_graph.html +++ b/doc/copy_graph.html @@ -1,24 +1,24 @@ Boost Graph Library: Copy Graph - -C++ Boost + +C++ Boost

copy_graph

-template <class VertexListGraph, class MutableGraph> 
+template <class VertexListGraph, class MutableGraph>
 void copy_graph(const VertexListGraph& G, MutableGraph& G_copy,
     const bgl_named_params<P, T, R>& params = all defaults)
 
@@ -113,4 +113,4 @@ The time complexity is O(V + E). - + diff --git a/doc/cuthill_mckee_ordering.html b/doc/cuthill_mckee_ordering.html index 5765c31c..41c0c734 100644 --- a/doc/cuthill_mckee_ordering.html +++ b/doc/cuthill_mckee_ordering.html @@ -1,19 +1,19 @@ - + Boost Graph Library: Cuthill-Mckee Ordering - -C++ Boost + +C++ Boost
@@ -46,25 +46,25 @@ OutputIterator cuthill_mckee_ordering(const IncidenceGraph& g, typename graph_traits<IncidenceGraph>::vertex_descriptor s, - OutputIterator inverse_permutation, + OutputIterator inverse_permutation, ColorMap color, DegreeMap degree) (2) template <class VertexListGraph, class OutputIterator> OutputIterator - cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation); + cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation); template <class VertexListGraph, class OutputIterator, class VertexIndexMap> OutputIterator - cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation, - VertexIndexMap index_map); - - template <class VertexListGraph, class OutputIterator, + cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation, + VertexIndexMap index_map); + + template <class VertexListGraph, class OutputIterator, class ColorMap, class DegreeMap> OutputIterator - cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation, + cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation, ColorMap color, DegreeMap degree) - + (3) template <class IncidenceGraph, class OutputIterator, class ColorMap, class DegreeMap> @@ -72,7 +72,7 @@ cuthill_mckee_ordering(const IncidenceGraph& g, std::deque< typename graph_traits<IncidenceGraph>::vertex_descriptor > vertex_queue, - OutputIterator inverse_permutation, + OutputIterator inverse_permutation, ColorMap color, DegreeMap degree)
@@ -92,10 +92,10 @@ increasing degree.

Version 1 of the algorithm lets the user choose the ``starting vertex'', version 2 finds a good starting vertex using the -pseudo-peripheral pair heuristic (among each component), while version 3 -contains the starting nodes for each vertex in the deque. The choice of the -``starting vertex'' can have a significant effect on the quality of the -ordering. For versions 2 and 3, find_starting_vertex will be called +pseudo-peripheral pair heuristic (among each component), while version 3 +contains the starting nodes for each vertex in the deque. The choice of the +``starting vertex'' can have a significant effect on the quality of the +ordering. For versions 2 and 3, find_starting_vertex will be called for each component in the graph, increasing run time significantly.

@@ -140,7 +140,7 @@ For version 1: