diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml new file mode 100644 index 000000000..58eb9e5ab --- /dev/null +++ b/.github/workflows/docs.yml @@ -0,0 +1,62 @@ +name: docs-check + +# PR-time sanity check for the Antora documentation: +# - b2 builds every example .cpp and regenerates its .txt sidecar +# (catches broken examples; failures here fail the job) +# - Antora renders the full site (catches broken .adoc, missing +# includes, broken xrefs) +# +# No deployment. The real publishing path is boostorg/release-tools, +# which auto-detects doc/build_antora.sh and ships to +# www.boost.org/doc/libs//libs/graph/. + +on: + pull_request: + branches: ["develop", "documentation"] + workflow_dispatch: + +permissions: + contents: read + +jobs: + docs-check: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Install Node 20 + uses: actions/setup-node@v4 + with: + node-version: '20' + + # Set up boost-root so b2 can build the example .cpp files (needs + # the full Boost build tree, not just the headers we ship in this + # repo). + - name: Set up boost-root + run: | + git clone -b develop --depth 1 https://github.com/boostorg/boost.git ../boost-root + cd ../boost-root + git submodule update --init tools/boostdep + rm -rf libs/graph + cp -r "$GITHUB_WORKSPACE" libs/graph + python tools/boostdep/depinst/depinst.py --git_args "--jobs 3" graph + git submodule update --init --depth 1 libs/static_assert + ./bootstrap.sh + ./b2 headers + + - name: Snapshot example outputs (b2) + working-directory: ../boost-root + run: ./b2 -j$(nproc) libs/graph/doc/modules/ROOT/examples + + # Mirror the regenerated .txt sidecars back into the workspace so + # the Antora build below renders pages against fresh outputs. + - name: Mirror generated .txt back to workspace + run: rsync -a ../boost-root/libs/graph/doc/modules/ROOT/examples/ doc/modules/ROOT/examples/ + + # Build the site exactly as boostorg/release-tools will at release + # time: invoke doc/build_antora.sh, which runs npm ci + npx antora + # against the committed package-lock.json. + - name: Build the site (release-tools entry point) + working-directory: doc + run: ./build_antora.sh playbook.yml diff --git a/.gitignore b/.gitignore index 778bb19d9..4786df32c 100644 --- a/.gitignore +++ b/.gitignore @@ -10,3 +10,11 @@ test/*.dot example/routing-table.dat example/figs/ospf-sptree.dot CMakeFiles/ + +# Antora docs build artifacts +doc/build/ +doc/node_modules/ + +# macOS +.DS_Store +**/.DS_Store diff --git a/doc/AStarHeuristic.html b/doc/AStarHeuristic.html deleted file mode 100644 index b035a2825..000000000 --- a/doc/AStarHeuristic.html +++ /dev/null @@ -1,138 +0,0 @@ - - - -Boost Graph Library: AStarHeuristic - -C++ Boost - -
- -

AStar Heuristic Concept

- -This concept defines the interface for the heuristic function of an A* -search, which is responsible for estimating the remaining cost from -some vertex to a goal. The user can create a class that matches this -interface, and then pass objects of the class into astar_search() to guide the -order of vertex examination of the search. The heuristic instance -must incorporate any necessary information about goal vertices in the -graph. - -For further discussion of the use of heuristics in an A* search, see -the documentation of astar_search(). - -

Refinement of

- -Unary -Function (must take a single argument -- a graph vertex -- and -return a cost value) and Copy Constructible -(copying a heuristic should be a lightweight operation). - - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HA type that is a model of AStar Heuristic.
hAn object of type H.
GA type that is a model of Graph.
gAn object of type G.
uAn object of type boost::graph_traits<G>::vertex_descriptor.
CostTypeA type that can be used with the compare and -combine functions passed to A*.
cAn object of type CostType.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Call HeuristicCostType c = h(u)CostType -Called for the target of every out edge of a vertex being examined. -
- -

Models

- - - -

Concept Checking Class

- -
-  template <class Heuristic, class Graph>
-  struct AStarHeuristicConcept {
-    void constraints()
-    {
-      BOOST_CONCEPT_ASSERT(( CopyConstructibleConcept<Heuristic> ));
-      h(u);
-    }
-    Heuristic h;
-    typename graph_traits<Graph>::vertex_descriptor u;
-  };
-
- -
-
- - -
Copyright © 2004 -Kristopher Beevers, -Rensselaer Polytechnic Institute (beevek@cs.rpi.edu) -
- - - diff --git a/doc/AStarVisitor.html b/doc/AStarVisitor.html deleted file mode 100644 index bf11b9d94..000000000 --- a/doc/AStarVisitor.html +++ /dev/null @@ -1,213 +0,0 @@ - - - -Boost Graph Library: AStarVisitor - -C++ Boost - -
- -

AStar Visitor Concept

- -This concept defines the visitor interface for astar_search(). Users can -define a class with the AStar Visitor interface and pass an object of -the class to astar_search(), thereby augmenting the actions -taken during the graph search. - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of AStar Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type const G&.
eAn object of type boost::graph_traits<G>::edge_descriptor.
s,u,vAn object of type boost::graph_traits<G>::vertex_descriptor.
dAn object of type DistanceMap.
WeightMapA type that is a model of Readable Property -Map.
wAn object of type WeightMap.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Initialize Vertexvis.initialize_vertex(u, g)void -This is invoked on each vertex of the graph when it is first -initialized (i.e., when its property maps are initialized). -
Discover Vertexvis.discover_vertex(u, g)void -This is invoked when a vertex is first discovered and is added to the -OPEN list. -
Examine Vertexvis.examine_vertex(u, g)void -This is invoked on a vertex as it is popped from the queue (i.e., it -has the lowest cost on the OPEN list). This happens immediately before -examine_edge() is invoked on each of the out-edges of vertex -u. -
Examine Edgevis.examine_edge(e, g)void -This is invoked on every out-edge of each vertex after it is -examined. -
Edge Relaxedvis.edge_relaxed(e, g)void -Upon examination, if the following condition holds then the edge is -relaxed (the distance of its target vertex is reduced) and this method -is invoked: -
-
-tie(u, s) = incident(e, g);
-D d_u = get(d, u), d_v = get(d, s);
-W w_e = get(w, e);
-assert(compare(combine(d_u, w_e), d_s));
-
-
-
Edge Not Relaxedvis.edge_not_relaxed(e, g)void -Upon examination, if an edge is not relaxed (see above) then this -method is invoked. -
Black Targetvis.black_target(e, g)void -This is invoked when a vertex that is on the CLOSED list is -``rediscovered'' via a more efficient path and is re-added to the -OPEN list. -
Finish Vertexvis.finish_vertex(u, g)void -This is invoked on a vertex when it is added to the CLOSED list. This -happens after all of its out-edges have been examined. -
- -

Models

- - - - -

See also

- -Visitor concepts - -
-
- - -
Copyright © 2004 -Kristopher Beevers, -Rensselaer Polytechnic Institute (beevek@cs.rpi.edu) -
- - - diff --git a/doc/AddEdgeVisitor.html b/doc/AddEdgeVisitor.html deleted file mode 100644 index 3cbc48170..000000000 --- a/doc/AddEdgeVisitor.html +++ /dev/null @@ -1,130 +0,0 @@ - - - -AddEdgeVisitor Concept - - - -C++ Boost - -
- -

AddEdgeVisitor Concept

- -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 -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. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Visitor is a type that models the AddEdgeVisitor concept
vis is an object of type Visitor
Graph is the type of a graph
u,v are objects of type graph_traits<Graph>::vertex_descriptor -
e is an object of type graph_traits<Graph>::edge_descriptor -
v is an object of type graph_traits<Graph>::vertex_descriptor -
- -
- - -

Associated Types

- -None - -

Valid Expressions

- -

- - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Add an Edge vis.visit_vertex_pair(u, v, g) void Invoked every time an edge between vertices u and v - should be added to the graph g. -
- -

Models

- -Two models of this concept are defined in the file - -add_edge_visitors.hpp: - - - -

- -
-

-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/AdjacencyGraph.html b/doc/AdjacencyGraph.html deleted file mode 100644 index 097ac90c5..000000000 --- a/doc/AdjacencyGraph.html +++ /dev/null @@ -1,167 +0,0 @@ - - - -AdjacencyGraph - -C++ Boost - -
- - - -

-AdjacencyGraph -

- -The AdjacencyGraph concept provides an interface for efficient access -of the adjacent vertices to a vertex in a graph. This is quite similar -to the IncidenceGraph concept (the -target of an out-edge is an adjacent vertex). Both concepts are -provided because in some contexts there is only concern for the -vertices, whereas in other contexts the edges are also important. - -

Refinement of

- -Graph - -

Notation

- - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
vAn object of type boost::graph_traits<G>::vertex_descriptor.
- - -

Associated Types

- - - - - - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to adjacency_graph_tag. -
boost::graph_traits<G>::adjacency_iterator
-An adjacency iterator for a vertex v provides access to the -vertices adjacent to v. As such, the value type of an -adjacency iterator is the vertex descriptor type of its graph. An -adjacency iterator must meet the requirements of MultiPassInputIterator. -
- -

Valid Expressions

- - - - - - - - - -
adjacent_vertices(v, g) -Returns an iterator-range providing access to the vertices adjacent to -vertex v in graph g.[1] - -
Return type: -std::pair<adjacency_iterator, adjacency_iterator> -
- -

Complexity guarantees

- -The adjacent_vertices() function must return in constant time. - -

See Also

- -Graph concepts, -adjacency_iterator - -

Concept Checking Class

- -
-  template <class G>
-  struct AdjacencyGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::adjacency_iterator
-      adjacency_iterator;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( MultiPassInputIteratorConcept<adjacency_iterator> ));
-
-      p = adjacent_vertices(v, g);
-      v = *p.first;
-      const_constraints(g);
-    }
-    void const_constraints(const G& g) {
-      p = adjacent_vertices(v, g);
-    }
-    std::pair<adjacency_iterator,adjacency_iterator> p;
-    typename boost::graph_traits<G>::vertex_descriptor v;
-    G g;
-  };
-
- -

Design Rationale

- -The AdjacencyGraph concept is somewhat frivolous since IncidenceGraph really covers the same -functionality (and more). The AdjacencyGraph concept exists because -there are situations when adjacent_vertices() is more -convenient to use than out_edges(). If you are constructing a -graph class and do not want to put in the extra work of creating an -adjacency iterator, have no fear. There is an adaptor class named adjacency_iterator that -you can use to create an adjacency iterator out of an out-edge -iterator. - -

Notes

- -[1] The case of a -multigraph (where multiple edges can connect the same two -vertices) brings up an issue as to whether the iterators returned by -the adjacent_vertices() function access a range that -includes each adjacent vertex once, or whether it should match the -behavior of the out_edges() function, and access a -range that may include an adjacent vertex more than once. For now the -behavior is defined to match that of out_edges(), -though this decision may need to be reviewed in light of more -experience with graph algorithm implementations. - - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/AdjacencyMatrix.html b/doc/AdjacencyMatrix.html deleted file mode 100644 index a77a0aea5..000000000 --- a/doc/AdjacencyMatrix.html +++ /dev/null @@ -1,103 +0,0 @@ - - - -AdjacencyMatrix - -C++ Boost - -
- - - -

-AdjacencyMatrix -

- -

-The AdjacencyMatrix concept refines Graph -concept and adds the requirement for efficient access to any edge in -the graph given the source and target vertices. No Boost Graph Library -algorithms currently use this concept. However there are algorithms -not yet implemented such as Floyd-Warshall that would require this -concept. - -

Refinement of

- -Graph - -

Associated Types

- - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to adjacency_matrix_tag. -
- -

Valid Expressions

- - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Direct Edge Accessedge(u,v,g)std::pair<edge_descriptor, bool> -Returns a pair consisting of a flag saying whether there exists an -edge between u and v in graph g, and -consisting of the edge descriptor if the edge was found. -
- -

Complexity guarantees

- -The edge() function must return in constant time. - - -

Models

- -adjacency_matrix - -

Concept Checking Class

- -
-  template <class G>
-  struct AdjacencyMatrix
-  {
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    void constraints() {
-      p = edge(u, v, g);
-    }
-    typename boost::graph_traits<G>::vertex_descriptor u, v;
-    std::pair<bool, edge_descriptor> p;
-    G g;
-  };
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/BFSVisitor.html b/doc/BFSVisitor.html deleted file mode 100644 index 1f4241f53..000000000 --- a/doc/BFSVisitor.html +++ /dev/null @@ -1,220 +0,0 @@ - - - -Boost Graph Library: BFSVisitor - -C++ Boost - -
- -

(Python)BFS Visitor Concept

- -This concept defines the visitor interface for breadth_first_search(). -Users can define a class with the BFS Visitor interface and pass and -object of the class to breadth_first_search(), thereby -augmenting the actions taken during the graph search. - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of BFS Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
s,uAn object of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Initialize Vertexvis.initialize_vertex(s, g)void -This is invoked on every vertex of the graph before the start of the -graph search. -
Discover Vertexvis.discover_vertex(u, g)void -This is invoked when a vertex is encountered for the first time. -
Examine Vertexvis.examine_vertex(u, g)void -This is invoked on a vertex as it is popped from the queue. This -happens immediately before examine_edge() is invoked -on each of the out-edges of vertex u. -
Examine Edgevis.examine_edge(e, g)void -This is invoked on every out-edge of each vertex after it is discovered. -
Tree Edgevis.tree_edge(e, g)void -This is invoked on each edge as it becomes a member of the edges that -form the search tree.
Non-Tree Edgevis.non_tree_edge(e, g)void -This is invoked on back or cross edges for directed graphs and cross -edges for undirected graphs. -
Gray Targetvis.gray_target(e, g)void -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. -
Black Targetvis.black_target(e, g)void -This is invoked on the subset of non-tree edges whose target vertex is -colored black at the time of examination. The color black indicates -that the vertex has been removed from the queue. -
Finish Vertexvis.finish_vertex(u, g)void -This invoked on a vertex after all of its out edges have been added to the -search tree and all of the adjacent vertices have been discovered -(but before the out-edges of the adjacent vertices have been examined). -
- -

Models

- - - -

Python

-To implement a model of the BFSVisitor concept in Python, -create a new class that derives from the BFSVisitor type of -the graph, which will be -named GraphType.BFSVisitor. The events and syntax are -the same as with visitors in C++. Here is an example for the -Python bgl.Graph graph type: - -
-class count_tree_edges_bfs_visitor(bgl.Graph.BFSVisitor):
-  def __init__(self, name_map):
-    bgl.Graph.BFSVisitor.__init__(self)
-    self.name_map = name_map
-
-  def tree_edge(self, e, g):
-    (u, v) = (g.source(e), g.target(e))
-    print "Tree edge ",
-    print self.name_map[u],
-    print " -> ",
-    print self.name_map[v]
-
- -

See also

- -Visitor concepts - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/BUILD_DOCS.sh b/doc/BUILD_DOCS.sh deleted file mode 100755 index 2ad09e3ad..000000000 --- a/doc/BUILD_DOCS.sh +++ /dev/null @@ -1,22 +0,0 @@ -#!/bin/sh - -# Copyright (C) 2009 The Trustees of Indiana University. -# Copyright (C) 2010 Daniel Trebbien. -# Use, modification and distribution is subject to the Boost Software -# License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at -# http://www.boost.org/LICENSE_1_0.txt) - -# Authors: Jeremiah Willcock, Daniel Trebbien, Andrew Lumsdaine - -for i in read_graphml read_graphviz write_graphml; do - rst2html.py -gdt --link-stylesheet --traceback --trim-footnote-reference-space --footnote-references=superscript --stylesheet=../../../rst.css $i.rst > $i.html -done -# Also see grid_graph_export_png.sh for figure conversions - -# Stoer-Wagner images from Daniel Trebbien -fdp -s -n -Tgif -ostoer_wagner_imgs/digraph1.gif stoer_wagner_imgs/digraph1.dot -fdp -s -n -Tgif -ostoer_wagner_imgs/digraph1-min-cut.gif stoer_wagner_imgs/digraph1-min-cut.dot -fdp -s -n -Tgif -ostoer_wagner_imgs/stoer_wagner-example.gif stoer_wagner_imgs/stoer_wagner-example.dot -fdp -s -n -Tgif -ostoer_wagner_imgs/stoer_wagner-example-c1.gif stoer_wagner_imgs/stoer_wagner-example-c1.dot -fdp -s -n -Tgif -ostoer_wagner_imgs/stoer_wagner-example-min-cut.gif stoer_wagner_imgs/stoer_wagner-example-min-cut.dot -dot -Tgif -ostoer_wagner_imgs/stoer_wagner.cpp.gif stoer_wagner_imgs/stoer_wagner.cpp.dot diff --git a/doc/BasicMatrix.html b/doc/BasicMatrix.html deleted file mode 100644 index 589bf5991..000000000 --- a/doc/BasicMatrix.html +++ /dev/null @@ -1,103 +0,0 @@ - - - -BasicMatrix - -C++ Boost - -
- -

-BasicMatrix -

- -The BasicMatrix concept provides a minimalist interface for -accessing elements from a 2 dimensional table of values. - - -

Refinement of

- -none - -

Notation

- - - - - - - - - - - - - - - - - -
{M,I,V}The matrix, index, and values types that together model the BasicMatrix concept.
AAn object of type M.
i, jObjects of type I.
- -

Associated Types

- -none - -

Valid Expressions

- - - - - - - - -
A[i][j]Returns a reference to the element object stored at index (i,j)
-Return type: V& for mutable A or const V& -for constant A. -
- -

Complexity guarantees

- -Element access is constant time. - -

Concept Checking Class

- -
-  template <class M, class I, class V>
-  struct BasicMatrixConcept
-  {
-    void constraints() {
-      V& elt = A[i][j];
-      const_constraints(A);
-      ignore_unused_variable_warning(elt);
-    }
-    void const_constraints(const M& A) {
-      const V& elt = A[i][j];
-      ignore_unused_variable_warning(elt);
-    }
-    M A;
-    I i, j;
-  };
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/BellmanFordVisitor.html b/doc/BellmanFordVisitor.html deleted file mode 100644 index 37188e63c..000000000 --- a/doc/BellmanFordVisitor.html +++ /dev/null @@ -1,184 +0,0 @@ - - - -Boost Graph Library: Bellman Ford Visitor - -C++ Boost - -
- -

(Python)Bellman Ford Visitor Concept

- -This concept defines the visitor interface for bellman_ford_shortest_paths(). -Users can define a class with the Bellman Ford Visitor interface and -pass and object of the class to bellman_ford_shortest_paths(), -thereby augmenting the actions taken during the graph search. - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of Bellman Ford Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
s,uAn object of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Examine Edgevis.examine_edge(e, g)void -This is invoked on every edge in the graph num_vertices(g) times. -
Edge Relaxedvis.edge_relaxed(e, g)void -Upon examination, if the following condition holds then the edge -is relaxed (its distance is reduced), and this method is invoked.
- -tie(u,v) = incident(e, g);
-D d_u = get(d, u), d_v = get(d, v);
-W w_e = get(w, e);
-assert(compare(combine(d_u, w_e), d_v));
- -
Edge Not Relaxededge_not_relaxed(e, g)void -Upon examination, if the edge is not relaxed (see above) then -this method is invoked. -
Edge Minimizedvis.edge_minimized(e, g)void -After num_vertices(g) iterations through the edge set -of the graph are completed, one last iteration is made to test whether -each edge was minimized. If the edge is minimized then this function -is invoked. -
Edge Not Minimizededge_not_minimized(e, g)void -If the edge is not minimized, this function is invoked. This happens -when there is a negative cycle in the graph. -
- - -

Models

- - - - -

Python

- -To implement a model of the BellmanFordVisitor concept in Python, -create a new class that derives from the BellmanFordVisitor type of -the graph, which will be -named GraphType.BellmanFordVisitor. The events and syntax are -the same as with visitors in C++. Here is an example for the -Python bgl.Graph graph type: - -
-class count_tree_edges_bellman_ford_visitor(bgl.Graph.BellmanFordVisitor):
-  def __init__(self, name_map):
-    bgl.Graph.BellmanFordVisitor.__init__(self)
-    self.name_map = name_map
-
-  def edge_relaxed(self, e, g):
-    (u, v) = (g.source(e), g.target(e))
-    print "Relaxed edge ",
-    print self.name_map[u],
-    print " -> ",
-    print self.name_map[v]
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/BidirectionalGraph.html b/doc/BidirectionalGraph.html deleted file mode 100644 index f897c4297..000000000 --- a/doc/BidirectionalGraph.html +++ /dev/null @@ -1,180 +0,0 @@ - - - -Bidirectional - -C++ Boost - -
- - -

- -BidirectionalGraph -

- -

-The BidirectionalGraph concept refines IncidenceGraph and adds the -requirement for efficient access to the in-edges of each vertex. This -concept is separated from IncidenceGraph because for directed -graphs efficient access to in-edges typically requires more storage -space, and many algorithms do not require access to in-edges. For -undirected graphs this is not an issue, since the in_edges() -and out_edges() functions are the same, they both return the -edges incident to the vertex. - -

Refinement of

- -IncidenceGraph - -

Notation

- - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
vAn object of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- - - - - - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to bidirectional_graph_tag. -
boost::graph_traits<G>::in_edge_iterator
-An in-edge iterator for a vertex v provides access to the -in-edges of v. As such, the value type of an in-edge iterator -is the edge descriptor type of its graph. An in-edge iterator must -meet the requirements of MultiPassInputIterator. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - -
in_edges(v, g) -Returns an iterator-range providing access to the -in-edges (for directed graphs) or incident edges (for -undirected graphs) of vertex v in graph g. -For both directed and undirected graphs, the target of -an out-edge is required to be vertex v and the -source is required to be a vertex that is adjacent to v. -
-Return type: std::pair<in_edge_iterator, in_edge_iterator> -
in_degree(v, g) -Returns the number of in-edges (for directed graphs) or the -number of incident edges (for undirected graphs) of vertex v -in graph g.
-Return type: degree_size_type -
degree(v, g)Returns the number of in-edges plus out-edges (for directed graphs) or the -number of incident edges (for undirected graphs) of vertex v -in graph g.
-Return type: degree_size_type -
- -

Models

- - - - -

Complexity guarantees

- -The in_edges() function is required to be constant time. The -in_degree() and degree() functions must be linear in -the number of in-edges (for directed graphs) or incident edges (for -undirected graphs). - -

See Also

- -Graph concepts - -

Concept Checking Class

- -
-  template <class G>
-  struct BidirectionalGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::in_edge_iterator
-      in_edge_iterator;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( IncidenceGraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( MultiPassInputIteratorConcept<in_edge_iterator> ));
-
-      p = in_edges(v, g);
-      n = in_degree(v, g);
-      n = degree(v, g);
-      e = *p.first;
-      const_constraints(g);
-    }
-    void const_constraints(const G& g) {
-      p = in_edges(v, g);
-      n = in_degree(v, g);
-      n = degree(v, g);
-      e = *p.first;
-    }
-    std::pair<in_edge_iterator, in_edge_iterator> p;
-    typename boost::graph_traits<G>::vertex_descriptor v;
-    typename boost::graph_traits<G>::edge_descriptor e;
-    typename boost::graph_traits<G>::degree_size_type n;
-    G g;
-  };
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/Buffer.html b/doc/Buffer.html deleted file mode 100644 index cba8b4579..000000000 --- a/doc/Buffer.html +++ /dev/null @@ -1,118 +0,0 @@ - - - -Buffer - - -C++ Boost - -
- -

Buffer Concept

- -A Buffer is something in which items can be put and removed. -The Buffer concept has very few requirements. It does -not require any particular ordering of how the items are stored or in -what order they will appear when removed, however, there is typically -some sort of ordering policy. - -

Notation

- - - - - -
B is a type that models Buffer.
T is the value type of B.
t is an object of type T.
- - -

Members

- -For a type to model the Buffer concept it must have the following members. - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Member Description
value_type The type of object stored in the Buffer. The value type - must be Assignable.
size_type An unsigned integral type for representing the number of - objects in the Buffer.
void push(const T& t) Inserts t into the Buffer. size() will be - incremented by one.
void pop() Removes an object from the Buffer. size() will be - decremented by one. Precondition: empty() - is false.
T& top() Returns a mutable reference to some object in the Buffer. - Precondition: empty() is false.
const T& top() const Returns a const reference to some object in the Buffer. - Precondition: empty() is false.
size_type size() const Returns the number of objects in the Buffer. - Invariant: size() >= 0.
bool empty() const Equivalent to b.size() == 0.
- -

Complexity Guarantees

- - - -

Models

- - - -

- -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University and C++ Library & Compiler Group/SGI (jsiek@engr.sgi.com) -
- - - - diff --git a/doc/CONTRIBUTING.md b/doc/CONTRIBUTING.md new file mode 100644 index 000000000..d3813bf0c --- /dev/null +++ b/doc/CONTRIBUTING.md @@ -0,0 +1,85 @@ +# Contributing to the Boost.Graph documentation + +The docs are built with [Antora](https://antora.org) from AsciiDoc +sources under `doc/modules/ROOT/`. + +## Layout + +| Where | What | +|---|---| +| `doc/modules/ROOT/pages/` | All `.adoc` pages (organized by topic) | +| `doc/modules/ROOT/examples/` | One `.cpp` per page; the build script captures stdout into a sibling `.txt` | +| `doc/modules/ROOT/nav.adoc` | Left-side navigation tree | +| `doc/templates/` | Starter templates: `algorithm.adoc`, `generator.adoc`, `graph_class.adoc` — copy and fill in | +| `doc/playbook.yml` | Antora playbook (UI bundle, content sources) | +| `doc/modules/ROOT/examples/Jamfile` | b2 rules that compile every example and snapshot its stdout into a sibling `.txt` | +| `doc/build_example_outputs.sh`| g++-only fallback that does the same thing as the Jamfile, for contributors without a `boost-root` checkout | + +## Adding a new page + +1. Pick a template in `doc/templates/` and copy it into the right + `pages/` subdirectory. +2. Replace the placeholders (title, signatures, parameter table). Keep + the section order from the template so the page is consistent with + the rest. +3. Add an `.cpp` example under `modules/ROOT/examples/` at the path + the page's `include::example$…[]` directive points to. +4. Add an `xref:` line to `doc/modules/ROOT/nav.adoc`. + +## Building locally + +The example outputs are generated by b2 (the standard Boost build +system). From a `boost-root` layout: + +```sh +# 1) Compile every example and snapshot its stdout into a sibling .txt. +b2 libs/graph/doc/modules/ROOT/examples + +# 2) Build the static site. +cd libs/graph +npx antora doc/playbook.yml + +# 3) Open the result. +open doc/build/site/index.html # macOS +xdg-open doc/build/site/index.html # Linux +``` + +CI runs the same commands on every push. + +### Quick fallback (no boost-root required) + +For doc-only contributors who only want to fix typos and don't have a +boost-root checkout, a shell-script equivalent is provided: + +```sh +BOOST_INCLUDE=/path/to/boost/include \ +BOOST_LIB=/path/to/boost/lib \ +bash doc/build_example_outputs.sh +``` + +Functionally equivalent to step 1 above; uses g++ directly instead of +b2. `BOOST_LIB` is only needed for the three link-required examples +(`io/graphml.cpp`, `io/graphviz.cpp`, +`algorithms/isomorphism/isomorphism.cpp`). + +## Conventions + +- **Examples first.** `== Example` (with `*Expected output:*` block) + goes immediately after `*Defined in:*` so readers see working code + before signatures. +- **Bold metadata.** `*Complexity:*`, `*Defined in:*`, + `*Expected output:*` are bold. +- **Output blocks** use `[,text]\n----` (same listing-block wrapper as + the code above) and pull from the `.txt` sidecar via + `include::example$…[]`, so the documentation can never drift from the + code and the two blocks align vertically on the page. +- **Heading levels:** `==` for top-level sections; `===` only for + numbered overloads or grouped variants. The `'''` thematic break + appears only before a `===`, never before a `==`. +- **Bundled properties** preferred over interior tag properties in + examples, unless the algorithm requires the tag. + +## License + +By contributing you agree to license your contribution under the +[Boost Software License 1.0](http://www.boost.org/LICENSE_1_0.txt). diff --git a/doc/ColorValue.html b/doc/ColorValue.html deleted file mode 100644 index dec048705..000000000 --- a/doc/ColorValue.html +++ /dev/null @@ -1,108 +0,0 @@ - - - -Boost Graph Library: ColorValue Concept - -C++ Boost - -
- - -

-ColorValue -

- -

-This concept describes the requirements for the type used for color -values, as in for coloring a graph during a breath-first search to -mark which vertices have been visited. - -

- -

Refinement of

EqualityComparable -and DefaultConstructible - - -

Notation

- - - - - - - - - - - - -
TA type that is a model of ColorValue.
cvAn object of type T.
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Get Color White color_traits<T>::white()TReturns an object that represents the color white.
Get Color Gray color_traits<T>::gray()TReturns an object that represents the color gray.
Get Color Black color_traits<T>::black()TReturns an object that represents the color black.
- -

- - - -

Models

- - - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/DFSVisitor.html b/doc/DFSVisitor.html deleted file mode 100644 index 54483b9cc..000000000 --- a/doc/DFSVisitor.html +++ /dev/null @@ -1,221 +0,0 @@ - - - -DFS Visitor - -C++ Boost - -
- -

(Python)DFS Visitor Concept

- -This concept defines the visitor interface for depth_first_search(). -Users can define a class with the DFS Visitor interface and pass an -object of the class to depth_first_search(), thereby -augmenting the actions taken during the graph search. - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of DFS Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
s,uAn object of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Initialize Vertexvis.initialize_vertex(s, g)void -This is invoked on every vertex of the graph before the start of the -graph search. -
Start Vertexvis.start_vertex(s, g)void -This is invoked on the source vertex once before the start of the -search. -
Discover Vertexvis.discover_vertex(u, g)void -This is invoked when a vertex is encountered for the first time. -
Examine Edgevis.examine_edge(e, g)void -This is invoked on every out-edge of each vertex after it is discovered. -
Tree Edgevis.tree_edge(e, g)void -This is invoked on each edge as it becomes a member of the edges that -form the search tree.
Back Edgevis.back_edge(e, g)void -This is invoked on the back edges in the graph. For an undirected -graph there is some ambiguity between tree edges and back edges since -the edge (u,v) and (v,u) are the same edge, but both the -tree_edge() and back_edge() functions will be -invoked. One way to resolve this ambiguity is to record the tree -edges, and then disregard the back-edges that are already marked as -tree edges. An easy way to record tree edges is to record -predecessors at the tree_edge event point. -
Forward or Cross Edgevis.forward_or_cross_edge(e, g)void -This is invoked on forward or cross edges in the graph. In an -undirected graph this method is never called. -
Finish Edgevis.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 Vertexvis.finish_vertex(u, g)void -This is invoked on vertex u after finish_vertex has -been called for all the vertices in the DFS-tree rooted at vertex -u. If vertex u is a leaf in the DFS-tree, then -the finish_vertex function is called on u after -all the out-edges of u have been examined. -
- -

Models

- - - - -

Python

- -To implement a model of the DFSVisitor concept in Python, -create a new class that derives from the DFSVisitor type of -the graph, which will be -named GraphType.DFSVisitor. The events and syntax are -the same as with visitors in C++. Here is an example for the -Python bgl.Graph graph type: - -
-class count_tree_edges_dfs_visitor(bgl.Graph.DFSVisitor):
-  def __init__(self, name_map):
-    bgl.Graph.DFSVisitor.__init__(self)
-    self.name_map = name_map
-
-  def tree_edge(self, e, g):
-    (u, v) = (g.source(e), g.target(e))
-    print "Tree edge ",
-    print self.name_map[u],
-    print " -> ",
-    print self.name_map[v]
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/DijkstraVisitor.html b/doc/DijkstraVisitor.html deleted file mode 100644 index 90d0fafdb..000000000 --- a/doc/DijkstraVisitor.html +++ /dev/null @@ -1,222 +0,0 @@ - - - -Boost Graph Library: Dijkstra Visitor - -C++ Boost - -
- -

(Python)Dijkstra Visitor Concept

- -This concept defines the visitor interface for dijkstra_shortest_paths() -and related algorithms. The user can create a class that matches this -interface, and then pass objects of the class into -dijkstra_shortest_paths() to augment the actions taken during -the search. - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of Dijkstra Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
s,u,vAn object of type boost::graph_traits<G>::vertex_descriptor.
DistanceMapA type that is a model of Read/Write Property Map.
dAn object of type DistanceMap.
WeightMapA type that is a model of Readable Property Map.
wAn object of type WeightMap.
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Initialize Vertexvis.initialize_vertex(u, g)void -This is invoked one each vertex of the graph when it is initialized. -
Examine Vertexvis.examine_vertex(u, g)void -This is invoked on a vertex as it is popped from the queue. This -happens immediately before examine_edge() is invoked -on each of the out-edges of vertex u. -
Examine Edgevis.examine_edge(e, g)void -This is invoked on every out-edge of each vertex after it is discovered. -
Discover Vertexvis.discover_vertex(u, g)void -This is invoked when a vertex is encountered for the first time. -
Edge Relaxedvis.edge_relaxed(e, g)void -Upon examination, if the following condition holds then the edge -is relaxed (its distance is reduced), and this method is invoked.
- -tie(u,v) = incident(e, g);
-D d_u = get(d, u), d_v = get(d, v);
-W w_e = get(w, e);
-assert(compare(combine(d_u, w_e), d_v));
- -
Edge Not Relaxedvis.edge_not_relaxed(e, g)void -Upon examination, if the edge is not relaxed (see above) then -this method is invoked. -
Finish Vertexvis.finish_vertex(u, g)void -This invoked on a vertex after all of its out edges have been added to the -search tree and all of the adjacent vertices have been discovered -(but before their out-edges have been examined). -
- -

Models

- - - - -

Python

- -To implement a model of the DijkstraVisitor concept in Python, -create a new class that derives from the DijkstraVisitor type of -the graph, which will be -named GraphType.DijkstraVisitor. The events and syntax are -the same as with visitors in C++. Here is an example for the -Python bgl.Graph graph type: - -
-class count_tree_edges_dijkstra_visitor(bgl.Graph.DijkstraVisitor):
-  def __init__(self, name_map):
-    bgl.Graph.DijkstraVisitor.__init__(self)
-    self.name_map = name_map
-
-  def edge_relaxed(self, e, g):
-    (u, v) = (g.source(e), g.target(e))
-    print "Relaxed edge ",
-    print self.name_map[u],
-    print " -> ",
-    print self.name_map[v]
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/EdgeListGraph.html b/doc/EdgeListGraph.html deleted file mode 100644 index 70c33ccdf..000000000 --- a/doc/EdgeListGraph.html +++ /dev/null @@ -1,184 +0,0 @@ - - - -EdgeListGraph - -C++ Boost - -
- - -

-EdgeListGraph -

- -The EdgeListGraph concept refines the Graph -concept, and adds the requirement for efficient access to all the -edges in the graph. - - -

Refinement of

- -Graph - - -

Notation

- - - - - - - - - - - - - - - - - -
GA type that is a model of EdgeListGraph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
- -

Associated Types

- - - - - - - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to edge_list_graph_tag. -
boost::graph_traits<G>::edge_iterator
-An edge iterator (obtained via edges(g)) provides access to -all of the edges in a graph. An edge iterator type must meet the -requirements of MultiPassInputIterator. The -value type of the edge iterator must be the same as the edge -descriptor of the graph. - -
boost::graph_traits<G>::edges_size_type
-The unsigned integer type used to represent the number of edges in the -graph. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - -
edges(g)Returns an iterator-range providing access to all - the edges in the graph g.
-Return type: std::pair<edge_iterator, edge_iterator> -
num_edges(g)Returns the number of edges in the graph g.
-Return type: edges_size_type -
source(e, g) -Returns the vertex descriptor for u of the edge (u,v) -represented by e.
-Return type: vertex_descriptor -
target(e, g) -Returns the vertex descriptor for -v of the edge (u,v) represented by e.
-Return type: vertex_descriptor -
- - -

Models

- - - - -

Complexity guarantees

- -The edges(), source(), and target() functions -must all return in constant time. - - -

See Also

- -Graph concepts - -

Concept Checking Class

- -

-

-  template <class G>
-  struct EdgeListGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::edge_iterator
-      edge_iterator;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( GraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( MultiPassInputIteratorConcept<edge_iterator> ));
-
-      p = edges(g);
-      E = num_edges(g);
-      e = *p.first;
-      u = source(e, g);
-      v = target(e, g);
-      const_constraints(g);
-    }
-    void const_constraints(const G& g) {
-      p = edges(g);
-      E = num_edges(g);
-      e = *p.first;
-      u = source(e, g);
-      v = target(e, g);
-    }
-    std::pair<edge_iterator,edge_iterator> p;
-    typename boost::graph_traits<G>::vertex_descriptor u, v;
-    typename boost::graph_traits<G>::edge_descriptor e;
-    typename boost::graph_traits<G>::edges_size_type E;
-    G g;
-  };
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/EdgeMutableGraph.html b/doc/EdgeMutableGraph.html deleted file mode 100644 index 594406653..000000000 --- a/doc/EdgeMutableGraph.html +++ /dev/null @@ -1,108 +0,0 @@ - - - -Edge Mutable Graph - -C++ Boost - -
- - -

-Edge Mutable Graph -

- -The Edge Mutable Graph concept defines the interface for a -graph that supports the addition and removal of edges. - -

Refinement of

- -Graph - -

Associated Types

- -No additional associated types. - -

Valid Expressions

- - - - -

Complexity guarantees

- -

-UNDER CONSTRUCTION - -

See Also

- -Graph concepts - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/EventVisitor.html b/doc/EventVisitor.html deleted file mode 100644 index e7611e694..000000000 --- a/doc/EventVisitor.html +++ /dev/null @@ -1,161 +0,0 @@ - - - -Boost Graph Library: EventVisitor - -C++ Boost - -
- -

EventVisitor Concept

- -This concept defines the interface for single-event visitors. An -EventVisitor has an apply member function (operator()) which -is invoked within the graph algorithm at the event-point specified by -the event_filter typedef within the -EventVisitor. EventVisitor's can be combined into an EventVistorList. - -

-The following is the list of event tags that can be invoked in BGL -algorithms. Each tag corresponds to a member function of the visitor -for an algorithm. For example, the BFSVisitor of breadth_first_search() -has a cycle_edge() member function. The corresponding tag is -on_cycle_edge. The first argument is the event visitor's -operator() must be either an edge or vertex descriptor -depending on the event tag. - -

-namespace boost {
-  struct on_initialize_vertex { };
-  struct on_start_vertex { };
-  struct on_discover_vertex { };
-  struct on_examine_edge { };
-  struct on_tree_edge { };
-  struct on_cycle_edge { };
-  struct on_finish_vertex { };
-  struct on_forward_or_cross_edge { };
-  struct on_back_edge { };
-  struct on_edge_relaxed { };
-  struct on_edge_not_relaxed { };
-  struct on_edge_minimized { };
-  struct on_edge_not_minimized { };
-} // namespace boost
-
- - -

Refinement of

- -Copy Constructible -(copying a visitor should be a lightweight operation). - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
VA type that is a model of EventVisitor.
visAn object of type V.
xAn object of type -boost::graph_traits<G>::vertex_descriptor -or boost::graph_traits<G>::edge_descriptor.
- -

Associated Types

- - - - - - - - - -
Event Filter V::event_filter -A tag struct to specify on which event the visitor should be invoked. -
- -

Valid Expressions

- - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Apply Visitorvis(x, g)void -Invokes the visitor operation on object x, which is -either a vertex or edge descriptor of the graph. -
- - -

Models

- - - -

See Also

- -EventVisitorList, -Visitor concepts - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/EventVisitorList.html b/doc/EventVisitorList.html deleted file mode 100644 index 293f9303b..000000000 --- a/doc/EventVisitorList.html +++ /dev/null @@ -1,127 +0,0 @@ - - - -Boost Graph Library: EventVisitorList - -C++ Boost - -
- -

EventVisitorList Concept

- -An EventVisitorList is either an EventVisitor, or a list of -EventVisitors combined using std::pair. Each graph algorithm -defines visitor adaptors that convert an EventVisitorList into the -particular kind of visitor needed by the algorithm. - -In the following example we will show how to combine event visitors -into a list using std::pair and how to use an algorithm's -visitor adaptor class. - -

-Suppose we would like to print out the parenthesis -structure of the discover/finish times of vertices in a depth-first -search. We can use the BGL algorithm depth_first_search() and -two event visitors to accomplish this. The complete source code for -the following example is in -examples/dfs_parenthesis.cpp. First we define the two -event visitors. We use on_discover_vertex and -on_finish_vertex as the event points, selected from the list -of event points specified in DFSVisitor. - -

-struct open_paren : public base_visitor<open_paren> {
-  typedef on_discover_vertex event_filter;
-  template <class Vertex, class Graph>
-  void operator()(Vertex v, Graph& G) {
-    std::cout << "(" << v;
-  }
-};
-struct close_paren : public base_visitor<close_paren> {
-  typedef on_finish_vertex event_filter;
-  template <class Vertex, class Graph>
-  void operator()(Vertex v, Graph& G) {
-    std::cout << v << ")";
-  }
-};
-
- -Next we create two event visitor objects and make an EventVisitorList -out of them using a std::pair which created by -std::make_pair. - -
-std::make_pair(open_paren(), close_paren())
-
- -Next we want to pass this list into depth_first_search(), but -depth_first_search() is expecting a DFSVisitor, not a EventVisitorList. We -therefore use the dfs_visitor adaptor which turns -an EventVisitor list into a DFSVisitor. Like all of the visitor -adaptors, dfs_visitor has a creation function called -make_dfs_visitor(). - -
-make_dfs_visitor(std::make_pair(open_paren(), close_paren()))
-
- -Now we can pass the resulting visitor object into -depth_first_search() as follows. - -
-  // graph object G is created ...
-
-  std::vector<default_color_type> color(num_vertices(G));
-
-  depth_first_search(G, make_dfs_visitor(std::make_pair(open_paren(), close_paren())),
-                     color.begin());
-
- -For creating a list of more than two event visitors, you can nest calls to -std::make_pair in the following way: - -
-std::make_pair(visitor1,
-  std::make_pair(visitor2,
-    ...
-    std::make_pair(visitorN-1, visitorN)...));
-
- - - -

See Also

- -EventVisitor, -Visitor concepts - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/Graph.html b/doc/Graph.html deleted file mode 100644 index c5d6108af..000000000 --- a/doc/Graph.html +++ /dev/null @@ -1,149 +0,0 @@ - - - -Graph - -C++ Boost - -
- -

-Graph -

- -

-The Graph concept contains a few requirements that are common to all -the graph concepts. These include some associated types for -vertex_descriptor, edge_descriptor, etc. One should -note that a model of Graph is not required to be a model of Assignable, -so algorithms should pass graph objects by reference. - -

- -

Notation

- - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
- -

Associated Types

- - - - - - - - - - - - - - - - - - - - - - -
boost::graph_traits<G>::vertex_descriptor
-A vertex descriptor corresponds to a unique vertex in an abstract -graph instance. A vertex descriptor must be -Default Constructible, -Assignable, and -Equality Comparable. -
boost::graph_traits<G>::edge_descriptor
-An edge descriptor corresponds to a unique edge (u,v) in a -graph. An edge descriptor must be Default Constructible, -Assignable, and -Equality Comparable. -
boost::graph_traits<G>::directed_category
-This type shall be convertible to directed_tag or undirected_tag. -
boost::graph_traits<G>::edge_parallel_category
-This describes whether the graph class allows the insertion of -parallel edges (edges with the same source and target). The two tags -are allow_parallel_edge_tag and disallow_parallel_edge_tag. -
boost::graph_traits<G>::traversal_category
-This describes the ways in which the vertices and edges of the -graph can be visited. The choices are incidence_graph_tag, -adjacency_graph_tag, bidirectional_graph_tag, -vertex_list_graph_tag, edge_list_graph_tag, and -adjacency_matrix_tag. You can also create your own -tag which should inherit from one or more of the above. -
- -

Valid Expressions

- - - - - - -
boost::graph_traits<G>::null_vertex()
 -Returns a special boost::graph_traits<G>::vertex_descriptor object which does not refer to -any vertex of graph object which type is G. - -
- - - -

Concept Checking Class

- -
-  template <class G>
-  struct GraphConcept
-  {
-    typedef typename boost::graph_traits<G>::vertex_descriptor vertex_descriptor;
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    typedef typename boost::graph_traits<G>::directed_category directed_category;
-    typedef typename boost::graph_traits<G>::edge_parallel_category edge_parallel_category;
-    typedef typename boost::graph_traits<G>::traversal_category traversal_category;
-
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( DefaultConstructibleConcept<vertex_descriptor> ));
-      BOOST_CONCEPT_ASSERT(( EqualityComparableConcept<vertex_descriptor> ));
-      BOOST_CONCEPT_ASSERT(( AssignableConcept<vertex_descriptor> ));
-      BOOST_CONCEPT_ASSERT(( DefaultConstructibleConcept<edge_descriptor> ));
-      BOOST_CONCEPT_ASSERT(( EqualityComparableConcept<edge_descriptor> ));
-      BOOST_CONCEPT_ASSERT(( AssignableConcept<edge_descriptor> ));
-    }
-    G g;
-  };
-
- -

See Also

- -Graph concepts - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/IncidenceGraph.html b/doc/IncidenceGraph.html deleted file mode 100644 index 843ecb595..000000000 --- a/doc/IncidenceGraph.html +++ /dev/null @@ -1,202 +0,0 @@ - - - -IncidenceGraph - -C++ Boost - -
- -

-IncidenceGraph -

- -The IncidenceGraph concept provides an interface for -efficient access to the out-edges of each vertex in the graph. - - -

Refinement of

- -Graph - -

Notation

- - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of IncidenceGraph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
u, vAre objects of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- - - - - - - - - - - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to incidence_graph_tag. -
-
boost::graph_traits<G>::out_edge_iterator
-An out-edge iterator for a vertex v provides access to the -out-edges of the vertex. As such, the value type of an out-edge -iterator is the edge descriptor type of its graph. An out-edge -iterator must meet the requirements of MultiPassInputIterator. -
boost::graph_traits<G>::degree_size_type
-The unsigned integral type used for representing the number -out-edges or incident edges of a vertex. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - -
source(e, g)Returns the vertex descriptor for u of the edge (u,v) represented by e.
-Return type: vertex_descriptor -
target(e, g)Returns the vertex descriptor for v of the edge (u,v) represented by e.
-Return type: vertex_descriptor -
out_edges(u, g)Returns an iterator-range providing access to the out-edges (for -directed graphs) or incident edges (for undirected graphs) of vertex -u in graph g. The source vertex of an edge obtained -via an out edge iterator is guaranteed (for both directed and -undirected graphs) to be the vertex u used in the call to -out_edges(u, g) and the target vertex must be a vertex -adjacent to u.[1] -
-Return type: std::pair<out_edge_iterator, out_edge_iterator> -
out_degree(u, g)Returns the number of out-edges (for directed graphs) or the -number of incident edges (for undirected graphs) of vertex u -in graph g.
-Return type: degree_size_type -
- -

- -

Complexity guarantees

- -

-The source(), target(), and out_edges() -functions must all be constant time. The out_degree() -function must be linear in the number of out-edges. - -

- -

See Also

- -Graph concepts - -

Notes

- -[1] For undirected graphs, the edge (u,v) is -the same as edge (v,u), so without some extra guarantee an -implementation would be free use any ordering for the pair of vertices -in an out-edge. For example, if you call out_edges(u, g), and -v is one of the vertices adjacent to u, then the -implementation would be free to return (v,u) as an out-edge -which would be non-intuitive and cause trouble for algorithms. -Therefore, the extra requirement is added that the out-edge connecting -u and v must be given as (u,v) and not -(v,u). - -

Concept Checking Class

- -
-  template <class G>
-  struct IncidenceGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::out_edge_iterator out_edge_iterator;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( GraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( MultiPassInputIteratorConcept<out_edge_iterator> ));
-
-      p = out_edges(u, g);
-      e = *p.first;
-      u = source(e, g);
-      v = target(e, g);
-    }
-    void const_constraints(const G& g) {
-      p = out_edges(u, g);
-      e = *p.first;
-      u = source(e, g);
-      v = target(e, g);
-    }
-    std::pair<out_edge_iterator, out_edge_iterator> p;
-    typename boost::graph_traits<G>::vertex_descriptor u, v;
-    typename boost::graph_traits<G>::edge_descriptor e;
-    G g;
-  };
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/IteratorConstructibleGraph.html b/doc/IteratorConstructibleGraph.html deleted file mode 100644 index 29b4129d2..000000000 --- a/doc/IteratorConstructibleGraph.html +++ /dev/null @@ -1,161 +0,0 @@ - - - -IteratorConstructibleGraph - -C++ Boost - -
- -

-IteratorConstructibleGraph -

- -The IteratorConstructibleGraph concept describes the interface for -graph types that can be constructed using a kind of edge iterator. The -edge iterator can be any InputIterator -that dereferences to a pair of integers (i,j), which represent -an edge that should be in the graph. The two integers i and -j represent vertices where 0 <= i < |V| and 0 <= j < -|V|. The edge iterator's value type should be -std::pair<T,T> (or at least be a structure that has -members first and second) and the value type -T of the pair must be convertible to the -vertices_size_type of the graph (an integer). - -There are two valid expressions required by this concept, both of -which are constructors. The first creates a graph object from a -first/last iterator range. The second constructor also takes a -first/last iterator range and in addition requires the number of -vertices and number of edges. For some graph and edge iterator types -the second constructor can be more efficient than the first. - -

Example

- -The following exampe creates two graph objects from an array of edges -(vertex pairs). The type Edge* satisfies the requirements for -an InputIterator -and can therefore be used to construct a graph. - -
-  typedef ... IteratorConstructibleGraph;
-  typedef boost::graph_traits Traits;
-
-  typedef std::pair Edge;
-  Edge edge_array[] =
-    { Edge(0,1), Edge(0,2), Edge(0,3), Edge(0,4), Edge(0,5),
-      Edge(1, 2), Edge(1,5), Edge(1,3),
-      Edge(2, 4), Edge(2,5),
-      Edge(3, 2),
-      Edge(4, 3), Edge(4,1),
-      Edge(5, 4) };
-  Edge* first = edge_array,
-    last = edge_array + sizeof(edge_array)/sizeof(Edge);
-
-  IteratorConstructibleGraph G1(first, last);
-  // do something with G1 ...
-
-  Traits::vertices_size_type size_V = 6;
-  Traits::edges_size_type size_E = sizeof(edge_array)/sizeof(Edge);
-  IteratorConstructibleGraph G2(first, last, size_V, size_E);
-  // do something with G2 ...
-
- -

Refinement of

- -Graph - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gis a graph type that models IteratorConstructibleGraph.
gis an object of type G.
first, lastare edge iterators (see above).
Tris an object of type graph_traits<G>.
n_verticesis an object of type Tr::vertices_size_type.
n_edgesis an object of type Tr::edges_size_type.
- - -

Valid Expressions

- - - - - - - - - - - -
-
G g(first, last);
-Construct graph object g given an edge range [first,last). -
-
G g(first, last, n_vertices, n_edges);
-Construct graph object g given an edge range -[first,last), the number of vertices, and the number of -edges. Sometimes this constructor is more efficient than the -constructor lacking the graph size information. -
- - - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/KeyedUpdatableQueue.html b/doc/KeyedUpdatableQueue.html deleted file mode 100644 index 9a03a9b89..000000000 --- a/doc/KeyedUpdatableQueue.html +++ /dev/null @@ -1,99 +0,0 @@ - - - - -KeyedUpdatableQueue - - -C++ Boost - -

KeyedUpdatableQueue

- -

A KeyedUpdatableQueue is a refinement of the UpdatableQueue concept. -It requires that models order the contained values by their keys, to which -values are mapped via a read/write key map. - -

Notation

- - - - -
Q is a type that models KeyedUpdatableQueue.
T is the value type of Q.
- - -

Members

- -For a type to model the KeyedUpdatableQueue concept it must have the following members -in addition to the members that are required of types that model UpdatableQueue: - -

- - - - - - - - - - - - - - - - - -
Member Description
key_type The type of keys that are associated with values
key_map The key property map type. This type must model Read/Write Property Map.
key_map keys() const Returns the key map
- -

Concept Checking Class

- -

boost/graph/buffer_concepts.hpp - -

-  template <class Q>
-  struct KeyedUpdatableQueueConcept
-  {
-    typedef typename Q::key_type key_type;
-    typedef typename Q::key_map key_map;
-
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( UpdatableQueue<Q> ));
-      BOOST_CONCEPT_ASSERT(( ReadWritePropertyMap< key_map, typename Buffer<Q>::value_type > ));
-    }
-
-    void const_constraints(const Q& cq) {
-      km = cq.keys();
-      k = get(km, g_ct);
-    }
-
-    static const typename Buffer<Q>::value_type g_ct;
-    key_type k;
-    key_map km;
-    Q q;
-  };
-
- -

Models

- - - -
-
- - - - - -
Copyright © 2010Daniel Trebbien (dtrebbien@gmail.com) -
- - - \ No newline at end of file diff --git a/doc/Makefile b/doc/Makefile deleted file mode 100644 index 02d2899a2..000000000 --- a/doc/Makefile +++ /dev/null @@ -1,101 +0,0 @@ -# Copyright (c) 2002 Trustees of Indiana University -# -# Distributed under the Boost Software License, Version 1.0. -# (See accompanying file LICENSE_1_0.txt or copy at -# http://www.boost.org/LICENSE_1_0.txt) - -DVIPS = dvips - -LATEX = latex -LATEXOUT = dvi -RESULT = ps - -LATEX = pdflatex -LATEXOUT = pdf -RESULT = pdf - -.SUFFIXES: .tex .dvi .ps .pdf .c .lg .eps .fig .gif .dot .w .cpp .o .exe - -.tex.$(LATEXOUT): - @ if test ! -f $*.ind; then echo "" > $*.ind; fi - @ $(LATEX) $* - @ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \ - then $(LATEX) $* ; fi - @ if ( grep 'LaTeX Warning: Citation' $*.log > /dev/null ); \ - then bibtex $* ; $(LATEX) $* ; fi - @ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \ - then $(LATEX) $* ; fi - @ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \ - then $(LATEX) $* ; fi - @ if ( grep 'Writing index file' $*.log > /dev/null ); \ - then makeindex $* ; $(LATEX) $* ; fi - @ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \ - then $(LATEX) $* ; fi - @ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \ - then $(LATEX) $* ; fi - -.dvi.ps: - $(DVIPS) -t letter -o $*.ps $* - -.eps.pdf: - epstopdf $*.eps - -.dot.eps: - dot -Tps -o $*.eps $*.dot - -.w.tex: /afs/nd.edu/user11/jsiek/.jweb - jweb -np $*.w - -BOOST = $(HOME)/boost -BOOST_ALGO = $(HOME)/boost.algorithm -CXX = c++ -INCLUDES = -I$(BOOST) -I$(BOOST_ALGO) -#OPT = +K2 --display_error_number --diag_suppress=186 -OPT = -Wall -Wno-long-double -ftemplate-depth-30 -CXXFLAGS = $(OPT) $(INCLUDES) - -.cpp.o: - $(CXX) $(CXXFLAGS) $< -c - - -JWEB = isomorphism-impl.w isomorphism-impl-v3.w -DOT = out.dot in.dot iso-eg.dot iso-eg2.dot -EPS_GEN = $(DOT:.dot=.eps) -WEBTEX = $(JWEB:.w=.tex) -PDFPICT = $(EPS_GEN:.eps=.pdf) - -default: isomorphism-impl-v3.$(RESULT) - -final: isomorphism-impl-v3.$(RESULT) - $(LATEX) isomorphism-impl-v3 - csh ./mungeaux.csh *.aux - $(LATEX) isomorphism-impl-v3 - -#isomorphism-impl.dvi: $(EPS_GEN) $(WEBTEX) -#isomorphism-impl.ps: isomorphism-impl.dvi -#isomorphism-impl.pdf: $(EPS_GEN) $(PDFPICT) $(WEBTEX) -#isomorphism.hpp: isomorphism-impl.w isomorphism-impl.tex - -isomorphism-impl-v3.dvi: $(DOT) $(EPS_GEN) $(WEBTEX) -isomorphism-impl-v3.ps: isomorphism-impl-v3.dvi -isomorphism-impl-v3.pdf: $(EPS_GEN) $(PDFPICT) $(WEBTEX) - -isomorphism-v3.hpp: isomorphism-impl-v3.w isomorphism-impl-v3.tex - -out.dot: isomorphism-impl.tex -in.dot: isomorphism-impl.tex - -isomorphism.o: isomorphism-v3.hpp isomorphism-impl-v3.w - -isomorphism: isomorphism.o - $(CXX) $(CXXFLAGS) $< -o $@ $(LIBS) - -isomorphism-v3.hpp: isomorphism-impl-v3.tex isomorphism-impl-v3.w -eg1-iso.o: isomorphism-impl-v3.tex isomorphism-impl-v3.w - -eg1-iso: eg1-iso.o - $(CXX) $(CXXFLAGS) $< -o $@ $(LIBS) - - -clean: - rm *.aux *.dvi $(EPS_GEN) $(PDFPICT) diff --git a/doc/Monoid.html b/doc/Monoid.html deleted file mode 100644 index 3694f312e..000000000 --- a/doc/Monoid.html +++ /dev/null @@ -1,122 +0,0 @@ - - - -Monoid - -C++ Boost - -
- -

-Monoid -

- -A Monoid is a concept that describes a simple kind of algebraic -system. A monoid consists of a set of elements S, a -binary operation, and an identity element. The C++ representation of a -monoid consists of a function object that implements the binary -operation, a set of objects that represent the elements of S, -and an object that represents the identity element. - - -

Refinement of

- -The element type must be a model of Assignable and CopyConstructible. -The function object type must be a model of BinaryFunction. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - -
XIs the element type of the Monoid.
a, bare objects of type X.
opIs the function object implementing the Monoid operation.
iis an object of type X and is the identity element -for the Monoid.
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - -
op(a, b)See below for semantics.
-Return type: X -
a == bReturns true if a and b represent - the same element of S.
-Return type: bool -
a != bReturns true if a and b represent - different elements of S.
-Return type: bool -
- -

- -

Invariants

- - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/MutableGraph.html b/doc/MutableGraph.html deleted file mode 100644 index 4d958f2ca..000000000 --- a/doc/MutableGraph.html +++ /dev/null @@ -1,299 +0,0 @@ - - - -MutableGraph - -C++ Boost - -
- - -

-MutableGraph -

- -A MutableGraph can be changed via the addition or removal of -edges and vertices. - -

Refinement of

- -Graph - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
u,vare objects of type boost::graph_traits<G>::vertex_descriptor.
iteris an object of type boost::graph_traits<G>::out_edge_iterator.
pis an object of a type that models Predicate -and whose argument type matches the edge_descriptor type. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
add_edge(u, v, g) -Inserts the edge (u,v) into the graph, and returns an edge -descriptor pointing to the new edge. If the graph disallows parallel -edges, and the edge (u,v) is already in the graph, then the -bool flag returned is false and the returned edge -descriptor points to the already existing edge. Note that for -undirected graphs, (u,v) is the same edge as (v,u), so -after a call to the function add_edge(), this implies that -edge (u,v) will appear in the out-edges of u and -(u,v) (or equivalently (v,u)) will appear in the -out-edges of v. Put another way, v will be adjacent to -u and u will be adjacent to v. -
-Return type: std::pair<edge_descriptor, bool> -
remove_edge(u, v, g) -Remove the edge (u,v) from the graph. If the -graph allows parallel edges this remove all occurrences of -(u,v).
-Return type: void
-Precondition: u and v are vertices in the graph.
-Postcondition: (u,v) is no longer in the edge set for -g.
-
remove_edge(e, g)Remove the edge e from the graph.
-Return type: void
-Precondition: e is an edge in the graph.
-Postcondition: e is no longer in the edge set for g. -
remove_edge(iter, g)Remove the edge pointed to be iter from the graph. This -expression is only required when the graph also models IncidenceGraph.
-Return type: void
-Precondition: *iter is an edge in the graph.
-Postcondition: *iter is no longer in the edge set for g. -
remove_edge_if(p, g)Remove all the edges from graph g for which -the predicate p returns true.
-Return type: void -
remove_out_edge_if(u, p, g)Remove all the out-edges of vertex u for which the -predicate p returns true. This expression is only required -when the graph also models IncidenceGraph.
-Return type: void -
remove_in_edge_if(u, p, g)Remove all the in-edges of vertex u for which the -predicate p returns true. This expression is only required when the -graph also models BidirectionalGraph.
-Return type: void -
add_vertex(g) -Add a new vertex to the graph. The vertex_descriptor for the -new vertex is returned.
-Return type: vertex_descriptor -
clear_vertex(u, g) -Remove all edges to and from vertex u from the graph.
-Return type: void
-Precondition: u is a valid vertex descriptor of g.
-Postcondition: u does not appear as a source or target of -any edge in g. -
remove_vertex(u, g) -Remove u from the vertex set of the graph. Note that undefined -behavior may result if there are edges remaining in the graph who's -target is u. Typically the clear_vertex() function -should be called first.
-Return type: void
-Precondition: u is a valid vertex descriptor of g.
-Postcondition: num_vertices(g) is one less, u -no longer appears in the vertex set of the graph and it -is no longer a valid vertex descriptor. -
- -

- - - -

- -

Complexity Guarantees

- -

- -

- -

Models

- - - - -

Concept Checking Class

- -
-  template <class G>
-  struct MutableGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    void constraints() {
-      v = add_vertex(g);
-      clear_vertex(v, g);
-      remove_vertex(v, g);
-      e_b = add_edge(u, v, g);
-      remove_edge(u, v, g);
-      remove_edge(e, g);
-    }
-    G g;
-    edge_descriptor e;
-    std::pair<edge_descriptor, bool> e_b;
-    typename boost::graph_traits<G>::vertex_descriptor u, v;
-    typename boost::graph_traits<G>::out_edge_iterator iter;
-  };
-
-  template <class edge_descriptor>
-  struct dummy_edge_predicate {
-    bool operator()(const edge_descriptor& e) const {
-      return false;
-    }
-  };
-
-  template <class G>
-  struct MutableIncidenceGraphConcept
-  {
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( MutableGraph<G> ));
-      remove_edge(iter, g);
-      remove_out_edge_if(u, p, g);
-    }
-    G g;
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    dummy_edge_predicate<edge_descriptor> p;
-    typename boost::graph_traits<G>::vertex_descriptor u;
-    typename boost::graph_traits<G>::out_edge_iterator iter;
-  };
-
-  template <class G>
-  struct MutableBidirectionalGraphConcept
-  {
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( MutableIncidenceGraph<G> ));
-      remove_in_edge_if(u, p, g);
-    }
-    G g;
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    dummy_edge_predicate<edge_descriptor> p;
-    typename boost::graph_traits<G>::vertex_descriptor u;
-  };
-
-  template <class G>
-  struct MutableEdgeListGraphConcept
-  {
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( MutableGraph<G> ));
-      remove_edge_if(p, g);
-    }
-    G g;
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    dummy_edge_predicate<edge_descriptor> p;
-  };
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/MutablePropertyGraph.html b/doc/MutablePropertyGraph.html deleted file mode 100644 index 1c096f48c..000000000 --- a/doc/MutablePropertyGraph.html +++ /dev/null @@ -1,150 +0,0 @@ - - - -MutablePropertyGraph - -C++ Boost - -
- - - -

- -MutablePropertyGraph -

- -A MutablePropertyGraph is a MutableGraph with properties attached -internally to the vertices and edges. When adding vertices and edges -the value of the properties can be given. - - -

Refinement of

- -MutableGraph and -PropertyGraph - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
u,vare objects of type boost::graph_traits<G>::vertex_descriptor.
epis an object of type G::edge_property_type
vpis an object of type G::vertex_property_type
- -

- -

Associated Types

- - - - - - - - - - - - - -
Edge Property Type graph_traits<G>::edge_property_type
Vertex Property Type graph_traits<G>::vertex_property_type
- -

Valid Expressions

- - - - - - - - - - - - - -
add_edge(u, v, ep, g)Inserts the edge (u,v) into the graph, and -copies object ep into the property for that edge.
-Return type: std::pair<edge_descriptor, bool>
add_vertex(vp, g) -Add a new vertex to the graph and copy vp into the -property for the new vertex. The vertex_descriptor for the new -vertex is returned.
-Return type: vertex_descriptor -
- - -

Models

- - - -

Concept Checking Class

- -

-

-  template <class G>
-  struct MutablePropertyGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::edge_descriptor edge_descriptor;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( MutableGraphConcept<G> ));
-      v = add_vertex(vp, g);
-      p = add_edge(u, v, ep, g);
-    }
-    G g;
-    std::pair<edge_descriptor, bool> p;
-    typename boost::graph_traits<G>::vertex_descriptor u, v;
-    typename boost::graph_traits<G>::vertex_property_type vp;
-    typename boost::graph_traits<G>::edge_property_type ep;
-  };
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/PlanarEmbedding.html b/doc/PlanarEmbedding.html deleted file mode 100644 index fc62bf155..000000000 --- a/doc/PlanarEmbedding.html +++ /dev/null @@ -1,178 +0,0 @@ - -Planar Embedding Concept - - -C++ Boost - -
- -

Planar Embedding Concept

- - -A planar embedding is an important intermediate representation of a drawing -of a planar graph. Instead of specifying the absolute positions of the vertices -and edges in the plane, a planar embedding specifies their positions relative -to one another. A planar embedding consists of a sequence, for each vertex in -the graph, of all of the edges incident on that vertex in the order in which -they are to be drawn around that vertex. -

-A planar embedding is a refinement of -LValuePropertyMap that -places additional restrictions the value_type used in the property -map. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Embedding is a type that models the Planar Embedding concept.
embedding is an object of type Embedding.
Graph is the type of the underlying graph.
e is an object of type graph_traits<Graph>::edge_descriptor. -
v is an object of type graph_traits<Graph>::vertex_descriptor -.
- -
- - -

Associated Types

- - - - - - - - - -
Const Iterator boost::property_traits<Embedding>::value_type::const_iterator - - The iterator type used to iterate over the ordering of the edges in the -planar embedding of a particular vertex -
- -

Valid Expressions

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExpressionReturn TypeDescription
embedding[v].begin() boost::property_traits<Embedding>::value_type::const_iterator - Returns an iterator to the beginning of the range of edges in the - embedding around vertex v
embedding[v].end() boost::property_traits<Embedding>::value_type::const_iterator - Returns an iterator to the end of the range of edges in the - embedding around vertex v
embedding[v].clear() void Clears all edges in the embedding around a vertex v
embedding[v].push_back(e) void Adds an edge e to the end of the sequence of embedded edges - around the vertex v
- -

Complexity Guarantees

- -Starting with an empty embedding, any mixed sequence of n calls to a -particular vertex's push_back and clear should take -O(n) time. - -

Models

- -Any LValue property map that maps vertices to a std::vector, -std::list, or std::deque models this -concept. Below is an example of using this approach to create a model of -PlanarEmbedding: - -
-#include <boost/property_map/property_map.hpp>
-#include <vector>
-
-...
-
-// Assume a graph type "Graph" defined somewhere above and
-// an instance of Graph in a variable g.
-
-// A typedef for the storage - a vector of vectors of edge descriptors
-typedef
-    std::vector< std::vector< graph_traits<Graph>::edge_descriptor > >
-    planar_embedding_storage_t;
-
-// A typedef for the iterator property map, assuming the graph has
-// an interior vertex index map
-typedef
-    boost::iterator_property_map< planar_embedding_storage_t::iterator,
-                                  property_map<Graph, vertex_index_t>::type
-                                >
-    planar_embedding_t;
-
-// Create an instance of the storage and the property map
-planar_embedding_storage_t planar_embedding_storage(num_vertices(g));
-planar_embedding_t planar_embedding(planar_embedding_storage.begin(),
-                                    get(vertex_index, g)
-                                    );
-
-// planar_embedding can now be passed to any function expecting a model
-// of PlanarEmbedding.
-
- -

- -
-

-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/PlanarFaceVisitor.html b/doc/PlanarFaceVisitor.html deleted file mode 100644 index ba18cccc2..000000000 --- a/doc/PlanarFaceVisitor.html +++ /dev/null @@ -1,148 +0,0 @@ - - - -Planar Face Visitor Concept - - -C++ Boost - -
- -

Planar Face Visitor Concept

- -This concept defines the visitor interface for -planar_face_traversal. -Users can define a class with the Planar Face Visitor interface and pass an -object of the class to planar_face_traversal, thereby augmenting the -actions taken during the traversal. Note that objects passed to -planar_face_traversal are passed by reference. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of Planar Face Visitor.
visAn object of type V.
GA type that is a model of Graph.
eAn object of type boost::graph_traits<G>::edge_descriptor. -
vAn object of type boost::graph_traits<G>::vertex_descriptor. -
- - -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Begin Traversalvis.begin_traversal()void -This is invoked once per traversal, before the traversal begins. -
Begin Facevis.begin_face()void -This is invoked once for each face, before any vertices or edges on the face -are visited. -
Next Vertexvis.next_vertex(v)void -This is invoked when a vertex is encountered while traversing a face. -
Next Edgevis.next_edge(e)void -This is invoked when an edge is encountered while traversing a face. -
End Facevis.end_face()void -This is invoked once for each face, after all vertices and edges on the face -are visited. -
End Traversalvis.end_traversal()void -This is invoked once per traversal, after the traversal ends. -
- -

Models

- - - -
-
-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/PropertyGraph.html b/doc/PropertyGraph.html deleted file mode 100644 index 877aa5b3b..000000000 --- a/doc/PropertyGraph.html +++ /dev/null @@ -1,210 +0,0 @@ - - - -PropertyGraph - -C++ Boost - -
- -

-PropertyGraph -

- -A PropertyGraph is a graph that has some property associated with each -of the vertices or edges in the graph. As a given graph may have -several properties associated with each vertex or edge, a tag is used -to identify which property is being accessed. The graph provides a -function which returns a property map object. - -

- -

Refinement of

- -Graph - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of PropertyGraph.
gAn object of type G.
XEither the vertex or edge descriptor type for G.
xAn object of type X.
MapThe type boost::property_map<G, Property>::const_type.
vAn object of type boost::property_traits<Map>::value_type.
PropertyTagA type that models the PropertyTag concept.
pAn object of type PropertyTag.
pmapAn object of type Map.
- -

Associated types

- - - - - - - - - - - -
boost::property_map<G, PropertyTag>::type
-The type of the property map for the property specified by -PropertyTag. This type must be a model of ReadWritePropertyMap -with a key type the same as the graph's vertex or edge descriptor type. -
boost::property_map<G, PropertyTag>::const_type
-The type of the const property map for the property specified by -PropertyTag. This type must be a model of ReadablePropertyMap -with a key type the same as the graph's vertex or edge descriptor type. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - -
get(p, g) -Returns the property map for the property specified by the -PropertyTag type. The object p is only used to -carry the type.
-Return type: boost::property_map<G, PropertyTag>::type if g is mutable and
boost::property_map<G, PropertyTag>::const_type otherwise. -
get(p, g, x) -Returns the property value (specified by the PropertyTag type) -associated with object x (a vertex or edge). -The object p is only used to carry the type. -This function is equivalent to:
-get(get(p, g), x)
-Return type: boost::property_traits<Map>::value_type -
put(p, g, x, v) -Set the property (specified by the PropertyTag type) -associated with object x (a vertex or edge) to -the value v. The object p is only used to carry the type. -This function is equivalent to:
- -pmap = get(p, g);
-put(pmap, x, v) -
-Return type: void -
- -

Complexity

- -The get() property map function must be constant time. - - -

Models

- - - - - -

Concept Checking Class

- -
-  template <class Graph, class X, class PropertyTag>
-  struct PropertyGraphConcept
-  {
-    typedef typename property_map<G, PropertyTag>::type Map;
-    typedef typename property_map<G, PropertyTag>::const_type const_Map;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( GraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept<Map, X> ));
-      BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept<const_Map, X> ));
-
-      Map pmap = get(PropertyTag(), g);
-      pval = get(PropertyTag(), g, x);
-      put(PropertyTag(), g, x, pval);
-      ignore_unused_variable_warning(pmap);
-    }
-    void const_constraints(const G& g) {
-      const_Map pmap = get(PropertyTag(), g);
-      pval = get(PropertyTag(), g, x);
-      ignore_unused_variable_warning(pmap);
-    }
-    G g;
-    X x;
-    typename property_traits<Map>::value_type pval;
-  };
-
- - -

See Also

- -property_map - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/PropertyTag.html b/doc/PropertyTag.html deleted file mode 100644 index 5feb2c023..000000000 --- a/doc/PropertyTag.html +++ /dev/null @@ -1,117 +0,0 @@ - - - -Property - -C++ Boost - -
- -

-PropertyTag -

- -A Property Tag is a type used to name or identify properties that are -attached to the vertices and edges of a graph. A Property type is not -the type of the actual property values. Objects of the Property type -are not used except to carry the type information which specifies the -property. See the section about Custom -Edge Properties for a description of how to define your own -property tags. - - -

Associated Types

- - - - - - - - - - - - - - - -
Property Kind property_kind<PropertyTag>::type - -This specifies whether the property is a Vertex Property Tag -(vertex_property_tag), an Edge Property Tag (edge_property_tag), or -a Graph Property Tag which is attached to the -graph object itself (graph_property_tag). The tags are -defined in boost/graph/properties.hpp. The property_kind traits class is defined in boost/pending/property.hpp. - -
Property ID Number property_num<PropertyTag>::value -This is needed as a workaround when using compilers that do not -support partial specialization (and hence prevent us from using -boost::is_same to detect if two property tags are the same). -The property_num traits class is defined in boost/pending/property.hpp. -
- -

Refinement of

- -Default Constructible - - -

Models

- -The following models of the Property Tag concept are defined -in boost/graph/properties.hpp. - - - -

See Also

- -PropertyGraph -and -Property Map Concepts - -

Notes

- -On compilers that do not support partial specialization, each Property -type is also required to specialize -property_num<PropertyTag> to contain an enum named -value which uniquely identifies the property type. - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/TSPTourVisitor.html b/doc/TSPTourVisitor.html deleted file mode 100644 index 42d6e3b2d..000000000 --- a/doc/TSPTourVisitor.html +++ /dev/null @@ -1,99 +0,0 @@ - - - -Boost Graph Library: TSP Tour Visitor - -C++ Boost - -
- -

TSP Tour Visitor concept

- -This concept defines the visitor interface for metric_tsp_approx() -and related algorithms. The user can create a class that matches this -interface, and then pass objects of the class into -metric_tsp_approx() to augment the actions taken during -the search. - -

Refinement of

- -none - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
VA type that is a model of Dijkstra Visitor.
visAn object of type V.
GA type that is a model of Graph.
gAn object of type G.
vAn object of type boost::graph_traits<G>::vertex_descriptor.
- -

Associated Types

- -none - -

- -

Valid Expressions

- - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Visit Vertexvis.visit_vertex(v, g)void -This is invoked on each vertex of the graph when it is visited as part of the TSP tour. -
- -

Models

- - - -
-
- - -
Copyright © 2008 -Matyas Egyhazy
- - - diff --git a/doc/UpdatableQueue.html b/doc/UpdatableQueue.html deleted file mode 100644 index 89739d9ab..000000000 --- a/doc/UpdatableQueue.html +++ /dev/null @@ -1,100 +0,0 @@ - - - - -UpdatableQueue - - -C++ Boost - -

UpdatableQueue

- -

An UpdatableQueue is a refinement of the Buffer concept that additionally requires that the Buffer be updatable. - -

Implicit in the definition is an ordering of values. Though access to the order is not required, types that model UpdatableQueue must document how an object of the type orders values so that a program may change the position of a given value in the ordering. For example, an UpdatableQueue may choose to order values by using a property map, and a value v1 is considered less than a value v2 if get(pm, v1) < get(pm, v2). A program can update the properties of values, thus changing the order of values in the UpdatableQueue, and notify the UpdatableQueue of the specific values that have a different position in the ordering by calling the update member of the UpdatableQueue on each. - -

A program that modifies the order must notify the UpdatableQueue of values that may have different positions in the ordering since they were inserted or last updated. - -

Notation

- - - - -
Q is a type that models UpdatableQueue.
T is the value type of Q.
- - -

Members

- -For a type to model the UpdatableQueue concept it must have the following members -in addition to the members that are required of types that model Buffer: - -

- - - - - - - - - - - - - -
Member Description
void update(const T& t) Informs the UpdatableQueue that the program has modified the position of t in the ordering
unspecified-bool-type contains(const T& t) const Returns whether the queue contains t
- -

Concept Checking Class

- -

boost/graph/buffer_concepts.hpp - -

-  template <class Q>
-  struct UpdatableQueueConcept
-  {
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( Buffer<Q> ));
-
-      q.update(g_ct);
-    }
-
-    void const_constraints(const Q& cq) {
-      if (cq.contains(g_ct));
-    }
-
-    static const typename Buffer<Q>::value_type g_ct;
-    Q q;
-  };
-
- -

Futher Refinements

- - - -

UpdatablePriorityQueue

-

An UpdatablePriorityQueue is a slight refinement of UpdatableQueue -that imposes the requirement that a program may not increase the position of a value that is held in the queue. That is, -if a value v had position n in the ordering, a program may update the position of v only to 0, 1, ..., n - 1, or n, where 0 is the top of the queue. - -

The behavior when a program attempts to increase a value's position in the ordering is undefined. - -
-

- - - - - -
Copyright © 2010Daniel Trebbien (dtrebbien@gmail.com) -
- - - \ No newline at end of file diff --git a/doc/VertexAndEdgeListGraph.html b/doc/VertexAndEdgeListGraph.html deleted file mode 100644 index 896f1f8d1..000000000 --- a/doc/VertexAndEdgeListGraph.html +++ /dev/null @@ -1,70 +0,0 @@ - - - -VertexAndEdgeListGraph - -C++ Boost - -
- - -

-VertexAndEdgeListGraph -

- -The VertexAndEdgeListGraph concept refines the VertexListGraph and the EdgeListGraph concepts. No further -requirements are added. - -

Refinement of

- -VertexListGraph, -EdgeListGraph - - -

Models

- - - -

- -

See Also

- -Graph concepts - -

Concept Checking Class

- -

-

-  template <class G>
-  struct VertexAndEdgeListGraphConcept
-  {
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( VertexListGraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( EdgeListGraphConcept<G> ));
-    }
-  };
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/VertexListGraph.html b/doc/VertexListGraph.html deleted file mode 100644 index b0cb41b01..000000000 --- a/doc/VertexListGraph.html +++ /dev/null @@ -1,154 +0,0 @@ - - - -VertexListGraph - -C++ Boost - -
- - -

-VertexListGraph -

- -The VertexListGraph concept refines the Graph concept, and adds the requirement for -efficient traversal of all the vertices in the graph. - -

Refinement of

- -Graph - -

Associated Types

- - - - - - - - - - - - - - - -
boost::graph_traits<G>::traversal_category

- This tag type must be convertible to vertex_list_graph_tag. -
boost::graph_traits<G>::vertex_iterator

-A vertex iterator (obtained via vertices(g)) provides access -to all of the vertices in a graph. A vertex iterator type must meet -the requirements of MultiPassInputIterator. The -value type of the vertex iterator must be the vertex descriptor of the -graph. -
boost::graph_traits<G>::vertices_size_type

-The unsigned integer type used to represent the number of vertices -in the graph. -
- -

Valid Expressions

- - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Vertex Set of the Graphvertices(g)std::pair<vertex_iterator, vertex_iterator> -Returns an iterator-range providing access to all the vertices in the -graphg. -
Number of Vertices in the Graph num_vertices(g)vertices_size_typeReturns the number of vertices in the graph g.
- - -

Complexity guarantees

- -

-The vertices() function must return in constant time. - -

See Also

- -Graph concepts - - -

Design Rationale

- -One issue in the design of this concept is whether to include the -refinement from the IncidenceGraph -and AdjacencyGraph concepts. The -ability to traverse the vertices of a graph is orthogonal to -traversing out-edges, so it would make sense to have a VertexListGraph -concept that only includes vertex traversal. However, such a concept -would no longer really be a graph, but would just be a set, and the -STL already has concepts for dealing with such things. However, there -are many BGL algorithms that need to traverse the vertices and -out-edges of a graph, so for convenience a concept is needed that -groups these requirements together, hence the VertexListGraph concept. - - -

Concept Checking Class

- -

-

-  template <class G>
-  struct VertexListGraphConcept
-  {
-    typedef typename boost::graph_traits<G>::vertex_iterator
-      vertex_iterator;
-    void constraints() {
-      BOOST_CONCEPT_ASSERT(( IncidenceGraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( AdjacencyGraphConcept<G> ));
-      BOOST_CONCEPT_ASSERT(( MultiPassInputIteratorConcept<vertex_iterator> ));
-
-      p = vertices(g);
-      V = num_vertices(g);
-      v = *p.first;
-      const_constraints(g);
-    }
-    void const_constraints(const G& g) {
-      p = vertices(g);
-      V = num_vertices(g);
-      v = *p.first;
-    }
-    std::pair<vertex_iterator, vertex_iterator> p;
-    typename boost::graph_traits<G>::vertex_descriptor v;
-    typename boost::graph_traits<G>::vertices_size_type V;
-    G g;
-  };
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/VertexMutableGraph.html b/doc/VertexMutableGraph.html deleted file mode 100644 index b46a9cafc..000000000 --- a/doc/VertexMutableGraph.html +++ /dev/null @@ -1,83 +0,0 @@ - - - -Vertex Mutable Graph - -C++ Boost - -
- -

-Vertex Mutable Graph -

- -A vertex mutable graph can be changed by adding or removing -vertices. The memory management is the responsibility of the graph -implementation. The graph user need only make calls to -add_vertex and remove_vertex and the graph -implementation does the rest. - -

Refinement of

- -Graph and DefaultConstructible - -

Associated Types

- -No additional associated types. - -

Valid Expressions

- - - -

Complexity guarantees

- - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -Lie-Quan Lee, Indiana University (llee@cs.indiana.edu) -
- - - - diff --git a/doc/acknowledgements.html b/doc/acknowledgements.html deleted file mode 100644 index f70a12b1a..000000000 --- a/doc/acknowledgements.html +++ /dev/null @@ -1,76 +0,0 @@ - - - -Boost Graph Library: Acknowledgements - -C++ Boost - -
- - -

Acknowledgements

- -We owe many debts of thanks to a number of individuals who both -inspired and encouraged us in developing the Boost Graph Library. - -

-A most profound thanks goes to Alexander Stepanov for his pioneering -work in generic programming, for his encouragement, and for his -algorithm contributions to the BGL. We thank Matthew Austern for his -work on documenting the concepts of STL which provided a foundation -for creating the concepts in the BGL. We thank Dietmar Kühl for -his work on generic graph algorithms and design patterns; especially -for the property map abstraction. - -

-Dave Abrahams, Jens Maurer, Beman Dawes, Gary Powell, Greg Colvin, -Valentin Bonnard, and the rest of the group at Boost provided valuable -input to the BGL interface, numerous suggestions for improvement, -proof reads of the documentation, and help with polishing the code. A -special thanks to Dave Abrahams for managing the formal review. - -

-We also thank the following BGL users whose questions helped to -improve the BGL: Gordon Woodhull, Dave Longhorn, Joel Phillips, and -Edward Luke. - -

-A special thanks to Jeffrey Squyres for editing and proof reading -of the documentation. - -

-Our original work on the Boost Graph Library was supported in part by -NSF grant ACI-9982205 and by the Director, Office of Science, Division -of Mathematical, Information, and Computational Sciences of the U.S. -Department of Energy under contract number DE-AC03-76SF00098. -

-In our work we also used resources of the National Energy Research -Scientific Computing Center, which is supported by the Office of -Science of the U.S. Department of Energy. - - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/adjacency_iterator.html b/doc/adjacency_iterator.html deleted file mode 100644 index 6cdd75aa2..000000000 --- a/doc/adjacency_iterator.html +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - - -Adjacency Iterator Adaptor Documentation - - - - -boost.png (6897 bytes) - -

Adjacency Iterator Adaptor

- -Defined in header -boost/graph/adjacency_iterator.hpp - -

-The adjacency iterator adaptor transforms an -out_edge_iterator into an adjacency iterator. That is, it -takes an iterator that traverses over edges, and creates an iterator -that traverses over the target vertices of those edges. -With this adaptor it is trivial to take a graph type that models Incidence Graph and add the -capabilities required of Adjacency -Graph. - - -

Synopsis

- -
-namespace boost {
-  template <class Graph, class VertexDescriptor, class OutEdgeIter>
-  class adjacency_iterator_generator {
-  public:
-    typedef iterator_adaptor<...> type;
-  };
-}
-
- -
- -

Example

- -

-The following is an example of how to use the -adjacency_iterator_generator class. - -

-

-#include <boost/graph/adjacency_iterator.hpp>
-
-class my_graph {
-  // ...
-  typedef ... out_edge_iterator;
-  typedef ... vertex_descriptor;
-  typedef boost::adjacency_iterator_generator<my_graph, vertex_descriptor, out_edge_iterator>::type adjacency_iterator;
-  // ...
-};
-
-
- -

Template Parameters

- - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
GraphThe graph type, which must model Incidence Graph.
VertexDescriptorThis must be the same type as -graph_traits<Graph>::vertex_descriptor. The reason why -this is a template parameter is that the primary use of -adjacency_iterator_generator is inside the -definition of the graph class, and in that context we can not use -graph_traits on the not yet fully defined graph class.
-Default: graph_traits<Graph>::vertex_descriptor
OutEdgeIterThis must be the same type as -graph_traits<Graph>::out_edge_iterator.
-Default: graph_traits<Graph>::out_edge_iterator -
- -

Model of

- -The adjacency iterator adaptor (the type -adjacency_iterator_generator<...>::type) is a model of Multi-Pass Input Iterator -. - - -

Members

- -The adjacency iterator type implements the member functions and -operators required of the Random Access Iterator -concept, except that the reference type is the same as the value_type -so operator*() returns by-value. In addition it has the following constructor: - -
-adjacency_iterator_generator::type(const OutEdgeIter& it, const Graph* g)
-
- -
-

Revised 19 Aug 2001

-

© Copyright Jeremy Siek 2000. Permission to copy, use, -modify, sell and distribute this document is granted provided this copyright -notice appears in all copies. This document is provided "as is" -without express or implied warranty, and with no claim as to its suitability for -any purpose.

- - - - diff --git a/doc/adjacency_list.html b/doc/adjacency_list.html deleted file mode 100644 index a9b5abd78..000000000 --- a/doc/adjacency_list.html +++ /dev/null @@ -1,1148 +0,0 @@ - - - -Boost Graph Library: Adjacency List - -C++ Boost - -
- -

-
-adjacency_list<OutEdgeList, VertexList, Directed,
-               VertexProperties, EdgeProperties,
-               GraphProperties, EdgeList>
-
-

- - -

-The adjacency_list class implements a generalized adjacency -list graph structure. The template parameters provide many -configuration options so that you can pick a version of the class that -best meets your needs. An adjacency-list -is basically a two-dimensional structure, where each element of the -first dimension represents a vertex, and each of the vertices contains -a one-dimensional structure that is its edge list. Figure 1 shows an adjacency list -representation of a directed graph. - -

-
- - - - -
Figure 1: Adjacency List Representation of a Directed Graph.
-

- -The -VertexList template parameter of the adjacency_list -class controls what kind of container is used to represent the outer -two-dimensional container. The OutEdgeList template parameter -controls what kind of container is used to represent the edge -lists. The choices for OutEdgeList and VertexList will -determine the space complexity of the graph structure, and will -determine the time complexity of the various graph operations. The -possible choices and tradeoffs are discussed in Section Choosing -the Edgelist and VertexList. - -

-The Directed template parameter controls whether the graph is -directed, undirected, or directed with access to both the in-edges and -out-edges (which we call bidirectional). The bidirectional graph takes -up twice the space (per edge) of a directed graph since each edge will -appear in both an out-edge and in-edge list. Figure 2 shows an adjacency list -representation of an undirected graph. - -

-
- - - - -
Figure 2: Adjacency List Representation of an Undirected Graph.
-

- -

-A tutorial on how to use the adjacency_list class is in -Section Using -adjacency_list. - -

- -

Example

- -

-The example in examples/family_tree.cpp -shows how to represent a family tree with a graph. - -

Template Parameters

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
OutEdgeListThe selector for the container used to represent the - edge-list for each of the vertices.vecS
VertexListThe selector for the container used to represent the - vertex-list of the graph.vecS
DirectedA selector to choose whether the graph is directed, undirected, or directed with bidirectional edge access (access to both out-edges and in-edges). The options are directedS, undirectedS, and bidirectionalS.directedS
VertexPropertiesfor specifying internal property storage.no_property
EdgePropertiesfor specifying internal property storage.no_property
GraphPropertiesfor specifying property storage for the graph object.no_property
EdgeListThe selector for the container used to represent the - edge-list for the graph.listS
-

- -

Model of

- -

-VertexAndEdgeListGraph, -MutablePropertyGraph, -CopyConstructible, -Assignable, -and Serializable. - - -

- -

Where Defined

- -

-boost/graph/adjacency_list.hpp

-Also, the serialization functionality is in -boost/graph/adj_list_serialize.hpp. -

- -

Vertex and Edge Properties

- -

-Properties such as color, distance, weight, and user-defined -properties can be attached to the vertices and edges of the graph -using properties. The property values can be read from and written to -via the property maps provided by the graph. The property maps are -obtained via the get(property, g) function. How to use -properties is described in Section Internal -Properties . The property maps are objects that implement the -interface defined in Section Property Map -Concepts or may be bundled properties, -which have a more succinct syntax. The types of all property values -must be Copy Constructible, Assignable, and Default Constructible. -The property maps obtained from the -adjacency_list class are models of the Lvalue Property -Map concept. If the adjacency_list is const, -then the property map is constant, otherwise the property -map is mutable. - -

-If the VertexList of the graph is vecS, then the -graph has a builtin vertex indices accessed via the property map for -the vertex_index_t property. The indices fall in the range -[0, num_vertices(g)) and are contiguous. When a vertex is -removed the indices are adjusted so that they retain these -properties. Some care must be taken when using these indices to access -exterior property storage. The property map for vertex index is a -model of Readable -Property Map. - -

- -

Iterator and Descriptor Stability/Invalidation

- -Some care must be taken when changing the structure of a graph (via -adding or removing edges). Depending on the type of -adjacency_list and on the operation, some of the iterator or -descriptor objects that point into the graph may become invalid. For -example, the following code will result in undefined (bad) behavior: - -
-  typedef adjacency_list<listS, vecS> Graph; // VertexList=vecS
-  Graph G(N);
-  // Fill in the graph...
-
-  // Attempt to remove all the vertices. Wrong!
-  graph_traits<Graph>::vertex_iterator vi, vi_end;
-  for (boost::tie(vi, vi_end) = vertices(G); vi != vi_end; ++vi)
-    remove_vertex(*vi, G);
-
-  // Remove all the vertices. This is still wrong!
-  graph_traits<Graph>::vertex_iterator vi, vi_end, next;
-  boost::tie(vi, vi_end) = vertices(G);
-  for (next = vi; vi != vi_end; vi = next) {
-    ++next;
-    remove_vertex(*vi, G);
-  }
-
- -The reason this is a problem is that we are invoking -remove_vertex(), which when used with an -adjacency_list where VertexList=vecS, invalidates -all iterators and descriptors for the graph (such as vi and -vi_end), thereby causing trouble in subsequent iterations of -the loop. - -

- -If we use a different kind of adjacency_list, where -VertexList=listS, then the iterators are not invalidated by -calling remove_vertex unless the iterator is pointing to the -actual vertex that was removed. The following code demonstrates this. - -

-  typedef adjacency_list<listS, listS> Graph; // VertexList=listS
-  Graph G(N);
-  // Fill in the graph...
-
-  // Attempt to remove all the vertices. Wrong!
-  graph_traits<Graph>::vertex_iterator vi, vi_end;
-  for (boost::tie(vi, vi_end) = vertices(G); vi != vi_end; ++vi)
-    remove_vertex(*vi, G);
-
-  // Remove all the vertices. This is OK.
-  graph_traits<Graph>::vertex_iterator vi, vi_end, next;
-  boost::tie(vi, vi_end) = vertices(G);
-  for (next = vi; vi != vi_end; vi = next) {
-    ++next;
-    remove_vertex(*vi, G);
-  }
-
- -

- -The stability issue also affects vertex and edge descriptors. For -example, suppose you use vector of vertex descriptors to keep track of -the parents (or predecessors) of vertices in a shortest paths tree -(see examples/dijkstra-example.cpp). -You create the parent vector with a call to -dijkstra_shortest_paths(), and then remove a vertex from the -graph. Subsequently you try to use the parent vector, but since all -vertex descriptors have become invalid, the result is incorrect. - -

-  std::vector<Vertex> parent(num_vertices(G));
-  std::vector<Vertex> distance(num_vertices(G));
-
-  dijkstra_shortest_paths(G, s, distance_map(&distance[0]).
-    predecessor_map(&parent[0]));
-
-  remove_vertex(s, G); // Bad idea! Invalidates vertex descriptors in parent vector.
-
-  // The following will produce incorrect results
-  for(boost::tie(vi, vend) = vertices(G); vi != vend; ++vi)
-    std::cout << p[*vi] << " is the parent of " << *vi << std::endl;
-
- - -

-Note that in this discussion iterator and descriptor invalidation is -concerned with the invalidation of iterators and descriptors that are -not directly affected by the operation. For example, performing -remove_edge(u, v, g) will always invalidate any edge -descriptor for (u,v) or edge iterator pointing to (u,v), -regardless of the kind adjacency_list. In this discussion -of iterator and descriptor invalidation, we are only concerned with the -affect of remove_edge(u, v, g) on edge descriptors and -iterators that point to other edges (not (u,v)). - -

-In general, if you want your vertex and edge descriptors to be stable -(never invalidated) then use listS or setS for the -VertexList and OutEdgeList template parameters of -adjacency_list. If you are not as concerned about descriptor -and iterator stability, and are more concerned about memory -consumption and graph traversal speed, use vecS for the -VertexList and/or OutEdgeList template parameters. - -

-The following table summarizes which operations cause descriptors and -iterators to become invalid. In the table, EL is an -abbreviation for OutEdgeList and VL means -VertexList. The Adj Iter category includes the -out_edge_iterator, in_edge_iterator, and -adjacency_iterator types. A more detailed description of -descriptor and iterator invalidation is given in the documentation for -each operation. - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table: - Summary of Descriptor and Iterator Invalidation. -
FunctionVertex DescEdge DescVertex IterEdge IterAdj Iter
- add_edge()OKOKOKEL=vecS &&
Directed=directedS		EL=vecS
remove_edge()
remove_edge_if()
remove_out_edge_if()
- remove_in_edge_if()
clear_vertex() - 		OKOKOKEL=vecS &&
Directed=directedS		EL=vecS
add_vertex()OKOKOKVL=vecS &&
Directed=directedS		VL=vecS &&
Directed=directedS
remove_vertex()VL=vecSVL=vecSVL=vecSVL=vecSVL=vecS
- -

Associated Types

- -
- -graph_traits<adjacency_list>::vertex_descriptor -
-and -
-adjacency_list_traits<OutEdgeList, VertexList, Directed, EdgeList>::vertex_descriptor -

-The type for the vertex descriptors associated with the -adjacency_list. - -
- -graph_traits<adjacency_list>::edge_descriptor
-and
-adjacency_list_traits<OutEdgeList, VertexList, Directed, EdgeList>::edge_descriptor -

-The type for the edge descriptors associated with the -adjacency_list. - -
- -graph_traits<adjacency_list>::vertex_iterator -

-The type for the iterators returned by vertices(). - -When VertexList=vecS then the vertex_iterator models -RandomAccessIterator. Otherwise -the vertex_iterator models BidirectionalIterator. - -
- -graph_traits<adjacency_list>::edge_iterator -

-The type for the iterators returned by edges(). -The edge_iterator models BidirectionalIterator. - - -
- - -graph_traits<adjacency_list>::out_edge_iterator -

- -The type for the iterators returned by out_edges(). -When OutEdgeList=vecS then the out_edge_iterator models - -RandomAccessIterator. When OutEdgeList=slistS then the -out_edge_iterator models -ForwardIterator. Otherwise the out_edge_iterator models - -BidirectionalIterator. - -
- -graph_traits<adjacency_list>::adjacency_iterator -

-The type for the iterators returned by adjacent_vertices(). -The adjacency_iterator models the same iterator concept -as out_edge_iterator. -
- -adjacency_list::inv_adjacency_iterator -

-The type for the iterators returned by inv_adjacent_vertices(). -The inv_adjacency_iterator models the same iterator concept -as out_edge_iterator. -
- -graph_traits<adjacency_list>::directed_category
-and
-adjacency_list_traits<OutEdgeList, VertexList, Directed, EdgeList>::directed_category -

-Provides information about whether the graph is -directed (directed_tag) or undirected -(undirected_tag). - -
- -graph_traits<adjacency_list>::edge_parallel_category
-and
-adjacency_list_traits<OutEdgeList, VertexList, Directed, EdgeList>::edge_parallel_category -

-This describes whether the graph class allows the insertion of -parallel edges (edges with the same source and target). The two tags -are allow_parallel_edge_tag and -disallow_parallel_edge_tag. The -setS and hash_setS variants disallow -parallel edges while the others allow parallel edges. - -
- -graph_traits<adjacency_list>::vertices_size_type
-and
-adjacency_list_traits<OutEdgeList, VertexList, Directed_list, EdgeList>::vertices_size_type
-

-The type used for dealing with the number of vertices in the graph. - -
- -graph_traits<adjacency_list>::edges_size_type
-and
-adjacency_list_traits<OutEdgeList, VertexList, Directed_list, EdgeList>::edges_size_type
-

-The type used for dealing with the number of edges in the graph. - -
- -graph_traits<adjacency_list>::degree_size_type -

-The type used for dealing with the number of edges incident to a vertex -in the graph. - -
- -property_map<adjacency_list, Property>::type
-and
-property_map<adjacency_list, Property>::const_type -

-The property map type for vertex or edge properties in the graph. The -specific property is specified by the Property template argument, -and must match one of the properties specified in the -VertexProperties or EdgeProperties for the graph. - -
- -graph_property<adjacency_list, Property>::type -

-The property value type for the graph property specified by the -Property tag. - -
- -adjacency_list::out_edge_list_selector -

-The type OutEdgeListS. - -
- -adjacency_list::vertex_list_selector -

-The type VertexListS. - -
- -adjacency_list::directed_selector -

-The type DirectedS. - -
- -adjacency_list::edge_list_selector -

-The type EdgeListS. - -
- -

Member Functions

- -
- -
-adjacency_list(const GraphProperty& p = GraphProperty())
-
-Default constructor. Creates an empty graph object with zero vertices -and zero edges. - -
- -
-adjacency_list(const adjacency_list& x)
-
-Copy constructor. Creates a new graph that is a copy of graph -x, including the edges, vertices, and properties. - -
- -
-adjacency_list& operator=(const adjacency_list& x)
-
-Assignment operator. Makes this graph a copy of graph -x, including the edges, vertices, and properties. - -
- -
-adjacency_list(vertices_size_type n,
-               const GraphProperty& p = GraphProperty())
-
-Creates a graph object with n vertices and zero edges. - -
- - -
-template <class EdgeIterator>
-adjacency_list(EdgeIterator first, EdgeIterator last,
-               vertices_size_type n,
-               edges_size_type m = 0,
-               const GraphProperty& p = GraphProperty())
-
-Creates a graph object with n vertices and with the edges -specified in the edge list given by the range [first, last). -The EdgeIterator must be a model of InputIterator. -The value type of the EdgeIterator must be a -std::pair, where the type in the pair is an integer type. The -integers will correspond to vertices, and they must all fall in the -range of [0, n). - - -
- -
-template <class EdgeIterator, class EdgePropertyIterator>
-adjacency_list(EdgeIterator first, EdgeIterator last,
-               EdgePropertyIterator ep_iter,
-               vertices_size_type n,
-               edges_size_type m = 0,
-               const GraphProperty& p = GraphProperty())
-
-Creates a graph object with n vertices and with the edges -specified in the edge list given by the range [first, last). -The EdgeIterator and EdgePropertyIterator must be a -model of InputIterator. -The value type of the EdgeIterator must be a -std::pair, where the type in the pair is an integer type. The -integers will correspond to vertices, and they must all fall in the -range of [0, n). The value_type of the -ep_iter should be EdgeProperties. - -
- -
-void clear()
-
-Remove all of the edges and vertices from the graph. - -
- -
-void swap(adjacency_list& x)
-
-Swap the vertices, edges, and properties of this graph with the -vertices, edges, and properties of graph x. -
- -

- -

Non-Member Functions

- - -

Structure Access

- -
- -
-std::pair<vertex_iterator, vertex_iterator>
-vertices(const adjacency_list& g)
-
-Returns an iterator-range providing access to the vertex set of graph -g. - -
- -
-std::pair<edge_iterator, edge_iterator>
-edges(const adjacency_list& g)
-
-Returns an iterator-range providing access to the edge set of graph -g. - -
- -
-std::pair<adjacency_iterator, adjacency_iterator>
-adjacent_vertices(vertex_descriptor u, const adjacency_list& g)
-
-Returns an iterator-range providing access to the vertices adjacent to -vertex u in graph g. For example, if u -> v -is an edge in the graph, then v will be in this iterator-range. - -
- -
-std::pair<inv_adjacency_iterator, inv_adjacency_iterator>
-inv_adjacent_vertices(vertex_descriptor u, const adjacency_list& g)
-
- -Returns an iterator-range providing access to the vertices in graph -g to which u is adjacent. (inv is for -inverse.) For example, if v -> u is an edge in the graph, -then v will be in this iterator range. This function is only -available for bidirectional and undirected adjacency_list's. - -
- - -
-std::pair<out_edge_iterator, out_edge_iterator>
-out_edges(vertex_descriptor u, const adjacency_list& g)
-
-Returns an iterator-range providing access to the out-edges of vertex -u in graph g. If the graph is undirected, this -iterator-range provides access to all edges incident on vertex -u. For both directed and undirected graphs, for an out-edge -e, source(e, g) == u and target(e, g) == v -where v is a vertex adjacent to u. - -
- -
-std::pair<in_edge_iterator, in_edge_iterator>
-in_edges(vertex_descriptor v, const adjacency_list& g)
-
-Returns an iterator-range providing access to the in-edges of vertex -v in graph g. This operation is only available if -bidirectionalS was specified for the Directed -template parameter. For an in-edge e, target(e, g) == v -and source(e, g) == u for some vertex u that is -adjacent to v, whether the graph is directed or undirected. - -
- -
-vertex_descriptor
-source(edge_descriptor e, const adjacency_list& g)
-
-Returns the source vertex of edge e. - -
- -
-vertex_descriptor
-target(edge_descriptor e, const adjacency_list& g)
-
-Returns the target vertex of edge e. - -
- -
-degree_size_type
-out_degree(vertex_descriptor u, const adjacency_list& g)
-
-Returns the number of edges leaving vertex u. - -
- -
-degree_size_type
-in_degree(vertex_descriptor u, const adjacency_list& g)
-
-Returns the number of edges entering vertex u. This operation -is only available if bidirectionalS was specified for -the Directed template parameter. - -
- -
-vertices_size_type
-num_vertices(const adjacency_list& g)
-
-Returns the number of vertices in the graph g. - -
- -
-edges_size_type
-num_edges(const adjacency_list& g)
-
-Returns the number of edges in the graph g. - -
- -
-vertex_descriptor
-vertex(vertices_size_type n, const adjacency_list& g)
-
-Returns the nth vertex in the graph's vertex list. - -
- - -
-std::pair<edge_descriptor, bool>
-edge(vertex_descriptor u, vertex_descriptor v,
-     const adjacency_list& g)
-
-If an edge from vertex u to vertex v exists, return a pair -containing one such edge and true. If there are no edges between -u and v, return a pair with an arbitrary edge descriptor and -false. - -
- -
-std::pair<out_edge_iterator, out_edge_iterator>
-edge_range(vertex_descriptor u, vertex_descriptor v,
-           const adjacency_list& g)
-
-Returns a pair of out-edge iterators that give the range for -all the parallel edges from u to v. This -function only works when the OutEdgeList for the -adjacency_list is a container that sorts the -out edges according to target vertex, and allows for -parallel edges. The multisetS selector chooses -such a container. - -
- -

Structure Modification

- -
- -
-std::pair<edge_descriptor, bool>
-add_edge(vertex_descriptor u, vertex_descriptor v,
-         adjacency_list& g)
-
-Adds edge (u,v) to the graph and returns the edge descriptor -for the new edge. For graphs that do not allow parallel edges, if the -edge is already in the graph then a duplicate will not be added and -the bool flag will be false. When the flag is -false, the -returned edge descriptor points to the already existing edge. - -

-The placement of the new edge in the out-edge list is in general -unspecified, though ordering of the out-edge list can be accomplished -through the choice of OutEdgeList. - -If the VertexList selector is -vecS, and if either vertex descriptor u or -v (which are integers) has a value greater than the current -number of vertices in the graph, the graph is enlarged so that the -number of vertices is std::max(u,v) + 1. - -

-If the OutEdgeList selector is vecS then this operation -will invalidate any out_edge_iterator for vertex -u. This also applies if the OutEdgeList is a user-defined -container that invalidates its iterators when push(container, -x) is invoked (see Section Customizing the -Adjacency List Storage). If the graph is also bidirectional then -any in_edge_iterator for v is also invalidated. If -instead the graph is undirected then any out_edge_iterator -for v is also invalidated. If instead the graph is directed, -then add_edge() also invalidates any edge_iterator. - - -

- -
-std::pair<edge_descriptor, bool>
-add_edge(vertex_descriptor u, vertex_descriptor v,
-         const EdgeProperties& p,
-         adjacency_list& g)
-
-Adds edge (u,v) to the graph and attaches p as the -value of the edge's internal property storage. Also see the previous -add_edge() non-member function for more details. - -
- -
-void remove_edge(vertex_descriptor u, vertex_descriptor v,
-                 adjacency_list& g)
-
-Removes the edge (u,v) from the graph. -

-This operation causes any outstanding edge descriptors or iterators -that point to edge (u,v) to become invalid. In addition, if -the OutEdgeList selector is vecS then this operation -will invalidate any iterators that point into the edge-list for vertex -u and also for vertex v in the undirected and -bidirectional case. Also, for directed graphs this invalidates any -edge_iterator. - -

- -
-void remove_edge(edge_descriptor e, adjacency_list& g)
-
-Removes the edge e from the graph. This differs from the -remove_edge(u, v, g) function in the case of a -multigraph. This remove_edge(e, g) function removes a single -edge, whereas the remove_edge(u, v, g) function removes all -edges (u,v). -

-This operation invalidates any outstanding edge descriptors and -iterators for the same edge pointed to by descriptor e. In -addition, this operation will invalidate any iterators that point into -the edge-list for the target(e, g). Also, for directed -graphs this invalidates any edge_iterator for the graph. - -

- -
-void remove_edge(out_edge_iterator iter, adjacency_list& g)
-
-This has the same effect as remove_edge(*iter, g). The -difference is that this function has constant time complexity -in the case of directed graphs, whereas remove_edge(e, g) -has time complexity O(E/V). - -
- -
-template <class Predicate>
-void remove_out_edge_if(vertex_descriptor u, Predicate predicate,
-                        adjacency_list& g)
-
-Removes all out-edges of vertex u from the graph that satisfy -the predicate. That is, if the predicate returns true when -applied to an edge descriptor, then the edge is removed. -

-The affect on descriptor and iterator stability is the same as that of -invoking remove_edge() on each of the removed edges. - -

- -
-template <class Predicate>
-void remove_in_edge_if(vertex_descriptor v, Predicate predicate,
-                       adjacency_list& g)
-
-Removes all in-edges of vertex v from the graph that satisfy -the predicate. That is, if the predicate returns true when -applied to an edge descriptor, then the edge is removed. -

-The affect on descriptor and iterator stability is the -same as that of invoking remove_edge() on each of the -removed edges. -

-This operation is available for undirected and bidirectional -adjacency_list graphs, but not for directed. - -

- -
-template <class Predicate>
-void remove_edge_if(Predicate predicate, adjacency_list& g)
-
-Removes all edges from the graph that satisfy -the predicate. That is, if the predicate returns true when -applied to an edge descriptor, then the edge is removed. -

-The affect on descriptor and iterator stability is the same as that of -invoking remove_edge() on each of the removed edges. - -

- - -
-vertex_descriptor
-add_vertex(adjacency_list& g)
-
-Adds a vertex to the graph and returns the vertex descriptor for the -new vertex. - - -
- -
-vertex_descriptor
-add_vertex(const VertexProperties& p,
-           adjacency_list& g)
-
-Adds a vertex to the graph with the specified properties. Returns the -vertex descriptor for the new vertex. - - -
- -
-void clear_vertex(vertex_descriptor u, adjacency_list& g)
-
-Removes all edges to and from vertex u. The vertex still appears -in the vertex set of the graph. -

-The affect on descriptor and iterator stability is the -same as that of invoking remove_edge() for all of -the edges that have u as the source or target. - -

- -
-void clear_out_edges(vertex_descriptor u, adjacency_list& g)
-
-Removes all out-edges from vertex u. The vertex still appears -in the vertex set of the graph. -

-The affect on descriptor and iterator stability is the -same as that of invoking remove_edge() for all of -the edges that have u as the source. -

-This operation is not applicable to undirected graphs -(use clear_vertex() instead). - -

- -
-void clear_in_edges(vertex_descriptor u, adjacency_list& g)
-
-Removes all in-edges from vertex u. The vertex still appears -in the vertex set of the graph. -

-The affect on descriptor and iterator stability is the -same as that of invoking remove_edge() for all of -the edges that have u as the target. -

-This operation is only applicable to bidirectional graphs. - -

- -
-void remove_vertex(vertex_descriptor u, adjacency_list& g)
-
-Remove vertex u from the vertex set of the graph. It is assumed -that there are no edges to or from vertex u when it is removed. -One way to make sure of this is to invoke clear_vertex() -beforehand. -

-If the VertexList template parameter of the -adjacency_list was vecS, then all vertex -descriptors, edge descriptors, and iterators for the graph are -invalidated by this operation. The builtin -vertex_index_t property for each vertex is renumbered so that -after the operation the vertex indices still form a contiguous range -[0, num_vertices(g)). If you are using external property -storage based on the builtin vertex index, then the external storage -will need to be adjusted. Another option is to not use the builtin -vertex index, and instead use a property to add your own vertex index -property. If you need to make frequent use of the -remove_vertex() function the listS selector is a -much better choice for the VertexList template parameter. - -

- -

Property Map Accessors

- -
- -
-template <class PropertyTag>
-property_map<adjacency_list, PropertyTag>::type
-get(PropertyTag, adjacency_list& g)
-
-template <class PropertyTag>
-property_map<adjacency_list, Tag>::const_type
-get(PropertyTag, const adjacency_list& g)
-
-Returns the property map object for the vertex property specified by -PropertyTag. The PropertyTag must match one of the -properties specified in the graph's VertexProperty template -argument. - -
- -
-template <class PropertyTag, class X>
-typename property_traits<property_map<adjacency_list, PropertyTag>::const_type>::value_type
-get(PropertyTag, const adjacency_list& g, X x)
-
-This returns the property value for x, where x is either -a vertex or edge descriptor. -
- -
-template <class PropertyTag, class X, class Value>
-void
-put(PropertyTag, const adjacency_list& g, X x, const Value& value)
-
-This sets the property value for x to -value. x is either a vertex or edge descriptor. -Value must be convertible to -typename property_traits<property_map<adjacency_list, PropertyTag>::type>::value_type - -
- -
-template <class GraphProperties, class GraphPropertyTag>
-typename graph_property<adjacency_list, GraphPropertyTag>::type&
-get_property(adjacency_list& g, GraphPropertyTag);
-
-Return the property specified by GraphPropertyTag that is -attached to the graph object g. The graph_property -traits class is defined in boost/graph/adjacency_list.hpp. - -
- -
-template <class GraphProperties, class GraphPropertyTag>
-const typename graph_property<adjacency_list, GraphPropertyTag>::type&
-get_property(const adjacency_list& g, GraphPropertyTag);
-
-Return the property specified by GraphPropertyTag that is -attached to the graph object g. The graph_property -traits class is defined in boost/graph/adjacency_list.hpp. - - - -
- - - -

Serialization

- -
- -
-template<class SavingArchive>
-SavingArchive& operator<<(SavingArchive& ar, const adjacency_list& graph);
-
-Serializes the graph into the archive. Requires the vertex and edge properties of the -graph to be Serializable. -
-Include boost/graph/adj_list_serialize.hpp. -
- -
-template<class LoadingArchive>
-LoadingArchive& operator>>(LoadingArchive& ar, const adjacency_list& graph);
-
-Reads the graph from the archive. Requires the vertex and edge properties of the -graph to be Serializable. -
-Include boost/graph/adj_list_serialize.hpp. -
- - -

See Also

- -adjacency_list_traits, -property_map, -graph_traits - - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - - - - - - - diff --git a/doc/adjacency_list_traits.html b/doc/adjacency_list_traits.html deleted file mode 100644 index 90519c701..000000000 --- a/doc/adjacency_list_traits.html +++ /dev/null @@ -1,158 +0,0 @@ - - - -Boost Graph Library: Graph Traits - -C++ Boost - -
- -

-
-adjacency_list_traits<EdgeList, VertexList, Directed>
-
-

- -This class provides an alternate method for accessing some of the -associated types of the adjacency_list class. The main reason -for this class is that sometimes one would like to create graph -properties whose values are vertex or edge descriptors. If you try to -use graph_traits for this you will run into a problem with -mutually recursive types. To get around this problem, the -adjacency_list_traits class is provided, which gives the user -access to the vertex and edge descriptor types without requiring the -user to provide the property types for the graph. - -
-  template <class EdgeList, class VertexList, class Directed>
-  struct adjacency_list_traits {
-    typedef ... vertex_descriptor;
-    typedef ... edge_descriptor;
-    typedef ... directed_category;
-    typedef ... edge_parallel_category;
-  };
-
- -

Where Defined

- -boost/graph/adjacency_list.hpp - -

Template Parameters

- -

- - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
EdgeList -The selector type for the edge container implementation. -vecS
VertexList -The selector type for the vertex container implementation. -vecS
Directed -The selector type whether the graph is directed or undirected. -directedS
- -

Model of

- -DefaultConstructible and -Assignable - -

Type Requirements

- -Under construction. - -

Members

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - -
MemberDescription
-vertex_descriptor - -The type for the objects used to identify vertices in the graph. -
-edge_descriptor - -The type for the objects used to identify edges in the graph. -
-directed_category - -This says whether the graph is undirected (undirected_tag) -or directed (directed_tag). -
-edge_parallel_category - -This says whether the graph allows parallel edges to be inserted -(allow_parallel_edge_tag) or if it automatically removes -parallel edges (disallow_parallel_edge_tag). -
- -

See Also

- -adjacency_list - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/adjacency_matrix.html b/doc/adjacency_matrix.html deleted file mode 100644 index 4ce613b70..000000000 --- a/doc/adjacency_matrix.html +++ /dev/null @@ -1,584 +0,0 @@ - - - -Boost Graph Library: Adjacency Matrix - -C++ Boost - -
- -

-
-adjacency_matrix<Directed, VertexProperty,
-                 EdgeProperty, GraphProperty,
-                 Allocator>
-
-

- -The adjacency_matrix class implements the BGL graph interface -using the traditional adjacency matrix storage format. For a graph -with V vertices, a V x V matrix is used, where each -element aij is a boolean flag that says whether -there is an edge from vertex i to vertex j. Figure 1 shows the adjacency matrix -representation of a graph. - -

-
- - - - -
Figure 1: Adjacency Matrix Representation of a Directed Graph.
-

- -The advantage of this matrix format over the adjacency list is that -edge insertion and removal is constant time. There are several -disadvantages. The first is that the amount of memory used is -O(V2) instead of O(V + E) (where E is -the number of edges). The second is that operations that traverse all -the out-edges of each vertex (such as breadth-first search) run in -O(V2) time instead of O(V + E) time for the -adjacency list. In short, it is better to use the -adjacency_matrix for dense graphs (where E is close to -V2) and it is better to use adjacency_list for sparse -graphs (where E is much smaller than V2). - -The adjacency_matrix class extends the traditional -data-structure by allowing objects to be attached to vertices and -edges using the same property template parameters supported by adjacency_list. These may be -bundled properties or standard (backward-compatible) -interior -properties. The types of all property values must be -Copy Constructible, Assignable and Default Constructible. - -In the case of an undirected graph, the -adjacency_matrix. class does not use a full V x V -matrix but instead uses a lower triangle (the diagonal and below) -since the matrix for an undirected graph is symmetric. This reduces -the storage to (V2)/2. Figure 2 shows an adjacency -matrix representation of an undirected graph. - -

-
- - - - -
Figure 2: Adjacency Matrix Representation of an Undirected Graph.
-

- - -

Example

- -Creating the graph of Figure 1. -
-  enum { A, B, C, D, E, F, N };
-  const char* name = "ABCDEF";
-
-  typedef boost::adjacency_matrix<boost::directedS> Graph;
-  Graph g(N);
-  add_edge(B, C, g);
-  add_edge(B, F, g);
-  add_edge(C, A, g);
-  add_edge(C, C, g);
-  add_edge(D, E, g);
-  add_edge(E, D, g);
-  add_edge(F, A, g);
-
-  std::cout << "vertex set: ";
-  boost::print_vertices(g, name);
-  std::cout << std::endl;
-
-  std::cout << "edge set: ";
-  boost::print_edges(g, name);
-  std::cout << std::endl;
-
-  std::cout << "out-edges: " << std::endl;
-  boost::print_graph(g, name);
-  std::cout << std::endl;
-
-The output is: -
-  vertex set: A B C D E F
-
-  edge set: (B,C) (B,F) (C,A) (C,C) (D,E) (E,D) (F,A)
-
-  out-edges:
-  A -->
-  B --> C F
-  C --> A C
-  D --> E
-  E --> D
-  F --> A
-
- -Creating the graph of Figure 2. -
-  enum { A, B, C, D, E, F, N };
-  const char* name = "ABCDEF";
-
-  typedef boost::adjacency_matrix<boost::undirectedS> UGraph;
-  UGraph ug(N);
-  add_edge(B, C, ug);
-  add_edge(B, F, ug);
-  add_edge(C, A, ug);
-  add_edge(D, E, ug);
-  add_edge(F, A, ug);
-
-  std::cout << "vertex set: ";
-  boost::print_vertices(ug, name);
-  std::cout << std::endl;
-
-  std::cout << "edge set: ";
-  boost::print_edges(ug, name);
-  std::cout << std::endl;
-
-  std::cout << "incident edges: " << std::endl;
-  boost::print_graph(ug, name);
-  std::cout << std::endl;
-
-The output is: -
-  vertex set: A B C D E F
-
-  edge set: (C,A) (C,B) (E,D) (F,A) (F,B)
-
-  incident edges:
-  A <--> C F
-  B <--> C F
-  C <--> A B
-  D <--> E
-  E <--> D
-  F <--> A B
-
- - -

Where Defined

- -boost/graph/adjacency_matrix.hpp - - -

Template Parameters

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
DirectedA selector to choose whether the graph is directed or undirected. The options are directedS and undirectedS.directedS
VertexPropertyfor specifying internal property storage.no_property
EdgePropertyfor specifying internal property storage.no_property
GraphPropertyfor specifying property storage for the graph object.no_property
- -

Model Of

- -VertexAndEdgeListGraph, -Incidence Graph, -Bidirectional Graph, -AdjacencyMatrix, MutablePropertyGraph, -CopyConstructible, -and Assignable. - - -

Associated Types

- -
- -graph_traits<adjacency_matrix>::vertex_descriptor -

-The type for the vertex descriptors associated with the -adjacency_matrix.
-(Required by Graph.) - -
- -graph_traits<adjacency_matrix>::edge_descriptor -

-The type for the edge descriptors associated with the - adjacency_matrix.
- (Required by Graph.) - -
-graph_traits<adjacency_matrix>::vertex_iterator -

- The type for the iterators returned by vertices(). - The vertex iterator models RandomAccessIterator.
- (Required by VertexListGraph.) - -
-graph_traits<adjacency_matrix>::edge_iterator -

- The type for the iterators returned by edges(). This - iterator models MultiPassInputIterator.
- (Required by EdgeListGraph.) - -
-graph_traits<adjacency_matrix>::out_edge_iterator -

- The type for the iterators returned by out_edges(). This - iterator models MultiPassInputIterator.
- (Required by IncidenceGraph.) - -
-graph_traits<adjacency_matrix>::in_edge_iterator -

- The type for the iterators returned by in_edges(). This - iterator models MultiPassInputIterator.
- (Required by BidirectionalGraph.) - -
-graph_traits<adjacency_matrix>::adjacency_iterator -

- The type for the iterators returned by adjacent_vertices(). This - iterator models the same concept as the out-edge iterator.
- (Required by AdjacencyGraph.) - -
-graph_traits<adjacency_matrix>::directed_category -

- Provides information about whether the graph is directed - (directed_tag) or undirected (undirected_tag).
- (Required by Graph.) - -
-graph_traits<adjacency_matrix>::edge_parallel_category -

- An adjacency matrix does not allow the insertion of - parallel edges, so this type is always - disallow_parallel_edge_tag.
- (Required by Graph.) - -
-graph_traits<adjacency_matrix>::vertices_size_type -

- The type used for dealing with the number of vertices in - the graph.
- (Required by VertexListGraph.) - -
-graph_traits<adjacency_matrix>::edges_size_type -

- The type used for dealing with the number of edges in the graph.
- (Required by EdgeListGraph.) - -
-graph_traits<adjacency_matrix>::degree_size_type -

- The type used for dealing with the number of out-edges of a vertex.
- (Required by IncidenceGraph.) - -
-property_map<adjacency_matrix, PropertyTag>::type
-property_map<adjacency_matrix, PropertyTag>::const_type -

- The map type for vertex or edge properties in the graph. The - specific property is specified by the PropertyTag template - argument, and must match one of the properties specified in the - VertexProperty or EdgeProperty for the graph.
- (Required by PropertyGraph.) - -
- -

Member Functions

- -
-
-adjacency_matrix(vertices_size_type n,
-                 const GraphProperty& p = GraphProperty())
-
-Creates a graph object with n vertices and zero edges.
-(Required by MutableGraph.) - -
-
-template <typename EdgeIterator>
-adjacency_matrix(EdgeIterator first,
-                 EdgeIterator last,
-                 vertices_size_type n,
-                 const GraphProperty& p = GraphProperty())
-
- Creates a graph object with n vertices with the edges - specified in the edge list given by the range [first, last). - The value type of the EdgeIterator must be a - std::pair, where the type in the pair is an integer type. The - integers will correspond to vertices, and they must all fall in the - range of - [0, n).
- (Required by IteratorConstructibleGraph.) - -
-
-template <typename EdgeIterator, typename EdgePropertyIterator>
-adjacency_matrix(EdgeIterator first, EdgeIterator last,
-                 EdgePropertyIterator ep_iter,
-                 vertices_size_type n,
-                 const GraphProperty& p = GraphProperty())
-
- Creates a graph object with n vertices, with the edges - specified in the edge list given by the range [first, last). - The value type of the EdgeIterator must be a - std::pair, where the type in the pair is an integer type. The - integers will correspond to vertices, and they must all fall in the - range of [0, n). The value_type of the - ep_iter should be EdgeProperty. - -
- - -

Non-Member Functions

- -
-
-std::pair<vertex_iterator, vertex_iterator>
-vertices(const adjacency_matrix& g)
-
-Returns an iterator-range providing access to the vertex set of graph g.
-(Required by VertexListGraph.) - -
-
-std::pair<edge_iterator, edge_iterator>
-edges(const adjacency_matrix& g);
-
-Returns an iterator-range providing access to the edge set of graph g.
-(Required by EdgeListGraph.) - -
-
-std::pair<adjacency_iterator, adjacency_iterator>
-adjacent_vertices(vertex_descriptor v, const adjacency_matrix& g)
-
-Returns an iterator-range providing access to the vertices adjacent to -vertex v in graph g.
-(Required by AdjacencyGraph.) - -
-
-std::pair<out_edge_iterator, out_edge_iterator>
-out_edges(vertex_descriptor v, const adjacency_matrix& g)
-
-Returns an iterator-range providing access to the out-edges of -vertex v in graph g. If the graph is undirected, -this iterator-range provides access to all edges incident on -vertex v.
-(Required by IncidenceGraph.) - -
-
-vertex_descriptor
-source(edge_descriptor e, const adjacency_matrix& g)
-
-Returns the source vertex of edge e.
-(Required by IncidenceGraph.) - -
-
-vertex_descriptor
-target(edge_descriptor e, const adjacency_matrix& g)
-
-Returns the target vertex of edge e.
-(Required by IncidenceGraph.) - -
-
-degree_size_type
-out_degree(vertex_descriptor u, const adjacency_matrix& g)
-
-Returns the number of edges leaving vertex u.
-(Required by IncidenceGraph.) -
- -
-
-std::pair<in_edge_iterator, in_edge_iterator>
-in_edges(vertex_descriptor v, const adjacency_matrix& g)
-
-Returns an iterator-range providing access to the in-edges of -vertex v in graph g. If the graph is undirected, -this iterator-range provides access to all edges incident on -vertex v.
-(Required by BidirectionalGraph.) - -
-
-degree_size_type
-in_degree(vertex_descriptor u, const adjacency_matrix& g)
-
-Returns the number of edges entering vertex u.
-(Required by BidirectionalGraph.) -
- -
-
-vertices_size_type num_vertices(const adjacency_matrix& g)
-
-Returns the number of vertices in the graph g.
-(Required by VertexListGraph.) - -
-
-edges_size_type num_edges(const adjacency_matrix& g)
-
-Returns the number of edges in the graph g.
-(Required by EdgeListGraph.) - -
-
-vertex_descriptor vertex(vertices_size_type n, const adjacency_matrix& g)
-
-Returns the nth vertex in the graph's vertex list. - -
-
-std::pair<edge_descriptor, bool>
-edge(vertex_descriptor u, vertex_descriptor v,
-     const adjacency_matrix& g)
-
-Returns the edge connecting vertex u to vertex v in graph g.
-(Required by AdjacencyMatrix.) - -
-
-std::pair<edge_descriptor, bool>
-add_edge(vertex_descriptor u, vertex_descriptor v,
-         adjacency_matrix& g)
-
- Adds edge (u,v) to the graph and returns the edge descriptor for - the new edge. If the edge is already in the graph then a duplicate - will not be added and the bool flag will be false. - This operation does not invalidate any of the graph's iterators - or descriptors.
-(Required by MutableGraph.) - -
-
-std::pair<edge_descriptor, bool>
-add_edge(vertex_descriptor u, vertex_descriptor v,
-         const EdgeProperty& p,
-         adjacency_matrix& g)
-
-Adds edge (u,v) to the graph and attaches p as the -value of the edge's internal property storage. Also see the previous -add_edge() member function for more details. - -
-
-void remove_edge(vertex_descriptor u, vertex_descriptor v,
-                 adjacency_matrix& g)
-
-Removes the edge (u,v) from the graph.
-(Required by MutableGraph.) - -
-
-void remove_edge(edge_descriptor e, adjacency_matrix& g)
-
-Removes the edge e from the graph. This is equivalent -to calling remove_edge(source(e, g), target(e, g), g).
-(Required by MutableGraph.) - -
-
-void clear_vertex(vertex_descriptor u, adjacency_matrix& g)
-
-Removes all edges to and from vertex u. The vertex still appears -in the vertex set of the graph.
-(Required by MutableGraph.) - -
-
-template <typename Property>
-property_map<adjacency_matrix, Property>::type
-get(Property, adjacency_matrix& g)
-
-template <typename Property>
-property_map<adjacency_matrix, Property>::const_type
-get(Property, const adjacency_matrix& g)
-
-Returns the property map object for the vertex property specified by -Property. The Property must match one of the -properties specified in the graph's VertexProperty template -argument.
-(Required by PropertyGraph.) - -
-
-template <typename Property, typename X>
-typename property_traits<
-  typename property_map<adjacency_matrix, Property>::const_type
->::value_type
-get(Property, const adjacency_matrix& g, X x)
-
-This returns the property value for x, which is either -a vertex or edge descriptor.
-(Required by PropertyGraph.) - -
-
-template <typename Property, typename X, typename Value>
-void
-put(Property, const adjacency_matrix& g, X x, const Value& value)
-
-This sets the property value for x to -value. x is either a vertex or edge descriptor. -Value must be convertible to -typename property_traits<property_map<adjacency_matrix, Property>::type>::value_type.
-(Required by PropertyGraph.) - -
-
-template <typename GraphProperty, typename GraphProperty>
-typename property_value<GraphProperty, GraphProperty>::type&
-get_property(adjacency_matrix& g, GraphProperty)
-
-Return the property specified by GraphProperty that is attached -to the graph object g. The property_value traits class -is defined in boost/pending/property.hpp. - -
-
-template <typename GraphProperty, typename GraphProperty>
-const typename property_value<GraphProperty, GraphProperty>::type&
-get_property(const adjacency_matrix& g, GraphProperty)
-
-Return the property specified by GraphProperty that is -attached to the graph object g. The property_value -traits class is defined in boost/pending/property.hpp. - - -
diff --git a/doc/antora.yml b/doc/antora.yml new file mode 100644 index 000000000..07e646cec --- /dev/null +++ b/doc/antora.yml @@ -0,0 +1,10 @@ +name: graph +version: ~ +title: Boost.Graph +start_page: index.adoc +asciidoc: + attributes: + source-language: cpp@ + table-caption: false +nav: + - modules/ROOT/nav.adoc diff --git a/doc/astar_heuristic.html b/doc/astar_heuristic.html deleted file mode 100644 index d42ea4863..000000000 --- a/doc/astar_heuristic.html +++ /dev/null @@ -1,96 +0,0 @@ - - - -Boost Graph Library: astar_heuristic - -C++ Boost - -
- -

-
-astar_heuristic<Graph, CostType>
-
-

- -This class is a default implementation of the AStarHeuristic concept. It -implements a "zero" heuristic -- a heuristic function that returns a -cost of zero regardless of the vertex it is passed. - -

Model of

- -AStarHeuristic - -

Template Parameters

- -

- - - - - - - - - - - - - - - -
ParameterDescriptionDefault
Graph -The type of the graph being searched. -
CostType -A type that can be used with the compare and -combine functions passed to A*. Typically an integer or -floating point type. -
- -

Where Defined

- -

- -boost/graph/astar_search.hpp - -

Member Functions

- -This class implements the single member function required by AStarHeuristic: - - - - - - - - -
FunctionDescription
-CostType operator()(graph_traits<Graph>::vertex_descriptor u); - -Called for the target of every out edge of a vertex being examined. -Returns the cost, estimated by the heuristic, from vertex u -to a goal. -
- -
-
- - -
Copyright © 2004 -Kristopher Beevers, -Rensselaer Polytechnic Institute (beevek@cs.rpi.edu) -
- - - diff --git a/doc/astar_search.html b/doc/astar_search.html deleted file mode 100644 index e020ff384..000000000 --- a/doc/astar_search.html +++ /dev/null @@ -1,589 +0,0 @@ - - - -Boost Graph Library: A* Heuristic Search - -C++ Boost - -
- -

-astar_search -

- - -

-

-// Named parameter interfaces
-template <typename VertexListGraph,
-          typename AStarHeuristic,
-          typename P, typename T, typename R>
-void
-astar_search
-  (const VertexListGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, const bgl_named_params<P, T, R>& params);
-
-template <typename VertexListGraph,
-          typename AStarHeuristic,
-          typename P, typename T, typename R>
-void
-astar_search_no_init
-  (const IncidenceGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, const bgl_named_params<P, T, R>& params);
-
-template <typename VertexListGraph,
-          typename AStarHeuristic,
-          typename P, typename T, typename R>
-void
-astar_search_tree
-  (const VertexListGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, const bgl_named_params<P, T, R>& params);
-
-template <typename VertexListGraph,
-          typename AStarHeuristic,
-          typename P, typename T, typename R>
-void
-astar_search_no_init_tree
-  (const IncidenceGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, const bgl_named_params<P, T, R>& params);
-
-// Non-named parameter interface
-template <typename VertexListGraph, typename AStarHeuristic,
-          typename AStarVisitor, typename PredecessorMap,
-          typename CostMap, typename DistanceMap,
-          typename WeightMap, typename VertexIndexMap,
-	  typename ColorMap,
-          typename CompareFunction, typename CombineFunction,
-          typename CostInf, typename CostZero>
-inline void
-astar_search
-  (const VertexListGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, AStarVisitor vis,
-   PredecessorMap predecessor, CostMap cost,
-   DistanceMap distance, WeightMap weight,
-   VertexIndexMap index_map, ColorMap color,
-   CompareFunction compare, CombineFunction combine,
-   CostInf inf, CostZero zero);
-
-template <typename VertexListGraph, typename AStarHeuristic,
-          typename AStarVisitor, typename PredecessorMap,
-          typename CostMap, typename DistanceMap,
-          typename WeightMap,
-          typename CompareFunction, typename CombineFunction,
-          typename CostInf, typename CostZero>
-inline void
-astar_search_tree
-  (const VertexListGraph &g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   AStarHeuristic h, AStarVisitor vis,
-   PredecessorMap predecessor, CostMap cost,
-   DistanceMap distance, WeightMap weight,
-   CompareFunction compare, CombineFunction combine,
-   CostInf inf, CostZero zero);
-
-// Versions that do not initialize property maps (used for implicit graphs)
-template <typename IncidenceGraph, typename AStarHeuristic,
-          typename AStarVisitor, typename PredecessorMap,
-          typename CostMap, typename DistanceMap,
-          typename WeightMap, typename ColorMap,
-          typename VertexIndexMap,
-          typename CompareFunction, typename CombineFunction,
-          typename CostInf, typename CostZero>
-inline void
-astar_search_no_init
-  (const IncidenceGraph &g,
-   typename graph_traits<IncidenceGraph>::vertex_descriptor s,
-   AStarHeuristic h, AStarVisitor vis,
-   PredecessorMap predecessor, CostMap cost,
-   DistanceMap distance, WeightMap weight,
-   ColorMap color, VertexIndexMap index_map,
-   CompareFunction compare, CombineFunction combine,
-   CostInf inf, CostZero zero);
-
-Note that the index_map and color parameters are swapped in
-astar_search_no_init() relative to astar_search(); the named parameter
-interfaces are not affected.
-
-template <typename IncidenceGraph, typename AStarHeuristic,
-          typename AStarVisitor, typename PredecessorMap,
-          typename CostMap, typename DistanceMap,
-          typename WeightMap,
-          typename CompareFunction, typename CombineFunction,
-          typename CostInf, typename CostZero>
-inline void
-astar_search_no_init_tree
-  (const IncidenceGraph &g,
-   typename graph_traits<IncidenceGraph>::vertex_descriptor s,
-   AStarHeuristic h, AStarVisitor vis,
-   PredecessorMap predecessor, CostMap cost,
-   DistanceMap distance, WeightMap weight,
-   CompareFunction compare, CombineFunction combine,
-   CostInf inf, CostZero zero);
-
- -

-This algorithm implements a heuristic search on a weighted, directed -or undirected graph for the case where all edge weights are -non-negative. -

- -

-The A* algorithm is a heuristic graph search algorithm: an A* -search is "guided" by a heuristic function. A heuristic -function h(v) is one which estimates the cost from a non-goal -state (v) in the graph to some goal state, g. -Intuitively, A* follows paths (through the graph) to the goal that are -estimated by the heuristic function to be the best paths. Unlike -best-first search, A* takes into account the known cost from the start -of the search to v; the paths A* takes are guided by a function -f(v) = g(v) + h(v), where h(v) is the heuristic -function, and g(v) (sometimes denoted c(s, v)) is the -known cost from the start to v. Clearly, the efficiency of A* -is highly dependent on the heuristic function with which it is used. -

- -

-The A* algorithm is very similar to Dijkstra's Shortest Paths -algorithm. This implementation finds all the shortest paths from the -start vertex to every other vertex by creating a search tree, -examining vertices according to their remaining cost to some goal, as -estimated by a heuristic function. Most commonly, A* is used to find -some specific goal vertex or vertices in a graph, after which the -search is terminated. -

- -

-A* is particularly useful for searching implicit graphs. -Implicit graphs are graphs that are not completely known at the -beginning of the search. Upon visiting a vertex, its neighbors are -"generated" and added to the search. Implicit graphs are particularly -useful for searching large state spaces -- in game-playing scenarios -(e.g. chess), for example -- in which it may not be possible to store -the entire graph. Implicit searches can be performed with this -implementation of A* by creating special visitors that generate -neighbors of newly-expanded vertices. Please note that -astar_search_no_init() or astar_search_no_init_tree() must be -used for implicit graphs; the basic -astar_search() function requires a graph that models -the Vertex List Graph concept. Both -versions -also require the graph type to model the Incidence Graph concept. -

- -

-For the non-tree versions of the algorithm, -this implementation of A* is based on an OPEN/CLOSED list formulation. -Vertices on the OPEN list have been ``discovered'' -by the algorithm, but not ``expanded'' (we have not discovered their -adjacent vertices). Vertices on the CLOSED list have been completely -examined by our search (we have expanded them and added their children -to the OPEN list). Vertices that are on neither list have not been -encountered in any context so far in our search. A major advantage of -this formulation of the A* algorithm over other approaches is that it -avoids ``cycles'' in the state space; the search will not become -trapped by loops in the graph. The OPEN/CLOSED lists are implemented -using BGL's vertex coloring mechanisms. Vertices in OPEN are colored -gray, vertices in CLOSED are colored black, and undiscovered vertices -are colored white. For the versions of the algorithm whose names end in -_tree, all vertices are assumed to always be white, leading to -checking for repeated vertices being done using the distance map. If a dummy -value is used for the distance map and the graph contains cycles, the algorithm -will probably enter an infinite loop. -

- -

-The criteria for expanding a vertex on the OPEN list is that it has -the lowest f(v) = g(v) + h(v) value of all vertices on OPEN. -Cost information about vertices is stored in a property map. -

- -

-The following is the pseudocode for the A* heuristic search algorithm. -In the pseudocode, h is the heuristic function, w is the -edge weight, d is the distance of a vertex from s, and -Q is a priority queue, sorted by f, the estimated cost -to the goal of the path through a vertex. p is a predecessor -map. The visitor event points for the algorithm are indicated by the -labels on the right. -

- - - - - - -
-
-A*(G, s, h)
-  for each vertex u in V
-    d[u] := f[u] := infinity
-    color[u] := WHITE
-    p[u] := u
-  end for
-  color[s] := GRAY
-  d[s] := 0
-  f[s] := h(s)
-  INSERT(Q, s)
-  while (Q != Ø)
-    u := EXTRACT-MIN(Q)
-    for each vertex v in Adj[u]
-      if (w(u,v) + d[u] < d[v])
-        d[v] := w(u,v) + d[u]
-	f[v] := d[v] + h(v)
-	p[v] := u
-	if (color[v] = WHITE)
-	  color[v] := GRAY
-	  INSERT(Q, v)
-	else if (color[v] = BLACK)
-	  color[v] := GRAY
-	  INSERT(Q, v)
-	end if
-      else
-        ...
-    end for
-    color[u] := BLACK
-  end while
-
-		 -
-
-initialize vertex u
-
-
-
-
-
-
-
-discover vertex s
-
-examine vertex u
-examine edge (u,v)
-
-edge (u,v) relaxed
-
-
-
-
-discover vertex v
-
-
-reopen vertex v
-
-
-edge (u,v) not relaxed
-
-finish vertex u
-
-
- -

Where Defined

- -boost/graph/astar_search.hpp - -

Parameters

- -IN: const VertexListGraph& g -
- The graph object on which the algorithm will be applied for astar_search(). The type - VertexListGraph must be a model of the - Vertex List Graph and Incidence Graph - concepts. -
- -IN: const IncidenceGraph& g -
- The graph object on which the algorithm will be applied for astar_search_no_init(). The type - IncidenceGraph must be a model of the - Incidence Graph - concept. -
- -IN: vertex_descriptor s -
- The start vertex for the search. All distances will be calculated - from this vertex, and the shortest paths tree (recorded in the - predecessor map) will be rooted at this vertex. -
- -IN: AStarHeuristic h -
- The heuristic function that guides the search. The type - AStarHeuristic must be a model of the AStarHeuristic - concept. -
- -

Named Parameters

- -IN: weight_map(WeightMap w_map) -
- The weight or ``length'' of each edge in the graph. The weights - must all be non-negative; the algorithm will throw a negative_edge - exception if one of the edges is negative. The type - WeightMap must be a model of Readable - Property Map. The edge descriptor type of the graph needs - to be usable as the key type for the weight map. The value type - for this map must be the same as the value type of the distance - map.
- Default: get(edge\_weight, g) -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary in non-tree versions of the - algorithm for efficient updates of - the heap data structure when an edge is relaxed. 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 usable as - the key type of the map.
- - Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- -OUT: predecessor_map(PredecessorMap p_map) -
- - The predecessor map records the edges in the minimum spanning tree. - Upon completion of the algorithm, the edges (p[u],u) for - all u in V are in the minimum spanning tree. If - p[u] = u then u is either the start vertex or a - vertex that is not reachable from the start. The - PredecessorMap type must be a Read/Write - Property Map with key and vertex types the same as the - vertex descriptor type of the graph.
- - Default: dummy_property_map -
- -UTIL/OUT: distance_map(DistanceMap d_map) -
- - The shortest path weight from the start vertex s to each - vertex in the graph g is recorded in this property map. - The shortest path weight is the sum of the edge weights along the - shortest path. The type DistanceMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph - needs to be usable as the key type of the distance map. The value - type of the distance map is the element type of a Monoid formed with the - combine function object and the zero object for the - identity element. Also the distance value type must have a StrictWeakOrdering - provided by the compare function object. A - constant_writable_property_map returning the infinity value can be - used for this parameter in tree versions of the algorithm when the graph does - not contain a directed cycle.
- - Default: shared_array_property_map - with the same value type as the - WeightMap, and of size num_vertices(g), and using - the i_map for the index map. -
- -UTIL/OUT: rank_map(CostMap c_map) -
- - The f-value for each vertex. The f-value is defined - as the sum of the cost to get to a vertex from the start vertex, and - the estimated cost (as returned by the heuristic function - h) from the vertex to a goal. The type CostMap - must be a model of Read/Write - Property Map in non-tree versions of the algorithm, and Writable Property - Map in tree versions of the algorithm. The vertex descriptor type - of the graph - needs to be usable as the key type of the distance map. The value - type of the distance map is the element type of a Monoid formed with the - combine function object and the zero object for the - identity element. Also the distance value type must have a StrictWeakOrdering - provided by the compare function object. The value type - for this map must be the same as the value type for the distance - map. In tree versions of the algorithm, null_property_map can be - used for this parameter.
- - Default: shared_array_property_map - with the same value type as the - DistanceMap, and of size num_vertices(g), and using - the i_map for the index map. -
- -UTIL/OUT: color_map(ColorMap c_map) -
- - This is used during the execution of non-tree versions of the algorithm to - mark the - vertices, indicating whether they are on the OPEN or CLOSED lists. - The vertices start out white and become gray when they are inserted - into the OPEN list. They then turn black when they are examined and - placed on the CLOSED list. At the end of the algorithm, vertices - reachable from the source vertex will have been colored black. All - other vertices will still be white. The type ColorMap must - be a model of Read/Write - Property Map. A vertex descriptor must be usable as the - key type of the map, and the value type of the map must be a model - of Color Value.
- - Default: shared_array_property_map - of value type default_color_type, with size - num_vertices(g), and using - the i_map for the index map. -
- -IN: distance_compare(CompareFunction cmp) -
- - This function is use to compare distances to determine which vertex - is closer to the start vertex, and to compare f-values to - determine which vertex on the OPEN list to examine next. The - CompareFunction type must be a model of Binary - Predicate and have argument types that match the value type - of the DistanceMap property map.
- - Default: std::less<D> with D = typename - property_traits<DistanceMap>::value_type. -
- -IN: distance_combine(CombineFunction cmb) -
- - This function is used to combine distances to compute the distance - of a path, and to combine distance and heuristic values to compute - the f-value of a vertex. The CombineFunction type - must be a model of Binary - Function. Both argument types of the binary function must - match the value type of the DistanceMap property map (which - is the same as that of the WeightMap and CostMap - property maps). The result type must be the same type as the - distance value type.
- - Default: std::plus<D> with D = typename - property_traits<DistanceMap>::value_type. -
- -IN: distance_inf(D inf) -
- - The inf object must be the greatest value of any D - object. That is, compare(d, inf) == true for any d != - inf. The type D is the value type of the - DistanceMap.
- - Default: std::numeric_limits<D>::max() -
- -IN: distance_zero(D zero) -
- - The zero value must be the identity element for the Monoid formed by the distance - values and the combine function object. The type - D is the value type of the DistanceMap.
- - Default: D() with D = typename - property_traits<DistanceMap>::value_type. -
- -OUT: visitor(AStarVisitor v) -
- - Use this to specify actions that you would like to happen during - certain event points within the algorithm. The type - AStarVisitor must be a model of the AStarVisitor concept. The - visitor object is passed by value [1].
- - Default: astar_visitor<null_visitor> -
- -

Complexity

- -

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

Visitor Event Points

- - - -

Example

- -

-See -example/astar-cities.cpp for an example of -using A* search. - -

Notes

- -[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 passed in. Therefore you may want the visitor to hold -this state by pointer or reference. - -
-
- - -
Copyright © 2004 -Kristopher Beevers, -Rensselaer Polytechnic Institute (beevek@cs.rpi.edu) -
- - - diff --git a/doc/astar_visitor.html b/doc/astar_visitor.html deleted file mode 100644 index 27a164fc6..000000000 --- a/doc/astar_visitor.html +++ /dev/null @@ -1,108 +0,0 @@ - - - -Boost Graph Library: astar_visitor - -C++ Boost - -
- -

-
-astar_visitor<EventVisitorList>
-
-

- -This class is an adapter that converts a list of EventVisitor's (constructed using -std::pair) into a AStarVisitor. - - -

Example

- -See the example for EventVisitor. - -

Model of

- -AStarVisitor - -

Template Parameters

- -

- - - - - - - - - - -
ParameterDescriptionDefault
EventVisitorList -A list of EventVisitor's created -with std::pair. -null_visitor
- -

Where Defined

- -

- -boost/graph/astar_search.hpp - -

Member Functions

- -This class implements all of the member functions required by AStarVisitor. In each function the -appropriate event is dispatched to the EventVisitor's in the -EventVisitorList. - -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class EventVisitorList>
-astar_visitor<EventVisitorList>
-make_astar_visitor(EventVisitorList ev_list); -		 -Returns the event visitor list adapted to be an A* visitor. -
- -

See Also

- -Visitor concepts -

-The following are event visitors: predecessor_recorder, -distance_recorder, -time_stamper, -and property_writer. - -
-

- - -
Copyright © 2004 -Kristopher Beevers, -Rensselaer Polytechnic Institute (beevek@cs.rpi.edu) -
- - - diff --git a/doc/awpaper.sty b/doc/awpaper.sty deleted file mode 100644 index c8de93fe3..000000000 --- a/doc/awpaper.sty +++ /dev/null @@ -1,6 +0,0 @@ -\DeclareOption{awpaper} - {\setlength\paperheight {9.25in}% - \setlength\paperwidth {7.375in}} -\DeclareOption*{\PassOptonsToPackage{\CurrentOption}{newsiambook}} -\ProcessOptions -\ExecuteOptions{awpaper} diff --git a/doc/bandwidth.html b/doc/bandwidth.html deleted file mode 100644 index 521785b50..000000000 --- a/doc/bandwidth.html +++ /dev/null @@ -1,93 +0,0 @@ - - - -Boost Graph Library: Bandwidth - -C++ Boost - -
- -

-bandwidth -

- -
-  (1)
-  template <typename Graph>
-  typename graph_traits<Graph>::vertices_size_type
-  bandwidth(const Graph& g)
-
-  (2)
-  template <typename Graph, typename VertexIndexMap>
-  typename graph_traits<Graph>::vertices_size_type
-  bandwidth(const Graph& g, VertexIndexMap index_map)
-
- -The bandwidth of a graph is the maximum -distance between two adjacent vertices, with distance measured on a -line upon which the vertices have been placed at unit intervals. To -put it another way, if the vertices of a graph -G=(V,E) are each assigned an index from zero to |V| - 1 -given by index[v], then the bandwidth of G is
-
-B(G) = max { |index[u] - index[v]|  | (u,v) in E }
- - -

Defined in

- -boost/graph/bandwidth.hpp - - -
- -

-ith_bandwidth -

- -
-  (1)
-  template <typename Graph>
-  typename graph_traits<Graph>::vertices_size_type
-  ith_bandwidth(typename graph_traits<Graph>::vertex_descriptor i,
-		const Graph& g)
-
-  (2)
-  template <typename Graph, typename VertexIndexMap>
-  typename graph_traits<Graph>::vertices_size_type
-  ith_bandwidth(typename graph_traits<Graph>::vertex_descriptor i,
-		const Graph& g,
-		VertexIndexMap index)
-
- -The i-th bandwidth a graph is the maximum distance -between the i-th vertex and any of its neighbors.
-
-Bi(G) = max { |index[i] - index[j]|  | (i,j) in E }
-
-So the bandwidth B(G) can be expressed as the maximum -of the i-th bandwidths Bi(G).
-
-B(G) = max { Bi(G)   | i=0...|V|-1 }
- -

Defined in

- -boost/graph/bandwidth.hpp - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/bc_clustering.html b/doc/bc_clustering.html deleted file mode 100644 index 4686ff18a..000000000 --- a/doc/bc_clustering.html +++ /dev/null @@ -1,151 +0,0 @@ - - - - - - -Function betweenness_centrality_clustering - - -
-
- -C++ Boost - -

(Python)Function -betweenness_centrality_clustering

-

boost::betweenness_centrality_clustering — Graph -clustering based on edge betweenness centrality.

-
-

Synopsis

-
-
-template<typename MutableGraph, typename Done, typename EdgeCentralityMap,
-         typename VertexIndexMap>
-  void betweenness_centrality_clustering(MutableGraph & g, Done done,
-                                         EdgeCentralityMap edge_centrality,
-                                         VertexIndexMap vertex_index);
-template<typename MutableGraph, typename Done, typename EdgeCentralityMap>
-  void betweenness_centrality_clustering(MutableGraph & g, Done done,
-                                         EdgeCentralityMap edge_centrality);
-template<typename MutableGraph, typename Done>
-  void betweenness_centrality_clustering(MutableGraph & g, Done done);
-
-
-

Description

-

This algorithm implements graph clustering based on edge -betweenness centrality. It is an iterative algorithm, where in each -step it computes the edge betweenness centrality (via brandes_betweenness_centrality) and -removes the edge with the maximum betweenness centrality. The -done function object determines -when the algorithm terminates (the edge found when the algorithm -terminates will not be removed).

- -

Parameters

-IN: const Graph& g -
- The graph object on which the algorithm will be applied. The type - Graph must be a model of Vertex List Graph and Incidence Graph. When an edge - centrality map is supplied, it must also model Edge List Graph and MutableGraph.
- -Python: The parameter is named graph. -
- -IN: Done done -
-The function object that indicates termination of the algorithm. -It must be a ternary function object thats accepts the maximum -centrality, the descriptor of the edge that will be removed, and -the graph g.
-Python: Any callable Python object will suffice. -
- -OUT/UTIL: EdgeCentralityMap edge_centrality_map -
- This property map is used to accumulate the betweenness centrality - of each edge, and is a secondary form of output for the - algorithm. The type EdgeCentralityMap must be a model of Read/Write - Property Map, with the graph's edge descriptor type as its key - type. The value type of this property map should be the same as the - value type of the CentralityMap property map.
- - Default: a dummy_property_map, which requires no - work to compute and returns no answer.
- Python: The color map must be a edge_double_map for - the graph.
- Python default: graph.get_edge_double_map("centrality") -
- -IN: VertexIndexMap vertex_index -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure when an edge is relaxed. 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 - usable as the key type of the map.
- Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- Python: Unsupported parameter. -
- - - - - - -
-

Where Defined

-<boost/graph/bc_clustering.hpp> -
- - - - - -
Copyright © 2004Douglas Gregor, -Indiana University (dgregor@cs.indiana.edu)
-Andrew Lumsdaine, Indiana -University (lums@osl.iu.edu)
- - diff --git a/doc/bellman_ford_shortest.html b/doc/bellman_ford_shortest.html deleted file mode 100644 index 6c574cf4c..000000000 --- a/doc/bellman_ford_shortest.html +++ /dev/null @@ -1,349 +0,0 @@ - - - -Bellman Ford Shortest Paths - -C++ Boost - -
- - -

(Python) -bellman_ford_shortest_paths -

- -

-

-// named paramter version
-template <class EdgeListGraph, class Size, class P, class T, class R>
-bool bellman_ford_shortest_paths(const EdgeListGraph& g, Size N,
-  const bgl_named_params<P, T, R>& params = all defaults);
-
-template <class VertexAndEdgeListGraph, class P, class T, class R>
-bool bellman_ford_shortest_paths(const VertexAndEdgeListGraph& g,
-  const bgl_named_params<P, T, R>& params = all defaults);
-
-// non-named parameter version
-template <class EdgeListGraph, class Size, class WeightMap,
-	  class PredecessorMap, class DistanceMap,
-	  class BinaryFunction, class BinaryPredicate,
-	  class BellmanFordVisitor>
-bool bellman_ford_shortest_paths(EdgeListGraph& g, Size N,
-  WeightMap weight, PredecessorMap pred, DistanceMap distance,
-  BinaryFunction combine, BinaryPredicate compare, BellmanFordVisitor v)
-
- -

-The Bellman-Ford algorithm [4,11,20,8] solves the single-source -shortest paths problem for a graph with both positive and negative -edge weights. For the definition of the shortest paths problem see -Section Shortest-Paths -Algorithms. -If you only need to solve the shortest paths problem for positive edge -weights, Dijkstra's algorithm provides a more efficient -alternative. If all the edge weights are all equal to one then breadth-first -search provides an even more efficient alternative. -

- -

-Before calling the bellman_ford_shortest_paths() function, -the user must assign the source vertex a distance of zero and all -other vertices a distance of infinity unless you are providing -a starting vertex. The Bellman-Ford algorithm -proceeds by looping through all of the edges in the graph, applying -the relaxation operation to each edge. In the following pseudo-code, -v is a vertex adjacent to u, w maps edges to -their weight, and d is a distance map that records the length -of the shortest path to each vertex seen so far. p is a -predecessor map which records the parent of each vertex, which will -ultimately be the parent in the shortest paths tree -

- - - - - - -
-
-RELAX(u, v, w, d, p)
-  if (w(u,v) + d[u] < d[v])
-    d[v] := w(u,v) + d[u]
-    p[v] := u
-  else
-    ...
-
-		 -
-
-
-relax edge (u,v)
-
-
-edge (u,v) is not relaxed
-
-
- -

-The algorithm repeats this loop |V| times after which it is -guaranteed that the distances to each vertex have been reduced to the -minimum possible unless there is a negative cycle in the graph. If -there is a negative cycle, then there will be edges in the graph that -were not properly minimized. That is, there will be edges (u,v) such -that w(u,v) + d[u] < d[v]. The algorithm loops over the edges in -the graph one final time to check if all the edges were minimized, -returning true if they were and returning false -otherwise. -

- - - - - - -
-
-BELLMAN-FORD(G)
-  // Optional initialization
-  for each vertex u in V
-    d[u] := infinity
-    p[u] := u
-  end for
-  for i := 1 to |V|-1
-    for each edge (u,v) in E
-      RELAX(u, v, w, d, p)
-    end for
-  end for
-  for each edge (u,v) in E
-    if (w(u,v) + d[u] < d[v])
-      return (false, , )
-    else
-      ...
-  end for
-  return (true, p, d)
-
-		 -
-
-
-
-
-
-
-
-examine edge (u,v)
-
-
-
-
-
-edge (u,v) was not minimized
-
-edge (u,v) was minimized
-
-
- -There are two main options for obtaining output from the -bellman_ford_shortest_paths() function. If the user provides -a distance property map through the distance_map() parameter -then the shortest distance from the source vertex to every other -vertex in the graph will be recorded in the distance map (provided the -function returns true). The second option is recording the -shortest paths tree in the predecessor_map(). For each vertex -u in V, p[u] will be the predecessor of u in the -shortest paths tree (unless p[u] = u, in which case u is -either the source vertex or a vertex unreachable from the source). In -addition to these two options, the user can provide her own -custom-made visitor that can take actions at any of the -algorithm's event points. - -

- -

Parameters

- - -IN: EdgeListGraph& g -
- A directed or undirected graph whose type must be a model of - Edge List Graph. If a root vertex is - provided, then the graph must also model - Vertex List Graph.
- - Python: The parameter is named graph. -
- -IN: Size N -
- The number of vertices in the graph. The type Size must - be an integer type.
- Default: num_vertices(g).
- - Python: Unsupported parameter. -
- - -

Named Parameters

- -IN: weight_map(WeightMap w) -
- The weight (also know as ``length'' or ``cost'') of each edge in the - graph. The WeightMap type must be a model of Readable Property - Map. The key type for this property map must be the edge - descriptor of the graph. The value type for the weight map must be - Addable with the distance map's value type.
- Default: get(edge_weight, g)
- - Python: Must be an edge_double_map for the graph.
- Python default: graph.get_edge_double_map("weight") -
- -OUT: predecessor_map(PredecessorMap p_map) -
- The predecessor map records the edges in the minimum spanning - tree. Upon completion of the algorithm, the edges (p[u],u) - for all u in V are in the minimum spanning tree. If p[u] = - u then u is either the source vertex or a vertex that is - not reachable from the source. The PredecessorMap type - must be a Read/Write - Property Map which key and vertex types the same as the vertex - descriptor type of the graph.
- Default: dummy_property_map
- - Python: Must be a vertex_vertex_map for the graph.
-
- -IN/OUT: distance_map(DistanceMap d) -
- The shortest path weight from the source vertex to each vertex in - the graph g is recorded in this property map. The type - DistanceMap must be a model of Read/Write - Property Map. The key type of the property map must be the - vertex descriptor type of the graph, and the value type of the - distance map must be Less - Than Comparable.
Default: get(vertex_distance, - g)
- Python: Must be a vertex_double_map for the graph.
-
- -IN: root_vertex(Vertex s) -
- The starting (or "root") vertex from which shortest paths will be - computed. When provided, the distance map need not be initialized - (the algorithm will perform the initialization itself). However, the - graph must model Vertex List - Graph when this parameter is provided.
- Default: None; if omitted, the user must initialize the - distance map. -
- -IN: visitor(BellmanFordVisitor v) -
- The visitor object, whose type must be a model of - Bellman-Ford Visitor. - The visitor object is passed by value [1]. -
- Default: bellman_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the BellmanFordVisitor type - of the graph. - -
- -IN: distance_combine(BinaryFunction combine) -
- This function object replaces the role of addition in the relaxation - step. The first argument type must match the distance map's value - type and the second argument type must match the weight map's value - type. The result type must be the same as the distance map's value - type.
- Default:std::plus<D> - with D=typename property_traits<DistanceMap>::value_type.
- - Python: Unsupported parameter. -
- -IN: distance_compare(BinaryPredicate compare) -
- This function object replaces the role of the less-than operator - that compares distances in the relaxation step. The argument types - must match the distance map's value type.
- Default: std::less<D> - with D=typename property_traits<DistanceMap>::value_type.
- - Python: Unsupported parameter. -
- -

- -

Complexity

- -

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

Visitor Event Points

- - - -

Example

- -

-An example of using the Bellman-Ford algorithm is in examples/bellman-example.cpp. - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/bellman_visitor.html b/doc/bellman_visitor.html deleted file mode 100644 index 5912b1ff4..000000000 --- a/doc/bellman_visitor.html +++ /dev/null @@ -1,111 +0,0 @@ - - - -Boost Graph Library: bellman_visitor - -C++ Boost - -
- -

-
-bellman_visitor<EventVisitorList>
-
-

- -This class is an adapter that converts a list of EventVisitors (constructed using -std::pair) into a BellmanFordVisitor. - - -

Example

- - -

Model of

- -BellmanFordVisitor - -

Template Parameters

- -

- - - - - - - - - - -
ParameterDescriptionDefault
EventVisitorList -A list of EventVisitor's created -with std::pair. -null_visitor
- -

Where Defined

- -

- -boost/graph/bellman_ford_shortest_paths.hpp - -

Member Functions

- -This class implements all of the member functions required by BellmanFordVisitor. In each function the -appropriate event is dispatched to the EventVisitor in the EventVisitorList. - -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class EventVisitorList>
-bellman_visitor<EventVisitorList>
-make_bellman_visitor(EventVisitorList ev_list); -		 -Returns the event visitor list adapted to be a BellmanFordVisitor. -
- -

See Also

- -Visitor concepts -

-The following are event visitors: predecessor_recorder, -distance_recorder -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/betweenness_centrality.html b/doc/betweenness_centrality.html deleted file mode 100644 index 0932eb21f..000000000 --- a/doc/betweenness_centrality.html +++ /dev/null @@ -1,307 +0,0 @@ - - - - - Boost Graph Library: Brandes' Betweenness Centrality - - - - C++ Boost -

(Python)brandes_betweenness_centrality

- -

- 

-// named parameter versions
-template<typename Graph, typename Param, typename Tag, typename Rest>
-void
-brandes_betweenness_centrality(const Graph& g,
-                               const bgl_named_params<Param,Tag,Rest>& params);
-
-template<typename Graph, typename CentralityMap>
-void
-brandes_betweenness_centrality(const Graph& g, CentralityMap centrality_map);
-
-template<typename Graph, typename CentralityMap, typename EdgeCentralityMap>
-void
-brandes_betweenness_centrality(const Graph& g, CentralityMap centrality_map,
-                               EdgeCentralityMap edge_centrality);
-
-// non-named parameter versions
-template<typename Graph, typename CentralityMap, typename EdgeCentralityMap,
-         typename IncomingMap, typename DistanceMap, typename DependencyMap,
-         typename PathCountMap, typename VertexIndexMap>
-void
-brandes_betweenness_centrality(const Graph& g, CentralityMap centrality_map,
-                               EdgeCentralityMap edge_centrality,
-                               IncomingMap incoming,
-                               DistanceMap distance, DependencyMap dependency,
-                               PathCountMap path_count,
-                               VertexIndexMap vertex_index);
-
-template<typename Graph, typename CentralityMap, typename EdgeCentralityMap,
-         typename IncomingMap, typename DistanceMap, typename DependencyMap,
-         typename PathCountMap, typename VertexIndexMap, typename WeightMap>
-void
-brandes_betweenness_centrality(const Graph& g, CentralityMap centrality_map,
-                               EdgeCentralityMap edge_centrality,
-                               IncomingMap incoming,
-                               DistanceMap distance,  DependencyMap dependency,
-                               PathCountMap path_count,
-                               VertexIndexMap vertex_index,
-                               WeightMap weight_map);
-
-// helper functions
-template<typename Graph, typename CentralityMap>
-void
-relative_betweenness_centrality(const Graph& g, CentralityMap centrality_map);
-
-template<typename Graph, typename CentralityMap>
-typename property_traits<CentralityMap>::value_type
-central_point_dominance(const Graph& g, CentralityMap centrality_map);
-
- -

This algorithm [54] -computes the betweenness centrality [55,56] of each vertex or each -edge in the graph. The betweenness centrality of a vertex v -is defined by - -

, - -

where is the number of shortest paths from -vertex s to vertex t and -is the number of shortest paths from vertex s to vertex -t that pass through vertex v. - - - -

The edge betweenness centrality indicates for each edge the -betweenness centrality that was contributed to the target(s) of the -edge (plural for undirected graphs). Similar to (vertex) betweenness -centrality, edge betweenness centrality can be used to determine the -edges through which most shortest paths must pass. A single invocation -of this algorithm can compute either the vertex or edge centrality (or -both).

- -

This algorithm can operate either on weighted graphs (if a suitable -edge weight map is supplied) or unweighted graphs (if no edge weight -map is supplied). The result is the absolute betweenness centrality; -to convert to the relative betweenness centrality, which scales each -absolute centrality by -(where n is the number of vertices in the graph), use -relative_betweenness_centrality. Given the relative -betweenness centrality, one can compute the central point -dominance [55], which is a measure of the maximum "betweenness" of any -point in the graph: it will be 0 for complete graphs and -1 for "wheel" graphs (in which there is a central vertex that all -paths include; see Fig. 1). Let be the vertex with the largest relative betweenness centrality; then, the central point dominance is defined as: - -

- - - -

- - - - - - - - - - -
Fig. 1: A wheel graph, where every path travels through the central node.
The central point dominance of this graph is 1. -
- -

Where Defined

-boost/graph/betweenness_centrality.hpp - -

Parameters

-IN: const Graph& g -
- The graph object on which the algorithm will be applied. The type - Graph must be a model of Vertex List Graph and Incidence Graph. When an edge - centrality map is supplied, it must also model Edge List Graph.
- -Python: The parameter is named graph. -
- -UTIL: IncomingMap incoming -
- This property map records the set of edges incoming to each vertex that comprise a shortest path from a particular source vertex through this vertex, and is used internally by the algorithm.The IncomingMap type must be a Lvalue Property - Map whose key type is the same as the vertex descriptor type of - the graph and whose value type is a Sequence (e.g., an - std::vector) containing edge descriptors.
- - Default: - iterator_property_map created from a - std::vector of std::vector<Edge>, where - Edge is the edge descriptor type of the graph.
- - Python: Unsupported parameter. -
- -UTIL: DistanceMap distance_map -
- The shortest path weight from each source vertex s to each - vertex in the graph g is recorded in this property map, but - the result is only used internally. The type DistanceMap - must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the distance map. The value type of the - distance map is the element type of a Monoid.
- - Default: - iterator_property_map created from a - std::vector of the WeightMap's value type (or the - vertices_size_type of the graph when no weight map exists) - of size num_vertices(g) and using the vertex_index for - the index map.
- - Python: Unsupported parameter. -
- -UTIL: DependencyMap dependency -
- Property map used internally to accumulate partial betweenness - centrality results. The type DependencyMap must be a model - of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the dependency map. The value type of - the dependency map must be compatible with the value type of the - centrality map.
- - Default: - iterator_property_map created from a - std::vector of the CentralityMap's value type of - size num_vertices(g) and using the vertex_index - for the index map.
- - Python: Unsupported parameter. -
- -UTIL: PathCountMap path_count -
- Property map used internally to accumulate the number of paths that - pass through each particular vertex. The type PathCountMap - must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the dependency map. The value type of - the dependency map must be an integral type large enough to store - the number of paths in the graph.
- - Default: - iterator_property_map created from a - std::vector of the degree_size_type of the graph of - size num_vertices(g) and using the vertex_index - for the index map.
- - Python: Unsupported parameter. -
- -

Named parameters

-OUT/UTIL: CentralityMap centrality_map -
- This property map is used to accumulate the betweenness centrality - of each vertex, and is the primary output of the algorithm. The type - CentralityMap must be a model of Read/Write - Property Map, with the graph's vertex descriptor type as its key - type. The value type of this property map should be a floating-point - or rational type.
- - Default: a dummy_property_map, which requires no - work to compute and returns no answer.
- Python: The color map must be a vertex_double_map for - the graph.
- Python default: graph.get_vertex_double_map("centrality") -
- -OUT/UTIL: EdgeCentralityMap edge_centrality_map -
- This property map is used to accumulate the betweenness centrality - of each edge, and is a secondary form of output for the - algorithm. The type EdgeCentralityMap must be a model of Read/Write - Property Map, with the graph's edge descriptor type as its key - type. The value type of this property map should be the same as the - value type of the CentralityMap property map.
- - Default: a dummy_property_map, which requires no - work to compute and returns no answer.
- Python: The color map must be a edge_double_map for - the graph.
- Python default: graph.get_edge_double_map("centrality") -
- -IN: vertex_index_map(VertexIndexMap vertex_index) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure when an edge is relaxed. 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 - usable as the key type of the map.
- Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- Python: Unsupported parameter. -
- -IN: weight_map(WeightMap w_map) -
- The weight or ``length'' of each edge in the graph. The weights - must all be non-negative, and the algorithm will throw a - negative_edge - exception is one of the edges is negative. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for this map must be - the same as the value type of the distance map.
- Default: All edge weights are assumed to be equivalent. - Python: If supplied, must be an edge_double_map for the graph. -
- -

Complexity

-The time complexity is O(VE) for unweighted graphs and -O(VE + V(V+E) log V) for weighted graphs. The space complexity -is O(VE). - -
- - - -
Copyright © 2004 -Douglas Gregor, Indiana University (dgregor@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- -Last modified: Tue Mar 1 14:14:51 EST 2005 - - diff --git a/doc/bfs_visitor.html b/doc/bfs_visitor.html deleted file mode 100644 index 24750da81..000000000 --- a/doc/bfs_visitor.html +++ /dev/null @@ -1,128 +0,0 @@ - - - -Boost Graph Library: bfs_visitor - -C++ Boost - -
- -

-
-bfs_visitor<EventVisitorList>
-
-

- -This class is an adapter that converts a list of EventVisitors (constructed using -std::pair) into a BFSVisitor. - - -

Example

- -This is an excerpt from examples/bfs.cpp where three -event-visitors are combined to make a BFS visitor. The functions -boost::record_distances, boost::record_predecessors, -and copy_graph are all functions that create an event -visitor. - -
-  // Construct graph G and obtain the source vertex s ...
-
-  boost::breadth_first_search(G, s,
-   boost::make_bfs_visitor(
-    std::make_pair(boost::record_distances(d, boost::on_tree_edge()),
-    std::make_pair(boost::record_predecessors(p.begin(),
-                                              boost::on_tree_edge()),
-                   copy_graph(G_copy, boost::on_examine_edge())))) );
-
- - -

Model of

- -BFSVisitor - -

Template Parameters

- -

- - - - - - - - - - -
ParameterDescriptionDefault
EventVisitorList -A list of EventVisitor's created -with std::pair. -null_visitor
- -

Where Defined

- -

- -boost/graph/breadth_first_search.hpp - -

Member Functions

- -This class implements all of the member functions required by BFSVisitor. In each function the -appropriate event is dispatched to the EventVisitor in the EventVisitorList. - -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class EventVisitorList>
-bfs_visitor<EventVisitorList>
-make_bfs_visitor(EventVisitorList ev_list); -		 -Returns the event visitor list adapted to be a BFS visitor. -
- -

See Also

- -Visitor concepts -

-The following are event visitors: predecessor_recorder, -distance_recorder, -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/bgl-cover.jpg b/doc/bgl-cover.jpg deleted file mode 100644 index 684b81c03..000000000 Binary files a/doc/bgl-cover.jpg and /dev/null differ diff --git a/doc/bgl_named_params.html b/doc/bgl_named_params.html deleted file mode 100644 index e0da11699..000000000 --- a/doc/bgl_named_params.html +++ /dev/null @@ -1,96 +0,0 @@ - - - -Boost Graph Library: Named Parameters - -C++ Boost - -
- -

-
-bgl_named_params<Param, Type, Rest>
-
-

- -

-Many of the Boost.Graph algorithms have a long list of parameters, -most of which have default values. This causes several problems. -First, C++ does not provide a mechanism for handling default -parameters of template functions. However, this can be overcome by -creating multiply version of an algorithm with different numbers of -parameters with each version providing defaults for some subset of -the parameters. This is the approach used in previous versions of -Boost.Graph. This solution is still unsatisfactory for several -reasons: - -

- -

-A better solution is provided by bgl_named_params. This class -allows users to provide parameters is any order, and matches -arguments to parameters based on parameter names. - -

-The following code shows an example of calling -bellman_ford_shortest_paths using the named parameter -technique. Each of the arguments is passed to a function whose name -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),
-     boost::weight_map(weight).
-     distance_map(&distance[0]).
-     predecessor_map(&parent[0]));
-
- -

The order in which the arguments are provided does not matter as -long as they are matched with the correct parameter function. Here is -an call to bellman_ford_shortest_paths that is equivalent to -the one above. - -

-  bool r = boost::bellman_ford_shortest_paths(g, int(N),
-     boost::predecessor_map(&parent[0]).
-     distance_map(&distance[0]).
-     weight_map(weight));
-
- -

Typically the user never needs to deal with the -bgl_named_params class directly, since there are functions -like boost::weight_map that create an instance of -bgl_named_params. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/bibliography.html b/doc/bibliography.html deleted file mode 100644 index e79333f52..000000000 --- a/doc/bibliography.html +++ /dev/null @@ -1,472 +0,0 @@ - - - -Boost Graph Library: Bibliography - -C++ Boost - -
- - -

Bibliography

- -

1 -
-A. V. Aho, J. E. Hopcroft, and J. D. Ullman. -
Data Structures and Algorithms. -
Addison-Wesley, 1983. - -

2 -
-M. H. Austern. -
Generic Programming and the STL. -
Professional computing series. Addison-Wesley, 1999. - -

3 -
-G. Baumgartner and V. F. Russo. -
Signatures: A language extension for improving type abstraction and - subtype polymorphism in C++. -
Software-Practice and Experience, 25(8):863-889, August 1995. - -

4 -
-R. Bellman. -
On a routing problem. -
Quarterly of Applied Mathematics, 16(1):87-90, 1958. - -

5 -
-K. B. Bruce, L. Cardelli, G. Castagna, the Hopkins Objects Group, G. T. - Leavens, and B. Pierce. -
On binary methods. -
Theory and Practice of Object Systems, 1:221-242, 1995. - -

6 -
-T. F. Coleman, B. S. Garbow, and J. J. Mor'e. -
Algorithm 649: Fortran subroutines for estimating sparse hessian - matrices. -
ACM Transactions on Mathematical Software, 11(4):378, December - 1985. - -

7 -
-T. F. Coleman and J. J. Mor'e. -
Estimation of sparse jacobian matrices and graph coloring problems. -
SIAM Journal on Numerical Analysis, 20:187-209,, 1984. - -

8 -
-T. Cormen, C. Leiserson, and R. Rivest. -
Introduction to Algorithms. -
McGraw-Hill, 1990. - -

9 -
-A. Curtis, M. Powell, and J. Reid. -
On the estimation of sparse jacobian matrices. -
Journal of the Institute of Mathematics and its Applications, - 13:117-119, 1974. - -

10 -
-E. Dijkstra. -
A note on two problems in connexion with graphs. -
Numerische Mathematik, 1:269-271, 1959. - -

11 -
-L. R. Ford and D. R. Fulkerson. -
Flows in networks. -
Princeton University Press, 1962. - -

12 -
-E. Gamma, R. Helm, R. Johnson, and J. Vlissides. -
Design Patterns: Elements of Reusable Object-Oriented Software. -
Professional Computing. Addison-Welsey, 1995. - -

13 -
-A. George, J. R. Gilbert, and J. W. Liu, editors. -
Graph Theory and Sparse Matrix Computation. -
Springer-Verlag New York, Inc, 1993. - -

14 -
-A. George and J. W.-H. Liu. -
Computer Solution of Large Sparse Positive Definite Systems. -
Computational Mathematics. Prentice-Hall, 1981. - -

15 -
-R. Graham and P. Hell. -
On the history of the minimum spanning tree problem. -
Annals of the History of Computing, 7(1):43-57, 1985. - -

16 -
-P. E. Hart, N. J. Nilsson, and B. Raphael. -
A formal basis for the heuristic determination of minimum cost paths. -
IEEE Transactions on Systems Science and Cybernetics, - 4(2):100-107, 1968. - -

18 -
-J. B. Kruskal. -
On the shortest spanning subtree of a graph and the traveling - salesman problem. -
In Proceedings of the American Mathematical Sofiety, volume 7, - pages 48-50, 1956. - -

19 -
-D. Kühl. -
Design patterns for the implementation of graph algorithms. -
Master's thesis, Technische Universität Berlin, July 1996. - -

20 -
-E. L. Lawler. -
Combinatorial Opimization: Networks and Matroids. -
Holt, Rinehart, and Winston, 1976. - -

21 -
-J. W. H. Liu. -
Modification of the minimum-degree algorithm by multiple elimination. -
ACM Transaction on Mathematical Software, 11(2):141-153, 1985. - -

22 -
-K. Mehlhorn and S. Näher. -
The LEDA Platform of Combinatorial and Geometric Computing. -
Cambridge University Press, 1999. - -

23 -
-B. Meyer. -
Object-oriented Software Construction. -
Prentice Hall International Series in Computer Science. Prentice - Hall, 1988. - -

24 -
-N. C. Myers. -
Traits: a new and useful template technique. -
C++ Report, June 1995. - -

25 -
-R. Prim. -
Shortest connection networks and some generalizations. -
Bell System Technical Journal, 36:1389-1401, 1957. - -

26 -
-Y. Saad. -
Iterative Methods for Sparse Minear System. -
PWS Publishing Company, 1996. - -

27 -
-R. E. Tarjan. -
Data Structures and Network Algorithms. -
Society for Industrial and Applied Mathematics, 1983. - -

28 -
-Seymour Parter. -
The use of linear graphs in Gauss elimination. -
SIAM Review, 1961 3:119-130. - -

29 -
-D. Matula, G. Marble, and J. Isaacson -
Graph coloring algorithms in Graph Theory and -Computing.
-Academic Press, pp.104-122, 1972. - -

30 -
-M.R. Garey and D.S. Johnson
-Computers and Intractibility: A Guide to the Theory of -NP-Completeness
-W.H. Freeman, New York, 1979. - -

31 -
D. Welsch and M. B. Powel
-An upper bound for the chromatic number of a graph and its -application to timetabling problems -Computer Journal, 10:85-86, 1967. - -

32 -
D. Br'elaz
-New methods to color the vertices of a graph
-Communications of the ACM, vol. 22, 1979, pp. 251-256. - -

33 -
G. Heber, R. Biswas, G.R. Gao
-Self-Avoiding Walks over Adaptive Unstructured Grids
-Parallel and Distributed Processing, LNCS 1586, -Springer-Verlag, 1999, pp. 968-977 - - -

34 -
Esmond G. Ng amd Padma Raghavan
-Performance of greedy ordering heuristics for sparse {C}holesky factorization
-SIAM Journal on Matrix Analysis and Applications (To appear) - -

35 -
Alan George and Joseph W. H. Liu
-The Evolution of the Minimum Degree Ordering Algorithm
-SIAM Review, March 1989, vol. 31, num. 1, pp. 1-19. - -

36 -
L. R. Ford and D. R. Fulkerson
-Maximal flow through a network.
-Can. Journal of Mathematics 1956 pp.399-404 - -

37 -
A. V. Goldberg
-A New Max-Flow Algorithm.
-MIT Tehnical report MIT/LCS/TM-291, 1985. - -

38 -
A. V. Karzanov
-Determining the maximal flow in a network by the method of preflows.
-Sov. Math. Dokl. 1974 - -

39 -
Ravindra K. Ahuja and Thomas L. Magnanti and James B. Orlin
-Network Flows: Theory, Algorithms, and Applications.
-Prentice Hall, 1993. - -

40 -
Jack Edmonds and Richard M. Karp
-Theoretical improvements in the algorithmic efficiency for network flow problems.
-Journal of the ACM, 1972 19:248-264 - -

41 -
Robert E. Tarjan
-Depth first search and linear graph algorithms.
-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. - -

43 -
E. Cuthill and J. McKee
-Reducing the bandwidth of sparse symmetric matrices.
-Proceedings of the 24th National Conference of the ACM, 1969. - -

44 -
J. Liu and A. Sherman
-Comparative analysis of the Cuthill-Mckee and the reverse -Cuthill-Mckee ordering algorithms for sparse matrices.
-SIAM Journal of Numerical Analysis. 13 (1975), pp. 198-213. - -

45 -
Alan George
-Computer implementation of the finite element method
-Technical Report STAN-CS-208, Stanford University (1971). - -

46 -
Scott Fortin
-The Graph Isomorphism Problem
-TR 96-20, Dept. of Computer Science, University of Alberta (1996) - -

47 -
Brendan D. McKay
-Practical Graph Isomorphism
-Congressus Numerantium (1981) - -

48 -
Reingold, Nievergelt, and Deo
-Combinatorial Algorithms: Theory and Practice
-Prentice Hall (1977) - -

49 -
Edward Moore
-The shortest path through a maze
-International Symposium on the Theory of Switching (1959)
-Harvard University Press - -

50 -
E. Nuutila
-Efficient transitive closure computation in large digraphs
-PhD Thesis, Helsinki University of Technology, 1995.
-Acta Polytechnica Scandinavica, Mathematics and Computing in -Engineering Series, No. 74. - -

51 -
A. Goralcikova and V. Koubek
-A reduct and closure algorithm for graphs
-In Mathematical Foundations of Computer Science,
-volume 74 of Lecture Notes in Computer Science, pages 301-307.
-Springer-Verlag, 1979 - -

52 -
Klaus Simon
-An Improved Algorithm for Transitive Closure on Acyclic Digraphs
-Theoretical Computer Science 58
-Automata, Languages and Programming, 376-386, 1986 - -

53 -
P. Purdom
-A Transitive Closure Algorithm
-BIT, 10, 1970, pp. 76-94. - -

54 -
Ulrik Brandes
-A - Faster Algorithm for Betweenness Centrality
-Journal of Mathematical Sociology 25 (2):163-177, 2001. - -

55 -
Lindon C. Freeman
-A Set of Measures of Centrality Based on Betweenness
-Sociometry 40, pp. 35-41, 1977. - -

56 -
J.M. Anthonisse
-The rush in a directed graph.
-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. - -

58 -
T. Fruchterman and E. Reingold
- Graph drawing by force-directed placement.
-Software--Practice & Experience, 21 (11), pp. 1129-1164, 1991. - -

59 -
Thomas F. Coleman and Jorge J. More
- Estimation of sparse Jacobian - matrices and graph coloring problems.
- Journal of Numerical Analasis V20, pp. 187-209, 1983. - -

60 -
Attila Gürsoy and Murat Atun
- Neighborhood Preserving Load Balancing: A Self-Organizing Approach -
- Euro-Par Parallel Processing, LNCS 1900, pp. 324-41, 2000. - -

61 -
James R. Driscoll, Harold N. Gabow, Ruth Shrairman, and Robert E. Tarjan
- Relaxed Heaps: An alternative for Fibonacci Heaps with applications to parallel computation.
- Communications of the ACM, 31 (11), pp. 1343-1354, November 1988. - -

62 -
King, I. P.
-An automatic reordering scheme for simultaneous equations derived from network analysis.
-Int. J. Numer. Methods Engrg. 2, pp. 523-533, 1970. - -

63 -
C. Palmer and J. Steffan
-Generating Network Topologies That Obey Power Laws
-Proceedings of GLOBECOM. November, 2000. - -

64 -
J. Edmonds
-Paths, trees, and flowers
-Canadian Journal of Mathematics 17 (1965), pp. 449-467. - -

65 -
Thomas Lengauer and Robert Endre Tarjan
-A fast algorithm for finding dominators in a flowgraph
-ACM Transactions on Programming Language and Systems, 1(1):121-141, 1979. - -

66 -
Steven S. Muchnick
-Advanced Compiler Design and Implementation
-Morgan Kaufmann Publishers, San Fransisco, 1997. - -

67 -
Andrew W. Appel
-Modern Compiler Implementation in JAVA
-Cambridge University Press, 1998. - -

68 -
Vladimir Kolmogorov
-Graph Based Algorithms for Scene Reconstruction from Two or More Views
-PhD thesis, Cornell University, September 2003. - -

69 -
Yuri Boykov and Vladimir Kolmogorov
- An Experimental Comparison of Min-Cut/Max-Flow Algorithms for Energy Minimization in Vision
- In IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 26, no. 9, pp. 1124-1137, Sept. 2004. - -

70 -
John M. Boyer and Wendy J. Myrvold
- -On the Cutting Edge: Simplified O(n) Planarity by Edge Addition -
-Journal of Graph Algorithms and Applications, 8(2): 241-273, 2004. - -

71 -
M. Chrobak, T. Payne
- -A Linear-time Algorithm for Drawing a Planar Graph on the Grid -
-Information Processing Letters 54: 241-246, 1995. - -

72 -
H. de Fraysseix, J. Pach, R. Pollack
- -How to Draw a Planar Graph on a Grid -
-Combinatorica 10: 41-51, 1990. - -

73 -
-David Bruce Wilson -
Generating random spanning trees more quickly than the cover time. -ACM Symposium on the Theory of Computing, pp. 296-303, 1996. - -

74 -
J. Edmonds
-Maximum Matching and a Polyhedron with 0, 1-Vertices
-Journal of Research of the National Bureau of Standards B 69, pp. 125-130, 1965. - -

75 -
Harold N. Gabow
-An Efficient Implementation of Edmonds' Algorithm for Maximum Matching on Graphs
-Journal of the ACM (JACM), 23(2): 221-234, 1976. - -

76 -
Harold N. Gabow
-Data Structures for Weighted Matching and Nearest Common Ancestors with Linking
-Proceedings of the First Annual ACM-SIAM Symposium on Discrete Algorithms, pp. 434-443, 1990. - -

77 -
Zvi Galil
-Efficient Algorithms for Finding Maximum Matching in Graphs
-ACM Computing Surveys (CSUR), 18(1), 23-38, 1986. - -
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/biconnected_components.html b/doc/biconnected_components.html deleted file mode 100644 index 894e984cc..000000000 --- a/doc/biconnected_components.html +++ /dev/null @@ -1,263 +0,0 @@ - - - -Boost Graph Library: Biconnected Components and Articulation Points - -C++ Boost - -
- -

- -(Python) -biconnected_components - - -and -articulation_points -

- -
-// named parameter version
-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,
-                       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,
-                       const bgl_named_params<P, T, R>& params)
-
-template <typename Graph, typename OutputIterator,
-          typename P, typename T, typename R>
-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,
-                       DiscoverTimeMap discover_time, LowPointMap lowpt);
-
-template <typename Graph, typename ComponentMap, typename OutputIterator>
-std::pair<std::size_t, OutputIterator>
-biconnected_components(const Graph& g, ComponentMap comp, OutputIterator out);
-
-template <typename Graph, typename ComponentMap>
-std::size_t biconnected_components(const Graph& g, ComponentMap comp);
-
-template <typename Graph, typename OutputIterator>
-OutputIterator articulation_points(const Graph& g, OutputIterator out);
-
- -

-A connected graph is biconnected if the removal of any single -vertex (and all edges incident on that vertex) can not disconnect the -graph. More generally, the biconnected components of a graph are the -maximal subsets of vertices such that the removal of a vertex from a -particular component will not disconnect the component. Unlike -connected components, vertices may belong to multiple biconnected -components: those vertices that belong to more than one biconnected -component are called articulation points or, equivalently, -cut vertices. Articulation points are vertices whose removal -would increase the number of connected components in the graph. Thus, -a graph without articulation points is biconnected. The following -figure illustrates the articulation points and biconnected components -of a small graph: - -

- -

Vertices can be present in multiple biconnected components, but each -edge can only be contained in a single biconnected component. The -output of the biconnected_components algorithm records the -biconnected component number of each edge in the property map -comp. Articulation points will be emitted to the (optional) -output iterator argument to biconnected_components, or can be -computed without the use of a biconnected component number map via -articulation_points. These functions return the number of -biconnected components, the articulation point output iterator, or a -pair of these quantities, depending on what information was -recorded. - -

The algorithm implemented is due to Tarjan [41]. - -

Where Defined

- -

-boost/graph/biconnected_components.hpp - - -

Parameters

- -IN: const Graph& g -
-An undirected graph. The graph type must be a model of Vertex List Graph and Incidence Graph.
-Python: The parameter is named graph. -
- -OUT: ComponentMap c -
-The algorithm computes how many biconnected components are in the graph, -and assigning each component an integer label. The algorithm then -records which component each edge in the graph belongs to by -recording the component number in the component property map. The -ComponentMap type must be a model of Writable Property -Map. The value type should be an integer type, preferably the same -as the edges_size_type of the graph. The key type must be -the graph's edge descriptor type.
-Default: dummy_property_map.
- Python: Must be an edge_int_map for the graph.
- Python default: graph.get_edge_int_map("bicomponent") -
- -OUT: OutputIterator out -
-The algorithm writes articulation points via this output -iterator and returns the resulting iterator.
-Default: a dummy iterator that ignores values written to it.
- -Python: this parameter is not used in Python. Instead, both -algorithms return a Python list containing the articulation -points. -
- -

Named Parameters

- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - 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 - usable as the key type of the map.
- Default: get(vertex_index, g)
- - Python: Unsupported parameter. -
- -UTIL/OUT: discover_time_map(DiscoverTimeMap discover_time) -
- The discovery time of each vertex in the depth-first search. The - type DiscoverTimeMap must be a model of Read/Write - Property Map. The value type of the map must be an integer - type. The vertex descriptor type of the graph needs to be usable as - the key type of the map.
-Default: an - iterator_property_map created from a - std::vector of vertices_size_type of size - num_vertices(g) and using get(vertex_index, g) for - the index map.
- - Python: Unsupported parameter. -
- -UTIL/OUT: lowpoint_map(LowPointMap lowpt) -
- The low point of each vertex in the depth-first search, which is the - smallest vertex reachable from a given vertex with at most one back - edge. The type LowPointMap must be a model of Read/Write - Property Map. The value type of the map must be an integer - type. The vertex descriptor type of the graph needs to be usable as - the key type of the map.
-Default: an - iterator_property_map created from a - std::vector of vertices_size_type of size - num_vertices(g) and using get(vertex_index, g) for - the index map.
- - Python: Unsupported parameter. -
- -UTIL/OUT: predecessor_map(PredecessorMap p_map) -
- The predecessor map records the depth first search tree. - The PredecessorMap type - must be a Read/Write - Property Map whose key and value types are the same as the vertex - descriptor type of the graph.
- Default: an - iterator_property_map created from a - std::vector of vertex_descriptor of size - num_vertices(g) and using get(vertex_index, g) for - the index map.
- - Python: Must be a vertex_vertex_map for the graph.
-
- -IN: visitor(DFSVisitor vis) -
- A visitor object that is invoked inside the algorithm at the - event-points specified by the DFS - Visitor concept. The visitor object is passed by value [1].
Default: - dfs_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the DFSVisitor type of - the graph. -
- -

Complexity

- -

-The time complexity for the biconnected components and articulation -points algorithms -O(V + E). - -

- -

Example

- -

The file examples/biconnected_components.cpp -contains an example of calculating the biconnected components and -articulation points of an undirected graph. - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2004 -Jeremy Siek, Indiana -University (jsiek@osl.iu.edu)
-Doug Gregor, Indiana University -
- - - diff --git a/doc/biconnected_components.w b/doc/biconnected_components.w deleted file mode 100644 index df6c3c2b3..000000000 --- a/doc/biconnected_components.w +++ /dev/null @@ -1,387 +0,0 @@ -\documentclass[11pt]{report} - - -\usepackage[leqno]{amsmath} -\usepackage{amsfonts} -\usepackage{amssymb} -\usepackage{amsthm} -\usepackage{latexsym} -\usepackage{jweb} -\usepackage{times} -\usepackage{graphicx} -\usepackage[nolineno]{lgrind} - -\newif\ifpdf -\ifx\pdfoutput\undefined - \pdffalse -\else - \pdfoutput=1 - \pdftrue -\fi - -\ifpdf - \usepackage[ - pdftex, - colorlinks=true, % change to true for the electronic version - linkcolor=blue,filecolor=blue,pagecolor=blue,urlcolor=blue - ]{hyperref} - \newcommand{\myhyperref}[2]{\hyperref[#1]{#2}} -\fi - -\newcommand{\mtlfig}[2]{\centerline{\includegraphics*[#2]{#1.pdf}}} - -\newcommand{\Path}{\rightsquigarrow} -\newcommand{\ancestor}{\overset{T}{\rightsquigarrow}} -\newcommand{\descendant}{\ancestor^{-1}} -\newcommand{\backedge}{\overset{B}{\rightarrow}} -\newcommand{\edge}{\rightarrow} -\DeclareMathOperator{\suchthat}{s.t.} - -\newcommand{\code}[1]{{\small{\em \textbf{#1}}}} -\newcommand{\concept}[1]{\textsf{#1}} - -\begin{document} - -\title{An Implementation of Biconnected Components} -\author{Jeremy Siek} - -\maketitle - -\section{Introduction} - -This paper documents the implementation of the -\code{biconnected\_components()} function of the Boost Graph -Library. The function was implemented by Jeremy Siek. - -The algorithm used to implement the \code{biconnected\_components()} -function is the one based on depth-first search described -by Tarjan~\cite{tarjan72:dfs_and_linear_algo}. - -An undirected graph $G = (V,E)$ is \emph{biconnected} if for each -triple of distinct vertices $v, w, a \in V$ there is a path $p : v -\Path w$ such that $a$ is not on the path $p$. An \emph{articulation -point} of $G = (V,E)$ is a vertex $a \in V$ where there are two other -distinct vertices $v,w \in V$ such that $a$ is on any path $p:v \Path -w$ and there is at least one such path. If $a$ were to be removed from -$G$, then $v$ and $w$ would no longer be reachable from each other. -So articulation points act as bridges between biconnected components; -the only path from one biconnected component to another is through an -articulation point. - -The algorithm finds articulation points based on information provided -by depth-first search. During a DFS, we label each vertex $v \in G$ -with its discover time, denoted $d[v]$. During the DFS we also -compute the $lowpt(v)$, which is the smallest (in terms of discover -time) vertex reachable from $v$ by traversing zero or more DFS-tree -edges followed by at most one back edge. Tree edges and back edges can -be identified based on discover time because for tree edge $(u,v)$ we -have $d[u] < d[v]$ and for back edge $(u,v)$ we have $d[u] > -d[v]$. The $lowpt(v)$ is computed for $v$ by taking the minimum -$lowpt$ of the vertices to which $v$ is adjacent. The $lowpt(v)$ is -computed after the recursive DFS call so the $lowpt$ has already been -computed for the adjacent vertices by the time $lowpt(v)$ is computed. - -Now it turns out that $lowpt$ can be used to identify articulation -points. Suppose $a,v,w$ are distinct vertices in $G$ such that $(a,v)$ -is a tree edge and $w$ is not a descendant of $v$. If $d[lowpt(v)] -\geq d[a]$, then $a$ is an articulation point and removal of $a$ -disconnects $v$ and $w$. The reason this works is that if $d[lowpt(v)] -\geq d[a]$, then we know all paths starting from $v$ stay within the -sub-tree $T_v$ rooted at $v$. If a path were to escape from the -sub-tree, then consider the first vertex $w$ in that path outside of -$T_v$. $v \Path w$ must be considered for $lowpt(v)$, so $d[lowpt(v)] -< d[w]$. Now $d[w] < d[a]$ due the structure of the DFS, so -transitively $d[lowpt(v)] < d[a]$. - -\section{The Implementation} - -The implementation consists of a recursive DFS-like function named -\code{biconnect()} and the public interface function -\code{biconnected\-\_components()}. The \code{Graph} type must be a -model of \concept{VertexListGraph} and of \concept{IncidenceGraph}. -The result of the algorithm is recorded in the \code{ComponentMap}, -which maps edges to the biconnected component that they belong to -(components are labeled with integers from zero on up). The -\code{ComponentMap} type must be a model of -\concept{WritablePropertyMap}, which the graph's -\code{edge\-\_descriptor} type as the key type and an unsigned integer -type as the value type. We do not record which component each vertex -belongs to because vertices that are articulation points belong to -multiple biconnected components. The number of biconnected components -is returned in the \code{num\_components} parameter. The -\code{discover\_time} parameter is used internally to keep track of -the DFS discover time for each vertex. It must be a -\concept{ReadWritePropertyMap} with the graph's -\code{vertex\_\-descriptor} type as the key type and an unsigned -integer as the value type. The \code{lowpt} parameter is used -internally to keep track of the $d[lowpt(v)]$ for each vertex $v$. It -must be a \concept{ReadWritePropertyMap} with the graph's -\code{vertex\_\-descriptor} type is the key type and the value type is -the same unsigned integer type as the value type in the -\code{discover\-\_time} map. - -@d Biconnected Components Algorithm -@{ -namespace detail { - @ -} - -template -void biconnected_components - (typename graph_traits::vertex_descriptor v, - typename graph_traits::vertex_descriptor u, - const Graph& g, - ComponentMap comp, - std::size_t& num_components, - DiscoverTimeMap discover_time, - LowPointMap lowpt) -{ - typedef graph_traits::vertex_descriptor vertex_t; - typedef graph_traits::edge_descriptor edge_t; - @ - typedef typename property_traits::value_type D; - num_components = 0; - std::size_t dfs_time = 0; - std::stack S; - @ - @ -} -@} - -\noindent In the following code we use the Boost Concept Checking -Library to provide better error messages in the event that the user -makes a mistake in the kind of parameter used in the function -template. - -@d Concept checking of type parameters -@{ -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( IncidenceGraphConcept )); -BOOST_CONCEPT_ASSERT(( WritablePropertyMapConcept )); -BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept )); -BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept )); -@} - -The first step of the algorithm is to initialize the discover times of -all the vertices to infinity. This marks the vertices as undiscovered. - -@d Initialize discover times to infinity -@{ -typename graph_traits::vertex_iterator wi, wi_end; -std::size_t infinity = std::numeric_limits::max(); -for (tie(wi, wi_end) = vertices(g); wi != wi_end; ++wi) - put(discover_time, *wi, infinity); -@} - -\noindent Next we invoke \code{biconnect()} on every vertex in the -graph, making sure that all connected components within the graph are -searched (\code{biconnect()} only processes a single connected -component). - -@d Process each connected component -@{ -for (tie(wi, wi_end) = vertices(g); wi != wi_end; ++wi) - if (get(discover_time, *wi) == std::numeric_limits::max()) - detail::biconnect(*wi, *wi, true, - g, comp, num_components, - discover_time, dfs_time, lowpt, S); -@} - -The recursive \code{biconnect()} function is shown below. The -\code{v} parameter is where the DFS is started. The \code{u} -parameter is the parent of \code{v} in the DFS-tree if \code{at\_top -== false} or if \code{at\_top == true} the \code{u} is not used. -\code{S} is a stack of edges that is used to collect all edges in a -biconnected component. The way this works is that on ``the way down'' -edges are pushed into the stack. ``On the way back up'', when an -articulation point $v$ is found (identified because $d[lowpt(w)] \geq -d[v]$) we know that a contiguous portion of the stack (starting at the -top) contains the edges in the sub-tree $T_v$ which is the biconnected -component. We therefore pop these edges off of the stack (until we -find an edge $e$ where $d[lowpt(source(e))] < d[w]$) and mark them as -belonging to the same component. The code below also includes the -bookkeeping details such as recording the discover times and computing -$lowpt$. When a back edge $(v,w)$ is encountered, we do not use -$lowpt(w)$ in calculating $lowpt(v)$ since $lowpt(w)$ has not yet been -computed. Also, we ignore the edge $(v,w)$ if $w$ is the parent of $v$ -in the DFS-tree, meaning that $(w,v)$ has already been examined and -categorized as a tree edge (not a back edge). - -@d Recursive Biconnect Function -@{ -template -void biconnect(typename graph_traits::vertex_descriptor v, - typename graph_traits::vertex_descriptor u, - bool at_top, - const Graph& g, - ComponentMap comp, - std::size_t& c, - DiscoverTimeMap d, - std::size_t& dfs_time, - LowPointMap lowpt, - Stack& S) -{ - typedef typename graph_traits::vertex_descriptor vertex_t; - typedef typename property_traits::value_type D; - D infinity = std::numeric_limits::max(); - put(d, v, ++dfs_time); - put(lowpt, v, get(d, v)); - typename graph_traits::out_edge_iterator ei, ei_end; - for (tie(ei, ei_end) = out_edges(v, g); ei != ei_end; ++ei) { - vertex_t w = target(*ei, g); - if (get(d, w) == infinity) { - S.push(*ei); - biconnect(w, v, false, g, comp, c, d, dfs_time, lowpt, S); - put(lowpt, v, std::min(get(lowpt, v), get(lowpt, w))); - if (get(lowpt, w) >= get(d, v)) { - @ - } - } else if (get(d, w) < get(d, v) && (!at_top && w != u)) { - S.push(*ei); - put(lowpt, v, std::min(get(lowpt, v), get(d, w))); - } - } -} -@} - -\noindent The following is the code for popping the edges of sub-tree -$T_v$ off of the stack and recording them as being in the same -biconnected component. - -@d Record the biconnected component -@{ -while (d[source(S.top(), g)] >= d[w]) { - put(comp, S.top(), c); - S.pop(); -} -put(comp, S.top(), c); -S.pop(); -++c; -@} - - -\section{Appendix} - -@o biconnected-components.hpp -@{ -// Copyright (c) Jeremy Siek 2001 -// -// Permission to use, copy, modify, distribute and sell this software -// and its documentation for any purpose is hereby granted without fee, -// provided that the above copyright notice appears in all copies and -// that both that copyright notice and this permission notice appear -// in supporting documentation. Silicon Graphics makes no -// representations about the suitability of this software for any -// purpose. It is provided "as is" without express or implied warranty. - -// NOTE: this final is generated by libs/graph/doc/biconnected_components.w - -#ifndef BOOST_GRAPH_BICONNECTED_COMPONENTS_HPP -#define BOOST_GRAPH_BICONNECTED_COMPONENTS_HPP - -#include -#include -#include -#include -#include -#include - -namespace boost { - @ -} // namespace boost - -#endif BOOST_GRAPH_BICONNECTED_COMPONENTS_HPP -@} - -Figure~\ref{fig:bcc} shows the graph used in the following example and -the edges are labeled by biconnected component number, as computed by -the algorithm. - - -\begin{figure}[htbp] - \mtlfig{bcc}{width=3.0in} - \caption{The biconnected components.} - \label{fig:bcc} -\end{figure} - - -@o biconnected-components.cpp -@{ -#include -#include -#include -#include - -namespace boost { - struct edge_component_t { - enum { num = 555 }; - typedef edge_property_tag kind; - } edge_component; -} - -int main() -{ - using namespace boost; - typedef adjacency_list > graph_t; - typedef graph_traits::vertex_descriptor vertex_t; - graph_t g(9); - add_edge(0, 5, g); add_edge(0, 1, g); add_edge(0, 6, g); - add_edge(1, 2, g); add_edge(1, 3, g); add_edge(1, 4, g); - add_edge(2, 3, g); - add_edge(4, 5, g); - add_edge(6, 8, g); add_edge(6, 7, g); - add_edge(7, 8, g); - - std::size_t c = 0; - std::vector discover_time(num_vertices(g)); - std::vector lowpt(num_vertices(g)); - property_map::type - component = get(edge_component, g); - biconnected_components(0, 8, g, component, - c, &discover_time[0], &lowpt[0]); - - std::cout << "graph A {\n" - << " node[shape=\"circle\"]\n"; - - graph_traits::edge_iterator ei, ei_end; - for (tie(ei, ei_end) = edges(g); ei != ei_end; ++ei) - std::cout << source(*ei, g) << " -- " << target(*ei, g) - << "[label=\"" << component[*ei] << "\"]\n"; - std::cout << "}\n"; - - return 0; -} -@} - - - -% \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: - -% \begin{enumerate} - -% \item The subgraph $T$ containing the edges $v \rightarrow w$ is a -% spanning tree of $P$. - -% \item $\backedge \; \subseteq \descendant$. That is, each edge of $P$ -% that is not in $T$ connects a vertex to one of its ancestors in $T$. -% \end{enumerate} - - - -\bibliographystyle{abbrv} -\bibliography{jtran,ggcl,optimization,generic-programming,cad} - -\end{document} - -% LocalWords: Biconnected Siek biconnected Tarjan undirected DFS lowpt num dfs -% LocalWords: biconnect VertexListGraph IncidenceGraph ComponentMap namespace -% LocalWords: WritablePropertyMap ReadWritePropertyMap typename LowPointMap wi -% LocalWords: DiscoverTimeMap const comp typedef VertexListGraphConcept max ei -% LocalWords: IncidenceGraphConcept WritablePropertyMapConcept iterator bool -% LocalWords: ReadWritePropertyMapConcept hpp ifndef endif bcc cpp struct enum -% LocalWords: adjacency vecS undirectedS jtran ggcl diff --git a/doc/boyer_myrvold.html b/doc/boyer_myrvold.html deleted file mode 100644 index df4574f7c..000000000 --- a/doc/boyer_myrvold.html +++ /dev/null @@ -1,259 +0,0 @@ - - - -Boost Graph Library: Boyer-Myrvold Planarity Testing/Embedding - -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 -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 -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 -appear in the planar embedding. -
- -
-
-

-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 -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 -subgraph can be found if the graph is not planar. -boyer_myrvold_planarity_test uses named parameter arguments (courtesy -of the Boost.Parameter -library) to specify what the function actually does. Some examples are: - -

    -
  • Testing whether or not a graph is planar: -
    -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,
-                                 boyer_myrvold_params::kuratowski_subgraph = out_itr
-                                 )
-    )
-{
-  //do something with the embedding in embedding_pmap
-}
-else
-{
-  //do something with the kuratowski subgraph output to out_itr
-}
-
    -
- -

-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 -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 -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 -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 -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 -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 -kuratowski_subgraph argument is provided and this parameter is not -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. -
  • kuratowski_subgraph : If the graph is not planar, a minimal -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. - -

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. -

-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 -(such as -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 -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 -is_kuratowski_subgraph. - -

Where Defined

- -

- -boost/graph/boyer_myrvold_planar_test.hpp - - -

Parameters

- -IN: Graph& g - -
-Any undirected graph. The graph type must be a model of -VertexAndEdgeListGraph and -IncidenceGraph. -
- -OUT PlanarEmbedding embedding - -
-Must model the PlanarEmbedding concept. -
- -IN OutputIterator kuratowski_subgraph - -
-An OutputIterator which accepts values of the type -graph_traits<Graph>::edge_descriptor -
- -IN VertexIndexMap vm - -
-A Readable Property Map - that maps vertices from g to distinct integers in the range -[0, num_vertices(g) )
-Default: get(vertex_index,g)
-
- -IN EdgeIndexMap em - -
-A Readable Property Map - 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 -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 -(a graph with n = o(m)) - the running time will be O(n+m) -[2]. - -

Examples

- -

-

- -

See Also

- -Planar Graphs in the Boost Graph Library - - -

Notes

- -

[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 -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 -graph to boyer_myrvold_planarity_test. - - -
-

-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/boykov_kolmogorov_max_flow.html b/doc/boykov_kolmogorov_max_flow.html deleted file mode 100644 index ebcf8b851..000000000 --- a/doc/boykov_kolmogorov_max_flow.html +++ /dev/null @@ -1,395 +0,0 @@ - - - - - Boost Graph Library: Boykov-Kolmogorov Maximum Flow - - - - - - - - -

C++ Boost -

-

boykov_kolmogorov_max_flow -

-
// named parameter version
-template <class Graph, class P, class T, class R>
-typename property_traits<typename property_map<Graph, edge_capacity_t>::const_type>::value_type
-boykov_kolmogorov_max_flow(Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor src,
-   typename graph_traits<Graph>::vertex_descriptor sink,
-   const bgl_named_params<P, T, R>& params = all defaults)
-
-// non-named parameter version
-template <class Graph, class CapacityEdgeMap, class ResidualCapacityEdgeMap, class ReverseEdgeMap,
-          class PredecessorMap, class ColorMap, class DistanceMap, class IndexMap>
-typename property_traits<CapacityEdgeMap>::value_type
-boykov_kolmogorov_max_flow(Graph& g,
-       CapacityEdgeMap cap,
-       ResidualCapacityEdgeMap res_cap,
-       ReverseEdgeMap rev_map,
-       PredecessorMap pre_map,
-       ColorMap color,
-       DistanceMap dist,
-       IndexMap idx,
-       typename graph_traits <Graph>::vertex_descriptor src,
-       typename graph_traits <Graph >::vertex_descriptor sink)

-Additional overloaded versions for non-named parameters -are provided (without DistanceMap/ColorMap/DistanceMap; for those -iterator_property_maps with the provided index map are used)

-

The boykov_kolmogorov_max_flow() function calculates the maximum -flow of a network. See Section Network -Flow Algorithms for a description of maximum flow. The calculated -maximum flow will be the return value of the function. The function -also calculates the flow values f(u,v) for all (u,v) in -E, which are returned in the form of the residual capacity -r(u,v) = c(u,v) - f(u,v). -

-

Requirements:
The directed graph G=(V,E) that -represents the network must include a reverse edge for every edge in -E. That is, the input graph should be Gin = -(V,{E U ET}). The ReverseEdgeMap argument rev -must map each edge in the original graph to its reverse edge, that is -(u,v) -> (v,u) for all (u,v) in E. -

- -

Remarks: While the push-relabel method states that each edge in ET -has to have capacity of 0, the reverse edges for this algorithm ARE -allowed to carry capacities. If there are already reverse edges in -the input Graph G, -those can be used. This can halve the amount of edges and will -noticeably increase the performance.

- -

-Algorithm description:
The Boykov-Kolmogorov max-flow (or often -BK max-flow) algorithm is a variety of the augmenting-path algorithm. Standard -augmenting path algorithms find shortest paths from source to sink vertex and -augment them by subtracting the bottleneck capacity found on that path from the -residual capacities of each edge and adding it to the total flow. Additionally -the minimum capacity is added to the residual capacity of the reverse edges. If -no more paths in the residual-edge tree are found, the algorithm terminates. -Instead of finding a new shortest path from source to sink in the graph in each -iteration, the Boykov-Kolmogorov algorithm keeps the already found paths as -follows:

- -

The algorithm builds up two search trees, a source-tree and a -sink-tree. Each vertex has a label (stored in ColorMap) to -which tree it belongs and a status-flag if this vertex is active or -passive. In the beginning of the algorithm only the source and the -sink are colored (source==black, sink==white) and have active status. -All other vertices are colored gray. The algorithm consists of three -phases:

-

grow-phase: In this phase active vertices are allowed to -acquire neighbor vertices that are connected through an edge that has -a capacity-value greater than zero. Acquiring means that those vertices -become active and belong now to the search tree of the current -active vertex. If there are no more valid connections to neighbor -vertices, the current vertex becomes passive and the grow phase -continues with the next active vertex. The grow phase terminates if -there are no more active vertices left or a vertex discovers a vertex -from the other search tree through an unsaturated edge. In this case -a path from source to sink is found.

-

augment-phase: This phase augments the path that was found -in the grow phase. First it finds the bottleneck capacity of the -found path, and then it updates the residual-capacity of the edges -from this path by subtracting the bottleneck capacity from the -residual capacity. Furthermore the residual capacity of the reverse -edges are updated by adding the bottleneck capacity. This phase can -destroy the built up search trees, as it creates at least one -saturated edge. That means, that the search trees collapse to -forests, because a condition for the search trees is, that each -vertex in them has a valid (=non-saturated) connection to a terminal.

-

adoption-phase: Here the search trees are reconstructed. A -simple solution would be to mark all vertices coming after the first -orphan in the found path free vertices (gray). A more sophisticated -solution is to give those orphans new parents: The neighbor vertices -are checked if they have a valid connection to the same terminal like -this vertex had (a path with unsaturated edges). If there is one, -this vertex becomes the new parent of the current orphan and this -forest is re-included into the search tree. If no new valid parent is -found, this vertex becomes a free vertex (marked gray), and it's -children become orphans. The adoption phase terminates if there are -no more orphans.

-


Details:

-
    -

  • Marking heuristics: A timestamp is stored for each vertex - which shows in which iteration of the algorithm the distance to the - corresponding terminal was calculated. -

    -
      -

    • This distance is used and gets calculated in the - adoption-phase. In order to find a valid new parent for an orphan, - the possible parent is checked for a connection to the terminal to - which tree it belongs. If there is such a connection, the path is - tagged with the current time-stamp, and the distance value. If - another orphan has to find a parent and it comes across a vertex - with a current timestamp, this information is used.

      -

    • The distance is also used in the grow-phase. If a vertex - comes across another vertex of the same tree while searching for - new vertices, the other's distance is compared to its distance. If - it is smaller, that other vertex becomes the new parent of the - current. This can decrease the length of the search paths, and so - amount of adoptions.

      -
    -

  • Ordering of orphans: As described above, the augment-phase - and the adoption phase can create orphans. The orphans the - augment-phase generates, are ordered according to their distance to - the terminals (smallest first). This combined with the - distance/timestamp heuristics results in the possibility for not - having to recheck terminal-connections too often. New orphans which - are generated in adoption phase are processed before orphans from - the main queue for the same reason.

    -
-


Implementation notes:

-

The algorithm is mainly implemented as described by Boykov and Kolmogorov in -[69]. An extended version -can be found in the PhD Thesis of Kolmogorov [68]. -The following changes are made to improve performance:

-
    -
  • initialization: the algorithm first augments all paths from - source->sink and all paths from source->VERTEX->sink. This - improves especially graph-cuts used in image vision where nearly - each vertex has a source and sink connect. During this step, all - vertices that have an unsaturated connection from source are added - to the active vertex list and so the source is not.
    • -
  • active vertices: Boykov-Kolmogorov uses two lists for active nodes - and states that new active vertices are added to the rear of the - second. Fetching an active vertex is done from the beginning of the - first list. If the first list is empty, it is exchanged by the - second. This implementation uses just one list.
    • -
  • grow-phase: In the grow phase the first vertex in the - active-list is taken and all outgoing edges are checked if they are - unsaturated. This decreases performance for graphs with high-edge - density. This implementation stores the last accessed edge and - continues with it, if the first vertex in the active-list is the - same one as during the last grow-phase.
    • -
-

Where Defined

-

boost/graph/boykov_kolmogorov_max_flow.hpp -

-

Parameters

-

IN: Graph& g -

-
A directed graph. The graph's type must be a model of -Vertex List Graph, Edge -List Graph and Incidence Graph. -For each edge (u,v) in the graph, the reverse edge (v,u) -must also be in the graph. Performance of the algorithm will be slightly -improved if the graph type also models Adjacency -Matrix. -
-

IN: vertex_descriptor src -

-
The source vertex for the flow network graph. -
-

IN: vertex_descriptor sink -

-
The sink vertex for the flow network graph. -
-

Named Parameters

-

IN: edge_capacity(EdgeCapacityMap cap) -

-
The edge capacity property map. The type must be a model -of a constant Lvalue -Property Map. The key type of the map must be the graph's edge -descriptor type.
Default: get(edge_capacity, g) -
-

OUT: edge_residual_capacity(ResidualCapacityEdgeMap res) -

-
The edge residual capacity property map. The type must be -a model of a mutable Lvalue -Property Map. The key type of the map must be the graph's edge -descriptor type.
Default: get(edge_residual_capacity, -g) -
-

IN: edge_reverse(ReverseEdgeMap rev) -

-
An edge property map that maps every edge (u,v) in -the graph to the reverse edge (v,u). The map must be a model -of constant Lvalue -Property Map. The key type of the map must be the graph's edge -descriptor type.
Default: get(edge_reverse, g) -
-

UTIL: vertex_predecessor(PredecessorMap pre_map) -

-
A vertex property map that stores the edge to the vertex' -predecessor. The map must be a model of mutable Lvalue -Property Map. The key type of the map must be the graph's vertex -descriptor type.
Default: get(vertex_predecessor, g) -
-

OUT/UTIL: vertex_color(ColorMap color) -

-
A vertex property map that stores a color for edge -vertex. If the color of a vertex after running the algorithm is black -the vertex belongs to the source tree else it belongs to the -sink-tree (used for minimum cuts). The map must be a model of mutable -Lvalue Property -Map. The key type of the map must be the graph's vertex -descriptor type.
Default: get(vertex_color, g) -
-

UTIL: vertex_distance(DistanceMap dist) -

-
A vertex property map that stores the distance to the -corresponding terminal. It's a utility-map for speeding up the -algorithm. The map must be a model of mutable Lvalue -Property Map. The key type of the map must be the graph's vertex -descriptor type.
Default: get(vertex_distance, g) -
-

IN: vertex_index(VertexIndexMap index_map) -

-
Maps each vertex of the graph to a unique integer in the -range [0, num_vertices(g)). The map must be a model of -constant LvaluePropertyMap. -The key type of the map must be the graph's vertex descriptor -type.
Default: get(vertex_index, g) -
-

Example

-

This reads an example maximum flow problem (a graph with edge -capacities) from a file in the DIMACS format (example/max_flow.dat). -The source for this example can be found in -example/boykov_kolmogorov-eg.cpp. -

-
#include <boost/config.hpp>
-#include <iostream>
-#include <string>
-#include <boost/graph/adjacency_list.hpp>
-#include <boost/graph/boykov_kolmogorov_max_flow.hpp>
-#include <boost/graph/read_dimacs.hpp>
-#include <boost/graph/graph_utility.hpp>
-
-int
-main()
-{
-  using namespace boost;
-
-  typedef adjacency_list_traits < vecS, vecS, directedS > Traits;
-  typedef adjacency_list < vecS, vecS, directedS,
-    property < vertex_name_t, std::string,
-    property < vertex_index_t, long,
-    property < vertex_color_t, boost::default_color_type,
-    property < vertex_distance_t, long,
-    property < vertex_predecessor_t, Traits::edge_descriptor > > > > >,
-
-    property < edge_capacity_t, long,
-    property < edge_residual_capacity_t, long,
-    property < edge_reverse_t, Traits::edge_descriptor > > > > Graph;
-
-  Graph g;
-  property_map < Graph, edge_capacity_t >::type
-      capacity = get(edge_capacity, g);
-  property_map < Graph, edge_residual_capacity_t >::type
-      residual_capacity = get(edge_residual_capacity, g);
-  property_map < Graph, edge_reverse_t >::type rev = get(edge_reverse, g);
-  Traits::vertex_descriptor s, t;
-  read_dimacs_max_flow(g, capacity, rev, s, t);
-
-  std::vector<default_color_type> color(num_vertices(g));
-  std::vector<long> distance(num_vertices(g));
-  long flow = boykov_kolmogorov_max_flow(g ,s, t);
-
-  std::cout << "c  The total flow:" << std::endl;
-  std::cout << "s " << flow << std::endl << std::endl;
-
-  std::cout << "c flow values:" << std::endl;
-  graph_traits < Graph >::vertex_iterator u_iter, u_end;
-  graph_traits < Graph >::out_edge_iterator ei, e_end;
-  for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
-    for (boost::tie(ei, e_end) = out_edges(*u_iter, g); ei != e_end; ++ei)
-      if (capacity[*ei] > 0)
-        std::cout << "f " << *u_iter << " " << target(*ei, g) << " "
-          << (capacity[*ei] - residual_capacity[*ei]) << std::endl;
-
-  return EXIT_SUCCESS;
-}

-The output is: -

-
c  The total flow:
-s 13
-
-c flow values:
-f 0 6 3
-f 0 1 0
-f 0 2 10
-f 1 5 1
-f 1 0 0
-f 1 3 0
-f 2 4 4
-f 2 3 6
-f 2 0 0
-f 3 7 5
-f 3 2 0
-f 3 1 1
-f 4 5 4
-f 4 6 0
-f 5 4 0
-f 5 7 5
-f 6 7 3
-f 6 4 0
-f 7 6 0
-f 7 5 0

-See Also

-

-edmonds_karp_max_flow(), -push_relabel_max_flow(). -

-
- - - - - -
-

Copyright © 2006

- 		-

Stephan Diederich, University - Mannheim(diederich@ti.uni-manheim.de)

-
-



-

- - diff --git a/doc/breadth_first_search.html b/doc/breadth_first_search.html deleted file mode 100644 index 0608fc9ba..000000000 --- a/doc/breadth_first_search.html +++ /dev/null @@ -1,338 +0,0 @@ - - - -Boost Graph Library: Breadth-First Search - -C++ Boost - -
- -

-(Python) -breadth_first_search -

- -

-

-// 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,
-  const bgl_named_params<P, T, R>& params);
-
-// non-named parameter version
-template <class Graph, class Buffer, class BFSVisitor,
-	  class ColorMap>
-void breadth_first_search(const Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor s,
-   Buffer& Q, BFSVisitor vis, ColorMap color);
-
- - -

-The breadth_first_search() function performs a breadth-first -traversal [49] of a directed -or undirected graph. A breadth-first traversal visits vertices that -are closer to the source before visiting vertices that are further -away. In this context ``distance'' is defined as the number of edges -in the shortest path from the source vertex. The -breadth_first_search() function can be used to compute the -shortest path from the source to all reachable vertices and the -resulting shortest-path distances. For more definitions related to BFS -see section -Breadth-First Search. -

- -

-BFS uses two data structures to to implement the traversal: a color -marker for each vertex and a queue. White vertices are undiscovered -while gray vertices are discovered but have undiscovered adjacent -vertices. Black vertices are discovered and are adjacent to only other -black or gray vertices. The algorithm proceeds by removing a vertex -u from the queue and examining each out-edge (u,v). If an -adjacent vertex v is not already discovered, it is colored gray and -placed in the queue. After all of the out-edges are examined, vertex -u is colored black and the process is repeated. Pseudo-code for the -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
-  end for
-  color[s] := GRAY
-  d[s] := 0
-  ENQUEUE(Q, s)
-  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
-        ENQUEUE(Q, v)
-      else
-        if (color[v] = GRAY)
-          ...
-        else
-          ...
-    end for
-    color[u] := BLACK
-  end while
-  return (d, p)
-
-		 -
-
-initialize vertex u
-
-
-
-
-
-
-discover vertex s
-
-examine vertex u
-examine edge (u,v)
-(u,v) is a tree edge
-
-
-
-discover vertex v
-(u,v) is a non-tree edge
-
-(u,v) has a gray target
-
-(u,v) has a black target
-
-finish vertex u
-
-
- -The breadth_first_search() function can be extended with -user-defined actions that will be called a certain event points. The -actions must be provided in the form of a visitor object, that is, an -object who's type meets the requirements for a BFS Visitor. In the above pseudo-code, -the event points are the labels on the right. Also a description of -each event point is given below. By default, the -breadth_first_search() function does not carry out any -actions, not even recording distances or predecessors. However these -can be easily added using the distance_recorder and predecessor_recorder -event visitors. - - -

Where Defined

- -

-boost/graph/breadth_first_search.hpp - -

- -

Parameters

- -IN: Graph& g -
- A directed or undirected graph. The graph type must - be a model of Vertex List Graph - and Incidence Graph.
- - Python: The parameter is named graph. -
- -IN: vertex_descriptor s -
- The source vertex where the search is started.
- - Python: The parameter is named root_vertex. -
- - -

Named Parameters

- -IN: visitor(BFSVisitor vis) -
- A visitor object that is invoked inside the algorithm at the - event-points specified by the BFS - Visitor concept. The visitor object is passed by value [1].
Default: - bfs_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the BFSVisitor type of the graph. - -
- -UTIL/OUT: color_map(ColorMap color) -
- This is used by the algorithm to keep track of its progress through - the graph. The user need not initialize the color map before calling - breadth_first_search() since the algorithm initializes the - color of every vertex to white at the start of the algorihtm. If you - need to perform multiple breadth-first searches on a graph (for - example, if there are some disconnected components) then use the breadth_first_visit() - function and do your own color initialization. - -

The type ColorMap must be a model of Read/Write - Property Map and its key type must be the graph's vertex - descriptor type and the value type of the color map must model - ColorValue.
- Default: an - iterator_property_map created from a - std::vector of default_color_type of size - num_vertices(g) and using the i_map for the index - map.
- - Python: The color map must be a vertex_color_map for - the graph. -

- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This parameter is only necessary when the - default color property map is used. 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 usable as the key - type of the map.
- - Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- - Python: Unsupported parameter. -
- -UTIL: buffer(Buffer& Q) -
- The queue used to determine the order in which vertices will be - discovered. If a FIFO queue is used, then the traversal will - be according to the usual BFS ordering. Other types of queues - can be used, but the traversal order will be different. - For example Dijkstra's algorithm can be implemented - using a priority queue. The type Buffer must be a model of - Buffer.
The value_type - of the buffer must be the vertex_descriptor type for the graph.
- Default: boost::queue
- - Python: The buffer must derive from the Buffer type for the graph. - -
- - -

-Complexity -

- -

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

- -

Visitor Event Points

- -
    -
  • vis.initialize_vertex(v, g) is invoked on every vertex - 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. - -
  • vis.tree_edge(e, g) is invoked (in addition to - examine_edge()) if the edge is a tree edge. The - target vertex of edge e is discovered at this time. - -
  • 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. - -
  • vis.non_tree_edge(e, g) is invoked (in addition to - 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. - -
  • 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. - -
  • vis.finish_vertex(u, g) is invoked after all of the out - edges of u have been examined and all of the adjacent vertices - have been discovered. - -
- -

-Example -

- -

-The example in example/bfs-example.cpp -demonstrates using the BGL Breadth-first search algorithm on the graph -from Figure -6. The file -example/bfs-example2.cpp -contains the same example, except that the adacency_list -class used has VertexList and EdgeList set -to listS. -

- -

See Also

- -bfs_visitor and -depth_first_search() - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/breadth_first_visit.html b/doc/breadth_first_visit.html deleted file mode 100644 index e3feaa92d..000000000 --- a/doc/breadth_first_visit.html +++ /dev/null @@ -1,186 +0,0 @@ - - - -Boost Graph Library: Breadth-First Visit - -C++ Boost - -
- -

(Python) -breadth_first_visit -

- -

-

-  template <class IncidenceGraph, class P, class T, class R>
-  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,
-     Buffer& Q, BFSVisitor vis, ColorMap color)
-
- -This function is basically the same as breadth_first_search() -except that the color markers are not initialized in the -algorithm. The user is responsible for making sure the color for every -vertex is white before calling the algorithm. With this difference, -the graph type is only required to be an Incidence Graph instead of a Vertex List Graph. Also, this -difference allows for more flexibility in the color property map. For -example, one could use a map that only implements a partial function -on the vertices, which could be more space efficient when the search -only reaches a small portion of the graph. - -

Where Defined

- -

-boost/graph/breadth_first_search.hpp - - -

Parameters

- -IN: IncidenceGraph& g -
- A directed or undirected graph. The graph type must - be a model of Incidence Graph.
- - Python: The parameter is named graph. -
- -IN: vertex_descriptor s -
- The source vertex where the search is started.
- - Python: The parameter is named root_vertex. -
- - -

Named Parameters

- -IN: visitor(BFSVisitor vis) -
- A visitor object that is invoked inside the algorithm at the - event-points specified by the BFS - Visitor concept. The visitor object is passed by value [1].
Default: - bfs_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the BFSVisitor type of the graph. -
- -UTIL/OUT: color_map(ColorMap color) -
- This is used by the algorithm to keep track of its progress through - the graph. The type ColorMap must be a model of Read/Write - Property Map and its key type must be the graph's vertex - descriptor type and the value type of the color map must model - ColorValue.
- Default: get(vertex_color, g)
- - Python: The color map must be a vertex_color_map for - the graph. -
- -UTIL: buffer(Buffer& Q) -
- The queue used to determine the order in which vertices will be - discovered. If a FIFO queue is used, then the traversal will - be according to the usual BFS ordering. Other types of queues - can be used, but the traversal order will be different. - For example Dijkstra's algorithm can be implemented - using a priority queue. The type Buffer must be a model of - Buffer.
- Default: boost::queue
- - Python: The buffer must derive from the Buffer type for the graph. -
- - -

-Complexity -

- -

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

- -

Visitor Event Points

- -
    -
  • 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. - -
  • vis.tree_edge(e, g) is invoked (in addition to - examine_edge()) if the edge is a tree edge. The - target vertex of edge e is discovered at this time. - -
  • 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. - -
  • vis.non_tree_edge(e, g) is invoked (in addition to - 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. - -
  • 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. - -
  • vis.finish_vertex(u, g) is invoked after all of the out - edges of u have been examined and all of the adjacent vertices - have been discovered. - -
- -

See Also

- -breadth_first_search(), -bfs_visitor, and -depth_first_search() - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/build_antora.sh b/doc/build_antora.sh new file mode 100755 index 000000000..bdeda74f0 --- /dev/null +++ b/doc/build_antora.sh @@ -0,0 +1,30 @@ +#!/bin/bash +# +# Distributed under the Boost Software License, Version 1.0. (See accompanying +# file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +# +# Official repository: https://github.com/boostorg/graph +# +# Picked up by boostorg/release-tools' build_docs/{linuxdocs.sh,macosdocs.sh, +# windowsdocs.ps1} via auto-detection: presence of this file selects the +# Antora build pipeline. Output lands in doc/build/site/. + +set -xe + +SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd ) +cd "$SCRIPT_DIR" + +if [ $# -eq 0 ]; then + PLAYBOOK="playbook.yml" +else + PLAYBOOK="$1" +fi + +echo "Installing npm dependencies..." +npm ci + +echo "Building docs with Antora using $PLAYBOOK..." +PATH="$(pwd)/node_modules/.bin:${PATH}" +export PATH +npx antora --clean --fetch "$PLAYBOOK" +echo "Done" diff --git a/doc/build_example_outputs.sh b/doc/build_example_outputs.sh new file mode 100755 index 000000000..c764513e0 --- /dev/null +++ b/doc/build_example_outputs.sh @@ -0,0 +1,89 @@ +#!/usr/bin/env bash +# Compiles every .cpp under modules/ROOT/examples/ with -std=c++14, runs it, +# and writes stdout to a sibling .txt file that Antora pages can include. +# +# Usage: +# BOOST_INCLUDE=/path/to/boost/include \ +# BOOST_LIB=/path/to/boost/lib \ +# ./build_example_outputs.sh +# +# Defaults below match the Conan-installed Boost 1.79 layout used for +# local development. CI overrides them. + +set -u + +HERE=$(cd "$(dirname "$0")" && pwd) +REPO_ROOT=$(cd "$HERE/.." && pwd) +EXAMPLES_ROOT="$HERE/modules/ROOT/examples" + +: "${BOOST_INCLUDE:=$HOME/.conan/data/boost/1.79.0/_/_/package/2c7a64ca03ffe00ac4600bf373ea3ecf338b36d9/include}" +: "${BOOST_LIB:=}" +: "${CXX:=g++}" +: "${CXXFLAGS:=-std=c++14 -O1 -w}" + +if [ ! -d "$BOOST_INCLUDE" ]; then + echo "BOOST_INCLUDE not found: $BOOST_INCLUDE" >&2 + echo "Set BOOST_INCLUDE to the Boost include directory and re-run." >&2 + exit 1 +fi + +# Per-example link flags. A handful of examples need the prebuilt +# boost_graph library (graphviz, graphml readers and the isomorphism +# example pull in non-header-only code). +extra_libs_for() { + case "$1" in + io/graphml.cpp|io/graphviz.cpp|algorithms/isomorphism/isomorphism.cpp) + echo "-lboost_graph" + ;; + *) + echo "" + ;; + esac +} + +LDFLAGS="" +if [ -n "$BOOST_LIB" ]; then + LDFLAGS="-L$BOOST_LIB -Wl,-rpath,$BOOST_LIB" +fi + +WORK=$(mktemp -d) +trap 'rm -rf "$WORK"' EXIT + +ok=0 +fail=0 +fail_list="" + +while IFS= read -r src; do + rel=${src#"$EXAMPLES_ROOT/"} + out_txt=${src%.cpp}.txt + bin="$WORK/$(basename "$src" .cpp).out" + extra=$(extra_libs_for "$rel") + + if ! "$CXX" $CXXFLAGS \ + -I"$REPO_ROOT/include" -I"$BOOST_INCLUDE" \ + "$src" -o "$bin" $LDFLAGS $extra 2>/dev/null; then + printf ' [compile FAIL] %s\n' "$rel" + fail=$((fail + 1)) + fail_list+="$rel (compile)\n" + continue + fi + + if ! "$bin" > "$out_txt.tmp" 2>&1; then + printf ' [run FAIL] %s\n' "$rel" + rm -f "$out_txt.tmp" + fail=$((fail + 1)) + fail_list+="$rel (run)\n" + continue + fi + + mv "$out_txt.tmp" "$out_txt" + printf ' [OK] %s\n' "$rel" + ok=$((ok + 1)) +done < <(find "$EXAMPLES_ROOT" -name '*.cpp' | sort) + +echo +echo "Generated $ok .txt outputs, $fail failures." +if [ "$fail" -gt 0 ]; then + printf "Failing examples:\n$fail_list" + exit 1 +fi diff --git a/doc/bundles.html b/doc/bundles.html deleted file mode 100644 index 4b789b0a5..000000000 --- a/doc/bundles.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - -Bundled Properties - - - - -

Bundled Properties

- -

Class templates adjacency_list and -adjacency_matrix support -the introduction of named properties via internal -properties. However, this method is cumbersome in many uses, -where it would be more intuitive to just specify a structure or -class that contains internal properties for edges or -vertices. Bundled properties allow one to use -adjacency_list and adjacency_matrix in this -manner, providing a simple -way to introduce and access any number of internal properties -for vertices and edges.

- -

One can introduce bundled properties into an -either graph type by providing a user-defined class -type for the VertexProperties or -EdgeProperties template arguments. The user-defined -class may alternatively be placed at the end of a -property list, replacing the (implicit) -boost::no_property argument.

- -

Example: Route planning

-

Consider the implementation of a simple route planner that - should find the shortest directions from one city to another - via a set of highways. The vertices of the graph are cities, - and we may wish to store several bits of information about the - city within each vertex:

-
-struct City
-{
-  string name;
-  int population;
-  vector<int> zipcodes;
-};
-
- -

-The edges in the graph represent highways, which also have several interesting -attributes: -

- -
-struct Highway
-{
-  string name;
-  double miles;
-  int speed_limit;
-  int lanes;
-  bool divided;
-};
-
- -

With bundled properties, we can directly use the City and -Highway structures to define the graph:

-
-typedef boost::adjacency_list<
-    boost::listS, boost::vecS, boost::bidirectionalS,
-    City, Highway>
-  Map;
-
- -

Without bundled properties, translating this example directly -into an instantiation of adjacency_list would -involve several custom properties and would result in a type -like this:

-
-typedef boost::adjacency_list<
-    boost::listS, boost::vecS, boost::bidirectionalS,
-    // Vertex properties
-    boost::property<boost::vertex_name_t, std::string,
-    boost::property<population_t, int,
-    boost::property<zipcodes_t, std::vector<int> > > >,
-    // Edge properties
-    boost::property<boost::edge_name_t, std::string,
-    boost::property<boost::edge_weight_t, double,
-    boost::property<edge_speed_limit_t, int,
-    boost::property<edge_lanes_t, int,
-    boost::property<edge_divided, bool> > > > > >
-  Map;
-
- -

-Bundling vertex and edge properties greatly simplifies the declaration of -graphs. -

-

-In addition to vertex and edge bundles, we can also bundle properties of the -graph itself. Suppopse we extend the application to include a portfolio of -route-planning maps for different countries. In addition to the City -and Highway bundles above, we can declare a graph bundle, -Country. -

- -
-struct Country {
-  string name;
-  bool use_right;   // Drive on the left or right
-  bool use_metric;  // mph or km/h
-};
-
- -

The graph would now be declared as:

- -
-
-typedef boost::adjacency_list<
-    boost::listS, boost::vecS, boost::bidirectionalS,
-    City, Highway, Country>
-  Map;
-

-
- -

Accessing bundled properties

-

To access a bundled property for a particular edge or vertex, - subscript your graph with the descriptor of the edge or vertex - whose bundled property you wish to access. For instance:

-
-Map map; // load the map
-Map::vertex_descriptor v = *vertices(map).first;
-map[v].name = "Troy";
-map[v].population = 49170;
-map[v].zipcodes.push_back(12180);
-Map::edge_descriptor e = *out_edges(v, map).first;
-map[e].name = "I-87";
-map[e].miles = 10.;
-map[e].speed_limit = 65;
-map[e].lanes = 4;
-map[e].divided = true;
-
- -

-The graph bundle, since it does not correspond to a vertex or edge descripor -is accessed using the graph_bundle object as a key. -

- -
-map[graph_bundle].name = "United States";
-map[graph_bundle].use_right = true;
-map[graph_bundle].use_metric = false;
-
- - -

Properties maps from bundled properties

-

Often one needs to create a property map from an internal - property for use in a generic algorithm. For instance, using the - graph without bundled properties we might invoke Dijkstra's shortest - paths algorithm like this:

-
-vector<double> distances(num_vertices(map));
-dijkstra_shortest_paths(map, from,
-      weight_map(get(edge_length, map))
-      .distance_map(make_iterator_property_map(distances.begin(),
-                                               get(vertex_index, map))));
-
- -

With bundled properties, we can just pass a member pointer -as the property for get. The equivalent example using bundled -properties is:

-
-vector<double> distances(num_vertices(map));
-dijkstra_shortest_paths(map, from,
-      weight_map(get(&Highway::miles, map))
-      .distance_map(make_iterator_property_map(distances.begin(),
-                                               get(vertex_index, map))));
-
- -

The type of the returned property map is property_map<Map, double Highway::*>::type -or property_map<Map, double Highway::*>::const_type, depending on whether the graph -map is non-constant or constant. - -

You may also access the entire vertex or edge bundle as a property map -using the vertex_bundle or edge_bundle properties, -respectively. For instance, the property map returned by get(vertex_bundle, map) is -an Lvalue Property Map providing access to the -City values stored in each vertex. - -

Property maps for a graph bundle

-There is currently no support for creating property maps from the bundled -properties of a graph. - -

Getting the type of bundled properties

- -

To get the type of the vertex or edge bundle for a given graph -type Graph, you can use the trait -classes vertex_bundle_type -and edge_bundle_type. The -type vertex_bundle_type<Graph>::type will be the -type bundled with vertices (or no_vertex_bundle if the -graph supports bundles but no vertex bundle -exists). Likewise, edge_bundle_type<Graph>::type -will be the type bundled with edges (or no_edge_bundle if -no edge bundle exists).

- -

Compatibility

Bundled properties will only work -properly on compilers that support class template partial -specialization.

- -
-Copyright © 2004 Doug Gregor. -
- - -Last modified: Fri May 7 10:56:01 EDT 2004 - - - diff --git a/doc/challenge.html b/doc/challenge.html deleted file mode 100644 index 99659502e..000000000 --- a/doc/challenge.html +++ /dev/null @@ -1,120 +0,0 @@ - - - -Challenge - -C++ Boost - -
- - -

Boost Graph Library Challenge and To-Do Items

- - -
    - -
  • Dynamic graph algorithms such as described in Dynamic Graph -Algorithms and A Software -Library of Dynamic Graph Algorithms. - -
  • Polish up code/docs for pending items and champion the formal -review. The pending items are:
    • -
      -
    • container_traits.hpp (this should also include - the work Matt Austern is doing on this topic)
      • - -
    • The queues and heaps: queue.hpp, - mutable_queue.hpp, fibonacci_heap.hpp. - Somehow merge implementation with Dietmer's heaps and queues.
      • - -
    • disjoint_sets (see Disjoint Sets)
      • -
    - -
  • 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 -and sides (see below), not just to the edge as a whole.
      • -
    • 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 -polygons.
      • -
    • Given a polygon, find intersecting whatever...
      • -
    • Various minimum bounding rectangle and clipping problems.
      • -
    • Construct a planar embedding of a planar graph.
      • -
    • Find a balanced separator of a graph.
      • -
    • Modify adjacency_list so that the out-edges can be ordered - according to a user defined comparison object.
      • -
    - -
  • Rewrite the Qhull algorithm using the Boost Graph Library (this is -high difficulty challenge). Or, for a more manageable challenge, -write an interface for Qhull with the BGL. Qhull computes the -convex hull, Delaunay triangulation, Voronoi diagram, and halfspace -intersection about a point. Qhull runs in 2-d, 3-d, 4-d, and higher -dimensions. Qhull is used for collision detection, animation, plate -tectonics, 3-d modeling, robot motion planning, and other applications. -It is currently difficult to use from a C++ program. - -
    • - - -
  • Explore the use of Algorithm Objects as an alternative to - the current approach with visitors.
    • - -
  • Analyze the algorithms that do not yet have visitors, and - come up with visitor interfaces for them.
    • - -
  • Add a check in the adjacency_list class to make sure - all the vertex property template arguments have kind=vertex_property_tag - and all edge property template arguments have kind=edge_property_tag.
    • - -
  • Clean up the output functions in graph_utility.hpp to - use streams, and document all the utility functions. Replace - the random number stuff with calls to the boost random number generator.
    • - -
  • Modularize the tests in test/graph.cpp to apply to particular - concepts. Make sure there are run-time tests for every BGL concept.
    • - -
  • Write tests for the BGL algorithms. There are a few, but - more are needed. The example provide a sanity check but do not - provide full coverage.
    • - -
  • Write up the examples from Knuth's Stanford GraphBase using - the BGL. The file examples/miles_span.cpp - is a start.
    • - -
  • Further testing of the subgraph class and add more - features.
    • - -
  • Implement a minimum-cost maximum-flow algorithm.
    • - -
  • Make the type of all (internal) property maps convertible to the const_type of the property maps.
  • - -
  • Add static functions to adjacency_list to return the per-vertex, per-edge, and per-graph overhead.
    • -
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/circle_layout.html b/doc/circle_layout.html deleted file mode 100644 index 57f91cb9c..000000000 --- a/doc/circle_layout.html +++ /dev/null @@ -1,51 +0,0 @@ - -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. - -

Parameters

-IN: const VertexListGraph& g -
- The graph object on which the algorithm will be applied. The type - VertexListGraph must be a model of Vertex List Graph.
-Python: The parameter is named graph. -
- -OUT: PositionMap position -
- This property map is used to store the position of each vertex. The - type PositionMap must be a model of Writable Property - Map, with the graph's edge descriptor type as its key type. The - value type of this property map should be assignable from the - type Radius.
- - Python: The position map must be a vertex_point2d_map for - the graph.
- Python default: graph.get_vertex_point2d_map("position") -
- -IN: Radius radius -
- This is the radius of the circle on which points will be layed - out. It must be compatible with double.
-
- -

- - - -
Copyright © 2004 -Douglas Gregor, Indiana University (dgregor -at- cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums -at- osl.iu.edu) -
- diff --git a/doc/cochet-terrasson98numerical.pdf b/doc/cochet-terrasson98numerical.pdf deleted file mode 100644 index c0ec550ab..000000000 Binary files a/doc/cochet-terrasson98numerical.pdf and /dev/null differ diff --git a/doc/compressed_sparse_row.html b/doc/compressed_sparse_row.html deleted file mode 100644 index 37ff84930..000000000 --- a/doc/compressed_sparse_row.html +++ /dev/null @@ -1,971 +0,0 @@ - - - - - Compressed Sparse Row Graph - - - - - - - - - C++ Boost -

Compressed Sparse Row Graph

- -

The class template compressed_sparse_row_graph is - a graph class that uses the compact Compressed Sparse Row (CSR) - format to store directed (and bidirectional) graphs. While CSR graphs have - much less - overhead than many other graph formats (e.g., adjacency_list), they - do not provide any mutability: one cannot add or remove vertices - or edges from a CSR graph. Use this format in high-performance - applications or for very large graphs that you do not need to - change.

- -

The CSR format stores vertices and edges in separate arrays, - with the indices into these arrays corresponding to the identifier - for the vertex or edge, respectively. The edge array is sorted by - the source of each edge, but contains only the targets for the - edges. The vertex array stores offsets into the edge array, - providing the offset of the first edge outgoing from each - vertex. Iteration over the out-edges for the ith - vertex in the graph is achieved by - visiting edge_array[vertex_array[i]], - edge_array[vertex_array[i]+1], - ..., edge_array[vertex_array[i+1]]. This format minimizes - memory use to O(n + m), where n and m are the - number of vertices and edges, respectively. The constants - multiplied by n and m are based on the size of the - integers needed to represent indices into the edge and vertex - arrays, respectively, which can be controlled using - the template parameters. The - Directed template parameter controls whether one edge direction - (the default) or both directions are stored. A directed CSR graph has - Directed = directedS and a bidirectional CSR graph (with - a limited set of constructors) - has Directed = bidirectionalS.

- - - -

Synopsis

- - 
-namespace boost {
-
-template<typename Directed = directedS, typename VertexProperty = no_property,
-         typename EdgeProperty = no_property, typename GraphProperty = no_property,
-         typename Vertex = std::size_t, typename EdgeIndex = Vertex>
-class compressed_sparse_row_graph
-{
-public:
-  // Graph constructors
-  compressed_sparse_row_graph();
-
-  // Unsorted edge list constructors 
-  template<typename InputIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  template<typename InputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  template<typename MultiPassInputIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_multi_pass_t,
-                              MultiPassInputIterator edge_begin, MultiPassInputIterator edge_end,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  template<typename MultiPassInputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_multi_pass_t,
-                              MultiPassInputIterator edge_begin, MultiPassInputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  // New sorted edge list constructors (directed only)
-  template<typename InputIterator>
-  compressed_sparse_row_graph(edges_are_sorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              vertices_size_type numverts,
-                              edges_size_type numedges = 0,
-                              const GraphProperty& prop = GraphProperty());
-
-  template<typename InputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_sorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              edges_size_type numedges = 0,
-                              const GraphProperty& prop = GraphProperty());
-
-  // In-place unsorted edge list constructors (directed only)
-  template<typename InputIterator>
-  compressed_sparse_row_graph(construct_inplace_from_sources_and_targets_t,
-                              std::vector<vertex_descriptor>& sources,
-                              std::vector<vertex_descriptor>& targets,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  template<typename InputIterator>
-  compressed_sparse_row_graph(construct_inplace_from_sources_and_targets_t,
-                              std::vector<vertex_descriptor>& sources,
-                              std::vector<vertex_descriptor>& targets,
-                              std::vector<EdgeProperty>& edge_props,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-  // Miscellaneous constructors (directed only)
-  template<typename Graph, typename VertexIndexMap>
-  compressed_sparse_row_graph(const Graph& g, const VertexIndexMap& vi,
-                              vertices_size_type numverts,
-                              edges_size_type numedges);
-
-  template<typename Graph, typename VertexIndexMap>
-  compressed_sparse_row_graph(const Graph& g, const VertexIndexMap& vi);
-
-  template<typename Graph>
-  explicit compressed_sparse_row_graph(const Graph& g);
-
-  // Graph mutators (directed only)
-  template<typename Graph, typename VertexIndexMap>
-  void assign(const Graph& g, const VertexIndexMap& vi,
-              vertices_size_type numverts, edges_size_type numedges);
-
-  template<typename Graph, typename VertexIndexMap>
-  void assign(const Graph& g, const VertexIndexMap& vi);
-
-  template<typename Graph>
-  void assign(const Graph& g);
-
-  // Property Access
-  VertexProperty& operator[](vertex_descriptor v);
-  const VertexProperty& operator[](vertex_descriptor v) const;
-  EdgeProperty& operator[](edge_descriptor v);
-  const EdgeProperty& operator[](edge_descriptor v) const;
-};
-
-// Incidence Graph requirements
-vertex_descriptor source(edge_descriptor, const compressed_sparse_row_graph&);
-vertex_descriptor target(edge_descriptor, const compressed_sparse_row_graph&);
-std::pair<out_edge_iterator, out_edge_iterator>
-  out_edges(vertex_descriptor, const compressed_sparse_row_graph&);
-degree_size_type out_degree(vertex_descriptor v, const compressed_sparse_row_graph&);
-
-// Bidirectional Graph requirements (bidirectional only)
-std::pair<in_edge_iterator, in_edge_iterator>
-  in_edges(vertex_descriptor, const compressed_sparse_row_graph&);
-degree_size_type in_degree(vertex_descriptor v, const compressed_sparse_row_graph&);
-
-// Adjacency Graph requirements
-std::pair<adjacency_iterator, adjacency_iterator>
-  adjacent_vertices(vertex_descriptor, const compressed_sparse_row_graph&);
-
-// Vertex List Graph requirements
-std::pair<vertex_iterator, vertex_iterator> vertices(const compressed_sparse_row_graph&);
-vertices_size_type num_vertices(const compressed_sparse_row_graph&);
-
-// Edge List Graph requirements
-std::pair<edge_iterator, edge_iterator> edges(const compressed_sparse_row_graph&);
-edges_size_type num_edges(const compressed_sparse_row_graph&);
-
-// Vertex access
-vertex_descriptor vertex(vertices_size_type i, const compressed_sparse_row_graph&);
-
-// Edge access
-std::pair<edge_descriptor, bool>
-  edge(vertex_descriptor u, vertex_descriptor v, const compressed_sparse_row_graph&);
-edge_descriptor edge_from_index(edges_size_type i, const compressed_sparse_row_graph&);
-
-// Property map accessors
-template<typename PropertyTag>
-property_map<compressed_sparse_row_graph, PropertyTag>::type
-get(PropertyTag, compressed_sparse_row_graph& g)
-
-template<typename PropertyTag>
-property_map<compressed_sparse_row_graph, Tag>::const_type
-get(PropertyTag, const compressed_sparse_row_graph& g)
-
-template<typename PropertyTag, class X>
-typename property_traits<property_map<compressed_sparse_row_graph, PropertyTag>::const_type>::value_type
-get(PropertyTag, const compressed_sparse_row_graph& g, X x)
-
-template<typename PropertyTag, class X, class Value>
-void put(PropertyTag, const compressed_sparse_row_graph& g, X x, const Value& value);
-
-template<typename GraphPropertyTag>
-typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type&
-get_property(compressed_sparse_row_graph& g, GraphPropertyTag);
-
-template<typename GraphPropertyTag>
-typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type const &
-get_property(const compressed_sparse_row_graph& g, GraphPropertyTag);
-
-template<typename GraphPropertyTag>
-void set_property(const compressed_sparse_row_graph& g, GraphPropertyTag,
-                  const typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type& value);
-
-// Incremental construction functions
-(directed only)
-template<typename InputIterator, typename Graph>
-void add_edges(InputIterator first, InputIterator last, compressed_sparse_row_graph& g);
-
-(directed only)
-template<typename InputIterator, typename EPIter, typename Graph>
-void add_edges(InputIterator first, InputIterator last, EPIter ep_first, EPIter ep_last, compressed_sparse_row_graph& g);
-
-(directed only)
-template<typename BidirectionalIterator, typename Graph>
-void add_edges_sorted(BidirectionalIterator first, BidirectionalIterator last, compressed_sparse_row_graph& g);
-
-(directed only)
-template<typename BidirectionalIterator, typename EPIter, typename Graph>
-void add_edges_sorted(BidirectionalIterator first, BidirectionalIterator last, EPIter ep_iter, compressed_sparse_row_graph& g);
-
-} // end namespace boost
-
- -

Where Defined

-

<boost/graph/compressed_sparse_row_graph.hpp>

- -

Models

- -

The compressed_sparse_row_graph class template models - (i.e., implements the requirements of) many of the - BGL graph concepts, allowing it - to be used with most of the BGL algorithms. In particular, it - models the following specific graph concepts:

- - - -

Template Parameters

- -

The compressed_sparse_row_graph class has several - template parameters that can customize the layout in memory and - what properties are attached to the graph itself. All - parameters have defaults, so users interested only in the - structure of a graph can use the - type compressed_sparse_row_graph<> and ignore - the parameters.

- - Parameters -
-
- - Directed -
- A selector that determines whether the graph will be directed, - bidirectional or undirected. At this time, the CSR graph type - only supports directed and bidirectional graphs, so this value must - be either boost::directedS or - boost::bidirectionalS.
- Default: boost::directedS -
- - VertexProperty -
- A class type that will be - attached to each vertex in the graph. If this value - is void, no properties will be attached to - the vertices of the graph.
- Default: void -
- - EdgeProperty -
- A class type that will be attached to each edge in the graph. If - this value is void, no properties will be - attached to the edges of the graph.
- Default: void -
- - GraphProperty -
- A nested set - of property templates that describe the - properties of the graph itself. If this value - is no_property, no properties will be attached to - the graph.
- Default: no_property -
- - Vertex -
- An unsigned integral type that will be - used as both the index into the array of vertices and as the - vertex descriptor itself. Larger types permit the CSR graph to - store more vertices; smaller types reduce the storage required - per vertex.
- Default: std::size_t -
- - EdgeIndex -
- An unsigned integral type that will be used as the index into - the array of edges. As with the Vertex parameter, - larger types permit more edges whereas smaller types reduce - the amount of storage needed per - edge. The EdgeIndex type shall not be smaller - than the Vertex type, but it may be larger. For - instance, Vertex may be a 16-bit integer - (allowing 32,767 vertices in the graph) - whereas EdgeIndex could then be a 32-bit integer - to allow a complete graph to be stored in the CSR format.
- Default: Vertex -
- -

Interior Properties

- -

The compressed_sparse_row_graph allows properties to - be attached to its vertices, edges, or to the graph itself by way - of its template parameters. These - properties may be accessed via - the member - and non-member property - access functions, using the bundled - properties scheme.

- -

The CSR graph provides two kinds of built-in - properties: vertex_index, which maps from vertices to - values in [0, n) and edge_index, which maps - from edges to values in [0, m), where n - and m are the number of vertices and edges in the graph, - respectively.

- -

Member Functions

- -

Constructors

- 

-  compressed_sparse_row_graph();
-
-

Constructs a graph with no vertices or edges.

- -
- - 

-  template<typename InputIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
- -

- Constructs a graph with numverts vertices whose - edges are specified by the iterator range [edge_begin, - edge_end). The InputIterator must be a model of - InputIterator - whose value_type is an std::pair of - integer values. These integer values are the source and target - vertices for the edges, and must fall within the range [0, - numverts). The edges in [edge_begin, - edge_end) do not need to be sorted. This constructor uses extra - memory to save the edge information before adding it to the graph, - avoiding the requirement for the iterator to have multi-pass capability. -

- -

- The value prop will be used to initialize the graph - property. -

- -
- - 

-  template<typename InputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-

- This constructor constructs a graph with numverts - vertices and the edges provided in the iterator range - [edge_begin, edge_end). Its semantics are identical - to the edge range constructor, except - that edge properties are also initialized. The type - EdgePropertyIterator must be a model of the InputIterator - concept whose value_type is convertible to - EdgeProperty. The iterator range [ep_iter, ep_ter + - m) will be used to initialize the properties on the edges - of the graph, where m is distance from - edge_begin to edge_end. This constructor uses extra - memory to save the edge information before adding it to the graph, - avoiding the requirement for the iterator to have multi-pass capability. -

- -
- - 

-  template<typename MultiPassInputIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_multi_pass_t,
-                              MultiPassInputIterator edge_begin, MultiPassInputIterator edge_end,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
- -

- Constructs a graph with numverts vertices whose - edges are specified by the iterator range [edge_begin, - edge_end). The MultiPassInputIterator must be a model of - MultiPassInputIterator - whose value_type is an std::pair of - integer values. These integer values are the source and target - vertices for the edges, and must fall within the range [0, - numverts). The edges in [edge_begin, - edge_end) do not need to be sorted. Multiple passes will be made - over the edge range. -

- -

- The value prop will be used to initialize the graph - property. -

- -
- - 

-  template<typename MultiPassInputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_unsorted_multi_pass_t,
-                              MultiPassInputIterator edge_begin, MultiPassInputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-

- This constructor constructs a graph with numverts - vertices and the edges provided in the iterator range - [edge_begin, edge_end). Its semantics are identical - to the edge range constructor, except - that edge properties are also initialized. The type - EdgePropertyIterator must be a model of the MultiPassInputIterator - concept whose value_type is convertible to - EdgeProperty. The iterator range [ep_iter, ep_ter + - m) will be used to initialize the properties on the edges - of the graph, where m is distance from - edge_begin to edge_end. Multiple passes will be made - over the edge and property ranges. -

- -
- - 

-  template<typename InputIterator>
-  compressed_sparse_row_graph(edges_are_sorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              vertices_size_type numverts,
-                              edges_size_type numedges = 0,
-                              const GraphProperty& prop = GraphProperty());
-
- -

- Constructs a graph with numverts vertices whose - edges are specified by the iterator range [edge_begin, - edge_end). The argument of type edges_are_sorted_t is - a tag used to distinguish this constructor; the value - edges_are_sorted can be used to initialize this parameter. - The InputIterator must be a model of - InputIterator - whose value_type is an std::pair of - integer values. These integer values are the source and target - vertices for the edges, and must fall within the range [0, - numverts). The edges in [edge_begin, - edge_end) must be sorted so that all edges originating - from vertex i precede any edges originating from all - vertices j where j > i. -

- -

- The value numedges, if provided, tells how many - edges are in the range [edge_begin, edge_end) and - will be used to preallocate data structures to save both memory - and time during construction. -

- -

- The value prop will be used to initialize the graph - property. -

- -
- - 

-  template<typename InputIterator, typename EdgePropertyIterator>
-  compressed_sparse_row_graph(edges_are_sorted_t,
-                              InputIterator edge_begin, InputIterator edge_end,
-                              EdgePropertyIterator ep_iter,
-                              vertices_size_type numverts,
-                              edges_size_type numedges = 0,
-                              const GraphProperty& prop = GraphProperty());
-
-

- This constructor constructs a graph with numverts - vertices and the edges provided in the iterator range - [edge_begin, edge_end). Its semantics are identical - to the edge range constructor, except - that edge properties are also initialized. The type - EdgePropertyIterator must be a model of the InputIterator - concept whose value_type is convertible to - EdgeProperty. The iterator range [ep_iter, ep_ter + - m) will be used to initialize the properties on the edges - of the graph, where m is distance from - edge_begin to edge_end. -

- -
- - 

-  template<typename InputIterator>
-  compressed_sparse_row_graph(construct_inplace_from_sources_and_targets_t,
-                              std::vector<vertex_descriptor>& sources,
-                              std::vector<vertex_descriptor>& targets,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-

- This constructor constructs a graph with numverts vertices - and the edges provided in the two vectors sources and - targets. The two vectors are mutated in-place to sort them - by source vertex. They are returned with unspecified values, but do not - share storage with the constructed graph (and so are safe to destroy). - The parameter prop, if provided, is used to initialize the - graph property. -

- -
- - 

-  template<typename InputIterator>
-  compressed_sparse_row_graph(construct_inplace_from_sources_and_targets_t,
-                              std::vector<vertex_descriptor>& sources,
-                              std::vector<vertex_descriptor>& targets,
-                              std::vector<EdgeProperty>& edge_props,
-                              vertices_size_type numverts,
-                              const GraphProperty& prop = GraphProperty());
-
-

- This constructor constructs a graph with numverts vertices - and the edges provided in the two vectors sources and - targets. Edge properties are initialized from the vector - edge_props. The three vectors are mutated in-place to sort - them by source vertex. They are returned with unspecified values, but do - not share storage with the constructed graph (and so are safe to - destroy). The parameter prop, if provided, is used to - initialize the graph property. -

- -
- - 

-  template<typename Graph, typename VertexIndexMap>
-  compressed_sparse_row_graph(const Graph& g, const VertexIndexMap& vi,
-                              vertices_size_type numverts,
-                              edges_size_type numedges);
-
-  template<typename Graph, typename VertexIndexMap>
-  compressed_sparse_row_graph(const Graph& g, const VertexIndexMap& vi);
-
-  template<typename Graph>
-  explicit compressed_sparse_row_graph(const Graph& g);
-
- -

- Calls the assign function with - all of the arguments it is given. -

- -
- -

Mutators

- 

-  template<typename Graph, typename VertexIndexMap>
-  void assign(const Graph& g, const VertexIndexMap& vi,
-              vertices_size_type numverts, edges_size_type numedges);
-
-  template<typename Graph, typename VertexIndexMap>
-  void assign(const Graph& g, const VertexIndexMap& vi);
-
-  template<typename Graph>
-  void assign(const Graph& g);
-
- -

- Clears the CSR graph and builds a CSR graph in place from the - structure of another graph. The graph type Graph must - be a model of IncidenceGraph. - -
Parameters - -

    -
  • g: The incoming graph.
    • - -
  • vi: A map from vertices to indices. If not - provided, get(vertex_index, g) will be used.
    • - -
  • numverts: The number of vertices in the graph - g. If not provided, Graph must be a model of - VertexListGraph.
    • - -
  • numedges: The number of edges in the graph - g. If not provided, Graph must be a model of - EdgeListGraph.
    • -
-

- -
- -

Property Access

- - 

-  VertexProperty& operator[](vertex_descriptor v);
-  const VertexProperty& operator[](vertex_descriptor v) const;
-
- -

- Retrieves the property value associated with vertex - v. Only valid when VertexProperty is a class - type that is not no_property. -

- -
- - 

-  EdgeProperty& operator[](edge_descriptor v);
-  const EdgeProperty& operator[](edge_descriptor v) const;
-
- -

- Retrieves the property value associated with edge - v. Only valid when EdgeProperty is a class - type that is not no_property. -

- -
-

Non-member Functions

- -

Vertex access

- - 

-  vertex_descriptor vertex(vertices_size_type i, const compressed_sparse_row_graph&);
-
-

- Retrieves the ith vertex in the graph in - constant time. -

- -
- -

Edge access

- - 

-  std::pair<edge_descriptor, bool>
-    edge(vertex_descriptor u, vertex_descriptor v, const compressed_sparse_row_graph&);
-
- -

- If there exists an edge (u, v) in the graph, returns the - descriptor for that edge and true; otherwise, the - second value in the pair will be false. If multiple - edges exist from u to v, the first edge will - be returned; use out_edges and a - conditional statement - to retrieve all edges to a given target. This function requires linear - time in the - number of edges outgoing from u. -

- -
- - 

-  edge_descriptor edge_from_index(edges_size_type i, const compressed_sparse_row_graph&);
-
- -

- Returns the ith edge in the graph. This - operation requires logarithmic time in the number of vertices. -

- -
- -

Property Map Accessors

- - 

-template<typename PropertyTag>
-property_map<compressed_sparse_row_graph, PropertyTag>::type
-get(PropertyTag, compressed_sparse_row_graph& g)
-
-template<typename PropertyTag>
-property_map<compressed_sparse_row_graph, Tag>::const_type
-get(PropertyTag, const compressed_sparse_row_graph& g)
-
- -

- Returns the property map object for the vertex property - specified by PropertyTag. The PropertyTag must - be a member pointer to access one of the fields in - VertexProperty or EdgeProperty. -

- -
- - 

-template<typename PropertyTag, class X>
-typename property_traits<property_map<compressed_sparse_row_graph, PropertyTag>::const_type>::value_type
-get(PropertyTag, const compressed_sparse_row_graph& g, X x)
-
- -

- This returns the property value for x, where x - is either a vertex or edge descriptor. -

- -
- - 

-template<typename PropertyTag, class X, class Value>
-void put(PropertyTag, const compressed_sparse_row_graph& g, X x, const Value& value);
-
- -

- This sets the property value for x to - value. x is either a vertex or edge - descriptor. Value must be convertible to typename - property_traits<property_map<compressed_sparse_row_graph, - PropertyTag>::type>::value_type -

- -
- - 

-template<typename GraphPropertyTag>
-typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type&
-get_property(compressed_sparse_row_graph& g, GraphPropertyTag);
-
-template<typename GraphPropertyTag>
-typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type const &
-get_property(const compressed_sparse_row_graph& g, GraphPropertyTag);
-
- -

- Return the property specified by GraphPropertyTag that - is attached to the graph object g. -

- -
- - 

-template<typename GraphPropertyTag>
-void set_property(const compressed_sparse_row_graph& g, GraphPropertyTag,
-                  const typename graph_property<compressed_sparse_row_graph, GraphPropertyTag>::type& value);
-
- -

- Set the property specified by GraphPropertyTag that - is attached to the graph object g. -

- -
- -

Incremental construction functions

- - 

-template<typename InputIterator>
-void add_edges(InputIterator first, InputIterator last, compressed_sparse_row_graph& g)
-
- -

- Add a range of edges (from first to last) to the graph. - The InputIterator must be a model of InputIterator - whose value_type is an std::pair of integer - values. These integer values are the source and target vertices of the - new edges. The edges do not need to be sorted. -

- -
- - 

-template<typename InputIterator, typename EPIter>
-void add_edges(InputIterator first, InputIterator last, EPIter ep_first, EPIter ep_last, compressed_sparse_row_graph& g)
-
- -

- Add a range of edges (from first to last) with - corresponding edge properties (from ep_first to - ep_last) to the graph. The InputIterator and - EPIter must be models of InputIterator; - the value_type of InputIterator must be an - std::pair of integer values, and the value_type - of EPIter must be the edge property type of the graph. The - integer values produced by the InputIterator are the source and - target vertices of the new edges. The edges do not need to be sorted. -

- -
- - 

-template<typename BidirectionalIterator>
-void add_edges_sorted(BidirectionalIterator first, BidirectionalIterator last, compressed_sparse_row_graph& g)
-
- -

- Add a range of edges (from first to last) to the graph. - The BidirectionalIterator must be a model of BidirectionalIterator - whose value_type is an std::pair of integer - values. These integer values are the source and target vertices of the - new edges. The edges must be sorted in increasing order by source vertex - index. -

- -
- - 

-template<typename BidirectionalIterator, typename EPIter>
-void add_edges_sorted(BidirectionalIterator first, BidirectionalIterator last, EPIter ep_iter, compressed_sparse_row_graph& g)
-
- -

- Add a range of edges (from first to last) to the graph. - The BidirectionalIterator and EPIter must be models of - BidirectionalIterator. - The value_type of the BidirectionalIterator must be - an std::pair of integer - values. These integer values are the source and target vertices of the - new edges. - The value_type of the EPIter must be the edge - property type of the graph. - The edges must be sorted in increasing order by source vertex - index. -

- -
-

Example

- -
[libs/graph/example/csr-example.cpp] - -

We will use the compressed_sparse_row_graph graph - class to store a simple Web graph. In this web graph the vertices - represent web pages and the edges represent links from one web - page to another. With each web page we want to associate a URL, so - we initially create a WebPage class that stores the - URL. Then we can create our graph type by providing - WebPage as a parameter to the - compressed_sparse_row_graph class template.

- - 
-class WebPage
-{
- public:
-  std::string url;
-};
-
-// ...
-
-typedef compressed_sparse_row_graph<directedS, WebPage> WebGraph;
-WebGraph g(&the_edges[0], &the_edges[0] + sizeof(the_edges)/sizeof(E), 6);
-
- -

We can then set the properties on the vertices of the graph - using the bundled properties syntax, - and display the edges for the user.

- - 
-// Set the URLs of each vertex
-int index = 0;
-BGL_FORALL_VERTICES(v, g, WebGraph)
-  g[v].url = urls[index++];
-
-// Output each of the links
-std::cout << "The web graph:" << std::endl;
-BGL_FORALL_EDGES(e, g, WebGraph)
-  std::cout << "  " << g[source(e, g)].url << " -> " << g[target(e, g)].url
-            << std::endl;
-
- -

See the complete example - source for other operations one can perform with a - compressed_sparse_row_graph.

-
-
- - -
Copyright © 2005 -Doug Gregor, Indiana University ()
-Jeremiah Willcock, Indiana University ()
- Andrew Lumsdaine, -Indiana University () -
- - diff --git a/doc/connected_components.html b/doc/connected_components.html deleted file mode 100644 index f91a13789..000000000 --- a/doc/connected_components.html +++ /dev/null @@ -1,157 +0,0 @@ - - - -Boost Graph Library: Connected Components - -C++ Boost - -
- - -

- -(Python) -connected_components -

- -
-// named parameter version
-template <class VertexListGraph, class ComponentMap, class P, class T, class R>
-typename property_traits<ComponentMap>::value_type
-connected_components(VertexListGraph& G, ComponentMap comp,
-    const bgl_named_params<P, T, R>& params = all defaults);
-
-// there is not a non-named parameter version of this function
-
- -

-The connected_components() functions compute the connected -components of an undirected graph using a DFS-based approach. A -connected component of an undirected graph is a set of -vertices that are all reachable from each other. If the connected -components need to be maintained while a graph is growing the -disjoint-set based approach of function -incremental_components() is faster. For ``static'' graphs -this DFS-based approach is faster [8]. - -

-The output of the algorithm is recorded in the component property map -comp, which will contain numbers giving the component number -assigned to each vertex. The total number of components is the return -value of the function. - -

Where Defined

- -

-boost/graph/connected_components.hpp - - -

Parameters

- -IN: const Graph& g -
-An undirected graph. The graph type must be a model of Vertex List Graph and Incidence Graph.
- -Python: The parameter is named graph. -
- -OUT: ComponentMap c -
-The algorithm computes how many connected components are in the graph, -and assigning each component an integer label. The algorithm then -records which component each vertex in the graph belongs to by -recording the component number in the component property map. The -ComponentMap type must be a model of Writable Property -Map. The value type should be an integer type, preferably the same -as the vertices_size_type of the graph. The key type must be -the graph's vertex descriptor type.
- - Python: Must be an vertex_int_map for the graph.
- Python default: graph.get_vertex_int_map("component") -
- -

Named Parameters

- -UTIL: color_map(ColorMap color) -
- This is used by the algorithm to keep track of its progress through - the graph. The type ColorMap must be a model of Read/Write - Property Map and its key type must be the graph's vertex - descriptor type and the value type of the color map must model - ColorValue.
- Default: an - iterator_property_map created from a - std::vector of default_color_type of size - num_vertices(g) and using the i_map for the index - map.
- Python: The color map must be a vertex_color_map for - the graph. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This parameter is only necessary when the - default color property map is used. 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 usable as the key - type of the map.
- - Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- - Python: Unsupported parameter. -
- - -

Complexity

- -

-The time complexity for the connected components algorithm is also -O(V + E). - -

- -

See Also

- -strong_components() -and incremental_components() - -

Example

- -

-The file examples/connected_components.cpp -contains an example of calculating the connected components of an -undirected graph. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/constructing_algorithms.html b/doc/constructing_algorithms.html deleted file mode 100644 index d173ae197..000000000 --- a/doc/constructing_algorithms.html +++ /dev/null @@ -1,183 +0,0 @@ - - - -Boost Graph Library: Constructing Graph Algorithms - -C++ Boost - -
- -

Constructing graph algorithms with BGL

- -

-The main goal of BGL is not to provide a nice graph class, or -to provide a comprehensive set of reusable graph algorithms (though -these are goals). The main goal of BGL is to encourage others to -write reusable graph algorithms. By reusable we mean maximally -reusable. Generic programming is a methodology for making algorithms -maximally reusable, and in this section we will discuss how to apply -generic programming to constructing graph algorithms. - -

-To illustrate the generic programming process we will step though the -construction of a graph coloring algorithm. The graph coloring problem -(or more specifically, the vertex coloring problem) is to label each -vertex in a graph G with a color such that no two adjacent -vertices are labeled with the same color and such that the minimum -number of colors are used. In general, the graph coloring problem is -NP-complete, and therefore it is impossible to find an optimal -solution in a reasonable amount of time. However, there are many -algorithms that use heuristics to find colorings that are close to the -minimum. - -

-The particular algorithm we present here is based on the linear time -SEQ subroutine that is used in the estimation of sparse -Jacobian and Hessian matrices [9,7,6]. This algorithm -visits all of the vertices in the graph according to the order defined -by the input order. At each vertex the algorithm marks the colors of -the adjacent vertices, and then chooses the smallest unmarked color -for the color of the current vertex. If all of the colors are already -marked, a new color is created. A color is considered marked if its -mark number is equal to the current vertex number. This saves the -trouble of having to reset the marks for each vertex. The -effectiveness of this algorithm is highly dependent on the input -vertex order. There are several ordering algorithms, including the -largest-first [31], -smallest-last [29], and -incidence degree [32] algorithms, which -improve the effectiveness of this coloring algorithm. - -

-The first decision to make when constructing a generic graph algorithm -is to decide what graph operations are necessary for implementing the -algorithm, and which graph concepts the operations map to. In this -algorithm we will need to traverse through all of the vertices to -intialize the vertex colors. We also need to access the adjacent -vertices. Therefore, we will choose the VertexListGraph concept because it -is the minimum concept that includes these operations. The graph type -will be parameterized in the template function for this algorithm. We -do not restrict the graph type to a particular graph class, such as -the BGL adjacency_list, -for this would drastically limit the reusability of the algorithm (as -most algorithms written to date are). We do restrict the graph type to -those types that model VertexListGraph. This is enforced by -the use of those graph operations in the algorithm, and furthermore by -our explicit requirement added as a concept check with -BOOST_CONCEPT_ASSERT() (see Section Concept -Checking for more details about concept checking). - -

-Next we need to think about what vertex or edge properties will be -used in the algorithm. In this case, the only property is vertex -color. The most flexible way to specify access to vertex color is to -use the propery map interface. This gives the user of the -algorithm the ability to decide how they want to store the properties. -Since we will need to both read and write the colors we specify the -requirements as ReadWritePropertyMap. The -key_type of the color map must be the -vertex_descriptor from the graph, and the value_type -must be some kind of integer. We also specify the interface for the -order parameter as a property map, in this case a ReadablePropertyMap. For -order, the key_type is an integer offset and the -value_type is a vertex_descriptor. Again we enforce -these requirements with concept checks. The return value of this -algorithm is the number of colors that were needed to color the graph, -hence the return type of the function is the graph's -vertices_size_type. The following code shows the interface for our -graph algorithm as a template function, the concept checks, and some -typedefs. The implementation is straightforward, the only step not -discussed above is the color initialization step, where we set the -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,
-    Order order, Color color)
-  {
-    typedef graph_traits<VertexListGraph> GraphTraits;
-    typedef typename GraphTraits::vertex_descriptor vertex_descriptor;
-    typedef typename GraphTraits::vertices_size_type size_type;
-    typedef typename property_traits<Color>::value_type ColorType;
-    typedef typename property_traits<Order>::value_type OrderType;
-
-    BOOST_CONCEPT_ASSERT(( VertexListGraphConcept<VertexListGraph> ));
-    BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept<Color, vertex_descriptor> ));
-    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>
-      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;
-
-      // find the smallest color unused by the adjacent vertices
-      size_type smallest_color = 0;
-      while (smallest_color < max_color && mark[smallest_color] == i)
-        ++smallest_color;
-
-      // if all the colors are used up, increase the number of colors
-      if (smallest_color == max_color)
-        ++max_color;
-
-      color[current] = smallest_color;
-    }
-    return max_color;
-  }
-} // namespace boost
-
- -

- - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/copy_graph.html b/doc/copy_graph.html deleted file mode 100644 index 76483bb4d..000000000 --- a/doc/copy_graph.html +++ /dev/null @@ -1,116 +0,0 @@ - - - -Boost Graph Library: Copy Graph - -C++ Boost - -
- -

copy_graph

- -
-template <class VertexListGraph, class MutableGraph>
-void copy_graph(const VertexListGraph& G, MutableGraph& G_copy,
-    const bgl_named_params<P, T, R>& params = all defaults)
-
- -This function copies all of the vertices and edges from graph -G into G_copy. Also, it copies the vertex and edge -properties, either by using the vertex_all and -edge_all property maps, or by user-supplied copy functions. - -

Where Defined

- -

-boost/graph/copy.hpp - -

- -

Parameters

- -IN: const VertexListGraph& G -
-A directed or undirected graph. The graph type must be a model of Vertex List Graph. -
- -OUT: MutableGraph& G_copy -
-The resulting copy of the graph. The graph type must be a model of Mutable Graph. -
- -

Named Parameters

- -IN: vertex_copy(VertexCopier vc) -
-This is a Binary Function that copies the properties of a vertex in the original graph -into the corresponding vertex in the copy.
- -Default: vertex_copier<VertexListGraph, MutableGraph> -which uses the property tag vertex_all to access a property -map from the graph. -
- -IN: edge_copy(EdgeCopier ec) -
-This is a Binary Function that copies the properties of an edge in the original graph -into the corresponding edge in the copy.
- -Default: edge_copier<VertexListGraph, MutableGraph> -which uses the property tag edge_all to access a property -map from the graph. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
-The vertex index map type must be a model of Readable Property -Map and must map the vertex descriptors of G to the -integers in the half-open range [0,num_vertices(G)).
- -Default: get(vertex_index, G). -Note: if you use this default, make sure your graph has -an internal vertex_index property. For example, -adjacency_list with VertexList=listS does -not have an internal vertex_index property. -
- - -UTIL/OUT: orig_to_copy(Orig2CopyMap c) -
-This maps vertices in the original graph to vertices in the copy. - -Default: an - iterator_property_map created from a - std::vector of the output graph's vertex descriptor type of size - num_vertices(g) and using the i_map for the index - map. -
- -

Complexity

- -

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

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/cuthill_mckee_ordering.html b/doc/cuthill_mckee_ordering.html deleted file mode 100644 index 41c0c734c..000000000 --- a/doc/cuthill_mckee_ordering.html +++ /dev/null @@ -1,248 +0,0 @@ - - - - - -Boost Graph Library: Cuthill-Mckee Ordering - - -C++ Boost - -
- -

-(Python) -cuthill_mckee_ordering -

- - -

-

- - - - - - - - - - -
Graphs:undirected
Properties:color, degree
Complexity:time: O(m log(m)|V|) where m = max { degree(v) | v in V }
-
- - -
-  (1)
-  template <class IncidenceGraph, class OutputIterator,
-            class ColorMap, class DegreeMap>
-  OutputIterator
-  cuthill_mckee_ordering(const IncidenceGraph& g,
-                         typename graph_traits<IncidenceGraph>::vertex_descriptor s,
-                         OutputIterator inverse_permutation,
-                         ColorMap color, DegreeMap degree)
-
-  (2)
-  template <class VertexListGraph, class OutputIterator>
-  OutputIterator
-  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,
-            class ColorMap, class DegreeMap>
-  OutputIterator
-  cuthill_mckee_ordering(const VertexListGraph& g, OutputIterator inverse_permutation,
-                         ColorMap color, DegreeMap degree)
-
-  (3)
-  template <class IncidenceGraph, class OutputIterator,
-            class ColorMap, class DegreeMap>
-  OutputIterator
-  cuthill_mckee_ordering(const IncidenceGraph& g,
-    			 std::deque< typename
-			 graph_traits<IncidenceGraph>::vertex_descriptor > vertex_queue,
-                         OutputIterator inverse_permutation,
-                         ColorMap color, DegreeMap degree)
-
- -The goal of the Cuthill-Mckee (and reverse Cuthill-Mckee) ordering -algorithm[14, 43, 44, 45 ] is to reduce the bandwidth of a graph by reordering the -indices assigned to each vertex. The Cuthill-Mckee ordering algorithm -works by a local minimization of the i-th bandwidths. The vertices are -basically assigned a breadth-first search order, except that at each -step, the adjacent vertices are placed in the queue in order of -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 -for each component in the graph, increasing run time significantly. -

- -

-The output of the algorithm are the vertices in the new ordering. -Depending on what kind of output iterator you use, you can get either -the Cuthill-Mckee ordering or the reverse Cuthill-McKee ordering. For -example, if you store the output into a vector using the vector's -reverse iterator, then you get the reverse Cuthill-McKee ordering. -

- -
-  std::vector<vertex_descriptor> inv_perm(num_vertices(G));
-  cuthill_mckee_ordering(G, inv_perm.rbegin(), ...);
-
- -

-Either way, storing the output into a vector gives you the -permutation from the new ordering to the old ordering. -

- -
-  inv_perm[new_index[u]] == u
-
- -

-Often times, it is the opposite permutation that you want, the -permutation from the old index to the new index. This can easily be -computed in the following way. -

- -
-  for (size_type i = 0; i != inv_perm.size(); ++i)
-    perm[old_index[inv_perm[i]]] = i;
-
- - - -

Parameters

- -For version 1: - -
    - -
  • IncidenceGraph& g  (IN)
    - An undirected graph. The graph's type must be a model of IncidenceGraph.
    - Python: The parameter is named graph. - -
  • vertex_descriptor s  (IN)
    - The starting vertex.
    - Python: Unsupported parameter. - -
  • OutputIterator inverse_permutation  (OUT)
    - The new vertex ordering. The vertices are written to the output - iterator in their new order.
    - Python: This parameter is unused in Python. The new vertex - ordering is returned as a Python list. - -
  • ColorMap color_map  (WORK)
    - Used internally to keep track of the progress of the algorithm - (to avoid visiting the same vertex twice).
    - Python: Unsupported parameter. - -
  • DegreeMap degree_map  (IN)
    - This must map vertices to their degree.
    - Python: Unsupported parameter. -
- - -For version 2: - -
    - -
  • VertexListGraph& g  (IN)
    - An undirected graph. The graph's type must be a model of VertexListGraph and IncidenceGraph.
    - Python: The parameter is named graph. - -
  • - OutputIterator inverse_permutation  (OUT)
    - The new vertex ordering. The vertices are written to the - output iterator in their new order.
    - Python: This parameter is unused in Python. The new vertex - ordering is returned as a Python list. - -
  • ColorMap color_map  (WORK)
    - Used internally to keep track of the progress of the algorithm - (to avoid visiting the same vertex twice).
    - Python: Unsupported parameter. - -
  • DegreeMap degree_map  (IN)
    - This must map vertices to their degree.
    - Python: Unsupported parameter. -
- - -For version 3: - -
    - -
  • IncidenceGraph& g  (IN)
    - An undirected graph. The graph's type must be a model of IncidenceGraph.
    - Python: The parameter is named graph. - -
  • std::deque< typename graph_traits<Graph>::vertex_descriptor > vertex_queue  (IN)
    - The deque containing the starting vertices for each component.
    - Python: Unsupported parameter. - -
  • OutputIterator inverse_permutation  (OUT)
    - The new vertex ordering. The vertices are written to the output - iterator in their new order.
    - Python: This parameter is unused in Python. The new vertex - ordering is returned as a Python list. - -
  • ColorMap color_map  (WORK)
    - Used internally to keep track of the progress of the algorithm - (to avoid visiting the same vertex twice).
    - Python: Unsupported parameter. - -
  • DegreeMap degree_map  (IN)
    - This must map vertices to their degree.
    - Python: Unsupported parameter. -
- - - -

Example

- -See example/cuthill_mckee_ordering.cpp. - -

See Also

- -bandwidth, -and degree_property_map in boost/graph/properties.hpp. - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/cycle_canceling.html b/doc/cycle_canceling.html deleted file mode 100644 index cd7f0433e..000000000 --- a/doc/cycle_canceling.html +++ /dev/null @@ -1,223 +0,0 @@ - - - -Boost Graph Library: Cycle Canceling for Min Cost Max Flow - -C++ Boost - -
- -

-cycle_canceling -

- -
-// named parameter version
-template <class Graph, class P, class T, class R>
-void cycle_canceling(
-        Graph &g,
-        const bgl_named_params<P, T, R> & params  = all defaults)
-
-// non-named parameter version
-template <class Graph, class Pred, class Distance, class Reversed, class ResidualCapacity, class Weight>
-void cycle_canceling(const Graph & g, Weight weight, Reversed rev, ResidualCapacity residual_capacity, Pred pred, Distance distance)
-
- -

-The cycle_canceling() function calculates the minimum cost flow of a network with given flow. See Section Network -Flow Algorithms for a description of maximum flow. -For given flow values f(u,v) function minimizes flow cost in such a way, that for each v in V the - sum u in V f(v,u) is preserved. Particularly if the input flow was the maximum flow, the function produces min cost max flow. - - - The function calculates the flow values f(u,v) for all (u,v) in -E, which are returned in the form of the residual capacity -r(u,v) = c(u,v) - f(u,v). - -

-There are several special requirements on the input graph and property -map parameters for this algorithm. First, the directed graph -G=(V,E) that represents the network must be augmented to -include the reverse edge for every edge in E. That is, the -input graph should be Gin = (V,{E U -ET}). The ReverseEdgeMap argument rev -must map each edge in the original graph to its reverse edge, that is -(u,v) -> (v,u) for all (u,v) in E. -The WeightMap has to map each edge from ET to -weight of its reversed edge. -Note that edges from E can have negative weights. -

-If weights in the graph are nonnegative, the -successive_shortest_path_nonnegative_weights() -might be better choice for min cost max flow. - -

-The algorithm is described in Network Flows. - -

-In each round algorithm augments the negative cycle (in terms of weight) in the residual graph. -If there is no negative cycle in the network, the cost is optimized. - -

-Note that, although we mention capacity in the problem description, the actual algorithm doesn't have to now it. - -

-In order to find the cost of the result flow use: -find_flow_cost(). - - -

Where Defined

- -

-boost/graph/successive_shortest_path_nonnegative_weights.hpp - -

- -

Parameters

- -IN: Graph& g -
- A directed graph. The - graph's type must be a model of VertexListGraph and IncidenceGraph For each edge - (u,v) in the graph, the reverse edge (v,u) must also - be in the graph. -
- -

Named Parameters

- - -IN/OUT: residual_capacity_map(ResidualCapacityEdgeMap res) -
- This maps edges to their residual capacity. The type must be a model - of a mutable Lvalue Property - Map. The key type of the map must be the graph's edge descriptor - type.
- Default: get(edge_residual_capacity, g) -
- -IN: reverse_edge_map(ReverseEdgeMap rev) -
- An edge property map that maps every edge (u,v) in the graph - to the reverse edge (v,u). The map must be a model of - constant Lvalue - Property Map. The key type of the map must be the graph's edge - descriptor type.
- Default: get(edge_reverse, g) -
- -IN: weight_map(WeightMap w) -
- The weight (also know as ``length'' or ``cost'') of each edge in the - graph. The WeightMap type must be a model of Readable Property - Map. The key type for this property map must be the edge - descriptor of the graph. The value type for the weight map must be - Addable with the distance map's value type.
- Default: get(edge_weight, g)
-
- -UTIL: predecessor_map(PredEdgeMap pred) -
- Use by the algorithm to store augmenting paths. The map must be a - model of mutable Lvalue Property Map. - The key type must be the graph's vertex descriptor type and the - value type must be the graph's edge descriptor type.
- - Default: an - iterator_property_map created from a std::vector - of edge descriptors of size num_vertices(g) and - using the i_map for the index map. -
- -UTIL: distance_map(DistanceMap d_map) -
- The shortest path weight from the source vertex s to each - vertex in the graph g is recorded in this property map. The - shortest path weight is the sum of the edge weights along the - shortest path. The type DistanceMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the distance map. - - Default: - iterator_property_map created from a - std::vector of the WeightMap's value type of size - num_vertices(g) and using the i_map for the index - map.
- -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- Maps each vertex of the graph to a unique integer in the range - [0, num_vertices(g)). This property map is only needed - if the default for the distance or predecessor map is used. - The vertex index map must be a model of Readable Property - Map. The key type of the map must be the graph's vertex - descriptor type.
- Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- -

Complexity

-In the integer capacity and weight case, if C is the initial cost of the flow, then the complexity is O(C * |V| * |E|), -where O(|E|* |V|) is the complexity of the bellman ford shortest paths algorithm and C is upper bound on number of iteration. -In many real world cases number of iterations is much smaller than C. - - -

Example

- -The program in example/cycle_canceling_example.cpp. - - -

See Also

- -successive_shortest_path_nonnegative_weights()
-find_flow_cost(). - -
-
- - -
Copyright © 2013 -Piotr Wygocki, University of Warsaw (wygos at mimuw.edu.pl) -
- - - - - - - - - - - - diff --git a/doc/dag_shortest_paths.html b/doc/dag_shortest_paths.html deleted file mode 100644 index baa2d319c..000000000 --- a/doc/dag_shortest_paths.html +++ /dev/null @@ -1,326 +0,0 @@ - - - -Boost Graph Library: Directed Acyclic Graph Shortest Paths - -C++ Boost - -
- -

-(Python) -dag_shortest_paths -

- - -

-

-// named paramter version
-template <class VertexListGraph, class Param, class Tag, class Rest>
-void dag_shortest_paths(const VertexListGraph& g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   const bgl_named_params<Param,Tag,Rest>& params)
-
-// non-named parameter version
-template <class VertexListGraph, class DijkstraVisitor,
-	  class DistanceMap, class WeightMap, class ColorMap,
-	  class PredecessorMap,
-	  class Compare, class Combine,
-	  class DistInf, class DistZero>
-void dag_shortest_paths(const VertexListGraph& g,
-   typename graph_traits<VertexListGraph>::vertex_descriptor s,
-   DistanceMap distance, WeightMap weight, ColorMap color,
-   PredecessorMap pred, DijkstraVisitor vis,
-   Compare compare, Combine combine, DistInf inf, DistZero zero)
-
- -

-This algorithm [8] solves -the single-source shortest-paths problem on a weighted, directed -acyclic graph (DAG). This algorithm is more efficient for DAG's -than either the Dijkstra or Bellman-Ford algorithm. -Use breadth-first search instead of this algorithm -when all edge weights are equal to one. For the definition of the -shortest-path problem see Section Shortest-Paths -Algorithms for some background to the shortest-path problem. -

- -

-There are two main options for obtaining output from the -dag_shortest_paths() function. If you provide a -distance property map through the distance_map() parameter -then the shortest distance from the source vertex to every other -vertex in the graph will be recorded in the distance map. Also you can -record the shortest paths tree in a predecessor map: for each vertex -u in V, p[u] will be the predecessor of u in -the shortest paths tree (unless p[u] = u, in which case u is -either the source or a vertex unreachable from the source). In -addition to these two options, the user can provide there own -custom-made visitor that can takes actions during any of the -algorithm's event points.

- -

Where Defined

- -boost/graph/dag_shortest_paths.hpp - -

Parameters

- -IN: const VertexListGraph& g -
- The graph object on which the algorithm will be applied. - The type VertexListGraph must be a model of \concept{VertexListGraph}.
- - Python: The parameter is named graph. -
- -IN: vertex_descriptor s -
- The source vertex. All distance will be calculated from this vertex, - and the shortest paths tree will be rooted at this vertex.
- - Python: The parameter is named root_vertex. -
- -

Named Parameters

- -IN: weight_map(WeightMap w_map) -
- The weight or ``length'' of each edge in the graph. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for the map must be - Addable with the value type of the distance map.
- Default: get(edge_weight, g)
- Python: Must be an edge_double_map for the graph.
- Python default: graph.get_edge_double_map("weight") - -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure when an edge is relaxed. 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 - usable as the key type of the map.
- Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- - Python: Unsupported parameter. -
- -OUT: predecessor_map(PredecessorMap p_map) -
- The predecessor map records the edges in the minimum spanning - tree. Upon completion of the algorithm, the edges (p[u],u) - for all u in V are in the minimum spanning tree. If p[u] = - u then u is either the source vertex or a vertex that is - not reachable from the source. The PredecessorMap type - must be a Read/Write - Property Map which key and vertex types the same as the vertex - descriptor type of the graph.
- Default: dummy_property_map
- Python: Must be a vertex_vertex_map for the graph.
-
- -UTIL/OUT: distance_map(DistanceMap d_map) -
- The shortest path weight from the source vertex s to each - vertex in the graph g is recorded in this property map. The - shortest path weight is the sum of the edge weights along the - shortest path. The type DistanceMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the distance map. - - The value type of the distance map is the element type of a Monoid formed with the combine - function object and the zero object for the identity - element. Also the distance value type must have a - StrictWeakOrdering provided by the compare function - object.
- Default: - iterator_property_map created from a - std::vector of the WeightMap's value type of size - num_vertices(g) and using the i_map for the index - map.
- - Python: Must be a vertex_double_map for the graph. -
- -IN: distance_compare(CompareFunction cmp) -
- This function is use to compare distances to determine which vertex - is closer to the source vertex. The CompareFunction type - must be a model of Binary - Predicate and have argument types that match the value type of - the DistanceMap property map.
- - Default: - std::less<D> with D=typename - property_traits<DistanceMap>::value_type
- - Python: Unsupported parameter. -
- -IN: distance_combine(CombineFunction cmb) -
- This function is used to combine distances to compute the distance - of a path. The CombineFunction type must be a model of Binary - Function. The first argument type of the binary function must - match the value type of the DistanceMap property map and - the second argument type must match the value type of the - WeightMap property map. The result type must be the same - type as the distance value type.
- - Default: std::plus<D> with - D=typename property_traits<DistanceMap>::value_type
- - Python: Unsupported parameter. -
- -IN: distance_inf(D inf) -
- The inf object must be the greatest value of any D object. - That is, compare(d, inf) == true for any d != inf. - The type D is the value type of the DistanceMap.
- Default: std::numeric_limits<D>::max()
- - Python: Unsupported parameter. -
- -IN: distance_zero(D zero) -
- The zero value must be the identity element for the - Monoid formed by the distance values - and the combine function object. - The type \code{D} is the value type of the \code{DistanceMap} - Default: D()
- - Python: Unsupported parameter. -
- -UTIL/OUT: color_map(ColorMap c_map) -
- This is used during the execution of the algorithm to mark the - vertices. The vertices start out white and become gray when they are - inserted in the queue. They then turn black when they are removed - from the queue. At the end of the algorithm, vertices reachable from - the source vertex will have been colored black. All other vertices - will still be white. The type ColorMap must be a model of - Read/Write - Property Map. A vertex descriptor must be usable as the key type - of the map, and the value type of the map must be a model of - Color Value.
- Default: an - iterator_property_map created from a std::vector - of default_color_type of size num_vertices(g) and - using the i_map for the index map.
- - Python: The color map must be a vertex_color_map for - the graph. - -
- -OUT: visitor(DijkstraVisitor v) -
- Use this to specify actions that you would like to happen - during certain event points within the algorithm. - The type DijkstraVisitor must be a model of the - Dijkstra Visitor concept. - The visitor object is passed by value [1].
- Default: dijkstra_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the DijkstraVisitor type - of the graph. -
- - -

Complexity

- -

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

Visitor Event Points

- -
    -
  • vis.initialize_vertex(u, g) - is invoked on each vertex in the graph before the start of the - algorithm. -
  • vis.examine_vertex(u, g) - is invoked on a vertex as it is added to set S. - At this point we know that (p[u],u) - is a shortest-paths tree edge so - d[u] = delta(s,u) = d[p[u]] + w(p[u],u). Also, the distances - of the examined vertices is monotonically increasing - d[u1] <= d[u2] <= d[un]. -
  • vis.examine_edge(e, g) - is invoked on each out-edge of a vertex immediately after it has - been added to set S. -
  • vis.edge_relaxed(e, g) - is invoked on edge (u,v) if d[u] + w(u,v) < d[v]. - The edge (u,v) that participated in the last - relaxation for vertex v is an edge in the shortest paths tree. -
  • vis.discover_vertex(v, g) - is invoked on vertex v when the edge - (u,v) is examined and v is WHITE. Since - a vertex is colored GRAY when it is discovered, - each reacable vertex is discovered exactly once. -
  • vis.edge_not_relaxed(e, g) - is invoked if the edge is not relaxed (see above). -
  • vis.finish_vertex(u, g) - is invoked on a vertex after all of its out edges have - been examined. -
- -

Example

- -

-See -example/dag_shortest_paths.cpp for an example of using this -algorithm. - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - - diff --git a/doc/dasdan-dac99.pdf b/doc/dasdan-dac99.pdf deleted file mode 100644 index 83d1bee36..000000000 Binary files a/doc/dasdan-dac99.pdf and /dev/null differ diff --git a/doc/depth_first_search.html b/doc/depth_first_search.html deleted file mode 100644 index a376de3f1..000000000 --- a/doc/depth_first_search.html +++ /dev/null @@ -1,320 +0,0 @@ - - - -Boost Graph Library: Depth-First Search - -C++ Boost - -
- -

(Python) -depth_first_search -

- -

-

-// named parameter version
-template <class Graph, class class P, class T, class R>
-void depth_first_search(Graph& G,
-  const bgl_named_params<P, T, R>& params);
-
-// non-named parameter version
-template <class Graph, class DFSVisitor, class ColorMap>
-void depth_first_search(const Graph& g, DFSVisitor vis, ColorMap color)
-
-template <class Graph, class DFSVisitor, class ColorMap>
-void depth_first_search(const Graph& g, DFSVisitor vis, ColorMap color,
-                        typename graph_traits<Graph>::vertex_descriptor start)
-
-
- -

-The depth_first_search() function performs a depth-first -traversal of the vertices in a directed graph. When -possible, a depth-first traversal chooses a vertex adjacent to the -current vertex to visit next. If all adjacent vertices have already -been discovered, or there are no adjacent vertices, then the algorithm -backtracks to the last vertex that had undiscovered neighbors. Once -all reachable vertices have been visited, the algorithm selects from -any remaining undiscovered vertices and continues the traversal. The -algorithm finishes when all vertices have been visited. Depth-first -search is useful for categorizing edges in a graph, and for imposing -an ordering on the vertices. Section Depth-First -Search describes the various properties of DFS and walks through -an example. -

- -

-Similar to BFS, color markers are used to keep track of which vertices -have been discovered. White marks vertices that have yet to be -discovered, gray marks a vertex that is discovered but still has -vertices adjacent to it that are undiscovered. A black vertex is -discovered vertex that is not adjacent to any white vertices. -

- -

-The depth_first_search() function invokes user-defined -actions at certain event-points within the algorithm. This provides a -mechanism for adapting the generic DFS algorithm to the many -situations in which it can be used. In the pseudo-code below, the -event points for DFS are the labels on -the right. The user-defined actions must be provided in the form of a -visitor object, that is, an object whose type meets the requirements -for a DFS Visitor. In the pseudo-code -we show the algorithm computing predecessors p, discover time -d and finish time t. By default, the -depth_first_search() function does not compute these -properties, however there are pre-defined visitors such as predecessor_recorder -and time_stamper that can -be used to do this. -

- - - - - - -
-
-DFS(G)
-  for each vertex u in V
-    color[u] := WHITE
-    p[u] = u
-  end for
-  time := 0
-  if there is a starting vertex s
-    call DFS-VISIT(G, s)
-  for each vertex u in V
-    if color[u] = WHITE
-      call DFS-VISIT(G, u)
-  end for
-  return (p,d_time,f_time) 

-DFS-VISIT(G, u)
-  color[u] := GRAY
-  d_time[u] := time := time + 1
-  for each v in Adj[u]
-    if (color[v] = WHITE)
-      p[v] = u
-      call DFS-VISIT(G, v)
-    else if (color[v] = GRAY)
-      ...
-    else if (color[v] = BLACK)
-      ...
-    ...
-  end for
-  color[u] := BLACK
-  f_time[u] := time := time + 1
-
-
 -
--
--
-initialize vertex u
--
--
--
--
-start vertex s
--
--
-start vertex u
--
--
--
--
-discover vertex u
--
-examine edge (u,v)
--
-(u,v) is a tree edge
--
--
-(u,v) is a back edge
--
-(u,v) is a cross or forward edge
--
-finish edge (u,v)
--
-finish vertex u
--
-
-
- - - -

Where Defined

- -

-boost/graph/depth_first_search.hpp - -

Parameters

- -IN: Graph& g -
- A directed graph. The graph type must - be a model of Incidence Graph - and Vertex List Graph.
- - Python: The parameter is named graph. -
- - -

Named Parameters

- -IN: visitor(DFSVisitor vis) -
- A visitor object that is invoked inside the algorithm at the - event-points specified by the DFS - Visitor concept. The visitor object is passed by value [1].
Default: - dfs_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the DFSVisitor type of - the graph. -
- -UTIL/OUT: color_map(ColorMap color) -
- This is used by the algorithm to keep track of its progress through - the graph. The type ColorMap must be a model of Read/Write - Property Map and its key type must be the graph's vertex - descriptor type and the value type of the color map must model - ColorValue.
- Default: an - iterator_property_map created from a - std::vector of default_color_type of size - num_vertices(g) and using the i_map for the index - map.
- - Python: The color map must be a vertex_color_map for - the graph. -
- -IN: root_vertex(typename -graph_traits<VertexListGraph>::vertex_descriptor start) -
- This specifies the vertex that the depth-first search should - originate from. The type is the type of a vertex descriptor for the - given graph.
- Default: *vertices(g).first
-
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This parameter is only necessary when the - default color property map is used. 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 usable as the key - type of the map.
- - Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property.
- - Python: Unsupported parameter. -
- -

- -

-Complexity -

- -

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

- -

Visitor Event Points

- -
    - -
  • vis.initialize_vertex(s, g) is invoked on every - vertex of the graph before the start of the graph search. - -
  • vis.start_vertex(s, g) is invoked on the source - vertex once before the start of the search. - -
  • vis.discover_vertex(u, g) is invoked when a vertex - is encountered for the first time. - -
  • vis.examine_edge(e, g) is invoked on every out-edge - of each vertex after it is discovered. - -
  • vis.tree_edge(e, g) is invoked on each edge as it - becomes a member of the edges that form the search tree. If you - wish to record predecessors, do so at this event point. - -
  • vis.back_edge(e, g) is invoked on the back edges in - the graph. - -
  • vis.forward_or_cross_edge(e, g) is invoked on - forward or cross edges in the graph. In an undirected graph this - method is never called. - -
  • vis.finish_edge(e, g) is invoked on the non-tree edges in - the graph as well as on each tree edge after its target vertex is finished. - -
  • vis.finish_vertex(u, g) is invoked on a vertex after - all of its out edges have been added to the search tree and all of - the adjacent vertices have been discovered (but before their - out-edges have been examined). - -
- - -

Example

- -

-The example in -examples/dfs-example.cpp shows DFS applied to the graph in -Figure 1. - -

See Also

- -depth_first_visit -undirected_dfs - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/depth_first_visit.html b/doc/depth_first_visit.html deleted file mode 100644 index 81f73ba90..000000000 --- a/doc/depth_first_visit.html +++ /dev/null @@ -1,144 +0,0 @@ - - - -Boost Graph Library: Depth-First Visit - -C++ Boost - -
- -

-(Python) -depth_first_visit -

- - -

-

-template <class IncidenceGraph, class DFSVisitor, class ColorMap>
-void depth_first_visit(IncidenceGraph& g,
-  typename graph_traits<IncidenceGraph>::vertex_descriptor s,
-  DFSVisitor& vis, ColorMap color)
-
-template <class IncidenceGraph, class DFSVisitor, class ColorMap,
-          class TerminatorFunc>
-void depth_first_visit(IncidenceGraph& g,
-  typename graph_traits<IncidenceGraph>::vertex_descriptor s,
-  DFSVisitor& vis, ColorMap color, TerminatorFunc func = TerminatorFunc())
-
- -

-This function visits all of the vertices in the same connected -component as the source vertex s, using the depth-first -pattern. The main purpose of the function is for the -implementation of depth_first_search() though sometimes it is -useful on its own. - -

-The DFSVisitor supplied by the user determines what -actions are taken at each event-point within the algorithm. - -

-The ColorMap is used by the algorithm to keep track -of which vertices have been visited. - -

The second variant can be used, for example, to find all marked vertices -reachable from a start vertex by a path which does not contain any another -marked vertices. - - -

- -

Where Defined:

- -boost/graph/depth_first_search.hpp - - -

Parameters

- -IN IncidenceGraph& g -
-A directed or undirected graph. The graph's type must be a model of -Incidence Graph.
- -Python: The parameter is named graph. -
- -IN: vertex_descriptor s -
- The source vertex from which to start the search.
- - Python: The parameter is named root_vertex. -
- -IN: DFSVisitor visitor -
- A visitor object that is invoked inside the algorithm at the - event-points specified by the DFS - Visitor concept. The visitor object is passed by value [1].
- - Python: The parameter should be an object that derives from - the DFSVisitor type of - the graph. -
- -UTIL: ColorMap color -
- This is used by the algorithm to keep track of its progress through - the graph. The type ColorMap must be a model of Read/Write - Property Map and its key type must be the graph's vertex - descriptor type and the value type of the color map map must model - Color Value.
- - Python: The color map must be a vertex_color_map for - the graph. -
- -IN: TerminatorFunc func -
-A function object callable with two parameters - the descriptor of -vertex and the graph instance - and returning bool. The call is made -immediately after call to 'discover_vertex' visitor -event. If true is returned, the out edges of the vertex are -not examined, as if they don't exist.
- - Python: Unsupported parameter. -
-

- -

Complexity

- -Time complexity is O(E). - - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/dfs_visitor.html b/doc/dfs_visitor.html deleted file mode 100644 index 840acd335..000000000 --- a/doc/dfs_visitor.html +++ /dev/null @@ -1,111 +0,0 @@ - - - -Boost Graph Library: dfs_visitor - -C++ Boost - -
- -

-
-dfs_visitor<EventVisitorList>
-
-

- -This class is an adapter that converts a list of EventVisitors (constructed using -std::pair) into a DFSVisitor. - - -

Example

- -See the example for EventVisitor. - -

Model of

- -DFSVisitor - -

Template Parameters

- -

- - - - - - - - - - -
ParameterDescriptionDefault
EventVisitorList -A list of EventVisitor's created -with std::pair. -null_visitor
- -

Where Defined

- -

- -boost/graph/depth_first_search.hpp - -

Member Functions

- -This class implements all of the member functions required by DFSVisitor. In each function the -appropriate event is dispatched to the EventVisitor in the EventVisitorList. - -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class EventVisitorList>
-dfs_visitor<EventVisitorList>
-make_dfs_visitor(EventVisitorList ev_list); -		 -Returns the event visitor list adapted to be a DFS visitor. -
- -

See Also

- -Visitor concepts -

-The following are event visitors: predecessor_recorder, -distance_recorder, -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/dijkstra_shortest_paths.html b/doc/dijkstra_shortest_paths.html deleted file mode 100644 index 2cd3978f7..000000000 --- a/doc/dijkstra_shortest_paths.html +++ /dev/null @@ -1,464 +0,0 @@ - - - -Boost Graph Library: Dijkstra's Shortest Paths - -C++ Boost - -
- -

(Python) -dijkstra_shortest_paths -

- -

-

-// named parameter version
-template <typename Graph, typename P, typename T, typename R>
-void
-dijkstra_shortest_paths(Graph& g,
-  typename graph_traits<Graph>::vertex_descriptor s,
-  const bgl_named_params<P, T, R>& params);
-
-// non-named parameter version
-template <typename Graph, typename DijkstraVisitor,
-	  typename PredecessorMap, typename DistanceMap,
-	  typename WeightMap, typename VertexIndexMap, typename CompareFunction, typename CombineFunction,
-	  typename DistInf, typename DistZero, typename ColorMap = default>
-void dijkstra_shortest_paths
-  (const Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor s,
-   PredecessorMap predecessor, DistanceMap distance, WeightMap weight,
-   VertexIndexMap index_map,
-   CompareFunction compare, CombineFunction combine, DistInf inf, DistZero zero,
-   DijkstraVisitor vis, ColorMap color = default)
-
-// version that does not initialize the property maps (except for the default color map)
-template <class Graph, class DijkstraVisitor,
-          class PredecessorMap, class DistanceMap,
-          class WeightMap, class IndexMap, class Compare, class Combine,
-          class DistZero, class ColorMap>
-void
-dijkstra_shortest_paths_no_init
-  (const Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor s,
-   PredecessorMap predecessor, DistanceMap distance, WeightMap weight,
-   IndexMap index_map,
-   Compare compare, Combine combine, DistZero zero,
-   DijkstraVisitor vis, ColorMap color = default);
-
- -

-This algorithm [10,8] solves the single-source -shortest-paths problem on a weighted, directed or undirected graph for -the case where all edge weights are nonnegative. Use the Bellman-Ford -algorithm for the case when some edge weights are negative. Use -breadth-first search instead of Dijkstra's algorithm when all edge -weights are equal to one. For the definition of the shortest-path -problem see Section Shortest-Paths -Algorithms for some background to the shortest-path problem. -

- -

-There are two main options for obtaining output from the -dijkstra_shortest_paths() function. If you provide a -distance property map through the distance_map() parameter -then the shortest distance from the source vertex to every other -vertex in the graph will be recorded in the distance map. Also you can -record the shortest paths tree in a predecessor map: for each vertex -u in V, p[u] will be the predecessor of u in -the shortest paths tree (unless p[u] = u, in which case u is -either the source or a vertex unreachable from the source). In -addition to these two options, the user can provide their own -custom-made visitor that takes actions during any of the -algorithm's event points.

- -

-Dijkstra's algorithm finds all the shortest paths from the source -vertex to every other vertex by iteratively ``growing'' the set of -vertices S to which it knows the shortest path. At each step of -the algorithm, the next vertex added to S is determined by a -priority queue. The queue contains the vertices in V - S[1] prioritized by their distance label, which is the -length of the shortest path seen so far for each vertex. The vertex -u at the top of the priority queue is then added to S, -and each of its out-edges is relaxed: if the distance to u plus -the weight of the out-edge (u,v) is less than the distance -label for v then the estimated distance for vertex v is -reduced. The algorithm then loops back, processing the next vertex at -the top of the priority queue. The algorithm finishes when the -priority queue is empty. -

-

-The algorithm uses color markers (white, gray, and black) to keep -track of which set each vertex is in. Vertices colored black are in -S. Vertices colored white or gray are in V-S. White vertices have -not yet been discovered and gray vertices are in the priority queue. -By default, the algorithm will allocate an array to store a color -marker for each vertex in the graph. You can provide your own storage -and access for colors with the color_map() parameter. -

-

-The following is the pseudo-code for Dijkstra's single-source shortest -paths algorithm. w is the edge weight, d is the distance label, -and p is the predecessor of each vertex which is used to encode -the shortest paths tree. Q is a priority queue that supports the -DECREASE-KEY operation. The visitor event points for the algorithm are -indicated by the labels on the right. -

- - - - - - -
-
-DIJKSTRA(G, s, w)
-  for each vertex u in V (This loop is not run in dijkstra_shortest_paths_no_init)
-    d[u] := infinity
-    p[u] := u
-    color[u] := WHITE
-  end for
-  color[s] := GRAY
-  d[s] := 0
-  INSERT(Q, s)
-  while (Q != Ø)
-    u := EXTRACT-MIN(Q)
-    S := S U { u }
-    for each vertex v in Adj[u]
-      if (w(u,v) + d[u] < d[v])
-        d[v] := w(u,v) + d[u]
-        p[v] := u
-        if (color[v] = WHITE)
-          color[v] := GRAY
-          INSERT(Q, v)
-        else if (color[v] = GRAY)
-          DECREASE-KEY(Q, v)
-      else
-        ...
-    end for
-    color[u] := BLACK
-  end while
-  return (d, p)
-
-		 -
-
-initialize vertex u
-
-
-
-
-
-
-discover vertex s
-
-examine vertex u
-
-examine edge (u,v)
-
-edge (u,v) relaxed
-
-
-
-discover vertex v
-
-
-
-edge (u,v) not relaxed
-
-finish vertex u
-
-
- -

Where Defined

- -boost/graph/dijkstra_shortest_paths.hpp - -

Parameters

- -IN: const Graph& g -
- The graph object on which the algorithm will be applied. - The type Graph must be a model of - Vertex List Graph - and Incidence Graph.
- - Python: The parameter is named graph. -
- -IN: vertex_descriptor s -
- The source vertex. All distance will be calculated from this vertex, - and the shortest paths tree will be rooted at this vertex.
- - Python: The parameter is named root_vertex. -
- -

Named Parameters

- -IN: weight_map(WeightMap w_map) -
- The weight or ``length'' of each edge in the graph. The weights - must all be non-negative, and the algorithm will throw a - negative_edge - exception is one of the edges is negative. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for this map must be - the same as the value type of the distance map.
- Default: get(edge_weight, g)
- - Python: Must be an edge_double_map for the graph.
- Python default: graph.get_edge_double_map("weight") -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure [61] when an edge is relaxed. - 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 - usable as the key type of the map.
- Default: get(vertex_index, g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- - Python: Unsupported parameter. -
- -OUT: predecessor_map(PredecessorMap p_map) -
- The predecessor map records the edges in the shortest path tree, the tree computed - by the traversal of the graph. Upon completion of the algorithm, the edges - (p[u],u) for all u in V are in the tree. The shortest path - from vertex s to each vertex v in the graph consists of the - vertices v, p[v], p[p[v]], and so on until s is - reached, in reverse order. The - tree is not guaranteed to be a minimum spanning tree. If p[u] = - u then u is either the source vertex or a vertex that is - not reachable from the source. The PredecessorMap type - must be a Read/Write - Property Map whose key and value types are the same as the vertex - descriptor type of the graph.
- Default: dummy_property_map
- - Python: Must be a vertex_vertex_map for the graph.
-
- -UTIL/OUT: distance_map(DistanceMap d_map) -
- The shortest path weight from the source vertex s to each - vertex in the graph g is recorded in this property map. The - shortest path weight is the sum of the edge weights along the - shortest path. The type DistanceMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the distance map. - - The value type of the distance map is the element type of a Monoid formed with the combine - function object and the zero object for the identity - element. Also the distance value type must have a - StrictWeakOrdering provided by the compare function - object.
- Default: - iterator_property_map created from a - std::vector of the WeightMap's value type of size - num_vertices(g) and using the i_map for the index - map.
- - Python: Must be a vertex_double_map for the graph.
-
- -IN: distance_compare(CompareFunction cmp) -
- This function is use to compare distances to determine which vertex - is closer to the source vertex. The CompareFunction type - must be a model of Binary - Predicate and have argument types that match the value type of - the DistanceMap property map.
- - Default: - std::less<D> with D=typename - property_traits<DistanceMap>::value_type
- - Python: Unsupported parameter. -
- -IN: distance_combine(CombineFunction cmb) -
- This function is used to combine distances to compute the distance - of a path. The CombineFunction type must be a model of Binary - Function. The first argument type of the binary function must - match the value type of the DistanceMap property map and - the second argument type must match the value type of the - WeightMap property map. The result type must be the same - type as the distance value type.
- - Default: std::plus<D> with - D=typename property_traits<DistanceMap>::value_type
- - Python: Unsupported parameter. -
- -IN: distance_inf(D inf) -
- The inf object must be the greatest value of any D object. - That is, compare(d, inf) == true for any d != inf. - The type D is the value type of the DistanceMap. Edges - are assumed to have a weight less than (using distance_compare for - comparison) this value.
- Default: std::numeric_limits<D>::max()
- - Python: Unsupported parameter. -
- -IN: distance_zero(D zero) -
- The zero value must be the identity element for the - Monoid formed by the distance values - and the combine function object. - The type D is the value type of the DistanceMap.
- Default: D()with - D=typename property_traits<DistanceMap>::value_type
- - Python: Unsupported parameter. -
- -UTIL/OUT: color_map(ColorMap c_map) -
- This is used during the execution of the algorithm to mark the - vertices. The vertices start out white and become gray when they are - inserted in the queue. They then turn black when they are removed - from the queue. At the end of the algorithm, vertices reachable from - the source vertex will have been colored black. All other vertices - will still be white. The type ColorMap must be a model of - Read/Write - Property Map. A vertex descriptor must be usable as the key type - of the map, and the value type of the map must be a model of - Color Value.
- Default: an - iterator_property_map created from a std::vector - of default_color_type of size num_vertices(g) and - using the i_map for the index map.
- - Python: The color map must be a vertex_color_map for - the graph. -
- -OUT: visitor(DijkstraVisitor v) -
- Use this to specify actions that you would like to happen - during certain event points within the algorithm. - The type DijkstraVisitor must be a model of the - Dijkstra Visitor concept. - The visitor object is passed by value [2].
- Default: dijkstra_visitor<null_visitor>
- - Python: The parameter should be an object that derives from - the DijkstraVisitor type - of the graph. -
- - -

Complexity

- -

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

Visitor Event Points

- -
    -
  • vis.initialize_vertex(u, g) - is invoked on each vertex in the graph before the start of the - algorithm. -
  • vis.examine_vertex(u, g) - is invoked on a vertex as it is removed from the priority queue - and added to set S. At this point we know that (p[u],u) - is a shortest-paths tree edge so - d[u] = delta(s,u) = d[p[u]] + w(p[u],u). Also, the distances - of the examined vertices is monotonically increasing - d[u1] <= d[u2] <= d[un]. -
  • vis.examine_edge(e, g) - is invoked on each out-edge of a vertex immediately after it has - been added to set S. -
  • vis.edge_relaxed(e, g) - is invoked on edge (u,v) if d[u] + w(u,v) < d[v]. - The edge (u,v) that participated in the last - relaxation for vertex v is an edge in the shortest paths tree. -
  • vis.discover_vertex(v, g) - is invoked on vertex v when the edge - (u,v) is examined and v is WHITE. Since - a vertex is colored GRAY when it is discovered, - each reachable vertex is discovered exactly once. This - is also when the vertex is inserted into the priority queue. -
  • vis.edge_not_relaxed(e, g) - is invoked if the edge is not relaxed (see above). -
  • vis.finish_vertex(u, g) - is invoked on a vertex after all of its out edges have - been examined. -
- -

Example

- -

-See -example/dijkstra-example.cpp for an example of using Dijkstra's -algorithm. - -

See also

dijkstra_shortest_paths_no_color_map for a version of Dijkstra's shortest path that does not use a color map. - -

Notes

- -[1] -The algorithm used here saves a little space by not putting all V - -S vertices in the priority queue at once, but instead only those -vertices in V - S that are discovered and therefore have a -distance less than infinity. - -

[2] - 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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/dijkstra_shortest_paths_no_color_map.html b/doc/dijkstra_shortest_paths_no_color_map.html deleted file mode 100644 index 07432082d..000000000 --- a/doc/dijkstra_shortest_paths_no_color_map.html +++ /dev/null @@ -1,394 +0,0 @@ - - - -Boost Graph Library: Dijkstra's Shortest Paths (No Color Map) - -C++ Boost - -
- -

-dijkstra_shortest_paths_no_color_map -

- -

-

-// named parameter version
-template <typename Graph, typename Param, typename Tag, typename Rest>
-void dijkstra_shortest_paths_no_color_map
-  (const Graph& graph,
-   typename graph_traits<Graph>::vertex_descriptor start_vertex,
-   const bgl_named_params& params);
-
-// non-named parameter version
-template <typename Graph, typename DijkstraVisitor,
-	  typename PredecessorMap, typename DistanceMap,
-	  typename WeightMap, typename VertexIndexMap, typename DistanceCompare, typename DistanceWeightCombine,
-	  typename DistanceInfinity, typename DistanceZero>
-void dijkstra_shortest_paths_no_color_map
-  (const Graph& graph,
-   typename graph_traits<Graph>::vertex_descriptor start_vertex,
-   PredecessorMap predecessor_map, DistanceMap distance_map, WeightMap weight_map,
-   VertexIndexMap index_map,
-   DistanceCompare distance_compare, DistanceWeightCombine distance_weight_combine,
-   DistanceInfinity distance_infinity, DistanceZero distance_zero);
-
-// version that does not initialize the property maps
-template <typename Graph, typename DijkstraVisitor,
-	  typename PredecessorMap, typename DistanceMap,
-	  typename WeightMap, typename VertexIndexMap, typename DistanceCompare, typename DistanceWeightCombine,
-	  typename DistanceInfinity, typename DistanceZero>
-void dijkstra_shortest_paths_no_color_map_no_init
-  (const Graph& graph,
-   typename graph_traits<Graph>::vertex_descriptor start_vertex,
-   PredecessorMap predecessor_map, DistanceMap distance_map, WeightMap weight_map,
-   VertexIndexMap index_map,
-   DistanceCompare distance_compare, DistanceWeightCombine distance_weight_combine,
-   DistanceInfinity distance_infinity, DistanceZero distance_zero);
-
- -

-This algorithm [10,8] solves the single-source -shortest-paths problem on a weighted, directed or undirected graph for -the case where all edge weights are nonnegative. Use the Bellman-Ford -algorithm for the case when some edge weights are negative. Use -breadth-first search instead of Dijkstra's algorithm when all edge -weights are equal to one. For the definition of the shortest-path -problem see Section Shortest-Paths -Algorithms for some background to the shortest-path problem. -

- -

- dijkstra_shortest_paths_no_color_map differs from the original dijkstra_shortest_paths algorithm by not using a color map to identify vertices as discovered or undiscovered. Instead, this is done with the distance map: a vertex u such that distance_compare(distance_map[u], distance_infinity) == false is considered to be undiscovered. Note that this means that edges with infinite weight will not work correctly in this algorithm. -

- -

-There are two main options for obtaining output from the -dijkstra_shortest_paths_no_color_map() function. If you provide a -distance property map through the distance_map() parameter -then the shortest distance from the start vertex to every other -vertex in the graph will be recorded in the distance map. Also you can -record the shortest paths tree in a predecessor map: for each vertex -u in V, p[u] will be the predecessor of u in -the shortest paths tree (unless p[u] = u, in which case u is -either the source or a vertex unreachable from the source). In -addition to these two options, the user can provide their own -custom-made visitor that takes actions during any of the -algorithm's event points [4].

- -

-Dijkstra's algorithm finds all the shortest paths from the source -vertex to every other vertex by iteratively "growing" the set of -vertices S to which it knows the shortest path. At each step of -the algorithm, the next vertex added to S is determined by a -priority queue. The queue contains the vertices in V - S[1] prioritized by their distance label, which is the -length of the shortest path seen so far for each vertex. The vertex -u at the top of the priority queue is then added to S, -and each of its out-edges is relaxed: if the distance to u plus -the weight of the out-edge (u,v) is less than the distance -label for v then the estimated distance for vertex v is -reduced. The algorithm then loops back, processing the next vertex at -the top of the priority queue. The algorithm finishes when the -priority queue is empty. -

-

-The following is the pseudo-code for Dijkstra's single-source shortest -paths algorithm. w is the edge weight, d is the distance label, -and p is the predecessor of each vertex which is used to encode -the shortest paths tree. Q is a priority queue that supports the -DECREASE-KEY operation. The visitor event points for the algorithm are -indicated by the labels on the right. -

- - - - - - -
-
-DIJKSTRA(G, s, w)
-  d[s] := 0
-  INSERT(Q, s)
-  while (Q != Ø)
-    u := EXTRACT-MIN(Q)
-    for each vertex v in Adj[u]
-      if (w(u,v) + d[u] < d[v])
-        d[v] := w(u,v) + d[u]
-        p[v] := u
-        if (d[v] was originally infinity)
-          INSERT(Q, v)
-        else
-          DECREASE-KEY(Q, v)
-      else
-      	...
-    end for
-  end while
-  return (d, p)
-
-		 -
-
-
-discover vertex s
-
-examine vertex u
-examine edge (u,v)
-
-edge (u,v) relaxed
-
-
-discover vertex v
-
-
-edge (u,v) not relaxed
-
-finish vertex u
-
-
- -

Where Defined

- -boost/graph/dijkstra_shortest_paths_no_color_map.hpp - -

Parameters

- -IN: const Graph& graph -
- The graph object on which the algorithm will be applied. - The type Graph must be a model of - Vertex List Graph - and Incidence Graph.
-
- -IN: vertex_descriptor start_vertex -
- The source vertex. All distance will be calculated from this vertex, - and the shortest paths tree will be rooted at this vertex.
-
- -

Named Parameters

- -IN: weight_map(WeightMap weight_map) -
- The weight or ``length'' of each edge in the graph. The weights - must all be non-negative and non-infinite [3]. The algorithm will throw a - negative_edge - exception is one of the edges is negative. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for this map must be - the same as the value type of the distance map.
- Default: get(edge_weight, graph)
-
- -IN: index_map(VertexIndexMap index_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(graph)). This is necessary for efficient updates of the - heap data structure [61] when an edge is relaxed. - 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 - usable as the key type of the map.
- Default: get(vertex_index, graph). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-
- -OUT: predecessor_map(PredecessorMap predecessor_map) -
- The predecessor map records the edges in the minimum spanning - tree. Upon completion of the algorithm, the edges (p[u],u) - for all u in V are in the minimum spanning tree. If p[u] = - u then u is either the source vertex or a vertex that is - not reachable from the source. The PredecessorMap type - must be a Read/Write - Property Map whose key and value types are the same as the vertex - descriptor type of the graph.
- Default: dummy_property_map
- - Python: Must be a vertex_vertex_map for the graph.
-
- -UTIL/OUT: distance_map(DistanceMap distance_map) -
- The shortest path weight from the source vertex start_vertex to each - vertex in the graph graph is recorded in this property map. The - shortest path weight is the sum of the edge weights along the - shortest path. The type DistanceMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the distance map. - - The value type of the distance map is the element type of a Monoid formed with the distance_weight_combine - function object and the distance_zero object for the identity - element. Also the distance value type must have a - StrictWeakOrdering provided by the distance_compare function - object.
- Default: - iterator_property_map created from a - std::vector of the WeightMap's value type of size - num_vertices(graph) and using the index_map for the index - map.
-
- -IN: distance_compare(CompareFunction distance_compare) -
- This function is use to compare distances to determine which vertex - is closer to the source vertex. The DistanceCompareFunction type - must be a model of Binary - Predicate and have argument types that match the value type of - the DistanceMap property map.
- - Default: - std::less<D> with D=typename - property_traits<DistanceMap>::value_type
-
- -IN: distance_combine(CombineFunction distance_weight_combine) -
- This function is used to combine distances to compute the distance - of a path. The DistanceWeightCombineFunction type must be a model of Binary - Function. The first argument type of the binary function must - match the value type of the DistanceMap property map and - the second argument type must match the value type of the - WeightMap property map. The result type must be the same - type as the distance value type.
- - Default: boost::closed_plus<D> with - D=typename property_traits<DistanceMap>::value_type
-
- -IN: distance_inf(D distance_infinity) -
- The distance_infinity object must be the greatest value of any D object. - That is, distance_compare(d, distance_infinity) == true for any d != distance_infinity. - The type D is the value type of the DistanceMap. All edges - are assumed to have weight less than (by distance_compare) this - value.
- Default: std::numeric_limits<D>::max()
-
- -IN: distance_zero(D distance_zero) -
- The distance_zero value must be the identity element for the - Monoid formed by the distance values - and the distance_weight_combine function object. - The type D is the value type of the DistanceMap.
- Default: D()with - D=typename property_traits<DistanceMap>::value_type
-
- -OUT: visitor(DijkstraVisitor v) -
- Use this to specify actions that you would like to happen - during certain event points within the algorithm. - The type DijkstraVisitor must be a model of the - Dijkstra Visitor concept. - The visitor object is passed by value [2].
- Default: dijkstra_visitor<null_visitor>
-
- - -

Complexity

- -

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

Visitor Event Points

- -
    -
  • vis.initialize_vertex(u, g) - is invoked on each vertex in the graph before the start of the - algorithm. -
  • vis.examine_vertex(u, g) - is invoked on a vertex as it is removed from the priority queue - and added to set S. At this point we know that (p[u],u) - is a shortest-paths tree edge so - d[u] = delta(s,u) = d[p[u]] + w(p[u],u). Also, the distances - of the examined vertices is monotonically increasing - d[u1] <= d[u2] <= d[un]. -
  • vis.examine_edge(e, g) - is invoked on each out-edge of a vertex immediately after it has - been added to set S. -
  • vis.edge_relaxed(e, g) - is invoked on edge (u,v) if d[u] + w(u,v) < d[v]. - The edge (u,v) that participated in the last - relaxation for vertex v is an edge in the shortest paths tree. -
  • vis.discover_vertex(v, g) - is invoked on vertex v when the edge - (u,v) is examined and v has not yet been discovered (i.e. its distance was infinity before relaxation was attempted on the edge). This - is also when the vertex is inserted into the priority queue. -
  • vis.edge_not_relaxed(e, g) - is invoked if the edge is not relaxed (see above). -
  • vis.finish_vertex(u, g) - is invoked on a vertex after all of its out edges have - been examined. -
- -

Example

- -

-See -example/dijkstra-no-color-map-example.cpp for an example of using Dijkstra's algorithm. - -

See also

dijkstra_shortest_paths for a version of Dijkstra's shortest path that uses a color map. - -

Notes

- -

Based on the documentation for dijkstra_shortest_paths. - -

[1] -The algorithm used here saves a little space by not putting all V - -S vertices in the priority queue at once, but instead only those -vertices in V - S that are discovered and therefore have a -distance less than infinity. - -

[2] - 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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. - -

[3] - The algorithm will not work correctly if any of the edge weights are equal to infinity since the infinite distance value is used to determine if a vertex has been discovered. - -

[4] - Calls to the visitor events occur in the same order as dijkstra_shortest_paths (i.e. discover_vertex(u) will always be called after examine_vertex(u) for an undiscovered vertex u). However, the vertices of the graph given to dijkstra_shortest_paths_no_color_map will not necessarily be visited in the same order as dijkstra_shortest_paths. - -
-

- - -
Copyright © 2009 -Trustees of Indiana University
- - - diff --git a/doc/dijkstra_visitor.html b/doc/dijkstra_visitor.html deleted file mode 100644 index ac4b3cb3a..000000000 --- a/doc/dijkstra_visitor.html +++ /dev/null @@ -1,125 +0,0 @@ - - - -Boost Graph Library: dijkstra_visitor - -C++ Boost - -
- -

-
-dijkstra_visitor<EventVisitorList>
-
-

- -This class is an adapter that converts a list of EventVisitors (constructed using -std::pair) into a DijkstraVisitor. - - -

Example

- -This is an excerpt from examples/dave.cpp -where the copy_graph single-event visitor -is used to create a copy the shortest-paths search-tree calculated -by Dijkstra's algorithm. - -
-boost::dijkstra_shortest_paths
-  (G, vertex(a, G),
-   distance_map(make_iterator_property_map(distance.begin(), vertex_id, distance[0])).
-   predecessor_map(make_iterator_property_map(parent.begin(), vertex_id, parent[0])).
-   visitor(make_dijkstra_visitor(copy_graph(G_copy, on_examine_edge()))));
-
- - -

Model of

- -Dijkstra Visitor - -

Template Parameters

- -

- - - - - - - - - - -
ParameterDescriptionDefault
EventVisitorList -A list of EventVisitor's created -with std::pair. -null_visitor
- -

Where Defined

- -

- -boost/graph/dijkstra_shortest_paths.hpp - -

Member Functions

- -This class implements all of the member functions required by DijkstraVisitor. In each -function the appropriate event is dispatched to the EventVisitor in the EventVisitorList. - -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class EventVisitorList>
-dijkstra_visitor<EventVisitorList>
-make_dijkstra_visitor(EventVisitorList ev_list); -		 -Returns the event visitor list adapted to be a Dijkstra Visitor. -
- -

See Also

- -Visitor concepts -

-The following are event visitors: predecessor_recorder, -distance_recorder -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/directed_graph.html b/doc/directed_graph.html deleted file mode 100644 index a410153e8..000000000 --- a/doc/directed_graph.html +++ /dev/null @@ -1,96 +0,0 @@ - - - -Boost Graph Library: Directed Graph - -C++ Boost - -
- -

-
-directed_graph<VertexProp, EdgeProp, GraphProp>
-
-

- - -

-The directed_graph class template is a simplified version -of the BGL adjacency list. This class is provided for ease of use, but -may not perform as well as custom-defined adjacency list classes. Instances -of this template model the BidirectionalGraph, VertexIndexGraph, and -EdgeIndexGraph concepts. - -

Example

- -A simple examples of creating a directed_graph is available here libs/graph/example/directed_graph.cpp. -

- - -

-  typedef boost::directed_graph<> Graph;
-  Graph g;
-  boost::graph_traits<Graph>::vertex_descriptor v0 = g.add_vertex();
-  boost::graph_traits<Graph>::vertex_descriptor v1 = g.add_vertex();
-
-  g.add_edge(v0, v1);
-
- -

Template Parameters

- -

- - - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
VertexPropA property map for the graph vertices. 
EdgePropA property map for the graph edges. 
GraphPropA property map for the graph itself.
-

- -

Where Defined

- -

-boost/graph/directed_graph.hpp - -

- -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/disjoint_sets.html b/doc/disjoint_sets.html deleted file mode 100644 index e5cb41daf..000000000 --- a/doc/disjoint_sets.html +++ /dev/null @@ -1,309 +0,0 @@ - - - - - - - - Boost Disjoint Sets - - - - C++ Boost
- -

Disjoint - Sets

- 
-disjoint_sets<Rank, Parent, FindCompress>
-
- -

This is a class that provides disjoint set operations with union by - rank and path compression. A disjoint-sets data structure - maintains a collection S = {S1, S2, ..., - Sk} of disjoint sets. Each set is identified by a - representative which is some member of of the set. Sets are - represented by rooted trees which are encoded in the Parent - property map. Two heuristics: "union by rank" and "path compression" are - used to speed up the operations [1, 2].

- -

Where Defined

boost/pending/disjoint_sets.hpp - -

Template Parameters

- - - - - - - - - - - - - - - - - - - -
Rankmust be a model of ReadWritePropertyMap - with an integer value type and a key type equal to the set's element - type.
Parentmust be a model of ReadWritePropertyMap - and the key and value type the same as the set's element type.
FindCompressshould be one of the find representative and path compress function - objects.
- -

Example

- -

A typical usage pattern for disjoint_sets can be seen in the - kruskal_minimum_spanning_tree() - algorithm. In this example, we call link() instead of - union_set() because u and v were obtained from - find_set() and therefore are already the representatives for their - sets.

- 
-  ...
-  disjoint_sets<Rank, Parent, FindCompress> dsets(rank, p);
-
-  for (ui  = vertices(G).first; ui != vertices(G).second; ++ui)
-    dsets.make_set(*ui);
-  ...
-  while ( !Q.empty() ) {
-    e = Q.front();
-    Q.pop();
-    u = dsets.find_set(source(e));
-    v = dsets.find_set(target(e));
-    if ( u != v ) {
-      *out++ = e;
-      dsets.link(u, v);
-    }
-  }
-
- -

Members

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MemberDescription
disjoint_sets(Rank r, Parent p)Constructor.
disjoint_sets(const disjoint_sets& x)Copy constructor.
template <class Element>
- void make_set(Element x)		Creates a singleton set containing Element x.
template <class Element>
- void link(Element x, Element y)		Union the two sets represented by element x and - y.
template <class Element>
- void union_set(Element x, Element y)		Union the two sets that contain elements x and - y. This is equivalent to - link(find_set(x),find_set(y)).
template <class Element>
- Element find_set(Element x)		Return the representative for the set containing element - x.
template <class ElementIterator>
- std::size_t count_sets(ElementIterator first, ElementIterator - last)		Returns the number of disjoint sets.
template <class ElementIterator>
- void compress_sets(ElementIterator first, ElementIterator - last)		Flatten the parents tree so that the parent of every element is its - representative.
- -

Complexity

- -

The time complexity is O(m alpha(m,n)), where alpha is the - inverse Ackermann's function, m is the number of disjoint-set - operations (make_set(), find_set(), and link() - and n is the number of elements. The alpha function grows - very slowly, much more slowly than the log function.

- -

See Also

incremental_connected_components() -
- 
-disjoint_sets_with_storage<ID,InverseID,FindCompress>
-
- -

This class manages the storage for the rank and parent properties - internally. The storage is in arrays, which are indexed by element ID, - hence the requirement for the ID and InverseID functors. - The rank and parent properties are initialized during construction so the - each element is in a set by itself (so it is not necessary to initialize - objects of this class with the - initialize_incremental_components() function). This class is - especially useful when computing the (dynamic) connected components of an - edge_list graph which does not provide a place to store vertex - properties.

- -

Template Parameters

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
IDmust be a model of ReadablePropertyMap that - maps elements to integers between zero 0 and N, the total number of - elements in the sets.boost::identity_property_map
InverseIDmust be a model of ReadablePropertyMap that - maps integers to elements.boost::identity_property_map
FindCompressshould be one of the find representative and path compress function - objects.representative_with_full_path_compression
- -

Members

- -

This class has all of the members in disjoint_sets as well as - the following members.

- 
-disjoint_sets_with_storage(size_type n = 0,
-                           ID id = ID(),
-                           InverseID inv = InverseID())
-
Constructor. - 
-template <class ElementIterator>
-void disjoint_sets_with_storage::
-  normalize_sets(ElementIterator first, ElementIterator last)
-
This rearranges the representatives such that the representative of -each set is the element with the smallest ID.
- Postcondition: v >= parent[v]
- Precondition: the disjoint sets structure must be compressed.
-
- -

- 
-representative_with_path_halving<Parent>
-
- -

This is a functor which finds the representative vertex for the same - component as the element x. While traversing up the representative - tree, the functor also applies the path halving technique to shorten the - height of the tree.

- 
-Element operator()(Parent p, Element x)
-
-
- -


- 
-representative_with_full_path_compression<Parent>
-
- -

This is a functor which finds the representative element for the set - that element x belongs to.

- 
-Element operator()(Parent p, Element x)
-
- -


-
- -

Valid HTML 4.01 Transitional

- -

Revised - 01 - December, 2006

- - - - - - - -
Copyright © 2000Jeremy Siek, Univ.of - Notre Dame (jsiek@lsc.nd.edu)
- Lie-Quan Lee, - Univ.of Notre Dame (llee1@lsc.nd.edu)
- Andrew Lumsdaine, Univ.of - Notre Dame (lums@lsc.nd.edu)
- -

Distributed under the Boost Software License, Version 1.0. (See - accompanying file LICENSE_1_0.txt or - copy at http://www.boost.org/LICENSE_1_0.txt)

- - diff --git a/doc/disjoint_sets_biblio.html b/doc/disjoint_sets_biblio.html deleted file mode 100644 index 96132347c..000000000 --- a/doc/disjoint_sets_biblio.html +++ /dev/null @@ -1,59 +0,0 @@ - - - - - - - - Boost Utility Library: Bibliography - - - - C++ Boost
- -

Bibliography

- -
-
1
- -
R. E. Tarjan.
- Data Structures and Network Algorithms.
- Society for Industrial and Applied Mathematics, 1983.
- -
 
- -
2
- -
T. Cormen, C. Leiserson, and R. Rivest.
- Introduction to Algorithms.
- McGraw-Hill, 1990.
-

-
- -

Valid HTML 4.01 Transitional

- -

Revised - 01 - December, 2006

- - - - - - - -
Copyright © 2000Jeremy Siek, Univ.of - Notre Dame (jsiek@lsc.nd.edu)
- -

Distributed under the Boost Software License, Version 1.0. (See - accompanying file LICENSE_1_0.txt or - copy at http://www.boost.org/LICENSE_1_0.txt)

- - diff --git a/doc/distance_recorder.html b/doc/distance_recorder.html deleted file mode 100644 index 50daaa447..000000000 --- a/doc/distance_recorder.html +++ /dev/null @@ -1,182 +0,0 @@ - - - -Boost Graph Library: distance_recorder - -C++ Boost - -
- -

-
-distance_recorder<DistanceMap, EventTag>
-
-

- -This is an EventVisitor that records -the distance of a vertex (using a property map) from some -source vertex during a graph search. When applied to edge e = -(u,v), the distance of v is recorded to be one more than -the distance of u. The distance recorder is typically used with -the on_tree_edge or on_relax_edge events and -cannot be used with vertex events. - -

-distance_recorder can be used with graph algorithms by -wrapping it with the algorithm specific adaptor, such as bfs_visitor and dfs_visitor. Also, this event -visitor can be combined with other event visitors using -std::pair to form an EventVisitorList. - -

Example

- -See the example for bfs_visitor. - -

Model of

- -EventVisitor - - -

Where Defined

- -

- -boost/graph/visitors.hpp - -

Template Parameters

- -

- - - - - - - - - - - - - - - -
ParameterDescriptionDefault
DistanceMap -A WritablePropertyMap -where the key type and the value type are the vertex descriptor type -of the graph. - 
EventTag -The tag to specify when the distance_recorder should be -applied during the graph algorithm. EventTag must be an -edge event. - 
- -

Associated Types

- - - - - - - - - - - - -
TypeDescription
distance_recorder::event_filter -This will be the same type as the template parameter EventTag. -
- -

Member Functions

- -

- - - - - - - - - - - - - - - - -
MemberDescription
-distance_recorder(DistanceMap pa); - -Construct a distance recorder object with distance property map -pa. -
-template <class Edge, class Graph>
-void operator()(Edge e, const Graph& g); -		 -Given edge e = (u,v), this records the distance of v as -one plus the distance of u. -
- -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class DistanceMap, class Tag>
-distance_recorder<DistanceMap, Tag>
-record_distances(DistanceMap pa, Tag); -		 -A convenient way to create a distance_recorder. -
- -

See Also

- -Visitor concepts -

-The following are other event visitors: predecessor_recorder, -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - - - - diff --git a/doc/edge_coloring.html b/doc/edge_coloring.html deleted file mode 100644 index bcc5df234..000000000 --- a/doc/edge_coloring.html +++ /dev/null @@ -1,98 +0,0 @@ - - - - - -Boost Graph Library: Edge Coloring - -C++ Boost - -
- -

- -edge_coloring -

- - -

-

- - - - - - - - - - -
Graphs:undirected, loop-free
Properties:color
Complexity:time: O(|E| |V|)
-
- - -
-  template <class Graph, class ColorMap>
-  typename boost::property_traits::value_type
-  edge_coloring(const Graph &g, ColorMap color);
-
- -

Computes an edge coloring for the vertices in the graph, using -an algorithm proposed by Misra et al. []. Given edges ordered -e1, e2, ..., en it assignes a -colors c1, c2, ..., cn in a way -that no vertex connects with 2 edges of the same color. Furthermore -at most m + 1 colors are used. - - - -

Where defined

-boost/graph/edge_coloring.hpp - -

Parameters

- -IN: const Graph& g -
- The graph object on which the algorithm will be applied. The type - Graph must be a model of - Edge List Graph and Incidence - Graph. -
- -OUT: ColorMap color -
- This property map records the colors of each edges. It must be a - model of - Read/Write Property Map whose key type is the same as the edge - descriptor type of the graph and whose value type is an integral type - that can store all values smaller or equal to m. -
- - -

Example

- -See example/edge_coloring.cpp. - -

See Also

- -sequential vertex ordering. - -
-
- - -
Copyright © 2013 -Maciej Piechotka (uzytkownik2@gmail.com) -
- - - diff --git a/doc/edge_list.html b/doc/edge_list.html deleted file mode 100644 index 6e627167f..000000000 --- a/doc/edge_list.html +++ /dev/null @@ -1,221 +0,0 @@ - - - -Boost Graph Library: Edge List Class - -C++ Boost - -
- - -

-
-edge_list<EdgeIterator, ValueType, DiffType>
-
-

- -

-The edge_list class is an adaptor that turns a pair of edge -iterators into a class that models EdgeListGraph. The -value_type of the edge iterator must be a std::pair (or -at least have first and second members). The -first_type and second_type of the pair must be the -same and they will be used for the graph's vertex_descriptor. -The ValueType and DiffType template parameters are only -needed if your compiler does not support partial -specialization. Otherwise they default to the correct types. - -

- -

Example

- -

-Applying the Bellman-Ford shortest paths algorithm to an -edge_list. - -

-

-  enum { u, v, x, y, z, N };
-  char name[] = { 'u', 'v', 'x', 'y', 'z' };
-
-  typedef std::pair<int,int> E;
-  E edges[] = { E(u,y), E(u,x), E(u,v),
-                E(v,u),
-                E(x,y), E(x,v),
-                E(y,v), E(y,z),
-                E(z,u), E(z,x) };
-
-  int weight[] = { -4, 8, 5,
-                   -2,
-                   9, -3,
-                   7, 2,
-                   6, 7 };
-
-  typedef boost::edge_list<E*> Graph;
-  Graph g(edges, edges + sizeof(edges) / sizeof(E));
-
-  std::vector<int> distance(N, std::numeric_limits<short>::max());
-  std::vector<int> parent(N,-1);
-
-  distance[z] = 0;
-  parent[z] = z;
-  bool r = boost::bellman_ford_shortest_paths(g, int(N), weight,
-                                              distance.begin(),
-                                              parent.begin());
-  if (r)
-    for (int i = 0; i < N; ++i)
-      std::cout << name[i] << ": " << distance[i]
-                << " " << name[parent[i]] << std::endl;
-  else
-    std::cout << "negative cycle" << std::endl;
-
-The output is the distance from the root and the parent -of each vertex in the shortest paths tree. -
-  u: 2 v
-  v: 4 x
-  x: 7 z
-  y: -2 u
-  z: 0 z
-
- -

-

- -

Where Defined

- -boost/graph/edge_list.hpp - -

-

Template Parameters

- -

- - - - - - - - - - - - - - - - -
ParameterDescription
EdgeIterator Must be model of InputIterator -who's value_type must be a pair of vertex descriptors.
ValueTypeThe value_type of the EdgeIterator.
-Default: std::iterator_traits<EdgeIterator>::value_type
DiffTypeThe difference_type of the EdgeIterator.
-Default: std::iterator_traits<EdgeIterator>::difference_type
-

- -

Model of

- -EdgeListGraph - -

- - -

Associated Types

- -
- -boost::graph_traits<edge_list>::vertex_descriptor -

-The type for the vertex descriptors associated with the -edge_list. This will be the same type as -std::iterator_traits<EdgeIterator>::value_type::first_type. - -
- - -boost::graph_traits<edge_list>::edge_descriptor - -

-The type for the edge descriptors associated with the -edge_list. - -
- - -boost::graph_traits<edge_list>::edge_iterator - -

-The type for the iterators returned by edges(). The iterator -category of the edge_iterator will be the same as that of the -EdgeIterator. - -
- -

Member Functions

- -
- - -edge_list(EdgeIterator first, EdgeIterator last) - -

-Creates a graph object with n vertices and with the -edges specified in the edge list given by the range [first,last). - -
- -

Non-Member Functions

- -
- - -std::pair<edge_iterator, edge_iterator>
-edges(const edge_list& g) - -

-Returns an iterator-range providing access to the edge set of graph g. - -
- - -vertex_descriptor
-source(edge_descriptor e, const edge_list& g) - -

-Returns the source vertex of edge e. - -
- - -vertex_descriptor
-target(edge_descriptor e, const edge_list& g) - -

-Returns the target vertex of edge e. - -
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/edge_predecessor_recorder.html b/doc/edge_predecessor_recorder.html deleted file mode 100644 index f4b0be765..000000000 --- a/doc/edge_predecessor_recorder.html +++ /dev/null @@ -1,197 +0,0 @@ - - - -Boost Graph Library: edge_predecessor_recorder - -C++ Boost - -
- -

-
-edge_predecessor_recorder<PredEdgeMap, EventTag>
-
-

- -This is an EventVisitor that records -the predecessor (or parent) edge of a vertex in a property -map. This is particularly useful in graph search algorithms where -recording the predecessors is an efficient way to encode the search -tree that was traversed during the search. The edge predecessor recorder is -typically used with the on_tree_edge or -on_relax_edge events and cannot be used with vertex events. This -visitor is meant to be used instead of predecessor_recorder when a -graph has parallel edges and it is necessary to know which incoming edge a -search algorithm -used to get to a particular vertex. - -

-edge_predecessor_recorder can be used with graph algorithms by -wrapping it with an algorithm-specific adaptor, such as bfs_visitor and dfs_visitor. Also, this event -visitor can be combined with other event visitors using -std::pair to form an EventVisitorList. - -

-Algorithms such as Dijkstra's and breadth-first search will not assign -a predecessor edge to the source vertex (which is the root of the search -tree). It is often useful to initialize the source vertex's -predecessor to a special value, thereby identifying the root vertex. -When using an algorithm like -depth-first search that creates a forest (multiple search trees) it -is useful to do the same for every vertex. This -way all the root nodes can be distinguished. - - - - -

Model of

- -EventVisitor - - -

Where Defined

- -

- -boost/graph/visitors.hpp - -

Template Parameters

- -

- - - - - - - - - - - - - - - -
ParameterDescriptionDefault
PredEdgeMap -A WritablePropertyMap -where the key and value types are the vertex and edge descriptor types, respectively, of the graph. - 
EventTag -The tag to specify when the edge_predecessor_recorder should be -applied during the graph algorithm. EventTag must be an -edge event. - 
- -

Associated Types

- - - - - - - - - - - - -
TypeDescription
edge_predecessor_recorder::event_filter -This will be the same type as the template parameter EventTag. -
- -

Member Functions

- -

- - - - - - - - - - - - - - - - -
MemberDescription
-edge_predecessor_recorder(PredEdgeMap pa); - -Construct an edge predecessor recorder object with predecessor property map -pa. -
-template <class Edge, class Graph>
-void operator()(Edge e, const Graph& g); -		 -Given edge e = (u,v), this records e as the -predecessor (or parent) edge of v. -
- -

Non-Member Functions

- - - - - - - - -
FunctionDescription
-template <class PredEdgeMap, class Tag>
-edge_predecessor_recorder<PredEdgeMap, Tag>
-record_edge_predecessors(PredEdgeMap pa, Tag); -		 -A convenient way to create a edge_predecessor_recorder. -
- -

See Also

- -Visitor concepts -

-The following are other event visitors: distance_recorder, -time_stamper, -and property_writer. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - - - - diff --git a/doc/edmonds_karp_max_flow.html b/doc/edmonds_karp_max_flow.html deleted file mode 100644 index 7b7df57de..000000000 --- a/doc/edmonds_karp_max_flow.html +++ /dev/null @@ -1,247 +0,0 @@ - - - -Boost Graph Library: Edmonds-Karp Maximum Flow - -C++ Boost - -
- -

-edmonds_karp_max_flow -

- -
-// named parameter version
-template <class Graph, class P, class T, class R>
-typename detail::edge_capacity_value<Graph, P, T, R>::value_type
-edmonds_karp_max_flow(Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor src,
-   typename graph_traits<Graph>::vertex_descriptor sink,
-   const bgl_named_params<P, T, R>& params = all defaults)
-
-// non-named parameter version
-template <class Graph,
-	  class CapacityEdgeMap, class ResidualCapacityEdgeMap,
-	  class ReverseEdgeMap, class ColorMap, class PredEdgeMap>
-typename property_traits<CapacityEdgeMap>::value_type
-edmonds_karp_max_flow(Graph& g,
-   typename graph_traits<Graph>::vertex_descriptor src,
-   typename graph_traits<Graph>::vertex_descriptor sink,
-   CapacityEdgeMap cap, ResidualCapacityEdgeMap res, ReverseEdgeMap rev,
-   ColorMap color, PredEdgeMap pred)
-
- -

-The edmonds_karp_max_flow() function calculates the maximum flow -of a network. See Section Network -Flow Algorithms for a description of maximum flow. The calculated -maximum flow will be the return value of the function. The function -also calculates the flow values f(u,v) for all (u,v) in -E, which are returned in the form of the residual capacity -r(u,v) = c(u,v) - f(u,v). - -

-There are several special requirements on the input graph and property -map parameters for this algorithm. First, the directed graph -G=(V,E) that represents the network must be augmented to -include the reverse edge for every edge in E. That is, the -input graph should be Gin = (V,{E U -ET}). The ReverseEdgeMap argument rev -must map each edge in the original graph to its reverse edge, that is -(u,v) -> (v,u) for all (u,v) in E. The -CapacityEdgeMap argument cap must map each edge in -E to a positive number, and each edge in ET -to 0. - -

-The algorithm is due to Edmonds and -Karp, though we are using the variation called the ``labeling -algorithm'' described in Network Flows. - -

-This algorithm provides a very simple and easy to implement solution to -the maximum flow problem. However, there are several reasons why this -algorithm is not as good as the push_relabel_max_flow() -or the boykov_kolmogorov_max_flow() -algorithm. - -

    -
  • In the non-integer capacity case, the time complexity is O(V - E2) which is worse than the time complexity of the - push-relabel algorithm O(V2E1/2) - for all but the sparsest of graphs.
    • - -
  • In the integer capacity case, if the capacity bound U is - very large then the algorithm will take a long time.
    • -
- - -

Where Defined

- -

-boost/graph/edmonds_karp_max_flow.hpp - -

- -

Parameters

- -IN: Graph& g -
- A directed graph. The - graph's type must be a model of VertexListGraph and IncidenceGraph For each edge - (u,v) in the graph, the reverse edge (v,u) must also - be in the graph. -
- -IN: vertex_descriptor src -
- The source vertex for the flow network graph. -
- -IN: vertex_descriptor sink -
- The sink vertex for the flow network graph. -
- -

Named Parameters

- - -IN: capacity_map(CapacityEdgeMap cap) -
- The edge capacity property map. The type must be a model of a - constant Lvalue Property Map. The - key type of the map must be the graph's edge descriptor type.
- Default: get(edge_capacity, g) -
- -OUT: residual_capacity_map(ResidualCapacityEdgeMap res) -
- This maps edges to their residual capacity. The type must be a model - of a mutable Lvalue Property - Map. The key type of the map must be the graph's edge descriptor - type.
- Default: get(edge_residual_capacity, g) -
- -IN: reverse_edge_map(ReverseEdgeMap rev) -
- An edge property map that maps every edge (u,v) in the graph - to the reverse edge (v,u). The map must be a model of - constant Lvalue - Property Map. The key type of the map must be the graph's edge - descriptor type.
- Default: get(edge_reverse, g) -
- -UTIL: color_map(ColorMap color) -
- Used by the algorithm to keep track of progress during the - breadth-first search stage. At the end of the algorithm, the white - vertices define the minimum cut set. The map must be a model of - mutable Lvalue Property Map. - The key type of the map should be the graph's vertex descriptor type, and - the value type must be a model of ColorValue.
- - Default: an - iterator_property_map created from a std::vector - of default_color_type of size num_vertices(g) and - using the i_map for the index map. -
- -UTIL: predecessor_map(PredEdgeMap pred) -
- Use by the algorithm to store augmenting paths. The map must be a - model of mutable Lvalue Property Map. - The key type must be the graph's vertex descriptor type and the - value type must be the graph's edge descriptor type.
- - Default: an - iterator_property_map created from a std::vector - of edge descriptors of size num_vertices(g) and - using the i_map for the index map. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- Maps each vertex of the graph to a unique integer in the range - [0, num_vertices(g)). This property map is only needed - if the default for the color or predecessor map is used. - The vertex index map must be a model of Readable Property - Map. The key type of the map must be the graph's vertex - descriptor type.
- Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- - -

Complexity

- -The time complexity is O(V E2) in the general case -or O(V E U) if capacity values are integers bounded by -some constant U. - -

Example

- -The program in example/edmonds-karp-eg.cpp -reads an example maximum flow problem (a graph with edge capacities) -from a file in the DIMACS format and computes the maximum flow. - - -

See Also

- -push_relabel_max_flow()
-boykov_kolmogorov_max_flow(). - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - - - - - - - - - diff --git a/doc/eg1-iso.cpp b/doc/eg1-iso.cpp deleted file mode 100644 index b16835c2d..000000000 --- a/doc/eg1-iso.cpp +++ /dev/null @@ -1,124 +0,0 @@ -// Boost.Graph library isomorphism test - -// Copyright (C) 2001 Douglas Gregor (gregod@cs.rpi.edu) -// -// Distributed under the Boost Software License, Version 1.0. (See -// accompanying file LICENSE_1_0.txt or copy at -// http://www.boost.org/LICENSE_1_0.txt) - -// For more information, see http://www.boost.org -// -// Revision History: -// -// 29 Nov 2001 Jeremy Siek -// Changed to use Boost.Random. -// 29 Nov 2001 Doug Gregor -// Initial checkin. - -#define BOOST_INCLUDE_MAIN -#include -#include -#include -//#include "isomorphism-v3.hpp" -#include -#include -#include -#include -#include -#include -#include - -using namespace boost; - -enum -{ - a, - b, - c, - d, - e, - f, - g, - h -}; -enum -{ - _1, - _2, - _3, - _4, - _5, - _6, - _7, - _8 -}; - -void test_isomorphism() -{ - typedef adjacency_list< vecS, vecS, bidirectionalS > GraphA; - typedef adjacency_list< vecS, vecS, bidirectionalS > GraphB; - - char a_names[] = "abcdefgh"; - char b_names[] = "12345678"; - - GraphA Ga(8); - add_edge(a, d, Ga); - add_edge(a, h, Ga); - add_edge(b, c, Ga); - add_edge(b, e, Ga); - add_edge(c, f, Ga); - add_edge(d, a, Ga); - add_edge(d, h, Ga); - add_edge(e, b, Ga); - add_edge(f, b, Ga); - add_edge(f, e, Ga); - add_edge(g, d, Ga); - add_edge(g, f, Ga); - add_edge(h, c, Ga); - add_edge(h, g, Ga); - - GraphB Gb(8); - add_edge(_1, _6, Gb); - add_edge(_2, _1, Gb); - add_edge(_2, _5, Gb); - add_edge(_3, _2, Gb); - add_edge(_3, _4, Gb); - add_edge(_4, _2, Gb); - add_edge(_4, _3, Gb); - add_edge(_5, _4, Gb); - add_edge(_5, _6, Gb); - add_edge(_6, _7, Gb); - add_edge(_6, _8, Gb); - add_edge(_7, _8, Gb); - add_edge(_8, _1, Gb); - add_edge(_8, _7, Gb); - - std::vector< std::size_t > in_degree_A(num_vertices(Ga)); - boost::detail::compute_in_degree(Ga, &in_degree_A[0]); - - std::vector< std::size_t > in_degree_B(num_vertices(Gb)); - boost::detail::compute_in_degree(Gb, &in_degree_B[0]); - - degree_vertex_invariant< std::size_t*, GraphA > invariantA( - &in_degree_A[0], Ga); - degree_vertex_invariant< std::size_t*, GraphB > invariantB( - &in_degree_B[0], Gb); - - std::vector< graph_traits< GraphB >::vertex_descriptor > f( - num_vertices(Ga)); - - bool ret = isomorphism(Ga, Gb, &f[0], invariantA, invariantB, - (invariantB.max)(), get(vertex_index, Ga), get(vertex_index, Gb)); - assert(ret == true); - - for (std::size_t i = 0; i < num_vertices(Ga); ++i) - std::cout << "f(" << a_names[i] << ")=" << b_names[f[i]] << std::endl; - - BOOST_TEST(verify_isomorphism(Ga, Gb, &f[0])); -} - -int test_main(int, char*[]) -{ - test_isomorphism(); - return boost::report_errors(); -} diff --git a/doc/erdos_renyi_generator.html b/doc/erdos_renyi_generator.html deleted file mode 100644 index 14b40dd0d..000000000 --- a/doc/erdos_renyi_generator.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - Boost Graph Library: Erdös-Renyi Generator - - - - -C++ Boost - -erdos_renyi_iterator - -
- -
-template<typename RandomGenerator, typename Graph>
-class erdos_renyi_iterator
-{
-public:
-  typedef std::input_iterator_tag iterator_category;
-  typedef std::pair<vertices_size_type, vertices_size_type> value_type;
-  typedef const value_type& reference;
-  typedef const value_type* pointer;
-  typedef void difference_type;
-
-  erdos_renyi_iterator();
-  erdos_renyi_iterator(RandomGenerator& gen, vertices_size_type n,
-                       double fraction = 0.0, bool allow_self_loops = false);
-  erdos_renyi_iterator(RandomGenerator& gen, vertices_size_type n,
-                       edges_size_type m, bool allow_self_loops = false);
-
-  // Iterator operations
-  reference operator*() const;
-  pointer operator->() const;
-  erdos_renyi_iterator& operator++();
-  erdos_renyi_iterator operator++(int);
-  bool operator==(const erdos_renyi_iterator& other) const;
-  bool operator!=(const erdos_renyi_iterator& other) const;
-};
-
- -

This class template implements a generator for Erdös-Renyi -graphs, suitable for initializing an adjacency_list or other graph -structure with iterator-based initialization. An Erdös-Renyi -graph G = (n, p) is a graph with n vertices -that. The probability of having an edge (u, v) in G -is p for any vertices u and v. Typically, -there are no self-loops, but the generator can optionally introduce -self-loops with probability p. This generator will not -produce any parallel edges and will produce edges in sorted order (as -required by, e.g., the compressed_sparse_row_graph).

- -

Erdös-Renyi graphs typically exhibit very little -structure. For this reason, they are rarely useful in modeling -real-world problems. However, they are often used when determining -the theoretical complexity of complex graph algorithms.

- -

If you want the possibility of generating parallel edges and don't -care about sorted order, use the erdos_renyi_iterator.

- -

Where Defined

- -boost/graph/erdos_renyi_generator.hpp - -

Constructors

- - -
erdos_renyi_iterator();
-
-Constructs a past-the-end iterator. -
- -
-erdos_renyi_iterator(RandomGenerator& gen, vertices_size_type n,
-                     double fraction = 0.0, bool allow_self_loops = false);
-
-
-Constructs an Erdös-Renyi generator iterator that creates a -graph with n vertices and a given fraction of the -total number of edges that a simple graph may have. -probability. Random vertices and edges are selected using the -random number generator gen. Self-loops are permitted only when -allow_self_loops is true. -
- -
-erdos_renyi_iterator(RandomGenerator& gen, vertices_size_type n,
-                     edges_size_type m, bool allow_self_loops = false);
-
-
-Constructs an Erdös-Renyi generator iterator that creates a -graph with n vertices and m edges. -probability. Random vertices and edges are selected using the -random number generator gen. Self-loops are permitted only when -allow_self_loops is true. -
- -

Example

- -
-#include <boost/graph/adjacency_list.hpp>
-#include <boost/graph/erdos_renyi_generator.hpp>
-#include <boost/random/linear_congruential.hpp>
-
-typedef boost::adjacency_list<> Graph;
-typedef boost::erdos_renyi_iterator<boost::minstd_rand, Graph> ERGen;
-
-int main()
-{
-  boost::minstd_rand gen;
-  // Create graph with 100 nodes and edges with probability 0.05
-  Graph g(ERGen(gen, 100, 0.05), ERGen(), 100);
-  return 0;
-}
-
- -
-
- - -
Copyright © 2005 -Doug Gregor, Indiana University ()
- Andrew Lumsdaine, -Indiana University () -
- - - diff --git a/doc/exception.html b/doc/exception.html deleted file mode 100644 index 42a968186..000000000 --- a/doc/exception.html +++ /dev/null @@ -1,46 +0,0 @@ - - - -Boost Graph Library: Exceptions - -C++ Boost - -
- -

boost/graph/exception.hpp

- -

-The BGL defines several exception classes for reporting errors from -BGL algorithms. Many of the BGL algorithms place certain requirements -on the input graph. If these requirements are not met then the -algorithm can not successfully complete, and instead throws the -appropriate exception. -

- -

Synopsis

- -
-  struct bad_graph : public invalid_argument {
-    bad_graph(const string& what_arg);
-  };
-  struct not_a_dag : public bad_graph {
-    not_a_dag();
-  };
-  struct negative_edge : public bad_graph {
-    negative_edge();
-  };
-  struct negative_cycle : public bad_graph {
-    negative_cycle();
-  };
-  struct not_connected : public bad_graph {
-    not_connected();
-  };
-
diff --git a/doc/faq.html b/doc/faq.html deleted file mode 100644 index 53c9c38f6..000000000 --- a/doc/faq.html +++ /dev/null @@ -1,152 +0,0 @@ - - - -Boost Graph Library: FAQ - -C++ Boost - -
- -

Frequently Asked Questions

- -
    - -
  1. -How do I perform an early exit from an algorithm such as BFS?
    - -

    -Create a visitor that throws an exception when you want to cut off the -search, then put your call to breadth_first_search inside of -an appropriate try/catch block. This strikes many programmers as a -misuse of exceptions, however, much thought was put into the decision -to have exceptions has the preferred way to exit early. See boost -email discussions for more details. -

    - -
  2. -Why is the visitor parameter passed by value rather than reference -in the various BGL algorithms?
    - -

    -One of the usage scenarios that we wanted to support with the -algorithms was creating visitor objects on the fly, within the -argument list of the call to the graph algorithm. In this situation, -the visitor object is a temporary object. Now there is a truly -unfortunate rule in the C++ standard that says a temporary cannot be -bound to a non-const reference parameter. So we had to decide whether -we wanted to support this kind of usage and call-by-value, or not and -call-by-reference. We chose call-by-value, following in the footsteps -of the STL (which passes functors by value). The disadvantage of this -decision is that if your visitor contains state and changes that state -during the algorithm, the change will be made to a copy of the visitor -object, not the visitor object passed in. Therefore you may want the -visitor to hold this state by pointer or reference. -

    - -
  3. Why does the BGL interface use friend functions (or free functions) - instead of member functions?
    -

    -For the most part, the differences between member functions and free -functions are syntactic, and not very important, though people can get -religious about them. However, we had one technical reason for -favoring free functions. A programmer can overload a free function for -a type coming from a 3rd party without modifying the source -code/definition of that type. There are several uses of this in the -BGL. For example, Stanford GraphBase and LEDA graphs can both be used -in BGL algorithms because of overloads in stanford_graph.hpp -and leda_graph.hpp. One can even use -std::vector<std::list> as a graph due to the overloads -in vector_as_graph.hpp. -

    -

    -Of course, there is a way to adapt 3rd party classes into an interface -with member functions. You create an adaptor class. However, the -disadvantage of an adaptor class (compared to overloaded functions) is -that one has to physically wrap and unwrap the objects as they go -into/out of BGL algorithms. So the overloaded function route is more -convenient. Granted, this is not a huge difference, but since there -weren't other strong reasons, it was enough for us to choose free -functions. -

    - -

    -Our religious reason for choosing free functions is to send the message -that BGL is a generic library, and not a traditional object-oriented -library. OO was hip in the 80s and 90s, but its time we moved beyond! -

    -
    4. - - - - -
  4. How do I create a graph where the edges are sorted/ordered?
    -

    The example - ordered_out_edges.cpp shows how to do this.

    -
    5. - -
  5. Why does the algorithm X work with adjacency_list where - VertexList=vecS but not when VertexList=listS?

    - Often the reason is that the algorithm expects to find the - vertex_index property stored in the graph. When - VertexList=vecS, the adjacency_list automatically - has a vertex_index property. However, when VertexList=listS - this is not the case, and the vertex_index property must be - explicitly added, and initialized. For example, -
    -  // specify the graph type
-  typedef adjacency_list<listS, listS, undirectedS,
-                         property<vertex_index_t, std::size_t>,
-                         no_property
-                        > graph_t;
-
-  // construct a graph object
-  graph_t G(num_nodes);
-  // obtain a property map for the vertex_index property
-  property_map<graph_t, vertex_index_t>::type
-    index = get(vertex_index, G);
-  // initialize the vertex_index property values
-  graph_traits<graph_t>::vertex_iterator vi, vend;
-  graph_traits<graph_t>::vertices_size_type cnt = 0;
-  for(boost::tie(vi,vend) = vertices(G); vi != vend; ++vi)
-    put(index, *vi, cnt++);
-
    -
    6. - -
  6. When using algorithm X, why do I get an error about a property -not being found, such as: -
    -../../../boost/concept_check.hpp:209: no match for
-`boost::detail::error_property_not_found & ==
- boost::detail::error_property_not_found &'
-
    -or a message such as: -
    -../../..\boost/graph/depth_first_search.hpp(78) : error C2664: 'white'
-: cannot convert parameter 1 from
- 'struct boost::detail::error_property_not_found'
- to 'enum boost::default_color_type'
-
    - -The reason is that the algorithm expected to find some property (like color or -weight) attached to the vertices or edges of the graph, but didn't -find it. You need to either add an interior property to the graph, or -create an exterior property map for the property and pass it as an -argument to the algorithm.
    7. - - - -
- - - diff --git a/doc/file_dependency_example.html b/doc/file_dependency_example.html deleted file mode 100644 index bbf1d03eb..000000000 --- a/doc/file_dependency_example.html +++ /dev/null @@ -1,363 +0,0 @@ - - - -File Dependency Example - -C++ Boost - -
- - -

-File Dependency Example -

- -

-One of the most common uses of the graph abstraction in computer -science is to track dependencies. An example of dependency tracking -that we deal with on a day to day basis is the compilation -dependencies for files in programs that we write. These dependencies -are used inside programs such as make or in an IDE such as -Visual C++ to minimize the number of files that must be recompiled -after some changes have been made. - -

-Figure 1 shows a graph that has a vertex -for each source file, object file, and library that is used in the -killerapp program. The edges in the graph show which files -are used in creating other files. The choice of which direction to -point the arrows is somewhat arbitrary. As long as we are consistent -in remembering that the arrows mean ``used by'' then things will work -out. The opposite direction would mean ``depends on''. - -

- -

-
- - - -
Figure 1: -A graph representing file dependencies.
-

- -

-A compilation system such as make has to be able to answer a -number of questions: - -

- -

    -
  1. If we need to compile (or recompile) all of the files, what order - should that be done it? -
    2. -
  2. What files can be compiled in parallel? -
    3. -
  3. If a file is changed, which files must be recompiled? -
    4. -
  4. Are there any cycles in the dependencies? (which means the user - has made a mistake and an error should be emitted) -
    5. -
- -

-In the following examples we will formulate each of these questions in -terms of the dependency graph, and then find a graph algorithm to -provide the solution. The graph in Figure -1 will be used in all of the following examples. The source code -for this example can be found in the file examples/file_dependencies.cpp. - -

- -

Graph Setup

- -

-Here we show the construction of the graph. First, these are the required -header files: - -

-

-#include <iostream> // std::cout
-#include <utility> // std::pair
-#include <boost/graph/graph_traits.hpp>
-#include <boost/graph/adjacency_list.hpp>
-#include <boost/graph/topological_sort.hpp>
-
- -

-For simplicity we have -constructed the graph "by-hand". A compilation system such -as make would instead parse a Makefile to get the -list of files and to set-up the dependencies. We use the -adjacency_list class to represent the graph. The -vecS selector means that a std::vector will be used -to represent each edge-list, which provides efficient traversal. The -bidirectionalS selector means we want a directed graph with access to both the edges outgoing from each vertex and the edges incoming to each vertex, and the -color_property attaches a color property to each vertex of the -graph. The color property will be used in several of the algorithms in -the following sections. - -

-

-  enum files_e { dax_h, yow_h, boz_h, zow_h, foo_cpp,
-                 foo_o, bar_cpp, bar_o, libfoobar_a,
-                 zig_cpp, zig_o, zag_cpp, zag_o,
-                 libzigzag_a, killerapp, N };
-  const char* name[] = { "dax.h", "yow.h", "boz.h", "zow.h", "foo.cpp",
-                         "foo.o", "bar.cpp", "bar.o", "libfoobar.a",
-                         "zig.cpp", "zig.o", "zag.cpp", "zag.o",
-                         "libzigzag.a", "killerapp" };
-
-  typedef std::pair<int, int> Edge;
-  Edge used_by[] = {
-    Edge(dax_h, foo_cpp), Edge(dax_h, bar_cpp), Edge(dax_h, yow_h),
-    Edge(yow_h, bar_cpp), Edge(yow_h, zag_cpp),
-    Edge(boz_h, bar_cpp), Edge(boz_h, zig_cpp), Edge(boz_h, zag_cpp),
-    Edge(zow_h, foo_cpp),
-    Edge(foo_cpp, foo_o),
-    Edge(foo_o, libfoobar_a),
-    Edge(bar_cpp, bar_o),
-    Edge(bar_o, libfoobar_a),
-    Edge(libfoobar_a, libzigzag_a),
-    Edge(zig_cpp, zig_o),
-    Edge(zig_o, libzigzag_a),
-    Edge(zag_cpp, zag_o),
-    Edge(zag_o, libzigzag_a),
-    Edge(libzigzag_a, killerapp)
-  };
-
-  using namespace boost;
-  typedef adjacency_list<vecS, vecS, bidirectionalS,
-      property<vertex_color_t, default_color_type>
-    > Graph;
-  Graph g(used_by, used_by + sizeof(used_by) / sizeof(Edge), N);
-  typedef graph_traits<Graph>::vertex_descriptor Vertex;
-
- -

- -

Compilation Order (All Files)

- -

-On the first invocation of make for a particular project, all -of the files must be compiled. Given the dependencies between the -various files, what is the correct order in which to compile and link -them? First we need to formulate this in terms of a graph. Finding a -compilation order is the same as ordering the vertices in the graph. -The constraint on the ordering is the file dependencies which we have -represented as edges. So if there is an edge (u,v) in the graph -then v better not come before u in the ordering. It -turns out that this kind of constrained ordering is called a -topological sort. Therefore, answering the question of -compilation order is as easy as calling the BGL algorithm topological_sort(). The -traditional form of the output for topological sort is a linked-list -of the sorted vertices. The BGL algorithm instead puts the sorted -vertices into any OutputIterator, -which allows for much more flexibility. Here we use the -std::front_insert_iterator to create an output iterator that -inserts the vertices on the front of a linked list. Other possible -options are writing the output to a file or inserting into a different -STL or custom-made container. - -

-

-  typedef std::list<Vertex> MakeOrder;
-  MakeOrder make_order;
-  boost::topological_sort(g, std::front_inserter(make_order));
-
-  std::cout << "make ordering: ";
-  for (MakeOrder::iterator i = make_order.begin();
-       i != make_order.end(); ++i)
-    std::cout << name[*i] << " ";
-  std::cout << std::endl;
-
-The output of this is: -
-  make ordering: zow.h boz.h zig.cpp zig.o dax.h yow.h zag.cpp \
-  zag.o bar.cpp bar.o foo.cpp foo.o libfoobar.a libzigzag.a killerapp
-
- -

- -

-Parallel Compilation -

- -

-Another question the compilation system might need to answer is: what -files can be compiled simultaneously? This would allow the system to -spawn threads and utilize multiple processors to speed up the build. -This question can also be put in a slightly different way: what is the -earliest time that a file can be built assuming that an unlimited -number of files can be built at the same time? The main criteria for -when a file can be built is that all of the files it depends on must -already be built. To simplify things for this example, we'll assume -that each file takes 1 time unit to build (even header files). For -parallel compilation, we can build all of the files corresponding to -vertices with no dependencies, e.g., those that have -an in-degree of 0, in the first step. For all other files, the -main observation for determining the ``time slot'' for a file is that -the time slot must be one more than the maximum time-slot of the files -it depends on. - -

We start by creating a vector time that will store the - time step at which each file can be built. We initialize every value - with time step zero.

- -

-

-  std::vector<int> time(N, 0);
-
- -

Now, we want to visit the vertices against in topological order, - from those files that need to be built first until those that need - to be built last. However, instead of printing out the order - immediately, we will compute the time step in which each file should - be built based on the time steps of the files it depends on. We - only need to consider those files whose in-degree is greater than - zero.

- -
-    for (i = make_order.begin(); i != make_order.end(); ++i) {
-      if (in_degree (*i, g) > 0) {
-        Graph::in_edge_iterator j, j_end;
-        int maxdist = 0;
-        for (boost::tie(j, j_end) = in_edges(*i, g); j != j_end; ++j)
-          maxdist = std::max(time[source(*j, g)], maxdist);
-        time[*i]=maxdist+1;
-      }
-    }
-
- -

-Last, we output the time-slot that we've calculated for each vertex. - -

-

-  std::cout << "parallel make ordering, " << std::endl
-       << "  vertices with same group number" << std::endl
-       << "  can be made in parallel" << std::endl << std::endl;
-  for (boost::tie(i, iend) = vertices(g); i != iend; ++i)
-    std::cout << "time_slot[" << name[*i] << "] = " << time[*i] << std::endl;
-
-The output is: -
-  parallel make ordering,
-    vertices with same group number
-    can be made in parallel
-  time_slot[dax.h] = 0
-  time_slot[yow.h] = 1
-  time_slot[boz.h] = 0
-  time_slot[zow.h] = 0
-  time_slot[foo.cpp] = 1
-  time_slot[foo.o] = 2
-  time_slot[bar.cpp] = 2
-  time_slot[bar.o] = 3
-  time_slot[libfoobar.a] = 4
-  time_slot[zig.cpp] = 1
-  time_slot[zig.o] = 2
-  time_slot[zag.cpp] = 2
-  time_slot[zag.o] = 3
-  time_slot[libzigzag.a] = 5
-  time_slot[killerapp] = 6
-
- -

- -

- -
-Cyclic Dependencies -

- -

-Another question the compilation system needs to be able to answer is -whether there are any cycles in the dependencies. If there are cycles, -the system will need to report an error to the user so that the cycles -can be removed. One easy way to detect a cycle is to run a depth-first search, and if the -search runs into an already discovered vertex (of the current search -tree), then there is a cycle. The BGL graph search algorithms (which -includes -depth_first_search()) are all extensible via the -visitor mechanism. A visitor is similar to a function object, -but it has several methods instead of just the one -operator(). The visitor's methods are called at certain -points within the algorithm, thereby giving the user a way to extend -the functionality of the graph search algorithms. See Section Visitor Concepts -for a detailed description of visitors. - -

-We will create a visitor class and fill in the back_edge() -method, which is the DFSVisitor method -that is called when DFS explores an edge to an already discovered -vertex. A call to this method indicates the existence of a -cycle. Inheriting from dfs_visitor<> -provides the visitor with empty versions of the other visitor methods. -Once our visitor is created, we can construct and object and pass it -to the BGL algorithm. Visitor objects are passed by value inside of -the BGL algorithms, so the has_cycle flag is stored by -reference in this visitor. - -

-

-  struct cycle_detector : public dfs_visitor<>
-  {
-    cycle_detector( bool& has_cycle)
-      : _has_cycle(has_cycle) { }
-
-    template <class Edge, class Graph>
-    void back_edge(Edge, Graph&) {
-      _has_cycle = true;
-    }
-  protected:
-    bool& _has_cycle;
-  };
-
- -

-We can now invoke the BGL depth_first_search() -algorithm and pass in the cycle detector visitor. - -

-

-  bool has_cycle = false;
-  cycle_detector vis(has_cycle);
-  boost::depth_first_search(g, visitor(vis));
-  std::cout << "The graph has a cycle? " << has_cycle << std::endl;
-
- -

-The graph in Figure 1 (ignoring the dotted -line) did not have any cycles, but if we add a dependency between -bar.cpp and dax.h there there will be. Such a -dependency would be flagged as a user error. - -

-

-  add_edge(bar_cpp, dax_h, g);
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/filtered_graph.html b/doc/filtered_graph.html deleted file mode 100644 index 66527b0e9..000000000 --- a/doc/filtered_graph.html +++ /dev/null @@ -1,535 +0,0 @@ - - - -Boost Graph Library: Filtered Graph - -C++ Boost - -
- - - -

-
-filtered_graph<Graph, EdgePredicate, VertexPredicate>
-
-

- - -

-The filtered_graph class template is an adaptor that creates -a filtered view of a graph. The predicate function objects determine -which edges and vertices of the original graph will show up in the -filtered graph. If the edge predicate returns true for an -edge then it shows up in the filtered graph, and if the predicate -returns false then the edge does not appear in the filtered -graph. Likewise for vertices. The filtered_graph class does -not create a copy of the original graph, but uses a reference to the -original graph. The lifetime of the original graph must extend past -any use of the filtered graph. The filtered graph does not change the -structure of the original graph, though vertex and edge properties of -the original graph can be changed through property maps of the -filtered graph. Vertex and edge descriptors of the filtered graph are -the same as, and interchangeable with, the vertex and edge descriptors -of the original graph. - -

The num_vertices and num_edges functions do not filter -before returning results, so they return the number of vertices or -edges in the underlying graph, unfiltered [2]. - -

Example

- -

-In this example we will filter a graph's edges based on edge -weight. We will keep all edges with positive edge weight. -First, we create a predicate function object. - -

-template <typename EdgeWeightMap>
-struct positive_edge_weight {
-  positive_edge_weight() { }
-  positive_edge_weight(EdgeWeightMap weight) : m_weight(weight) { }
-  template <typename Edge>
-  bool operator()(const Edge& e) const {
-    return 0 < get(m_weight, e);
-  }
-  EdgeWeightMap m_weight;
-};
-
- -Now we create a graph and print out the filtered graph. -
-int main()
-{
-  using namespace boost;
-
-  typedef adjacency_list<vecS, vecS, directedS,
-    no_property, property<edge_weight_t, int> > Graph;
-  typedef property_map<Graph, edge_weight_t>::type EdgeWeightMap;
-
-  enum { A, B, C, D, E, N };
-  const char* name = "ABCDE";
-  Graph g(N);
-  add_edge(A, B, 2, g);
-  add_edge(A, C, 0, g);
-  add_edge(C, D, 1, g);
-  add_edge(C, E, 0, g);
-  add_edge(D, B, 3, g);
-  add_edge(E, C, 0, g);
-
-  positive_edge_weight<EdgeWeightMap> filter(get(edge_weight, g));
-  filtered_graph<Graph, positive_edge_weight<EdgeWeightMap> >
-    fg(g, filter);
-
-  std::cout << "filtered edge set: ";
-  print_edges(fg, name);
-
-  std::cout << "filtered out-edges:" << std::endl;
-  print_graph(fg, name);
-
-  return 0;
-}
-
-The output is: -
-filtered edge set: (A,B) (C,D) (D,B)
-filtered out-edges:
-A --> B
-B -->
-C --> D
-D --> B
-E -->
-
- -

- -

Template Parameters

- -

- - - - - - - - - - - - - - - - - - - - - -
ParameterDescriptionDefault
GraphThe underlying graph type. 
EdgePredicate A function object that selects -which edges from the original graph will appear in the filtered -graph. The function object must model Predicate. The -argument type for the function object must be the edge descriptor type -of the graph. Also, the predicate must be Default Constructible [1]. 
VertexPredicateA function object that selects -which vertices from the original graph will appear in the filtered -graph. The function object must model Predicate. The -argument type for the function object must be the vertex descriptor type -of the graph. Also, the predicate must be Default Constructible [1].keep_all
-

- -

Model of

- -

-This depends on the underlying graph type. If the underlying -Graph type models VertexAndEdgeListGraph and PropertyGraph then so does the -filtered graph. If the underlying Graph type models fewer or -smaller concepts than these, then so does the filtered graph. - -

- -

Where Defined

- -

-boost/graph/filtered_graph.hpp - -

- -

Associated Types

- -
- -graph_traits<filtered_graph>::vertex_descriptor -

- -The type for the vertex descriptors associated with the -filtered_graph, which is the same type as the -vertex_descriptor for the original Graph. - - -
- -graph_traits<filtered_graph>::edge_descriptor
-

-The type for the edge descriptors associated with the -filtered_graph, which is the same type as the -edge_descriptor for the original Graph. - -
- -graph_traits<filtered_graph>::vertex_iterator
-

-The type for the iterators returned by vertices(), -which is: -
-filter_iterator<VertexPredicate, graph_traits<Graph>::vertex_iterator>
-
-The iterator is a model of MultiPassInputIterator. - - -
- -graph_traits<filtered_graph>::edge_iterator -

-The type for the iterators returned by edges(), which is: -
-filter_iterator<EdgePredicate, graph_traits<Graph>::edge_iterator>
-
-The iterator is a model of MultiPassInputIterator. - -
- - -graph_traits<filtered_graph>::out_edge_iterator -

-The type for the iterators returned by out_edges(), which is: -
-filter_iterator<EdgePredicate, graph_traits<Graph>::out_edge_iterator>
-
-The iterator is a model of MultiPassInputIterator. - - -
- -graph_traits<filtered_graph>::adjacency_iterator -

-The type for the iterators returned by adjacent_vertices(). - -The adjacency_iterator models the same iterator concept as -out_edge_iterator. - -
- -graph_traits<filtered_graph>::directed_category
-

-Provides information about whether the graph is directed -(directed_tag) or undirected (undirected_tag). - -
- -graph_traits<filtered_graph>::edge_parallel_category
-

-This describes whether the graph class allows the insertion of -parallel edges (edges with the same source and target). The two tags -are allow_parallel_edge_tag and -disallow_parallel_edge_tag. - -
- -graph_traits<filtered_graph>::vertices_size_type -

-The type used for dealing with the number of vertices in the graph. - -
- -graph_traits<filtered_graph>::edges_size_type -

-The type used for dealing with the number of edges in the graph. - -
- -graph_traits<filtered_graph>::degree_size_type -

-The type used for dealing with the number of edges incident to a vertex -in the graph. - -
- -property_map<filtered_graph, Property>::type
-and
-property_map<filtered_graph, Property>::const_type -

-The property map type for vertex or edge properties in the graph. -The same property maps from the adapted graph are available -in the filtered graph. - -
- -

Member Functions

- -
- -
-filtered_graph(Graph& g, EdgePredicate ep, VertexPredicate vp)
-
-Create a filtered graph based on the graph g and the -edge filter ep and vertex filter vp. - -
- -
-filtered_graph(Graph& g, EdgePredicate ep)
-
-Create a filtered graph based on the graph g and the -edge filter ep. All vertices from the original graph -are retained. - -
- -filtered_graph(const filtered_graph& x) - -This creates a filtered graph for the same underlying graph -as x. Anotherwords, this is a shallow copy. - -
- -
-filtered_graph& operator=(const filtered_graph& x)
-
-This creates a filtered graph for the same underlying graph -as x. Anotherwords, this is a shallow copy. - -
- -

- -

Non-Member Functions

- -

Structure Access

- -
- -
-std::pair<vertex_iterator, vertex_iterator>
-vertices(const filtered_graph& g)
-
-Returns an iterator-range providing access to the vertex set of graph -g. - -
- -
-std::pair<edge_iterator, edge_iterator>
-edges(const filtered_graph& g)
-
-Returns an iterator-range providing access to the edge set of graph -g. - -
- -
-std::pair<adjacency_iterator, adjacency_iterator>
-adjacent_vertices(vertex_descriptor u, const filtered_graph& g)
-
-Returns an iterator-range providing access to the vertices adjacent to -vertex u in graph g. - -
- - -
-std::pair<out_edge_iterator, out_edge_iterator>
-out_edges(vertex_descriptor u, const filtered_graph& g)
-
-Returns an iterator-range providing access to the out-edges of vertex -u in graph g. If the graph is undirected, this -iterator-range provides access to all edges incident on vertex -u. For both directed and undirected graphs, for an out-edge -e, source(e, g) == u and target(e, g) == v -where v is a vertex adjacent to u. - -
- -
-std::pair<in_edge_iterator, in_edge_iterator>
-in_edges(vertex_descriptor v, const filtered_graph& g)
-
-Returns an iterator-range providing access to the in-edges of vertex -v in graph g. For an in-edge e, -target(e, g) == v and source(e, g) == u for some -vertex u that is adjacent to v, whether the graph is -directed or undirected. - -
- -
-vertex_descriptor
-source(edge_descriptor e, const filtered_graph& g)
-
-Returns the source vertex of edge e. - -
- -
-vertex_descriptor
-target(edge_descriptor e, const filtered_graph& g)
-
-Returns the target vertex of edge e. - -
- -
-degree_size_type
-out_degree(vertex_descriptor u, const filtered_graph& g)
-
-Returns the number of edges leaving vertex u. - -
- -
-degree_size_type
-in_degree(vertex_descriptor u, const filtered_graph& g)
-
-Returns the number of edges entering vertex u. - -
- -

-vertices_size_type
-num_vertices(const filtered_graph& g)
-
-Returns the number of vertices in the underlying graph [2]. - -
- -

-edges_size_type
-num_edges(const filtered_graph& g)
-
-Returns the number of edges in the underlying graph [2]. - -
- -
-std::pair<edge_descriptor, bool>
-edge(vertex_descriptor u, vertex_descriptor v,
-     const filtered_graph& g)
-
-Returns the edge connecting vertex u to vertex v in -graph g. - -
- -
-template <typename G, typename EP, typename VP>
-std::pair<out_edge_iterator, out_edge_iterator>
-edge_range(vertex_descriptor u, vertex_descriptor v,
-	   const filtered_graph& g)
-
-Returns a pair of out-edge iterators that give the range for all the -parallel edges from u to v. This function only works -when the underlying graph supports edge_range, which requires -that it sorts its out edges according to target vertex and allows -parallel edges. The adjacency_list class with -OutEdgeList=multisetS is an example of such a graph. - - -
- -

Property Map Access

- -
- -
-template <class PropertyTag>
-property_map<filtered_graph, PropertyTag>::type
-get(PropertyTag, filtered_graph& g)
-
-template <class PropertyTag>
-property_map<filtered_graph, Tag>::const_type
-get(PropertyTag, const filtered_graph& g)
-
-Returns the property map object for the vertex property specified by -PropertyTag. The PropertyTag must match one of the -properties specified in the graph's VertexProperty template -argument. - -
- -
-template <class PropertyTag, class X>
-typename property_traits<property_map<filtered_graph, PropertyTag>::const_type>::value_type
-get(PropertyTag, const filtered_graph& g, X x)
-
-This returns the property value for x, where x is either -a vertex or edge descriptor. -
- -
-template <class PropertyTag, class X, class Value>
-void
-put(PropertyTag, const filtered_graph& g, X x, const Value& value)
-
-This sets the property value for x to -value. x is either a vertex or edge descriptor. -Value must be convertible to -typename property_traits<property_map<filtered_graph, PropertyTag>::type>::value_type - -
- -

See Also

- -property_map, -graph_traits - -

Notes

- -

-[1] The reason for requiring Default -Constructible in the EdgePredicate and -VertexPredicate types is that these predicates are stored -by-value (for performance reasons) in the filter iterator adaptor, and -iterators are required to be Default Constructible by the C++ -Standard. - -

[2] It would be nicer to return the number of -vertices (or edges) remaining after the filter has been applied, but -this has two problems. The first is that it would take longer to -calculate, and the second is that it would interact badly with the -underlying vertex/edge index mappings. The index mapping would no -longer fall in the range [0,num_vertices(g)) (resp. [0, -num_edges(g))) which is assumed in many of the algorithms. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/find_flow_cost.html b/doc/find_flow_cost.html deleted file mode 100644 index 63c0274be..000000000 --- a/doc/find_flow_cost.html +++ /dev/null @@ -1,139 +0,0 @@ - - - -Boost Graph Library: Find Flow Cost - -C++ Boost - -
- -

-find_flow_cost -

- -
-// named parameter version
-template <class Graph>
-typename property_traits<typename property_map < Graph, edge_capacity_t >::type>::value_type
-find_flow_cost(const Graph & g,
-        const bgl_named_params<P, T, R> & params  = all defaults)
-
-// non-named parameter version
-template<class Graph, class Capacity, class ResidualCapacity, class Weight>
-typename property_traits<typename property_map < Graph, edge_capacity_t >::type>::value_type
-find_flow_cost(const Graph & g, Capacity capacity, ResidualCapacity residual_capacity, Weight weight)
-
- -

-The find_flow_cost() function calculates the minimum cost maximum flow value of a network and given flow. See Section Network -Flow Algorithms for a description of maximum flow. -The function calculates the cost from the flow values f(u,v) for (u,v) in -E, which are passed in the form of the residual capacity -r(u,v) = c(u,v) - f(u,v). - -

-In order to compute the min cost max flow use : -successive_shortest_path_nonnegative_weights() or -cycle_canceling(). - -

Where Defined

- -

-boost/graph/successive_shortest_path_nonnegative_weights.hpp - -

- -

Parameters

- -IN: const Graph& g -
- A directed graph. The - graph's type must be a model of VertexListGraph and IncidenceGraph For each edge - (u,v) in the graph, the reverse edge (v,u) must also - be in the graph. -
-

Named Parameters

- - -IN: capacity_map(CapacityEdgeMap cap) -
- The edge capacity property map. The type must be a model of a - constant Lvalue Property Map. The - key type of the map must be the graph's edge descriptor type.
- Default: get(edge_capacity, g) -
- -IN: residual_capacity_map(ResidualCapacityEdgeMap res) -
- This maps edges to their residual capacity. The type must be a model - of a mutable Lvalue Property - Map. The key type of the map must be the graph's edge descriptor - type.
- Default: get(edge_residual_capacity, g) -
- - -IN: weight_map(WeightMap w_map) -
- The weight or ``cost'' of each edge in the graph. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for this map must be - the same as the value type of the distance map.
- Default: get(edge_weight, g)
- -
- -

Complexity

-The complexity is O(|E|), - -

Example

- -The function is used in the successive_shortest_path_nonnegative_weights example. The program in example/successive_shortest_path_nonnegative_weights_example.cpp. - -

See Also

- -cycle_canceling()
-successive_shortest_path_nonnegative_weights(). - -
-
- - -
Copyright © 2013 -Piotr Wygocki, University of Warsaw (wygos at mimuw.edu.pl) -
- - - - - - - - - - - - diff --git a/doc/find_odd_cycle.html b/doc/find_odd_cycle.html deleted file mode 100644 index 2f2e5710d..000000000 --- a/doc/find_odd_cycle.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - -Boost Graph Library: find_odd_cycle - - - - -

-find_odd_cycle -

- -
-// Version with a colormap to retrieve the bipartition
-template <typename Graph, typename IndexMap, typename PartitionMap, typename OutputIterator>
-OutputIterator find_odd_cycle (const Graph& graph, const IndexMap index_map, PartitionMap partition_map, OutputIterator result)
-
-template <typename Graph, typename IndexMap, typename OutputIterator>
-OutputIterator find_odd_cycle (const Graph& graph, const IndexMap index_map, OutputIterator result)
-
-// Version which uses the internal index map
-template <typename Graph, typename OutputIterator>
-OutputIterator find_odd_cycle (const Graph& graph, OutputIterator result)
-
- -

-The find_odd_cycle function tests a given graph for bipartiteness -using a DFS-based coloring approach. -

- -

-An undirected graph is bipartite if one can partition its set of vertices -into two sets "left" and "right", such that each edge goes from either side -to the other. Obviously, a two-coloring of the graph is exactly the same as -a two-partition. is_bipartite() tests whether such a two-coloring -is possible and can return it in a given property map. -

- -

-Another equivalent characterization is the non-existance of odd-length cycles, -meaning that a graph is bipartite if and only if it does not contain a -cycle with an odd number of vertices as a subgraph. -find_odd_cycle() does nearly the same as -is_bipartite(), -but additionally constructs an odd-length cycle if the graph is found to be -not bipartite. -

- -

-The bipartition is recorded in the color map partition_map, -which will contain a two-coloring of the graph, i.e. an assignment of -black and white to the vertices such that no edge is monochromatic. -The odd-length cycle is written into the Output Iterator result if -one exists. The final final iterator is returned by the function. -

- -

Where Defined

- -

-boost/graph/bipartite.hpp -

- -

Parameters

- -

-IN: const Graph& graph -

-

-An undirected graph. The graph type must be a model of Vertex List Graph and Incidence Graph.
-

- -

-IN: const IndexMap index_map -

-

-This maps each vertex to an integer in the range [0, -num_vertices(graph)). 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 usable as the key -type of the map.
-

- - -

-OUT: PartitionMap partition_map -

-

-The algorithm tests whether the graph is bipartite and assigns each -vertex either a white or a black color, according to the partition. -The PartitionMap type must be a model of -Readable Property -Map and -Writable Property -Map. The value type must model ColorValue. -

- -

-OUT: OutputIterator result -

-

-The find_odd_cycle function finds an odd-length cycle if the graph is -not bipartite. The sequence of vertices producing such a cycle is written -into this iterator. The OutputIterator type must be a model of - -OutputIterator. The graph's vertex descriptor type must be in the set -of value types of the iterator. The final value is returned by the -function. If the graph is bipartite (i.e. no odd-length cycle exists), nothing -is written, thus the given iterator matches the return value. -

- - -

Complexity

- -

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

- -

See Also

- -

-is_bipartite() -

- -

Example

- -

-The file example/bipartite_example.cpp -contains an example of testing an undirected graph for bipartiteness. -
-

- -
- -

-Copyright © 2010 Matthias Walter -(xammy@xammy.homelinux.net) -

- - - diff --git a/doc/floyd_warshall_shortest.html b/doc/floyd_warshall_shortest.html deleted file mode 100644 index 1a0fcd2c4..000000000 --- a/doc/floyd_warshall_shortest.html +++ /dev/null @@ -1,167 +0,0 @@ - - - -Floyd-Warshall All Pairs Shortest Paths - -C++ Boost - -
- -

-floyd_warshall_all_pairs_shortest_paths -

- -
// Named parameters version
-template <class VertexListGraph, class DistanceMatrix,
-    class P, class T, class R>
-bool floyd_warshall_initialized_all_pairs_shortest_paths(
-    const VertexListGraph& g, DistanceMatrix& d,
-    const bgl_named_params<P, T, R>& params)
-
-template <class VertexAndEdgeListGraph, class DistanceMatrix,
-    class P, class T, class R>
-bool floyd_warshall_all_pairs_shortest_paths(
-    const VertexAndEdgeListGraph& g, DistanceMatrix& d,
-    const bgl_named_params<P, T, R>& params)
-
-// Positional parameter versions
-\begin{verbatim}
-template <typename VertexListGraph, typename DistanceMatrix,
-    typename BinaryPredicate, typename BinaryFunction,
-    typename Infinity, typename Zero>
-bool floyd_warshall_initialized_all_pairs_shortest_paths(
-    const VertexListGraph& g, DistanceMatrix& d,
-    const BinaryPredicate& compare, const BinaryFunction& combine,
-    const Infinity& inf, const Zero& zero)
-
-template <typename VertexAndEdgeListGraph, typename DistanceMatrix,
-    typename WeightMap, typename BinaryPredicate,
-    typename BinaryFunction, typename Infinity, typename Zero>
-bool floyd_warshall_all_pairs_shortest_paths(
-    const VertexAndEdgeListGraph& g, DistanceMatrix& d,
-    const WeightMap& w, const BinaryPredicate& compare,
-    const BinaryFunction& combine,
-    const Infinity& inf, const Zero& zero)
- -

-These algorithms find the shortest distance between every pair of -vertices in the graph. The algorithms return false if there is a -negative weight cycle in the graph, true otherwise. The shortest -distance between each pair of vertices is stored in the distance -matrix d. The difference between the two algorithms is in -whether the distance matrix is assumed to be initialized or not, as -discussed below under the OUT parameter description. - -

This algorithm should be used to compute shortest paths between -every pair of vertices for dense graphs. For sparse graphs, use johnson_all_pairs_shortest_paths. - -

Where Defined

- -

-boost/graph/floyd_warshall_shortest.hpp - -

Parameters

-IN: Graph& g -
-A directed or undirected graph. The graph must be a model of Vertex List Graph for calls to -floyd_warshall_initialized_all_pairs_shortest_paths, and -Vertex And Edge List Graph for calls to -floyd_warshall_all_pairs_shortest_paths.
-
- -OUT: DistanceMatrix& d -
-The length of the shortest path between each pair of vertices -u,v are -stored in the matrix at location D[u][v]. The -DistanceMatrix must be -of type {M, I, V} where I is of type -vertex_descriptor and V is the -type of the weight_map. The set of types must be a model of -BasicMatrix, with the exceptions that -it isn't required to -run in constant time, and it must be mutable. The matrix must be -properly initialized when it is passed to the function -floyd_warshall_initialized_all_pairs_shortest_paths. If the -function floyd_warshall_all_pairs_shortest_paths is used then the -matrix will be initialized for the user. -
- -

Named Parameters

- -IN: weight_map(WeightMap w) -
-The weight of length of each edge in the graph. The WeightMap -must be a model of Readable Property -Map. The edge descriptor -type of the graph needs to be usable as the key type for the weight -map. The value_type of the weight map must be the type of the -DistanceMatrix, and must always either be part of the -graph passed to the function, or passed in as a parameter.
-Default: get(edge_weight, g) -
- -IN: distance_compare(CompareFunction cmp) -
-The function used to compare distances to determine which target -vertex is closer to the source vertex. The CompareFunction must be a -model of BinaryPredicate. The argument types must match the -value type of the WeightMap.
- -Default: std::less<WM>with WM = typename property_traits<WeightMap>::value_type -
- -IN: distance_combine(CombineFunction cmb) -
-The function used to combine distance to compute the distance of a -path. The CombineFunction must be a model of BinaryFunction. -The argument types must match the value type of the WeightMap. -The result type must be the same as the distance value type.
- -Default: boost::closed_plus<WM> with WM = typename property_traits<WeightMap>::value_type -
- -IN: distance_inf(WM inf) -
-The value used to initialize the distance for each vertex before -starting the algorithm, and to represent the distance between vertices -for which there is no path. Should be larger than any possible valid -path length. The argument type must match the value type of the -WeightMap.
- -Default: std::numeric_limits<WM>::max() with WM = typename property_traits<WeightMap>::value_type -
- -IN: distance_zero(WM zero) -
-The value used to represent the distance from a vertex to itself, and -to determine if a value is negative. The argument type must match the -value type of the WeightMap.
-Default: 0 -
- -

Complexity

- -The time complexity is O(V3). - -
-
- - - - -
Copyright © 2002-2004 - Lauren Foutz, Rensselaer Polytechnic Institute
Scott Hill, Rensselaer Polytechnic Institute -
- - - diff --git a/doc/fruchterman_reingold.html b/doc/fruchterman_reingold.html deleted file mode 100644 index a47f35cd7..000000000 --- a/doc/fruchterman_reingold.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - -Boost Graph Library: Fruchterman-Reingold Force-Directed Layout - -C++ Boost - -
-(Python) -fruchterman_reingold_force_directed_layout - - - -

-

-// named parameter version
-template<typename Graph, typename PositionMap, typename Topology, typename Param,
-	 typename Tag, typename Rest>
-void
-fruchterman_reingold_force_directed_layout
-  (const Graph&    g,
-   PositionMap     position,
-   const Topology&     space,
-   const bgl_named_params<Param, Tag, Rest>& params);
-
-// non-named parameter version
-template<typename Graph, typename PositionMap, typename Topology,
-         typename AttractiveForce, typename RepulsiveForce,
-         typename ForcePairs, typename DisplacementMap, typename Cooling>
-void
-fruchterman_reingold_force_directed_layout
- (const Graph&    g,
-  PositionMap     position,
-  const Topology& space,
-  AttractiveForce fa,
-  RepulsiveForce  fr,
-  ForcePairs      fp,
-  Cooling         cool,
-  DisplacementMap displacement);
-
-template<typename Graph, typename PositionMap, typename Topology>
-void
-fruchterman_reingold_force_directed_layout(const Graph&    g,
-			     		   PositionMap     position,
-			     		   Topology&     space,
-			     		   Dim             width,
-			     		   Dim             height);
-
- -

This algorithm [58] performs layout of -unweighted, undirected graphs. Unlike the Kamada-Kawai layout -algorithm, this algorithm directly supports the layout of disconnected -graphs (but see the force_pairs named parameter). It is a -force-directed algorithm, meaning that vertex layout is -determined by the forces pulling vertices together and pushing them -apart. Attractive forces occur between adjacent vertices only, whereas -repulsive forces occur between every pair of vertices. Each iteration -computes the sum of the forces on each vertex, then moves the vertices -to their new positions. The movement of vertices is mitigated by the -temperature of the system for that iteration: as the algorithm -progresses through successive iterations, the temperature should -decrease so that vertices settle in place. The cooling schedule, -attractive forces, and repulsive forces can be provided by the user. - -

The vertices are often placed randomly prior to execution of this algorithm via random_graph_layout. - -

Where Defined

- -boost/graph/fruchterman_reingold.hpp - -

Parameters

- -IN: const Graph& g -
- The graph object on which the algorithm will be applied. - The type Graph must be a model of - Vertex And Edge List Graph.
- Python: This parameter is named graph in Python. -
- -IN/OUT: PositionMap position -
- The property map that stores the position of each vertex. It should - typically be initialized with the vertices at random locations (use - random_graph_layout). The - type PositionMap must be a model of Lvalue Property - Map such that the vertex descriptor type of Graph is - convertible to its key type. Its value type must be - Topology::point_type, representing the coordinates - of the vertex.
- Python: The position map must be a vertex_point2d_map for - the graph.
- Python default: graph.get_vertex_point2d_map("position") -
- -IN: const Topology& space -
- The topology used to lay out the vertices. This parameter describes both the - size and shape of the layout area. Topologies are described in more detail - (with a list of BGL-provided topologies) in separate - documentation. -
- -

Named Parameters

- -IN: attractive_force(AttractiveForce fa) -
-Computes the magnitude of the attractive force between two adjacent -vertices. The function object fa must accept four -parameters: the edge descriptor, k, the distance between the -vertices, and the graph. k is the square root of the ratio -of the display area to the number of vertices.
-Default: square_distance_attractive_force(), which -computes the attractive force as dist2/k.
-Python: Any callable Python object that matches the signature will suffice. -
- -IN: repulsive_force(RepulsiveForce fr) -
-Computes the magnitude of the repulsive force between any two -vertices. The function object fr must accept five -parameters: the two vertex descriptors, k, the distance between the -vertices, and the graph. k is the square root of the ratio -of the display area to the number of vertices.
-Default: square_distance_repsulsive_force(), which -computes the repulsive force as k2/dist.
-Python: Any callable Python object that matches the signature will suffice. -
- -IN: force_pairs(ForcePairs fp) -
-Enumerates the pairs of vertices on which the repulsive force should -be applied. fp is a function object taking two parameters: -the graph g and a binary function object that should be -passed each pair of vertices to be considered. The basic formulation -of the Fruchterman-Reingold algorithm computes repulsive forces -between all pairs of vertices (pass all_force_pairs() for -this parameter), which is functional for disconnected graphs but -tends to push the connected components toward the edges of the -display area. The grid variant of the algorithm places a grid over -the display area and only computes repulsive forces among vertices -within each rectangle in the grid. The grid variant can be more -efficient than the basic formulation and tends to produce better -layouts for disconnected graphs, but is not better overall: pass -make_grid_force_pairs(width, height, position, g) as this -parameter to use the grid variant. Other enumeration strategies may -yield better results for particular graphs.
-Default: make_grid_force_pairs(width, height, position, g)
-Python: Unsupported parameter. -
- -IN: cooling(Cooling cool) -
-Determines the cooling schedule for the algorithm, which affects the -rate of movement of vertices and termination of the algorithm. The -cool parameter is a nullary function object (i.e., one that -takes no arguments) and returns the temperature for the current -iteration. When the returned temperature is zero, the algorithm -terminates. Cooling schedules should begin with some initial -temperature and gradually reduce the temperature to zero.
-Default: linear_cooling<double>(100)
-Python: Any callable Python object that matches the signature will suffice. -
- -UTIL: displacement_map(DisplacementMap displacement) -
-The displacement map is used to compute the amount by which each -vertex will move in each step. The DisplacementMap type must be a -property map whose key type is the graph's vertex type and whose value type is -Topology::point_difference_type.
-Default: An iterator_property_map with the specified value type -and using the given vertex index map.
-Python: Unsupported parameter. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is only necessary when no - displacement map is provided. - 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 usable as the key - type of the map.
-Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-Python: Unsupported parameter. -
- -Python IN: bool progressive -
- When false, performs a random layout of the graph before - running the Fruchterman-Reingold algorithm. If true, the - algorithm is executing starting with the vertex configuration in - the position map.
- Default: False. -
- -

Complexity

- -

The time complexity is O(|V|2 + |E|) for each -iteration of the algorithm in the worst case. The average case for the -grid variant is O(|V| + |E|). The number of iterations is -determined by the cooling schedule. - -

Example

-libs/graph/example/fr_layout.cpp - -
-
- - -
Copyright © 2004, 2010 Trustees of Indiana University -Doug Gregor, Indiana University -
- - - diff --git a/doc/graph_coloring.html b/doc/graph_coloring.html deleted file mode 100644 index 2175b0ea0..000000000 --- a/doc/graph_coloring.html +++ /dev/null @@ -1,191 +0,0 @@ - - - -Graph Coloring Example - -C++ Boost - -
- -

Graph Coloring

- -The graph (or vertex) coloring problem, which involves assigning -colors to vertices in a graph such that adjacenct vertices have -distinct colors, arises in a number of scientific and engineering -applications such as scheduling , register allocation , -optimization  and parallel numerical computation. - -

-Mathmatically, a proper vertex coloring of an undirected graph -G=(V,E) is a map c: V -> S such that c(u) != c(v) -whenever there exists an edge (u,v) in G. The elements -of set S are called the available colors. The problem is often -to determine the minimum cardinality (the number of colors) of -S for a given graph G or to ask whether it is able to -color graph G with a certain number of colors. For example, how -many color do we need to color the United States on a map in such a -way that adjacent states have different color? A compiler needs to -decide whether variables and temporaries could be allocated in fixed -number of registers at some point. If a target machine has K -registers, can a particular interference graph be colored with -K colors? (Each vertex in the interference graph represents a -temporary value; each edge indicates a pair of temporaries that cannot -be assigned to the same register.) - -

-Another example is in the estimation of sparse Jacobian matrix by -differences in large scale nonlinear problems in optimization and -differential equations. Given a nonlinear function F, the -estimation of Jacobian matrix J can be obtained by estimating -Jd for suitable choices of vector d. Curtis, Powell and -Reid [9] observed that a group of columns of J can be -determined by one evaluation of Jd if no two columns in this -group have a nonzero in the same row position. Therefore, a question -is emerged: what is the number of function evaluations need to compute -approximate Jacobian matrix? As a matter of fact this question is the -same as to compute the minimum numbers of colors for coloring a graph -if we construct the graph in the following matter: A vertex represents -a column of J and there is an edge if and only if the two -column have a nonzero in the same row position. - -

-However, coloring a general graph with the minimum number of colors -(the cardinality of set S) is known to be an NP-complete -problem [30]. -One often relies on heuristics to find a solution. A widely-used -general greedy based approach is starting from an ordered vertex -enumeration v1, ..., vn of G, to -assign vi to the smallest possible color for -i from 1 to n. In section Constructing graph -algorithms with BGL we have shown how to write this algorithm in -the generic programming paradigm. However, the ordering of the -vertices dramatically affects the coloring. The arbitrary order may -perform very poorly while another ordering may produces an optimal -coloring. Several ordering algorithms have been studied to help the -greedy coloring heuristics including largest-first ordering, -smallest-last ordering and incidence degree ordering. - -

-In the BGL framework, the process of constructing/prototyping such a -ordering is fairly easy because writing such a ordering follows the -algorithm description closely. As an example, we present the -smallest-last ordering algorithm. - -

-The basic idea of the smallest-last ordering [29] is -as follows: Assuming that the vertices vk+1, ..., -vn have been selected, choose vk so -that the degree of vk in the subgraph induced by -V - {vk+1, ..., vn} is minimal. - -

-The algorithm uses a bucket sorter for the vertices in the graph where -bucket is the degree. Two vertex property maps, degree and -marker, are used in the algorithm. The former is to store -degree of every vertex while the latter is to mark whether a vertex -has been ordered or processed during traversing adjacent vertices. The -ordering is stored in the order. The algorithm is as follows: - -

    -
  • put all vertices in the bucket sorter -
    • -
  • find the vertex node with smallest degree in the bucket sorter -
    • -
  • number node and traverse through its adjacent vertices to - update its degree and the position in the bucket sorter. -
    • -
  • go to the step 2 until all vertices are numbered. -
    • -
- -

-

-namespace boost {
-  template <class VertexListGraph, class Order, class Degree,
-            class Marker, class BucketSorter>
-  void
-  smallest_last_ordering(const VertexListGraph& G, Order order,
-                         Degree degree, Marker marker,
-                         BucketSorter& degree_buckets) {
-    typedef typename graph_traits<VertexListGraph> GraphTraits;
-
-    typedef typename GraphTraits::vertex_descriptor Vertex;
-    //typedef typename GraphTraits::size_type size_type;
-    typedef size_t size_type;
-
-    const size_type num = num_vertices(G);
-
-    typename GraphTraits::vertex_iterator v, vend;
-    for (boost::tie(v, vend) = vertices(G); v != vend; ++v) {
-      put(marker, *v, num);
-      put(degree, *v, out_degree(*v, G));
-      degree_buckets.push(*v);
-    }
-
-    size_type minimum_degree = 1;
-    size_type current_order = num - 1;
-
-    while ( 1 ) {
-      typedef typename BucketSorter::stack MDStack;
-      MDStack minimum_degree_stack = degree_buckets[minimum_degree];
-      while (minimum_degree_stack.empty())
-        minimum_degree_stack = degree_buckets[++minimum_degree];
-
-      Vertex node = minimum_degree_stack.top();
-      put(order, current_order, node);
-
-      if ( current_order == 0 ) //find all vertices
-        break;
-
-      minimum_degree_stack.pop();
-      put(marker, node, 0); //node has been ordered.
-
-      typename GraphTraits::adjacency_iterator v, vend;
-      for (boost::tie(v,vend) = adjacent_vertices(node, G); v != vend; ++v)
-
-        if ( get(marker, *v) > current_order ) { //*v is unordered vertex
-          put(marker, *v, current_order);   //mark the columns adjacent to node
-
-          //It is possible minimum degree goes down
-          //Here we keep tracking it.
-          put(degree, *v, get(degree, *v) - 1);
-          minimum_degree = std::min(minimum_degree, get(degree, *v));
-
-          //update the position of *v in the bucket sorter
-          degree_buckets.update(*v);
-        }
-
-      current_order--;
-    }
-    //at this point, get(order, i) == vertex(i, g);
-  }
-} // namespace boost
-
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/graph_concepts.html b/doc/graph_concepts.html deleted file mode 100644 index 413ab5297..000000000 --- a/doc/graph_concepts.html +++ /dev/null @@ -1,498 +0,0 @@ - - - -Boost Graph Concepts - -C++ Boost - -
- - -

-Graph Concepts -

- -

-The heart of the Boost Graph Library (BGL) is the interface, or -concepts (in the parlance of generic programming), that define how a -graph can be examined and manipulated in a data-structure neutral -fashion. In fact, the BGL interface need not even be implemented using -a data-structure, as for some problems it is easier or more efficient -to define a graph implicitly based on some functions. - -

-The BGL interface does not appear as a single graph concept. Instead -it is factored into much smaller pieces. The reason for this is that -the purpose of a concept is to summarize the requirements for -particular algorithms. Any one algorithm does not need every -kind of graph operation, typically only a small subset. Furthermore, -there are many graph data-structures that can not provide efficient -implementations of all the operations, but provide highly efficient -implementations of the operations necessary for a particular algorithm. -By factoring the graph interface into many smaller concepts we -provide the graph algorithm writer with a good selection from which to -choose the concept that is the closest match for their algorithm. - -Note that because of the use of traits classes rather than member -types, it is not safe (and often will not work) to define subclasses of BGL -graph types; those types may be missing important traits and properties that -were defined externally to the class definition. - -

Graph Structure Concepts Overview

- -

-Figure 1 shows the refinements -relations between the graph concepts. The reason for factoring the -graph interface into so many concepts is to encourage algorithm -interfaces to require and use only the minimum interface of a graph, -thereby increasing the reusability of the algorithm. - - -

-
- - - -
Figure 1: -The graph concepts and refinement relationships. -
-
-

- -Table 1 -gives a summary of the valid expressions and associated types for the -graph concepts and provides links to the detailed descriptions of -each of the concepts. The notation used in the table is as follows. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
GA type that is a model of Graph.
gAn object of type G.
eAn object of type boost::graph_traits<G>::edge_descriptor.
e_iterAn object of type boost::graph_traits<G>::out_edge_iterator.
u,vAre objects of type boost::graph_traits<G>::vertex_descriptor.
epis an object of type G::edge_property_type
vpis an object of type G::vertex_property_type
PropertyA type used to specify a vertex or edge property.
propertyAn object of type Property.
- - - - -

-

-
- - -
Table 1: - Summary of the graph concepts. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Expression Return Type or Description
- Graph
-boost::graph_traits<G>::vertex_descriptor The type for - vertex representative objects.
-boost::graph_traits<G>::edge_descriptor The type for - edge representative objects.
-boost::graph_traits<G>::directed_category Directed or undirected?
-boost::graph_traits<G>::edge_parallel_category Allow parallel edges?
-boost::graph_traits<G>::traversal_category The ways in which the vertices and edges of -the graph can be visited.
- IncidenceGraph refines Graph
-boost::graph_traits<G>::out_edge_iterator Iterate through - the out-edges.
-boost::graph_traits<G>::degree_size_type The integer type for -vertex degree.
-out_edges(v, g) std::pair<out_edge_iterator, out_edge_iterator>
-source(e, g) vertex_descriptor
-target(e, g) vertex_descriptor
-out_degree(v, g) degree_size_type
- BidirectionalGraph refines - IncidenceGraph
-boost::graph_traits<G>::in_edge_iterator Iterate through the in-edges.
-in_edges(v, g) std::pair<in_edge_iterator, in_edge_iterator>
-in_degree(v, g) degree_size_type
-degree(e, g) degree_size_type
-AdjacencyGraph refines Graph
-boost::graph_traits<G>::adjacency_iterator Iterate through - adjacent vertices.
-adjacent_vertices(v, g) std::pair<adjacency_iterator, adjacency_iterator>
-VertexListGraph refines - Graph
-boost::graph_traits<G>::vertex_iterator Iterate through the - graph's vertex set.
-boost::graph_traits<G>::vertices_size_type The unsigned integer type for -number of vertices in the graph.
-vertices(g) std::pair<vertex_iterator, vertex_iterator>
-num_vertices(g) vertices_size_type
-EdgeListGraph refines Graph
-boost::graph_traits<G>::edge_iterator Iterate through the graph's - edge set.
-boost::graph_traits<G>::edges_size_type The unsigned integer type for -number of edges in the graph.
-edges(g) std::pair<edge_iterator, edge_iterator>
-num_edges(g) edges_size_type
-source(e, g) vertex_descriptor
-target(e, g) vertex_descriptor
-AdjacencyMatrix refines Graph
-edge(u, v, g) std::pair<edge_descriptor, bool>
-MutableGraph refines - Graph
-add_vertex(g) vertex_descriptor
-clear_vertex(v, g) void
-remove_vertex(v, g) void
-add_edge(u, v, g) std::pair<edge_descriptor, bool>
-remove_edge(u, v, g) void
-remove_edge(e, g) void
-remove_edge(e_iter, g) void
-MutablePropertyGraph refines - Graph
-add_vertex(vp, g) vertex_descriptor
-add_edge(u, v, ep, g) std::pair<edge_descriptor, - bool>
-PropertyGraph refines Graph
-boost::property_map<G, Property>::type Type for a mutable property map.
-boost::property_map<G, Property>::const_type Type for a non-mutable property map.
-get(property, g) Function to get a property map.
-get(property, g, x) -Get property value for vertex or edge x.
-put(property, g, x, v) -Set property value for vertex or edge -x to v.
-
-

-
- -

- -

-Undirected Graphs -

- -

-The interface that the BGL provides for accessing and manipulating an -undirected graph is the same as the interface for directed graphs -described in the following sections, however there are some -differences in the behaviour and semantics. For example, in a -directed graph we can talk about out-edges and in-edges of a vertex. -In an undirected graph there is no ``in'' and ``out'', there are just -edges incident to a vertex. Nevertheless, in the BGL we still use the -out_edges() function (or in_edges()) to access the -incident edges in an undirected graph. Similarly, an undirected edge -has no ``source'' and ``target'' but merely an unordered pair of -vertices, but in the BGL we still use source() and -target() to access these vertices. The reason the BGL does -not provide a separate interface for undirected graphs is that many -algorithms on directed graphs also work on undirected graphs, and it -would be inconvenient to have to duplicate the algorithms just because -of an interface difference. When using undirected graphs just mentally -disregard the directionality in the function names. The example below -demonstrates using the out_edges(), source(), and -target() with an undirected graph. The source code for this -example and the following one can be found in example/undirected_adjacency_list.cpp. - -

-

-  const int V = 2;
-  typedef ... UndirectedGraph;
-  UndirectedGraph undigraph(V);
-
-  std::cout << "the edges incident to v: ";
-  boost::graph_traits<UndirectedGraph>::out_edge_iterator e, e_end;
-  boost::graph_traits<UndirectedGraph>::vertex_descriptor
-    s = vertex(0, undigraph);
-  for (boost::tie(e, e_end) = out_edges(s, undigraph); e != e_end; ++e)
-    std::cout << "(" << source(*e, undigraph)
-              << "," << target(*e, undigraph) << ")" << endl;
-
- -

-Even though the interface is the same for undirected graphs, there are -some behavioral differences because edge equality is defined -differently. In a directed graph, edge (u,v) is never equal to edge -(v,u), but in an undirected graph they may be equal. If the -undirected graph is a multigraph then (u,v) and (v,u) might be -parallel edges. If the graph is not a multigraph then (u,v) and -(v,u) must be the same edge. - -

-In the example below the edge equality test will return false -for the directed graph and true for the undirected graph. The -difference also affects the meaning of add_edge(). In the -example below, if we had also written add_edge(v, u, -undigraph), this would have added a parallel edge between -u and v (provided the graph type allows parallel -edges). The difference in edge equality also affects the association -of edge properties. In the directed graph, the edges (u,v) and -(v,u) can have distinct weight values, whereas in the -undirected graph the weight of (u,v) is the same as the weight -of (v,u) since they are the same edge. - -

-

-  typedef ... DirectedGraph;
-  DirectedGraph digraph(V);
-  {
-    boost::graph_traits<DirectedGraph>::vertex_descriptor u, v;
-    u = vertex(0, digraph);
-    v = vertex(1, digraph);
-    add_edge(digraph, u, v, Weight(1.2));
-    add_edge(digraph, v, u, Weight(2.4));
-    boost::graph_traits<DirectedGraph>::edge_descriptor e1, e2;
-    bool found;
-    boost::tie(e1, found) = edge(u, v, digraph);
-    boost::tie(e2, found) = edge(v, u, digraph);
-    std::cout << "in a directed graph is ";
-    std::cout << "(u,v) == (v,u) ? " << (e1 == e2) << std::endl;
-
-    property_map<DirectedGraph, edge_weight_t>::type
-      weight = get(edge_weight, digraph);
-    cout << "weight[(u,v)] = " << get(weight, e1) << endl;
-    cout << "weight[(v,u)] = " << get(weight, e2) << endl;
-  }
-  {
-    boost::graph_traits<UndirectedGraph>::vertex_descriptor u, v;
-    u = vertex(0, undigraph);
-    v = vertex(1, undigraph);
-    add_edge(undigraph, u, v, Weight(3.1));
-    boost::graph_traits<UndirectedGraph>::edge_descriptor e1, e2;
-    bool found;
-    boost::tie(e1, found) = edge(u, v, undigraph);
-    boost::tie(e2, found) = edge(v, u, undigraph);
-    std::cout << "in an undirected graph is ";
-    std::cout << "(u,v) == (v,u) ? " << (e1 == e2) << std::endl;
-
-    property_map<UndirectedGraph, edge_weight_t>::type
-      weight = get(edge_weight, undigraph);
-    cout << "weight[(u,v)] = " << get(weight, e1) << endl;
-    cout << "weight[(v,u)] = " << get(weight, e2) << endl;
-  }
-
-The output is: -
-in a directed graph is (u,v) == (v,u) ? 0
-weight[(u,v)] = 1.2
-weight[(v,u)] = 2.4
-in an undirected graph is (u,v) == (v,u) ? 1
-weight[(u,v)] = 3.1
-weight[(v,u)] = 3.1
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/graph_theory_review.html b/doc/graph_theory_review.html deleted file mode 100644 index 608bd3665..000000000 --- a/doc/graph_theory_review.html +++ /dev/null @@ -1,628 +0,0 @@ - - - -Boost Graph Library: Graph Theory Review - -C++ Boost - -
- -

Review of Elementary Graph Theory

- -

- -

-This chapter is meant as a refresher on elementary graph theory. If -the reader has some previous acquaintance with graph algorithms, this -chapter should be enough to get started. If the reader has no -previous background in graph algorithms we suggest a more thorough -introduction such as Introduction to Algorithms -by Cormen, Leiserson, and Rivest. - -

- -

The Graph Abstraction

- -

-A graph is a mathematical abstraction that is useful for solving many -kinds of problems. Fundamentally, a graph consists of a set of -vertices, and a set of edges, where an edge is something that connects -two vertices in the graph. More precisely, a graph is a pair (V,E), where -V is a finite set and E is a binary relation on -V. V is called a vertex -set whose elements are called vertices. E is a -collection of edges, where an edge is a -pair (u,v) with u,v in V. In a directed graph, edges are ordered -pairs, connecting a source vertex to a -target vertex. In an undirected graph edges are -unordered pairs and connect the two vertices in both directions, hence -in an undirected graph (u,v) and (v,u) are two ways of -writing the same edge. - -

-This definition of a graph is vague in certain respects; it does not -say what a vertex or edge represents. They could be cities with -connecting roads, or web-pages with hyperlinks. These details are left -out of the definition of a graph for an important reason; they are not -a necessary part of the graph abstraction. By leaving out the -details we can construct a theory that is reusable, that can help us -solve lots of different kinds of problems. - -

-Back to the definition: a graph is a set of vertices and edges. For -purposes of demonstration, let us consider a graph where we have -labeled the vertices with letters, and we write an edge simply as a -pair of letters. Now we can write down an example of a directed graph -as follows: - -

-

-
-V = {v, b, x, z, a, y }
-E = { (b,y), (b,y), (y,v), (z,a), (x,x), (b,x), (x,v), (a,z) }
-G = (V, E) -
-
-

- - -

-Figure 1 gives a pictorial view of -this graph. The edge (x,x) is called a self-loop. Edges (b,y) and -(b,y) are parallel edges, which are allowed in a multigraph (but are normally not -allowed in a directed or undirected graph). - -

- -

-
- - - -
Figure 1: -Example of a directed graph.
-

- -

-Next we have a similar graph, though this time it is undirected. Figure 2 gives the pictorial view. -Self loops are not allowed in undirected graphs. This graph is the undirected version of the the -previous graph (minus the parallel edge (b,y)), meaning it has -the same vertices and the same edges with their directions removed. -Also the self edge has been removed, and edges such as (a,z) -and (z,a) are collapsed into one edge. One can go the other -way, and make a directed version -of an undirected graph be replacing each edge by two edges, one -pointing in each direction. - -

-

-

- -

- -

-
- - - -
Figure 2: -Example of an undirected graph.
-

- -

-Now for some more graph terminology. If some edge (u,v) is in -graph G, then vertex v is adjacent to vertex u. In a -directed graph, edge (u,v) is an out-edge of vertex u and an in-edge of vertex v. In an -undirected graph edge (u,v) is incident on vertices u and -v. - -

-In Figure 1, - vertex y is adjacent to vertex b (but b is not - adjacent to y). The edge (b,y) is an out-edge of - b and an in-edge of y. In Figure 2, - y is adjacent to b and vice-versa. The edge - (y,b) is incident on vertices y and b. - -

-In a directed graph, the number of out-edges of a vertex is its out-degree and the number of in-edges -is its in-degree. For an -undirected graph, the number of edges incident to a vertex is its degree. In Figure 1, vertex b has an -out-degree of 3 and an in-degree of zero. In Figure 2, vertex b simply has -a degree of 2. - -

-Now a path is a sequence of edges in a -graph such that the target vertex of each edge is the source vertex of -the next edge in the sequence. If there is a path starting at vertex -u and ending at vertex v we say that v is reachable from u. A path is simple if none of the vertices in -the sequence are repeated. The path <(b,x), (x,v)> is simple, -while the path <(a,z), (z,a)> is not. Also, the path <(a,z), -(z,a)> is called a cycle because the -first and last vertices in the path are the same. A graph with no cycles -is acyclic. - -

-A planar graph is a graph that -can be drawn on a plane without any of the edges crossing over each -other. Such a drawing is called a plane graph. A face of a plane graph is a connected region -of the plane surrounded by edges. An important property of planar -graphs is that the number of faces, edges, and vertices are related -through Euler's formula: |F| - |E| + |V| = 2. This means that a -simple planar graph has at most O(|V|) edges. - -

- -

- -

Graph Data Structures

- -

-The primary property of a graph to consider when deciding which data -structure to use is sparsity, the number of edges relative to -the number of vertices in the graph. A graph where E is close -to V2 is a dense graph, whereas a graph -where E = alpha V and alpha is much smaller than -V is a sparse graph. For dense graphs, the -adjacency-matrix representation is usually the best choice, -whereas for sparse graphs the adjacency-list representation is -a better choice. Also the edge-list representation is a space -efficient choice for sparse graphs that is appropriate in some -situations. - -

- -

Adjacency Matrix Representation

- -

-An adjacency-matrix representation of a graph is a 2-dimensional V -x V array. Each element in the array auv stores -a Boolean value saying whether the edge (u,v) is in the graph. -Figure 3 depicts an adjacency matrix for -the graph in Figure 1 (minus the -parallel edge (b,y)). The amount of space required to store -an adjacency-matrix is O(V2). Any edge can be -accessed, added, or removed in O(1) time. To add or remove a -vertex requires reallocating and copying the whole graph, an -O(V2) operation. The adjacency_matrix class -implements the BGL graph interface in terms of the adjacency-matrix -data-structure. - - -

- -

-
- - - -
Figure 3: -The Adjacency Matrix Graph Representation.
-

- -

- -

-Adjacency List Representation -

- -

-An adjacency-list representation of a graph stores an out-edge -sequence for each vertex. For sparse graphs this saves space since -only O(V + E) memory is required. In addition, the out-edges -for each vertex can be accessed more efficiently. Edge insertion is -O(1), though accessing any given edge is O(alpha), where -alpha is the sparsity factor of the matrix (which is equal to -the maximum number of out-edges for any vertex in the graph). Figure 4 depicts an -adjacency-list representation of the graph in Figure 1. The -adjacency_list class is -an implementation of the adjacency-list representation. - -

- -

-
- - - -
Figure 4: -The Adjacency List Graph Representation.
-

- -

- -

Edge List Representation

- -

-An edge-list representation of a graph is simply a sequence of edges, -where each edge is represented as a pair of vertex ID's. The memory -required is only O(E). Edge insertion is typically O(1), -though accessing a particular edge is O(E) (not efficient). Figure 5 shows an -edge-list representation of the graph in Figure 1. The -edge_list adaptor class can be -used to create implementations of the edge-list representation. - -

- -

-
- - - -
Figure 5: -The Edge List Graph Representation.
-

- - -

- -

Graph Algorithms

- -

- -

Graph Search Algorithms

- -

-Tree edges are edges in the search tree (or forest) constructed -(implicitly or explicitly) by running a graph search algorithm over a -graph. An edge (u,v) is a tree edge if v was first -discovered while exploring (corresponding to the visitor explore() method) -edge (u,v). Back edges connect vertices to their -ancestors in a search tree. So for edge (u,v) the vertex -v must be the ancestor of vertex u. Self loops are -considered to be back edges. Forward edges are non-tree edges -(u,v) that connect a vertex u to a descendant v -in a search tree. Cross edges are edges that do not fall into -the above three categories. - -

- -

-Breadth-First Search -

- -

-Breadth-first search is a traversal through a graph that touches all -of the vertices reachable from a particular source vertex. In -addition, the order of the traversal is such that the algorithm will -explore all of the neighbors of a vertex before proceeding on to the -neighbors of its neighbors. One way to think of breadth-first search -is that it expands like a wave emanating from a stone dropped into a -pool of water. Vertices in the same ``wave'' are the same distance -from the source vertex. A vertex is discovered the first time -it is encountered by the algorithm. A vertex is finished after -all of its neighbors are explored. Here's an example to help make this -clear. A graph is shown in Figure 6 and the -BFS discovery and finish order for the vertices is shown below. - -

- -

-
- - - -
Figure 6: -Breadth-first search spreading through a graph.
-

- -

-

-  order of discovery: s r w v t x u y
-  order of finish:    s r w v t x u y
-
- -

-We start at vertex s, and first visit r and w (the two -neighbors of s). Once both neighbors of s are visited, we visit the -neighbor of r (vertex v), then the neighbors of w -(the discovery order between r and w does not matter) -which are t and x. Finally we visit the neighbors of -t and x, which are u and y. - -

-For the algorithm to keep track of where it is in the graph, and which -vertex to visit next, BFS needs to color the vertices (see the section -on Property Maps -for more details about attaching properties to graphs). The place to -put the color can either be inside the graph, or it can be passed into -the algorithm as an argument. - -

- -

-Depth-First Search -

- -

-A depth first search (DFS) visits all the vertices in a graph. When -choosing which edge to explore next, this algorithm always chooses to -go ``deeper'' into the graph. That is, it will pick the next adjacent -unvisited vertex until reaching a vertex that has no unvisited -adjacent vertices. The algorithm will then backtrack to the previous -vertex and continue along any as-yet unexplored edges from that -vertex. After DFS has visited all the reachable vertices from a -particular source vertex, it chooses one of the remaining undiscovered -vertices and continues the search. This process creates a set of -depth-first trees which together form the depth-first - forest. A depth-first search categorizes the edges in the graph -into three categories: tree-edges, back-edges, and forward or -cross-edges (it does not specify which). There are typically many -valid depth-first forests for a given graph, and therefore many -different (and equally valid) ways to categorize the edges. - -

-One interesting property of depth-first search is that the discover -and finish times for each vertex form a parenthesis structure. If we -use an open-parenthesis when a vertex is discovered, and a -close-parenthesis when a vertex is finished, then the result is a -properly nested set of parenthesis. Figure 7 shows -DFS applied to an undirected graph, with the edges labeled in the -order they were explored. Below we list the vertices of the graph -ordered by discover and finish time, as well as show the parenthesis -structure. DFS is used as the kernel for several other graph -algorithms, including topological sort and two of the connected -component algorithms. It can also be used to detect cycles (see the Cylic Dependencies -section of the File Dependency Example). - -

- -

-
- - - -
Figure 7: -Depth-first search on an undirected graph.
-

- -

-

-  order of discovery: a b e d c f g h i
-  order of finish:    d f c e b a i h g
-  parenthesis: (a (b (e (d d) (c (f f) c) e) b) a) (g (h (i i) h) g)
-
- -

- -

Minimum Spanning Tree Problem

- -

-The minimum-spanning-tree problem is defined as follows: find -an acyclic subset T of E that connects all of the vertices -in the graph and whose total weight is minimized, where the -total weight is given by -

-
-w(T) = sum of w(u,v) over all (u,v) in T, -where w(u,v) is the weight on the edge (u,v) -
-

-T is called the spanning tree. - - - -

- -

Shortest-Paths Algorithms

- -

-One of the classic problems in graph theory is to find the shortest -path between two vertices in a graph. Formally, a path is a -sequence of vertices <v0,v1,...,vk> -in a graph G = (V, E) such that each vertex is connected to the -next vertex in the sequence (the edges -(vi,vi+1) for i=0,1,...,k-1 are in -the edge set E). In the shortest-path problem, each edge is -given a real-valued weight. We can therefore talk about the weight -of a path
- -

-
-w(p) = sum of w(vi-1,vi) for i=1..k -
-

- -The shortest path weight from vertex u to v is then - -
-

-
-delta (u,v) = min { w(p) : u --> v } if there is a path from -u to v
-delta (u,v) = infinity otherwise. -
-

- -A shortest path is any path whose path weight is equal to the -shortest path weight. - -

-There are several variants of the shortest path problem. Above we -defined the single-pair problem, but there is also the -single-source problem (all shortest paths from one vertex to -every other vertex in the graph), the equivalent -single-destination problem, and the all-pairs problem. -It turns out that there are no algorithms for solving the single-pair -problem that are asymptotically faster than algorithms that solve the -single-source problem. - -

-A shortest-paths tree rooted at vertex r in graph G=(V,E) -is a directed subgraph G'=(V',E') where V' is a subset -of V and E' is a subset of E, V' is the -set of vertices reachable from r, G' forms a rooted tree with -root r, and for all v in V' the unique simple path from r -to v in G' is a shortest path from r to v in G. The -result of a single-source algorithm is a shortest-paths tree. - -

- -

Network Flow Algorithms

- -

-A flow network is a directed graph G=(V,E) with a -source vertex s and a sink vertex -t. Each edge has a positive real valued capacity -function c and there is a flow function f -defined over every vertex pair. The flow function must satisfy three -constraints: - -

-f(u,v) <= c(u,v) for all (u,v) in V x V (Capacity constraint)
-f(u,v) = - f(v,u) for all (u,v) in V x V (Skew symmetry)
-sumv in V f(u,v) = 0 for all v in V - {s,t} (Flow conservation) - -

-The flow of the network is the net flow entering the -sink vertex t (which is equal to the net flow leaving the -source vertex s).

- -|f| = sumu in V f(u,t) = sumv in V f(s,v) - -

-The residual capacity of an edge is r(u,v) = c(u,v) - -f(u,v). The edges with r(u,v) > 0 are residual edges -Ef which induce the residual graph Gf -= (V, Ef). An edge with r(u,v) = 0 is -saturated. - -

-The maximum flow problem is to determine the maximum -possible value for |f| and the corresponding flow values for -every vertex pair in the graph. -

-The minimum cost maximum flow problem is to determine -the maximum flow which minimizes sum(u,v) in E -cost(u,v) * f(u,v) . - -

-A flow network is shown in Figure -8. Vertex A is the source vertex and H is the target -vertex. - -

-
- - - -
Figure 8: A Maximum Flow -Network.
Edges are labeled with the flow and capacity -values.
-

- -

-There is a long history of algorithms for solving the maximum flow -problem, with the first algorithm due to Ford and Fulkerson. The -best general purpose algorithm to date is the push-relabel algorithm -of Goldberg -which is based on the notion of a preflow introduced by -Karzanov. - - -

Minimum Cut Algorithms

- -

Undirected Graphs

-

Given an undirected graph G = (V, E), a cut of G is a partition of the vertices into two, non-empty sets X and \overline{X} = V - X. The weight of a cut is defined as the number of edges between sets X and \overline{X} if G is unweighted, or the sum of the weights of all edges between sets X and \overline{X} if G is weighted (each edge has an associated, non-negative weight). - -

When the weight of a cut C = \{X, \overline{X}\} is minimal for a graph G (that is, no other cut of G has a lesser weight), then the cut is known as a minimum cut or a min-cut. For example, given this weighted graph: - -

- -

The cut {{0, 6}, {3, 2, 7, 1, 5, 4}} has weight 13: - -

- -

And the min-cut is {{0, 1, 4, 5}, {2, 3, 6, 7}} (weight 4): - -

- -

Unlike this example, a graph will sometimes have multiple min-cuts, all of equal weight. A minimum cut algorithm determines one of them as well as the min-cut weight. - -

Directed Graphs

- -

Given a directed graph G = (V, E), a cut of G is a partition of the vertices into two, non-empty sets S and T where S is known as the set of source vertices and T is known as the set of sink vertices. The capacity of a cut C = (S, T) is the number of edges from a vertex in S to a vertex in T if G is unweighted, or the sum of weights of edges from a vertex in S to a vertex in T if G is weighted. - -

When the capacity of a cut C = (S, T) of a directed graph is minimal (that is, no other cut of G has lesser capacity), then C is known as a minimum cut or min-cut. - -

For example, given this directed graph: - -

- -

A min-cut is: - -

- -

where S = {0}, T = {1, 2, 3}, and the min-cut capacity is 1. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/graph_traits.html b/doc/graph_traits.html deleted file mode 100644 index cb5bf2404..000000000 --- a/doc/graph_traits.html +++ /dev/null @@ -1,256 +0,0 @@ - - - -Boost Graph Library: Graph Traits - -C++ Boost - -
- -

-
-graph_traits<Graph>
-
-

- -Just like the -iterators of STL, graphs have associated types. As stated -in the various graph concepts, a -graph has quite a few associated types: vertex_descriptor, -edge_descriptor, out_edge_iterator, etc.. Any -particular graph concepts will not require that all of the following -associated types be defined. When implementing a graph class that -fullfils one or more graph concepts, for associated types that are not -required by the concepts, it is ok to use void as the type -(when using nested typedefs inside the graph class), or to leave the -typedef out of the graph_traits specialization for the graph -class. -Note that because of the use of traits classes rather than member -types, it is not safe (and often will not work) to define subclasses of BGL -graph types; those types may be missing important traits and properties that -were defined externally to the class definition. - -
-  template <typename Graph>
-  struct graph_traits {
-    typedef typename Graph::vertex_descriptor      vertex_descriptor;
-    typedef typename Graph::edge_descriptor        edge_descriptor;
-    typedef typename Graph::adjacency_iterator     adjacency_iterator;
-    typedef typename Graph::out_edge_iterator      out_edge_iterator;
-    typedef typename Graph::in_edge_iterator       in_edge_iterator;
-    typedef typename Graph::vertex_iterator        vertex_iterator;
-    typedef typename Graph::edge_iterator          edge_iterator;
-
-    typedef typename Graph::directed_category      directed_category;
-    typedef typename Graph::edge_parallel_category edge_parallel_category;
-    typedef typename Graph::traversal_category     traversal_category;
-
-    typedef typename Graph::vertices_size_type     vertices_size_type;
-    typedef typename Graph::edges_size_type        edges_size_type;
-    typedef typename Graph::degree_size_type       degree_size_type;
-  };
-
- -

Where Defined

- -boost/graph/graph_traits.hpp - -

Template Parameters

- -

- - - - - - - - - -
ParameterDescription
Graph -The graph type whose associated types are being accessed. -
- -

Model of

- -DefaultConstructible and -Assignable - -

Type Requirements

- - - -

Members

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MemberDescription
-vertex_descriptor - -The type for the objects used to identity vertices in the graph. -
-edge_descriptor - -The type for the objects used to identity edges in the graph. -
-adjacency_iterator - -The type for the iterators that traverse the vertices adjacent -to a vertex. -
-out_edge_iterator - -The type for the iterators that traverse through the out-edges -of a vertex. -
-in_edge_iterator - -The type for the iterators that traverse through the in-edges -of a vertex. -
-vertex_iterator - -The type for the iterators that traverse through the complete vertex -set of the graph. -
-edge_iterator - -The type for the iterators that traverse through the complete edge -set of the graph. -
-directed_category - -This says whether the graph is undirected (undirected_tag) -or directed (directed_tag). -
-edge_parallel_category - -This says whether the graph allows parallel edges to be inserted -(allow_parallel_edge_tag) or if it automatically removes -parallel edges (disallow_parallel_edge_tag). -
-traversal_category - -The ways in which the vertices in the graph can be traversed. -The traversal category tags are: -incidence_graph_tag, adjacency_graph_tag, -bidirectional_graph_tag, vertex_list_graph_tag, -edge_list_graph_tag, -adjacency_matrix_tag. You can also create your own -tag which should inherit from one or more of the above. -
-vertices_size_type - -The unsigned integer type used for representing the number of -vertices in the graph. -
-edges_size_type - -The unsigned integer type used for representing the number of -edge in the graph. -
-degree_size_type - -The unsigned integer type used for representing the degree -of vertices in the graph. -
- -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/grid_graph.html b/doc/grid_graph.html deleted file mode 100644 index 053ad115d..000000000 --- a/doc/grid_graph.html +++ /dev/null @@ -1,304 +0,0 @@ - - - - - Boost Graph Library: Grid Graph - - - - C++ Boost -
-

- grid_graph -

- - - -

Overview

-

- A grid_graph represents a multi-dimensional, - rectangular grid of vertices with user-defined dimension lengths - and wrapping. - -

-

- grid_graph models: -

-

-

- Defined in - boost/graph/grid_graph.hpp - with all functions in the boost namespace. A simple examples of creating and iterating over a grid_graph is available here libs/graph/example/grid_graph_example.cpp. An example of adding properties to a grid_graph is also available libs/graph/example/grid_graph_properties.cpp -

- -

Template Parameters

- 
-template <std::size_t Dimensions,
-          typename VertexIndex = std::size_t,
-          typename EdgeIndex = VertexIndex>
-  class grid_graph;
-
-
    -
  • - Dimensions - Number of dimensions in the graph -
    • -
  • - VertexIndex - Type used for vertex indices, defaults to std::size_t -
    • -
  • - EdgeIndex - Type used for edge indices, defaults to the same type as VertexIndex -
    • -
- -

Creating a Grid Graph

-

- The constructor to grid_graph has several overloads to aid in configuring each dimension: -

- 
-// Defines a grid_graph that does not wrap.
-grid_graph<...>(boost:array<VertexIndex, Dimensions> dimension_lengths);
-
-// Defines a grid_graph where all dimensions are either wrapped or unwrapped.
-grid_graph<...>(boost:array<VertexIndex, Dimensions> dimension_lengths,
-                bool wrap_all_dimensions);
-
-// Defines a grid_graph where the wrapping for each dimension is specified individually.
-grid_graph<...>(boost:array<VertexIndex, Dimensions> dimension_lengths,
-                boost:array<bool, Dimensions> wrap_dimension);
-
- -

Example

- 
-// Define dimension lengths, a 3x3 in this case
-boost::array<std::size_t, 2> lengths = { { 3, 3 } };
-
-// Create a 3x3 two-dimensional, unwrapped grid graph (Figure 1)
-grid_graph<2> graph(lengths);
-
-// Create a 3x3 two-dimensional, wrapped grid graph (Figure 2)
-grid_graph<2> graph(lengths, true);
-
-
-

- -
- Figure 1: A 3x3 two-dimensional, unwrapped grid graph -

-
-

- -
- Figure 2: A 3x3 two-dimensional, wrapped grid graph -

-
- -

Indexing

-

- The grid_graph supports addressing vertices and edges - by index. The following functions allow you to convert between - vertices, edges, and their associated indices: -

- - 
-typedef grid_graph<...> Graph;
-typedef graph_traits<Graph> Traits;
-
-// Get the vertex associated with vertex_index
-Traits::vertex_descriptor
-vertex(Traits::vertices_size_type vertex_index,
-       const Graph& graph);
-
-// Get the index associated with vertex
-Traits::vertices_size_type
-get(boost::vertex_index_t,
-    const Graph& graph,
-    Traits::vertex_descriptor vertex);
-
-// Get the edge associated with edge_index
-Traits::edge_descriptor
-edge_at(Traits::edges_size_type edge_index,
-        const Graph& graph);
-
-// Get the index associated with edge
-Traits::edges_size_type
-get(boost::edge_index_t,
-    const Graph& graph,
-    Traits::edge_descriptor edge);
-
-// Get the out-edge associated with vertex and out_edge_index
-Traits::edge_descriptor
-out_edge_at(Traits::vertex_descriptor vertex,
-            Traits::degree_size_type out_edge_index,
-            const Graph& graph);
-
-// Get the out-edge associated with vertex and in_edge_index
-Traits::edge_descriptor
-in_edge_at(Traits::vertex_descriptor vertex,
-           Traits::degree_size_type in_edge_index,
-           const Graph& graph);
-
- -

Example

- 
-typedef grid_graph<2> Graph;
-typedef graph_traits<Graph> Traits;
-
-// Create a 3x3, unwrapped grid_graph (Figure 3)
-boost::array<std::size_t, 2> lengths = { { 3, 3 } };
-Graph graph(lengths);
-
-// Do a round-trip test of the vertex index functions
-for (Traits::vertices_size_type v_index = 0;
-     v_index < num_vertices(graph); ++v_index) {
-
-  // The two indices should always be equal
-  std::cout << "Index of vertex " << v_index << " is " <<
-    get(boost::vertex_index, graph, vertex(v_index, graph)) << std::endl;
-
-}
-
-// Do a round-trip test of the edge index functions
-for (Traits::edges_size_type e_index = 0;
-     e_index < num_edges(graph); ++e_index) {
-
-  // The two indices should always be equal
-  std::cout << "Index of edge " << e_index << " is " <<
-    get(boost::edge_index, graph, edge_at(e_index, graph)) << std::endl;
-
-}
-
- -

- -
- Figure 3: 3x3 unwrapped grid_graph with vertex and edge indices shown. -

-
- -

Member Functions

-

- There are several grid_graph specific member functions available: -

- 
-typedef grid_graph<...> Graph;
-typedef graph_traits<Graph> Traits;
-
-// Returns the number of dimensions
-std::size_t dimensions();
-
-// Returns the length of a dimension
-Traits::vertices_size_type length(std::size_t dimension);
-
-// Returns true if the dimension wraps, false if not
-bool wrapped(std::size_t dimension);
-
-// Returns the "next" vertex in a dimension at a given distance. If the dimension
-// is unwrapped, next will stop at the last vertex in the dimension.
-Traits::vertex_descriptor next(Traits::vertex_descriptor vertex,
-                               std::size_t dimension,
-                               Traits::vertices_size_type distance = 1);
-
-// Returns the "previous" vertex in a dimension at a given distance. If the
-// dimension is unwrapped, previous will stop at the beginning vertex in the dimension.
-Traits::vertex_descriptor previous(Traits::vertex_descriptor vertex,
-                                   std::size_t dimension,
-                                   Traits::vertices_size_type distance = 1);
-
- -

Example

- 
-typedef grid_graph<3> Graph;
-typedef graph_traits<Graph> Traits;
-
-// Define a 3x5x7 grid_graph where the second dimension doesn't wrap
-boost::array<std::size_t, 3> lengths = { { 3, 5, 7 } };
-boost::array<bool, 3> wrapped = { { true, false, true } };
-Graph graph(lengths, wrapped);
-
-// Print number of dimensions
-std::cout << graph.dimensions() << std::endl; // prints "3"
-
-// Print dimension lengths (same order as in the lengths array)
-std::cout << graph.length(0) << "x" << graph.length(1) <<
-  "x" << graph.length(2) << std::endl; // prints "3x5x7"
-
-// Print dimension wrapping (W = wrapped, U = unwrapped)
-std::cout << graph.wrapped(0) ? "W" : "U" << ", " <<
-  graph.wrapped(1) ? "W" : "U" << ", " <<
-  graph.wrapped(2) ? "W" : "U" << std::endl; // prints "W, U, W"
-
-// Define a simple function to print vertices
-void print_vertex(Traits::vertex_descriptor vertex_to_print) {
-  std::cout << "(" << vertex_to_print[0] << ", " << vertex_to_print[1] <<
-    ", " << vertex_to_print[2] << ")" << std::endl;
-}
-
-// Start with the first vertex in the graph
-Traits::vertex_descriptor first_vertex = vertex(0, graph);
-print_vertex(first_vertex); // prints "(0, 0, 0)"
-
-// Print the next vertex in dimension 0
-print_vertex(graph.next(first_vertex, 0)); // prints "(1, 0, 0)"
-
-// Print the next vertex in dimension 1
-print_vertex(graph.next(first_vertex, 1)); // prints "(0, 1, 0)"
-
-// Print the 5th next vertex in dimension 2
-print_vertex(graph.next(first_vertex, 2, 5)); // prints "(0, 0, 5)"
-
-// Print the previous vertex in dimension 0 (wraps)
-print_vertex(graph.previous(first_vertex, 0)); // prints "(2, 0, 0)"
-
-// Print the previous vertex in dimension 1 (doesn't wrap, so it's the same)
-print_vertex(graph.previous(first_vertex, 1)); // prints "(0, 0, 0)"
-
-// Print the 20th previous vertex in dimension 2 (wraps around twice)
-print_vertex(graph.previous(first_vertex, 2, 20)); // prints "(0, 0, 1)"
-
- -
- Copyright © 2009 Trustees of Indiana University - - - diff --git a/doc/grid_graph_export_svg.sh b/doc/grid_graph_export_svg.sh deleted file mode 100755 index d12ea2169..000000000 --- a/doc/grid_graph_export_svg.sh +++ /dev/null @@ -1,19 +0,0 @@ -#!/bin/sh - -#======================================================================= -# Copyright 2009 Trustees of Indiana University. -# Authors: Michael Hansen, Andrew Lumsdaine -# -# Distributed under the Boost Software License, Version 1.0. (See -# accompanying file LICENSE_1_0.txt or copy at -# http:#www.boost.org/LICENSE_1_0.txt) -#======================================================================= - -# Unindexed, unwrapped -inkscape --export-png grid_graph_unwrapped.png --export-id g3150 --export-id-only grid_graph_unindexed.svg - -# Unindexed, wrapped -inkscape --export-png grid_graph_wrapped.png grid_graph_unindexed.svg - -# Indexed, unwrapped -inkscape --export-png grid_graph_indexed.png grid_graph_indexed.svg diff --git a/doc/gursoy_atun_layout.html b/doc/gursoy_atun_layout.html deleted file mode 100644 index 1c180a35e..000000000 --- a/doc/gursoy_atun_layout.html +++ /dev/null @@ -1,239 +0,0 @@ - - - -Boost Graph Library: Gürsoy-Atun Layout - - - - - -C++ Boost - -
- -

-gursoy_atun_layout -

- -

- -

Synopsis

-
-// Non-named parameter version
-template<typename VertexListAndIncidenceGraph,  typename Topology,
-	 typename PositionMap, typename VertexIndexMap,
-         typename EdgeWeightMap>
-void
-gursoy_atun_layout(const VertexListAndIncidenceGraph& g,
-                   const Topology& space,
-		   PositionMap position,
-		   int nsteps = num_vertices(g),
-		   double diameter_initial = sqrt((double)num_vertices(g)),
-		   double diameter_final = 1,
-		   double learning_constant_initial = 0.8,
-		   double learning_constant_final = 0.2,
-		   VertexIndexMap vertex_index_map = get(vertex_index, g),
-                   EdgeWeightMap weight = dummy_property_map());
-
-// Named parameter version
-template<typename VertexListAndIncidenceGraph, typename Topology,
-         typename PositionMap, typename P, typename T, typename R>
-void
-gursoy_atun_layout(const VertexListAndIncidenceGraph& g,
-                   const Topology& space,
-                   PositionMap position,
-                   const bgl_named_params<P,T,R>& params = all defaults);
-
- -

Description

- -

This algorithm [60] -performs layout of directed graphs, either weighted or unweighted. This -algorithm is very different from the Kamada-Kawai and Fruchterman-Reingold algorithms, -because it does not explicitly strive to layout graphs in a visually -pleasing manner. Instead, it attempts to distribute the vertices -uniformly within a topology (e.g., rectangle, sphere, heart shape), -keeping vertices close to their neighbors; various -topologies are provided by BGL, and users can also create their own. The -algorithm itself is -based on Self-Organizing -Maps. - -

- - - -

- -

Where Defined

- -boost/graph/gursoy_atun_layout.hpp - -

Parameters

- -IN: const Graph& g -
- The graph object on which the algorithm will be applied. The type - Graph must be a model of Vertex List Graph and Incidence Graph. -
- -IN: const Topology& space -
- The topology on which the graph will be laid out. The type must - model the Topology concept. -
- -OUT: PositionMap position -
- The property map that stores the position of each vertex. The type - PositionMap must be a model of Lvalue Property - Map such that the vertex descriptor type of Graph is - convertible to its key type. Its value type must be - Topology::point_type. -
- -IN: int nsteps -
- The number of iterations to perform.
- Default: num_vertices(g) -
- -IN: double diameter_initial -
- When a vertex is selected to be updated, all vertices that are - reachable from that vertex within a certain diameter (in graph - terms) will also be updated. This diameter begins at - diameter_initial in the first iteration and ends at - diameter_final in the last iteration, progressing - exponentially. Generally the diameter decreases, in a manner similar to - the cooling schedule in Fruchterman-Reingold. The -diameter should typically decrease in later iterations, so this value -should not be less than diameter_final.
- Default: sqrt((double)num_vertices(g)) -
- -IN: double diameter_final -
- The final value of the diameter.
- Default: 1.0 -
- -IN: double learning_constant_initial -
- The learning rate affects how far vertices can moved to rearrange - themselves in a given iteration. The learning rate progresses - linearly from the initial value to the final value, both of which - should be between 0 and 1. The learning rate should typically - decrease, so the initial value should not exceed the final - value.
Default: 0.8 -
- -IN: double learning_constant_final -
- The final learning rate constant.
- Default: 0.2 -
- -IN: VertexIndexMap vertex_index_map -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is only necessary when no - displacement map is provided. - 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 usable as the key - type of the map.
-Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- -IN: EdgeWeightMap weight -
- This maps each edge to a weight. - The type EdgeWeightMap must be a model of Readable Property - Map. The value type of the map must be an floating-point type - compatible with double. The edge descriptor type of the - graph needs to be usable as the key type of the map. When this map - is a dummy_property_map, the algorithm assumes the graph is - unweighted.
-Default: dummy_property_map() -
- -

Named Parameters

- -IN: iterations(int n) -
-Executes the algorithm for n iterations.
-Default: num_vertices(g) -
- -IN: diameter_range(std::pair range) -
-Range specifying the parameters (diameter_initial, diameter_final).
-Default: std::make_pair(sqrt((double)num_vertices(g)), 1.0) -
- -IN: learning_constant_range(std::pair range) -
-Range specifying the parameters (learning_constant_initial, learning_constant_final).
-Default: std::make_pair(0.8, 0.2) -
- -IN: edge_weight(EdgeWeightMap weight) -
-Equivalent to the non-named weight parameter.
-Default: dummy_property_map() -
- -IN: vertex_index_map(VertexIndexMap i_map) -
-Equivalent to the non-named vertex_index_map parameter.
-Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- -
-
- - -
Copyright © 2004 Trustees of Indiana University -Jeremiah Willcock, Indiana University ()
-Doug Gregor, Indiana University ()
- Andrew Lumsdaine, -Indiana University () -
- - - diff --git a/doc/hawick_circuits.html b/doc/hawick_circuits.html deleted file mode 100644 index 5658b9a1c..000000000 --- a/doc/hawick_circuits.html +++ /dev/null @@ -1,72 +0,0 @@ - - -

- -

C++ Boost

- -

hawick_circuits

- -
template <typename Graph, typename Visitor, typename VertexIndexMap>
-void hawick_circuits(Graph const& graph, Visitor visitor, VertexIndexMap const& vim = get(vertex_index, graph), unsigned int max_length = 0);
-
-template <typename Graph, typename Visitor, typename VertexIndexMap>
-void hawick_unique_circuits(Graph const& graph, Visitor visitor, VertexIndexMap const& vim = get(vertex_index, graph), unsigned int max_length = 0);
-
- -

Enumerate all the elementary circuits (of length ≤ max_length, if nonzero) in a directed multigraph. Specifically, -self-loops and redundant circuits caused by parallel edges are enumerated too. -hawick_unique_circuits may be used if redundant circuits caused by parallel -edges are not desired.

- -

The algorithm is described in detail in -https://www.researchgate.net/publication/221440635_Enumerating_Circuits_and_Loops_in_Graphs_with_Self-Arcs_and_Multiple-Arcs.

- -

Where defined

- -

#include <boost/graph/hawick_circuits.hpp>

- -

Parameters

- -

IN: Graph const& graph

- -
-

The graph on which the algorithm is to be performed. It must be a model of - the VertexListGraph and AdjacencyGraph concepts.

-
- -

IN: Visitor visitor

- -
-

The visitor that will be notified on each circuit found by the algorithm. - The visitor.cycle(circuit, graph) expression must be valid, with circuit - being a const-reference to a random access sequence of vertex_descriptors.

- -

For example, if a circuit u -> v -> w -> u exists in the graph, the - visitor will be called with a sequence consisting of (u, v, w).

-
- -

IN: VertexIndexMap const& vim = get(vertex_index, graph)

- -
-

A model of the ReadablePropertyMap concept mapping each vertex_descriptor - to an integer in the range [0, num_vertices(graph)). It defaults to using - the vertex index map provided by the graph.

-
- -

IN: unsigned int max_length = 0

- -
-

The maximum circuit length to consider. Beyond this it truncates the depth-first search, reducing the computation time by ignoring longer circuits. The default value of max_length = 0 implies no maximum.

-
- -
- -
- © 2013-2015 Louis Dionne -
diff --git a/doc/history.html b/doc/history.html deleted file mode 100644 index ca537482c..000000000 --- a/doc/history.html +++ /dev/null @@ -1,214 +0,0 @@ - - - -Boost Graph Library: History - -C++ Boost - -
- -

History of the Boost Graph Library

- -The Boost Graph Library began its life as the Generic Graph Component -Library (GGCL), a software project at the Lab for Scientific Computing (LSC) at -the University of Notre Dame, under the direction of Professor Andrew Lumsdaine. The Lab's -research directions include numerical linear algebra, parallel -computing, and software engineering (including generic programming). - -

-Soon after the Standard Template Library was released, work began at -the LSC to apply generic programming to scientific computing. The Matrix Template Library -(Jeremy Siek's masters thesis) was one of the first projects. Many of -the lessons learned during construction of the MTL were applied to the -design and implementation of the GGCL. - -

-Graph algorithms play an important role in sparse matrix computations, -so the LSC had a need for a good graph library. However, none of the -available graph libraries (LEDA, GTL, Stanford GraphBase) were -written using the generic programming style of the STL, and hence did -not fulfill the flexibility and high-performance requirements of the -LSC. Others were also expressing interest in a generic C++ graph -library. During a meeting with Bjarne Stroustrup we were introduced to -several people at AT\&T who needed such a library. There had also been -earlier work in the area of generic graph algorithms, including some -codes written by Alexander Stepanov, and Dietmar Kühl's masters -thesis. - -

-With this in mind, and motivated by homework assignments in his -algorithms class, Jeremy began prototyping an interface and some graph -classes in the spring on 1998. Lie-Quan Lee then developed the first -version of GGCL, which became his masters thesis project. - -

-The following year, Jeremy went to work for SGI with Alexander -Stepanov and Matt Austern. During this time Alex's disjoint-sets based -connected components algorithm was added to GGCL, and Jeremy began -working on the concept documentation for GGCL similar to Matt's STL -documentation. - -

-While working at SGI, Jeremy heard about Boost and was excited to find -a group of people interested in creating high-quality C++ -libraries. At boost there were several people interested in generic -graph algorithms, most notably Dietmar Kühl. Some discussions -about generic interfaces for graph structures resulted in the a -revision of GGCL which closely resembles the current Boost Graph -Library interface. - -

-On September 4, 2000 GGCL passed the Boost formal review and became -the Boost Graph Library (BGL). The first release of BGL was -September 27, 2000. - -

Changes by version

- - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - - - - diff --git a/doc/howard_cycle_ratio.html b/doc/howard_cycle_ratio.html deleted file mode 100644 index 2835b3080..000000000 --- a/doc/howard_cycle_ratio.html +++ /dev/null @@ -1,233 +0,0 @@ - - - - - Boost Graph Library: Maximum (Minimum) cycle ratio - - - - - - - - - -

C++ Boost -

-

[maximum|minimum]_cycle_ratio

-

-

-template <typename Graph, typename VertexIndexMap,
-          typename EdgeWeight1, typename EdgeWeight2>
-dobule
-maximum_cycle_ratio(const Graph &g, VertexIndexMap vim,
-                    EdgeWeight1 ewm, EdgeWeight2 ew2m,
-                    std::vector<typename boost::graph_traits<Graph>::edge_descriptor> *pcc = 0);
-
-template <typename FloatTraits, Graph, typename VertexIndexMap,
-          typename EdgeWeight1, typename EdgeWeight2>
-typename FloatTraits::float_type
-maximum_cycle_ratio(const Graph &g, VertexIndexMap vim,
-                    EdgeWeight1 ewm, EdgeWeight2 ew2m,
-                    std::vector<typename boost::graph_traits<Graph>::edge_descriptor> *pcc = 0,
-                    FloatTraits = FloatTraits());
-
-template <typename Graph, typename VertexIndexMap,
-          typename EdgeWeight1, typename EdgeWeight2>
-dobule
-minimum_cycle_ratio(const Graph &g, VertexIndexMap vim,
-                    EdgeWeight1 ewm, EdgeWeight2 ew2m,
-                    std::vector<typename boost::graph_traits<Graph>::edge_descriptor> *pcc = 0);
-
-template <typename FloatTraits, typename Graph, typename VertexIndexMap,
-          typename EdgeWeight1, typename EdgeWeight2>
-typename FloatTraits::float_type
-minimum_cycle_ratio(const Graph &g, VertexIndexMap vim,
-                    EdgeWeight1 ewm, EdgeWeight2 ew2m,
-                    std::vector<typename boost::graph_traits<Graph>::edge_descriptor> *pcc = 0,
-                    FloatTraits = FloatTraits());
-
-

- - -The maximum_cycle_ratio() function calculates the maximum cycle ratio of a -weighted directed multigraph G=(V,E,W1,W2), where V is a vertex set, -E is an edge set, W1 and W2 are edge weight functions, W2 is nonnegative. -As a multigraph, G can have multiple edges connecting a pair of vertices. -

- -

Let every edge e has two weights W1(e) and W2(e). -Let c be a cycle of the graphg. Then, the cycle ratio, cr(c), is defined as:

-

-Cycle ratio definition -

- -The maximum (minimum) cycle ratio (mcr) is the maximum (minimum) cycle ratio -of all cycles of the graph. A cycle is called critical if its ratio is equal -to the mcr. The calculated maximum cycle ratio will be the return value -of the function. The maximum_cycle_ratio()/minimum_cycle_ratio() returns --FloatTraits::infinity()/FloatTraits::infinity() if graph has no cycles. -If the pcc parameter is not zero then one critical cycle will be written -to the corresponding std::vector of edge descriptors. The edges in the -vector stored in the way such that *pcc[0], *ppc[1], ..., *ppc[n] is a -correct path. -

-

-The algorithm is due to Howard's iteration policy algorithm, descibed in -[1]. -Ali Dasdan, Sandy S. Irani and Rajesh K.Gupta in their paper -Efficient Algorithms for Optimum Cycle Mean and Optimum Cost to Time Ratio -Problems state that this is the most efficient algorithm to the time being (1999).

- -

-For the convenience, functions maximum_cycle_mean() and minimum_cycle_mean() -are also provided. They have the following signatures: -

-template <typename Graph, typename VertexIndexMap,
-          typename EdgeWeightMap, typename EdgeIndexMap>
-double
-maximum_cycle_mean(const Graph &g, VertexIndexMap vim,
-                   EdgeWeightMap ewm, EdgeIndexMap eim,
-                   std::vector<typename graph_traits<Graph>::edge_descriptor> *pcc = 0);
-template <typename FloatTraits, typename Graph, typename VertexIndexMap,
-          typename EdgeWeightMap, typename EdgeIndexMap>
-
-typename FloatTraits::float_type
-maximum_cycle_mean(const Graph &g, VertexIndexMap vim,
-                   EdgeWeightMap ewm, EdgeIndexMap eim,
-                   std::vector<typename graph_traits<Graph>::edge_descriptor> *pcc = 0,
-                   FloatTraits = FloatTraits());
-
-template <typename Graph, typename VertexIndexMap,
-          typename EdgeWeightMap, typename EdgeIndexMap>
-double
-minimum_cycle_mean(const Graph &g, VertexIndexMap vim,
-                   EdgeWeightMap ewm, EdgeIndexMap eim,
-                   std::vector<typename graph_traits<Graph>::edge_descriptor> *pcc = 0);
-template <typename FloatTraits, typename Graph, typename VertexIndexMap,
-          typename EdgeWeightMap, typename EdgeIndexMap>
-
-typename FloatTraits::float_type
-minimum_cycle_mean(const Graph &g, VertexIndexMap vim,
-                   EdgeWeightMap ewm, EdgeIndexMap eim,
-                   std::vector<typename graph_traits<Graph>::edge_descriptor> *pcc = 0,
-                   FloatTraits = FloatTraits());
-
-

- -

Where Defined

-

boost/graph/howard_cycle_ratio.hpp -

-

Parameters

-

IN: FloatTraits

-
-The FloatTrats encapsulates customizable limits-like information for -floating point types. This type must provide an associated type, -value_type for the floating point type. - -The default value is boost::mcr_float<>which has the following -definition:
-
- template <typename Float = double>
- struct mcr_float {
-    typedef Float value_type;
-
-    static Float infinity()
-    { return (std::numeric_limits<value_type>::max)(); }
-
-    static Float epsilon()
-    { return Float(-0.005); }
-  };
-
-The value FloatTraits::epsilon() controls the "tolerance" of the -algorithm. By increasing the absolute value of epsilon you may slightly decrease -the execution time but there is a risk to skip a global optima. By decreasing -the absolute value you may fall to the infinite loop. The best option is to -leave this parameter unchanged. -
-

IN: const Graph& g -

-
A weighted directed multigraph. -The graph's type must be a model of VertexListGraph -and IncidenceGraph -
-

IN: VertexIndexMap vim -

-
Maps each vertex of the graph to a unique integer in the -range [0, num_vertices(g)). -
-

IN: EdgeWeight1 ew1m -

-
-The W1 edge weight function. -
-

IN: EdgeWeight2 ew2m -

-
-The W2 edge weight function. Should be nonnegative. The actual limitation of the -algorithm is the positivity of the total weight of each directed cycle of the graph. -
-

-OUT: std::vector<typename boost::graph_traits<Graph>::edge_descriptor>* pcc -

-
-If non zero then one critical cycle will be stored in the std::vector. Default -value is 0. -
-

-IN (only for maximum/minimal_cycle_mean()): EdgeIndexMap eim -

-
-Maps each edge of the graph to a unique integer in the range [0, num_edges(g)). -
-
-All property maps must be models of Readable -Property Map -
- -

Complexity

-

There is no known precise upper bound for the time complexity of the -algorithm. Imperical time complexity is O(|E|), where the constant tends to -be pretty small (about 20-30). Space complexity is equal to 7*|V| plus the -space required to store a graph. -

- -

Example

-

The program in libs/graph/example/cycle_ratio_example.cpp -generates a random graph and computes its maximum cycle ratio. -

- -
- - - - - -
-

Copyright © 2006-2009

- 		-

Dmitry - Bufistov, Andrey Parfenov

-
-



-

diff --git a/doc/incident.html b/doc/incident.html deleted file mode 100644 index 28e1f489e..000000000 --- a/doc/incident.html +++ /dev/null @@ -1,79 +0,0 @@ - - - -Boost Graph Library: incident - -C++ Boost - -
- -

-incident -

- -

-

- - - - - - - - - -
Complexity:O(1) -
Where Defined: -boost/graph/graph_utility.hpp -
-
- -

-

-  template <class Graph>
-  std::pair<typename graph_traits<Graph>::vertex_descriptor,
-            typename graph_traits<Graph>::vertex_descriptor>
-  incident(typename graph_traits<Graph>::edge_descriptor e, Graph& g)
-
- -This function takes an edge descriptor and returns the pair of -vertices that are incident to the edge. For directed graphs, -the first vertex is the source and the second vertex -is the target. This function is equivalent to the expression -std::make_pair(source(e, g), target(e, g)). - - -

Example

- -
-  edge_descriptor e;
-  vertex_descriptor u, v;
-  ...
-  boost::tie(u, v) = incident(e, g);
-
- - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/incremental_components.html b/doc/incremental_components.html deleted file mode 100644 index a0c9de00d..000000000 --- a/doc/incremental_components.html +++ /dev/null @@ -1,420 +0,0 @@ - - - -Boost Graph Library: Incremental Connected Components - - - -C++ Boost - -
- -

Incremental Connected Components

- -

-This section describes a family of functions and classes that work -together to calculate the connected components of an undirected graph. -The algorithm used here is based on the disjoint-sets (fast -union-find) data structure [8,27] -which is a good method to use for situations where the graph is -growing (edges are being added) and the connected components -information needs to be updated repeatedly. This method does not cover -the situation where edges are both added and removed from the graph, -hence it is called incremental[42] (and not -fully dynamic). The disjoint-sets class is described in Section Disjoint Sets. - -

-The following five operations are the primary functions that you will -use to calculate and maintain the connected components. The objects -used here are a graph g, a disjoint-sets structure ds, -and vertices u and v. - -

- -

    -
  • initialize_incremental_components(g, ds) -
    -Basic initialization of the disjoint-sets structure. Each - vertex in the graph g is in its own set. -
    • -
  • incremental_components(g, ds) -
    -The connected components are calculated based on the edges in the graph - g and the information is embedded in ds. -
    • -
  • ds.find_set(v) -
    -Extracts the component information for vertex v from the - disjoint-sets. -
    • -
  • ds.union_set(u, v) -
    -Update the disjoint-sets structure when edge (u,v) is added to the graph. -
    • -
- -

- -

Complexity

- -

-The time complexity for the whole process is O(V + E -alpha(E,V)) where E is the total number of edges in the -graph (by the end of the process) and V is the number of -vertices. alpha is the inverse of Ackermann's function which -has explosive recursively exponential growth. Therefore its inverse -function grows very slowly. For all practical purposes -alpha(m,n) <= 4 which means the time complexity is only -slightly larger than O(V + E). - -

- -

Example

- -

-Maintain the connected components of a graph while adding edges using -the disjoint-sets data structure. The full source code for this -example can be found in examples/incremental_components.cpp. - -

-

-using namespace boost;
-
-int main(int argc, char* argv[])
-{
-  typedef adjacency_list  Graph;
-  typedef graph_traits::vertex_descriptor Vertex;
-  typedef graph_traits::vertices_size_type VertexIndex;
-
-  const int VERTEX_COUNT = 6;
-  Graph graph(VERTEX_COUNT);
-
-  std::vector rank(num_vertices(graph));
-  std::vector parent(num_vertices(graph));
-
-  typedef VertexIndex* Rank;
-  typedef Vertex* Parent;
-
-  disjoint_sets ds(&rank[0], &parent[0]);
-
-  initialize_incremental_components(graph, ds);
-  incremental_components(graph, ds);
-
-  graph_traits::edge_descriptor edge;
-  bool flag;
-
-  boost::tie(edge, flag) = add_edge(0, 1, graph);
-  ds.union_set(0,1);
-
-  boost::tie(edge, flag) = add_edge(1, 4, graph);
-  ds.union_set(1,4);
-
-  boost::tie(edge, flag) = add_edge(4, 0, graph);
-  ds.union_set(4,0);
-
-  boost::tie(edge, flag) = add_edge(2, 5, graph);
-  ds.union_set(2,5);
-
-  std::cout << "An undirected graph:" << std::endl;
-  print_graph(graph, get(boost::vertex_index, graph));
-  std::cout << std::endl;
-
-  BOOST_FOREACH(Vertex current_vertex, vertices(graph)) {
-    std::cout << "representative[" << current_vertex << "] = " <<
-      ds.find_set(current_vertex) << std::endl;
-  }
-
-  std::cout << std::endl;
-
-  typedef component_index Components;
-
-  // NOTE: Because we're using vecS for the graph type, we're
-  // effectively using identity_property_map for a vertex index map.
-  // If we were to use listS instead, the index map would need to be
-  // explicity passed to the component_index constructor.
-  Components components(parent.begin(), parent.end());
-
-  // Iterate through the component indices
-  BOOST_FOREACH(VertexIndex current_index, components) {
-    std::cout << "component " << current_index << " contains: ";
-
-    // Iterate through the child vertex indices for [current_index]
-    BOOST_FOREACH(VertexIndex child_index,
-                  components[current_index]) {
-      std::cout << child_index << " ";
-    }
-
-    std::cout << std::endl;
-  }
-
-  return (0);
-}
-
- -

-

-

- -

-initialize_incremental_components -

- -

-

- - - - - - - - - - -
Graphs:undirected
Properties:rank, parent (in disjoint-sets)
Complexity:
-
- -

-

-template <class VertexListGraph, class DisjointSets>
-void initialize_incremental_components(VertexListGraph& G, DisjointSets& ds)
-
- -

-This prepares the disjoint-sets data structure for the incremental -connected components algorithm by making each vertex in the graph a -member of its own component (or set). - -

- -

Where Defined

- -

-boost/graph/incremental_components.hpp - -

-

-

- -

-incremental_components -

- -

-

- - - - - - - - - - -
Graphs:undirected
Properties:rank, parent (in disjoint-sets)
Complexity:O(E)
-
- -

-

-template <class EdgeListGraph, class DisjointSets>
-void incremental_components(EdgeListGraph& g, DisjointSets& ds)
-
- -

-This function calculates the connected components of the graph, -embedding the results in the disjoint-sets data structure. - -

- -

Where Defined

- -

-boost/graph/incremental_components.hpp - -

- -

Requirements on Types

- -

- -

- -

-

-

- -

-same_component -

- -

-

- - - - - - - -
Properties:rank, parent (in disjoint-sets)
Complexity:O(alpha(E,V))
-
- -

-

-template <class Vertex, class DisjointSet>
-bool same_component(Vertex u, Vertex v, DisjointSet& ds)
-
- -

-This function determines whether u and v are in the same -component. - -

- -

Where Defined

- -

-boost/graph/incremental_components.hpp - -

- -

Requirements on Types

- -

- -

    -
  • Vertex must be compatible with the rank and parent - property maps of the DisjointSets data structure. -
    • -
- -

-

-

- -

-component_index -

- -

-

-component_index<Index>
-
- -

-The component_index class provides an STL -container-like view for the components of the graph. Each component is -a container-like object, and access is provided via -the operator[]. A component_index object is -initialized with the parents property in the disjoint-sets calculated -from the incremental_components() function. Optionally, a -vertex -> index property map is passed in -(identity_property_map is used by default). - -

- -

Where Defined

- -

-boost/graph/incremental_components.hpp - -

- -

Members

- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Member Description
value_type/size_type -The type for a component index (same as Index). -
size_type size() -Returns the number of components in the graph. -
iterator/const_iterator -Iterators used to traverse the available component indices [0 to size()). -
iterator begin() const -Returns an iterator at the start of the component indices (0). -
iterator end() const -Returns an iterator past the end of the component indices (size()). -
std::pair<component_iterator, component_iterator> operator[size_type index] const -Returns a pair of iterators for the component at index where index is in [0, size()). -
- -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/index.html b/doc/index.html deleted file mode 100644 index 8690dbc21..000000000 --- a/doc/index.html +++ /dev/null @@ -1,305 +0,0 @@ - - - - - -The Boost Graph Library - -C++ Boost - -

The Boost Graph Library (BGL) - -BGL Book -

- -

-Graphs are mathematical abstractions that are useful for solving many -types of problems in computer science. Consequently, these -abstractions must also be represented in computer programs. A -standardized generic interface for traversing graphs is of utmost -importance to encourage reuse of graph algorithms and data structures. -Part of the Boost Graph Library is a generic interface that allows -access to a graph's structure, but hides the details of the -implementation. This is an “open” interface in the sense that any -graph library that implements this interface will be interoperable -with the BGL generic algorithms and with other algorithms that also -use this interface. The BGL provides some general purpose graph classes -that conform to this interface, but they are not meant to be the -“only” graph classes; there certainly will be other graph classes -that are better for certain situations. We believe that the main -contribution of the The BGL is the formulation of this interface. - -

-The BGL graph interface and graph components are generic, in the -same sense as the Standard Template Library (STL) [2]. - -In the following sections, we review the role that generic programming -plays in the STL and compare that to how we applied generic -programming in the context of graphs. - -

-Of course, if you are already familiar with generic programming, -please dive right in! Here's the Table of Contents. For distributed-memory -parallelism, you can also look at the Parallel BGL. - -

-The source for the BGL is available as part of the Boost distribution, -which you can -download from here. - -

How to Build the BGL

-

DON'T! The Boost Graph Library is a header-only library and -does not need to be built to be used. The only exceptions are the GraphViz input parser and the GraphML parser.

- -

When compiling programs that use the BGL, be sure to compile -with optimization. For instance, select “Release” mode with -Microsoft Visual C++ or supply the flag -O2 or -O3 -to GCC.

- -

Genericity in STL

- -

-There are three ways in which the STL is generic. - -

- -

Algorithm/Data-Structure Interoperability

- -

-First, each algorithm is written in a data-structure neutral way, -allowing a single template function to operate on many different -classes of containers. The concept of an iterator is the key -ingredient in this decoupling of algorithms and data-structures. The -impact of this technique is a reduction in the STL's code size from -O(M*N) to O(M+N), where M is the number of -algorithms and N is the number of containers. Considering a -situation of 20 algorithms and 5 data-structures, this would be the -difference between writing 100 functions versus only 25 functions! And -the differences continues to grow faster and faster as the number of -algorithms and data-structures increase. - -

- -

Extension through Function Objects

- -

-The second way that STL is generic is that its algorithms and containers -are extensible. The user can adapt and customize the STL through the -use of function objects. This flexibility is what makes STL such a -great tool for solving real-world problems. Each programming problem -brings its own set of entities and interactions that must be -modeled. Function objects provide a mechanism for extending the STL to -handle the specifics of each problem domain. - -

- -

Element Type Parameterization

- -

-The third way that STL is generic is that its containers are -parameterized on the element type. Though hugely important, this is -perhaps the least “interesting” way in which STL is generic. -Generic programming is often summarized by a brief description of -parameterized lists such as std::list<T>. This hardly scratches -the surface! - -

- -

Genericity in the Boost Graph Library -

- -

-Like the STL, there are three ways in which the BGL is generic. - -

- -

Algorithm/Data-Structure Interoperability

- -

-First, the graph algorithms of the BGL are written to an interface that -abstracts away the details of the particular graph data-structure. -Like the STL, the BGL uses iterators to define the interface for -data-structure traversal. There are three distinct graph traversal -patterns: traversal of all vertices in the graph, through all of the -edges, and along the adjacency structure of the graph (from a vertex -to each of its neighbors). There are separate iterators for each -pattern of traversal. - -

-This generic interface allows template functions such as breadth_first_search() -to work on a large variety of graph data-structures, from graphs -implemented with pointer-linked nodes to graphs encoded in -arrays. This flexibility is especially important in the domain of -graphs. Graph data-structures are often custom-made for a particular -application. Traditionally, if programmers want to reuse an -algorithm implementation they must convert/copy their graph data into -the graph library's prescribed graph structure. This is the case with -libraries such as LEDA, GTL, Stanford GraphBase; it is especially true -of graph algorithms written in Fortran. This severely limits the reuse -of their graph algorithms. - -

-In contrast, custom-made (or even legacy) graph structures can be used -as-is with the generic graph algorithms of the BGL, using external -adaptation (see Section How to -Convert Existing Graphs to the BGL). External adaptation wraps a new -interface around a data-structure without copying and without placing -the data inside adaptor objects. The BGL interface was carefully -designed to make this adaptation easy. To demonstrate this, we have -built interfacing code for using a variety of graph structures (LEDA -graphs, Stanford GraphBase graphs, and even Fortran-style arrays) in -BGL graph algorithms. - -

- -

Extension through Visitors

- -

-Second, the graph algorithms of the BGL are extensible. The BGL introduces the -notion of a visitor, which is just a function object with -multiple methods. In graph algorithms, there are often several key -“event points” at which it is useful to insert user-defined -operations. The visitor object has a different method that is invoked -at each event point. The particular event points and corresponding -visitor methods depend on the particular algorithm. They often -include methods like start_vertex(), -discover_vertex(), examine_edge(), -tree_edge(), and finish_vertex(). - -

- -

Vertex and Edge Property Multi-Parameterization

- -

-The third way that the BGL is generic is analogous to the parameterization -of the element-type in STL containers, though again the story is a bit -more complicated for graphs. We need to associate values (called -“properties”) with both the vertices and the edges of the graph. -In addition, it will often be necessary to associate -multiple properties with each vertex and edge; this is what we mean -by multi-parameterization. -The STL std::list<T> class has a parameter T -for its element type. Similarly, BGL graph classes have template -parameters for vertex and edge “properties”. A -property specifies the parameterized type of the property and also assigns -an identifying tag to the property. This tag is used to distinguish -between the multiple properties which an edge or vertex may have. A -property value that is attached to a -particular vertex or edge can be obtained via a property -map. There is a separate property map for each property. - -

-Traditional graph libraries and graph structures fall down when it -comes to the parameterization of graph properties. This is one of the -primary reasons that graph data-structures must be custom-built for -applications. The parameterization of properties in the BGL graph -classes makes them well suited for re-use. - -

- -

Algorithms

- -

-The BGL algorithms consist of a core set of algorithm patterns -(implemented as generic algorithms) and a larger set of graph -algorithms. The core algorithm patterns are - -

- -

    -
  • Breadth First Search -
    • -
  • Depth First Search -
    • -
  • Uniform Cost Search -
    • -
- -

-By themselves, the algorithm patterns do not compute any meaningful -quantities over graphs; they are merely building blocks for -constructing graph algorithms. The graph algorithms in the BGL currently -include - -

- -

    -
  • Dijkstra's Shortest Paths
    • -
  • Bellman-Ford Shortest Paths
    • -
  • Johnson's All-Pairs Shortest Paths
    • -
  • Kruskal's Minimum Spanning Tree
    • -
  • Prim's Minimum Spanning Tree
    • -
  • Connected Components
    • -
  • Strongly Connected Components
    • -
  • Dynamic Connected Components (using Disjoint Sets)
    • -
  • Topological Sort
    • -
  • Transpose
    • -
  • Reverse Cuthill Mckee Ordering
    • -
  • Smallest Last Vertex Ordering
    • -
  • Sequential Vertex Coloring
    • -
- -

- -

Data Structures

- -

-The BGL currently provides two graph classes and an edge list adaptor: -

- -

- -

-The adjacency_list class is the general purpose “swiss army -knife” of graph classes. It is highly parameterized so that it can be -optimized for different situations: the graph is directed or -undirected, allow or disallow parallel edges, efficient access to just -the out-edges or also to the in-edges, fast vertex insertion and -removal at the cost of extra space overhead, etc. - -

-The adjacency_matrix class stores edges in a |V| x |V| -matrix (where |V| is the number of vertices). The elements of -this matrix represent edges in the graph. Adjacency matrix -representations are especially suitable for very dense graphs, i.e., -those where the number of edges approaches |V|2. - -

-The edge_list class is an adaptor that takes any kind of edge -iterator and implements an Edge List Graph. - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/inv_adjacency_iterator.html b/doc/inv_adjacency_iterator.html deleted file mode 100644 index e0fa8771b..000000000 --- a/doc/inv_adjacency_iterator.html +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - - -Inverse Adjacency Iterator Adaptor Documentation - - - - -boost.png (6897 bytes) - -

Inverse Adjacency Iterator Adaptor

- -Defined in header -boost/graph/adjacency_iterator.hpp - -

-The inverse adjacency iterator adaptor transforms an -in_edge_iterator into an inverse adjacency iterator. That is, it -takes an iterator that traverses over edges, and creates an iterator -that traverses over the source vertices of those edges. - - - - -

Synopsis

- -
-namespace boost {
-  template <class Graph, class VertexDescriptor, class InEdgeIter>
-  class inv_adjacency_iterator_generator {
-  public:
-    typedef iterator_adaptor<...> type;
-  };
-}
-
- -
- -

Example

- -

-The following is an example of how to use the -inv_adjacency_iterator_generator class. - -

-

-#include <boost/graph/adjacency_iterator.hpp>
-
-class my_graph {
-  // ...
-  typedef ... in_edge_iterator;
-  typedef ... vertex_descriptor;
-  typedef boost::inv_adjacency_iterator_generator<my_graph, vertex_descriptor, in_edge_iterator>::type inv_adjacency_iterator;
-  // ...
-};
-
-
- -

Template Parameters

- - - - - - - - - - - - - - - - - - - - - -
ParameterDescription
GraphThe graph type, which must model Incidence Graph.
VertexDescriptorThis must be the same type as -graph_traits<Graph>::vertex_descriptor. The reason why -this is a template parameter is that the primary use of -inv_adjacency_iterator_generator is inside the -definition of the graph class, and in that context we can not use -graph_traits on the not yet fully defined graph class.
-Default: graph_traits<Graph>::vertex_descriptor
InEdgeIterThis must be the same type as -graph_traits<Graph>::in_edge_iterator.
-Default: graph_traits<Graph>::in_edge_iterator -
- -

Model of

- -The inverse adjacency iterator adaptor (the type -inv_adjacency_iterator_generator<...>::type) is a model of Multi-Pass Input Iterator -. - - -

Members

- -The inverse adjacency iterator type implements the member functions and -operators required of the Random Access Iterator -concept, except that the reference type is the same as the value_type -so operator*() returns by-value. In addition it has the following constructor: - -
-inv_adjacency_iterator_generator::type(const InEdgeIter& it, const Graph* g)
-
- -
-

Revised 19 Aug 2001

-

© Copyright Jeremy Siek 2000. Permission to copy, use, -modify, sell and distribute this document is granted provided this copyright -notice appears in all copies. This document is provided "as is" -without express or implied warranty, and with no claim as to its suitability for -any purpose.

- - - - - - diff --git a/doc/is_bipartite.html b/doc/is_bipartite.html deleted file mode 100644 index 29e0ebe32..000000000 --- a/doc/is_bipartite.html +++ /dev/null @@ -1,127 +0,0 @@ - - - - -Boost Graph Library: is_bipartite - - - - -

-is_bipartite -

- -
-// Version with a colormap to retrieve the bipartition
-template <typename Graph, typename IndexMap, typename PartitionMap>
-bool is_bipartite (const Graph& graph, const IndexMap index_map, PartitionMap partition_map)
-
-template <typename Graph, typename IndexMap>
-bool is_bipartite (const Graph& graph, const IndexMap index_map)
-
-// Version which uses the internal index map
-template <typename Graph>
-bool is_bipartite (const Graph& graph);
-
- -

-The is_bipartite() functions tests a given graph for -bipartiteness using a DFS-based coloring approach. -

- -

-An undirected graph is bipartite if one can partition its set of vertices -into two sets "left" and "right", such that each edge goes from either side -to the other. Obviously, a two-coloring of the graph is exactly the same as -a two-partition. is_bipartite() tests whether such a two-coloring -is possible and can return it in a given property map. -

- -

-The bipartition is recorded in the color map partition_map, -which will contain a two-coloring of the graph, i.e. an assignment of -black and white to the vertices such that no edge is monochromatic. -The predicate whether the graph is bipartite is the return value of the function. -

- -

Where Defined

- -

-boost/graph/bipartite.hpp -

- -

Parameters

- -

-IN: const Graph& graph -

-

-An undirected graph. The graph type must be a model of Vertex List Graph and Incidence Graph.
-

- -

-IN: const IndexMap index_map -

-

-This maps each vertex to an integer in the range [0, -num_vertices(graph)). 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 usable as the key -type of the map.
-

- - -

-OUT: PartitionMap partition_map -

-

-The algorithm tests whether the graph is bipartite and assigns each -vertex either a white or a black color, according to the partition. -The PartitionMap type must be a model of -Readable Property -Map and -Writable Property -Map The value type must model ColorValue. -

- - -

Complexity

- -

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

- -

See Also

- -

-find_odd_cycle() -

- -

Example

- -

-The file examples/bipartite.cpp -contains an example of testing an undirected graph for bipartiteness. -
-

- -
- -

-Copyright © 2010 Matthias Walter -(xammy@xammy.homelinux.net) -

- - - diff --git a/doc/is_kuratowski_subgraph.html b/doc/is_kuratowski_subgraph.html deleted file mode 100644 index a118d9a0c..000000000 --- a/doc/is_kuratowski_subgraph.html +++ /dev/null @@ -1,126 +0,0 @@ - -Boost Graph Library: is_kuratowski_subgraph - - -C++ Boost - -
- -

is_kuratowski_subgraph

- -
template <typename Graph, typename ForwardIterator, typename VertexIndexMap>
-bool is_kuratowski_subgraph(const Graph& g, ForwardIterator begin, ForwardIterator end, VertexIndexMap vm)
-
- -

- -is_kuratowski_subgraph(g, begin, end) returns true exactly -when the sequence of edges defined by the range [begin, end) forms a - Kuratowski subgraph in -the graph g. If you need to verify that an arbitrary graph has a -K5 or K3,3 minor, you should use the -function boyer_myrvold_planarity_test -to isolate such a minor instead of this function. is_kuratowski_subgraph - exists to aid in testing and verification of the function -boyer_myrvold_planarity_test, and for that reason, it expects its -input to be a restricted set of edges forming a Kuratowski subgraph, as -described in detail below. -

-is_kuratowski_subgraph creates a temporary graph out of the sequence -of edges given and repeatedly contracts edges until it ends up with a graph -with either all edges of degree 3 or all edges of degree 4. The final -contracted graph is then checked against K5 or -K3,3 using the Boost Graph Library's -isomorphism -function. The contraction process starts by choosing edges adjacent to a vertex -of degree 1 and contracting those. When none are left, it moves on to edges -adjacent to a vertex of degree 2. If only degree 3 vertices are left after this -stage, the graph is checked against K3,3. Otherwise, if -there's at least one degree 4 vertex, edges adjacent to degree 3 vertices are -contracted as neeeded and the final graph is compared to K5. -

-In order for this process to be deterministic, we make the following two -restrictions on the input graph given to is_kuratowski_subgraph: -

    -
  1. No edge contraction needed to produce a kuratowski subgraph results in -multiple edges between the same pair of vertices (No edge {a,b} will be -contracted at any point in the contraction process if a and b -share a common neighbor.) -
  2. If the graph contracts to a K5, once the graph has -been contracted to only vertices of degree at least 3, no cycles exist that -contain solely degree 3 vertices. -
-The second restriction is needed both to discriminate between targeting a -K5 or a K3,3 and to determinstically -contract the vertices of degree 4 once the K5 has been -targeted. The Kuratowski subgraph output by the function -boyer_myrvold_planarity_test is -guaranteed to meet both of the above requirements. - - -

Complexity

- -On a graph with n vertices, this function runs in time O(n). - -

Where Defined

- -

- -boost/graph/is_kuratowski_subgraph.hpp - - -

Parameters

- -IN: Graph& g - -
-An undirected graph with no self-loops or parallel edges. The graph type must -be a model of Vertex List Graph. -
- -IN: ForwardIterator - -
-A ForwardIterator with value_type -graph_traits<Graph>::edge_descriptor. -
- -IN: VertexIndexMap vm - -
-A Readable Property Map - that maps vertices from g to distinct integers in the range -[0, num_vertices(g) )
-Default: get(vertex_index,g)
-
- - -

Example

- -

- -examples/kuratowski_subgraph.cpp - - -

See Also

- -

-Planar Graphs in the Boost Graph Library - - -
-

-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/is_straight_line_drawing.html b/doc/is_straight_line_drawing.html deleted file mode 100644 index 0df33ac71..000000000 --- a/doc/is_straight_line_drawing.html +++ /dev/null @@ -1,93 +0,0 @@ - - - -Boost Graph Library: is_straight_line_drawing - -C++ Boost - -
- -

is_straight_line_drawing

- -

-

-template <typename Graph, typename GridPositionMap, typename VertexIndexMap>
-bool is_straight_line_drawing(const Graph& g, GridPositionMap drawing, VertexIndexMap vm);
-
- -

-If drawing is a property map modeling the PositionMap -concept, is_straight_line_drawing returns true exactly when no two of -the line segments induced by edges in the graph under drawing -intersect. This function works correctly in the presence of self-loops and -parallel edges, and can be used to verify the output of the function - -chrobak_payne_straight_line_embedding. - - -

- -

Complexity

- -Runs in time O(n log n) on a planar graph with n vertices. - -

Where Defined

- -

-boost/graph/is_straight_line_drawing.hpp - -

Parameters

- -IN: Graph& g - -
-An undirected graph. The graph type must be a model of Edge List Graph -
- -IN: PositionMap - -
-A Readable LValue Property -Map that models the Position Map concept. The Position Map concept requires -that the value mapped to be an object that has members x and -y. For example, if p models PositionMap and v -is a vertex in the graph, p[v].x and p[v].y are valid -expressions. The type of x and y must be implicitly -convertable to std::size_t. -
- -IN: VertexIndexMap vm - -
-A Readable Property Map that maps vertices from g to distinct integers in the range [0, num_vertices(g) )
-Default: get(vertex_index,g)
-
- -

Example

- -

-examples/straight_line_drawing.cpp - -

See Also

- -

-

- -
-
-Copyright © 2007 Aaron Windsor (aaron.windsor@gmail.com) - - diff --git a/doc/iscope99.pdf b/doc/iscope99.pdf deleted file mode 100644 index afed76cdb..000000000 Binary files a/doc/iscope99.pdf and /dev/null differ diff --git a/doc/iso-eg.dot b/doc/iso-eg.dot deleted file mode 100644 index 33e10eb6f..000000000 --- a/doc/iso-eg.dot +++ /dev/null @@ -1,159 +0,0 @@ -digraph "g" { - graph [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - size = "4,2.5" - ratio = "fill" - ] - node [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - shape = "circle" - color = "black" - ] - edge [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - ] - "c (0)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - peripheries = 2 - ] - "a (1)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "b (2)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "d (3)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "e (4)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "f (5)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - peripheries = 2 - ] - "g (6)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "h (7)" [ - label = "\N" - color = "black" - width = "0.833333" - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - ] - "c (0)" -> "a (1)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "a (1)" -> "b (2)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "a (1)" -> "d (3)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "c (0)" -> "e (4)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "f (5)" -> "g (6)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "g (6)" -> "h (7)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "bold" - ] - "d (3)" -> "b (2)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "dashed" - ] - "c (0)" -> "d (3)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "dashed" - ] - "g (6)" -> "e (4)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "dashed" - ] - "h (7)" -> "f (5)" [ - fontsize = "14" - fontname = "Times-Roman" - fontcolor = "black" - color = "black" - style = "dashed" - ] -} diff --git a/doc/isomorphism-impl-v2.w b/doc/isomorphism-impl-v2.w deleted file mode 100644 index 1fd53b8dd..000000000 --- a/doc/isomorphism-impl-v2.w +++ /dev/null @@ -1,1067 +0,0 @@ -\documentclass[11pt]{report} - -%\input{defs} -\usepackage{math} -\usepackage{jweb} -\usepackage{lgrind} -\usepackage{times} -\usepackage{fullpage} -\usepackage{graphicx} - -\newif\ifpdf -\ifx\pdfoutput\undefined - \pdffalse -\else - \pdfoutput=1 - \pdftrue -\fi - -\ifpdf - \usepackage[ - pdftex, - colorlinks=true, %change to true for the electronic version - linkcolor=blue,filecolor=blue,pagecolor=blue,urlcolor=blue - ]{hyperref} -\fi - -\ifpdf - \newcommand{\stlconcept}[1]{\href{https://boost.org/sgi/stl/#1.html}{{\small \textsf{#1}}}} - \newcommand{\bglconcept}[1]{\href{http://www.boost.org/libs/graph/doc/#1.html}{{\small \textsf{#1}}}} - \newcommand{\pmconcept}[1]{\href{http://www.boost.org/libs/property_map/#1.html}{{\small \textsf{#1}}}} - \newcommand{\myhyperref}[2]{\hyperref[#1]{#2}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.pdf}}\caption{#2}\label{fig:#1}\end{figure}} -\else - \newcommand{\myhyperref}[2]{#2} - \newcommand{\bglconcept}[1]{{\small \textsf{#1}}} - \newcommand{\pmconcept}[1]{{\small \textsf{#1}}} - \newcommand{\stlconcept}[1]{{\small \textsf{#1}}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.eps}}\caption{#2}\label{fig:#1}\end{figure}} -\fi - -\newcommand{\code}[1]{{\small{\em \textbf{#1}}}} - - -\newcommand{\isomorphic}{\cong} - -\begin{document} - -\title{An Implementation of Isomorphism Testing} -\author{Jeremy G. Siek} - -\maketitle - -\section{Introduction} - -This paper documents the implementation of the \code{isomorphism()} -function of the Boost Graph Library. The implementation was by Jeremy -Siek with algorithmic improvements and test code from Douglas Gregor -and Brian Osman. The \code{isomorphism()} function answers the -question, ``are these two graphs equal?'' By \emph{equal} we mean -the two graphs have the same structure---the vertices and edges are -connected in the same way. The mathematical name for this kind of -equality is \emph{isomorphism}. - -More precisely, an \emph{isomorphism} is a one-to-one mapping of the -vertices in one graph to the vertices of another graph such that -adjacency is preserved. Another words, given graphs $G_{1} = -(V_{1},E_{1})$ and $G_{2} = (V_{2},E_{2})$, an isomorphism is a -function $f$ such that for all pairs of vertices $a,b$ in $V_{1}$, -edge $(a,b)$ is in $E_{1}$ if and only if edge $(f(a),f(b))$ is in -$E_{2}$. - -Both graphs must be the same size, so let $N = |V_1| = |V_2|$. The -graph $G_1$ is \emph{isomorphic} to $G_2$ if an isomorphism exists -between the two graphs, which we denote by $G_1 \isomorphic G_2$. - -In the following discussion we will need to use several notions from -graph theory. The graph $G_s=(V_s,E_s)$ is a \emph{subgraph} of graph -$G=(V,E)$ if $V_s \subseteq V$ and $E_s \subseteq E$. An -\emph{induced subgraph}, denoted by $G[V_s]$, of a graph $G=(V,E)$ -consists of the vertices in $V_s$, which is a subset of $V$, and every -edge $(u,v)$ in $E$ such that both $u$ and $v$ are in $V_s$. We use -the notation $E[V_s]$ to mean the edges in $G[V_s]$. - -In some places we express a function as a set of pairs, so the set $f -= \{ \pair{a_1}{b_1}, \ldots, \pair{a_n}{b_n} \}$ -means $f(a_i) = b_i$ for $i=1,\ldots,n$. - -\section{Exhaustive Backtracking Search} -\label{sec:backtracking} - -The algorithm used by the \code{isomorphism()} function is, at -first approximation, an exhaustive search implemented via -backtracking. The backtracking algorithm is a recursive function. At -each stage we will try to extend the match that we have found so far. -So suppose that we have already determined that some subgraph of $G_1$ -is isomorphic to a subgraph of $G_2$. We then try to add a vertex to -each subgraph such that the new subgraphs are still isomorphic to one -another. At some point we may hit a dead end---there are no vertices -that can be added to extend the isomorphic subgraphs. We then -backtrack to previous smaller matching subgraphs, and try extending -with a different vertex choice. The process ends by either finding a -complete mapping between $G_1$ and $G_2$ and return true, or by -exhausting all possibilities and returning false. - -We consider the vertices of $G_1$ for addition to the matched subgraph -in a specific order, so assume that the vertices of $G_1$ are labeled -$1,\ldots,N$ according to that order. As we will see later, a good -ordering of the vertices is by DFS discover time. Let $G_1[k]$ denote -the subgraph of $G_1$ induced by the first $k$ vertices, with $G_1[0]$ -being an empty graph. We also consider the edges of $G_1$ in a -specific order. We always examine edges in the current subgraph -$G_1[k]$ first, that is, edges $(u,v)$ where both $u \leq k$ and $v -\leq k$. This ordering of edges can be acheived by sorting the edges -according to number of the larger of the source and target vertex. - -Each step of the backtracking search examines an edge $(u,v)$ of $G_1$ -and decides whether to continue or go back. There are three cases to -consider: - -\begin{enumerate} - -\item $i \leq k \Land j \leq k$. Both $i$ and $j$ are in $G_1[k]$. We -check to make sure the $(f(i),f(j)) \in E_2[S]$. - -\item $i \leq k \Land j > k$. $i$ is in the matched subgraph $G_1[k]$, -but $j$ is not. We are about to increment $k$ try to grow the matched -subgraph to include $j$. However, first we need to finalize our check -of the isomorphism between subgraphs $G_1[k]$ and $G_2[S]$. At this -point we are guaranteed to have seen all the edges to and from vertex $k$ -(because the edges are sorted), and in previous steps we have checked -that for each edge incident on $k$ in $G_1[k]$ there is a matching -edge in $G_2[S]$. However we have not checked that for each edge -incident on $f(k)$ in $E_2[S]$, there is a matching edge in $E_1[k]$ -(we need to check the ``only if'' part of the ``if and only if''). -Therefore we scan through all the edges $(u,v)$ incident on $f(k)$ and -make sure that $(f^{-1}(u),f^{-1}(v)) \in E_1[k]$. Once this check has -been performed, we add $f(k)$ to $S$, we increment $k$ (so now $k=j$), -and then try assigning the new $k$ to any of the eligible vertices in -$V_2 - S$. More about what ``eligible'' means later. - -\item $i > k \Land j \leq k$. This case will not occur due to the DFS -numbering of the vertices. There is an edge $(i,j)$ so $i$ must be -less than $j$. - -\item $i > k \Land j > k$. Neither $i$ or $j$ is in the matched -subgraph $G_1[k]$. This situation only happens at the very beginning -of the search, or when $i$ and $j$ are not reachable from any of the -vertices in $G_1[k]$. This means the smaller of $i$ and $j$ must be -the root of a DFS tree. We assign $r$ to any of the eligible vertices -in $V_2 - S$, and then proceed as if we were in Case 2. - -\end{enumerate} - - - -@d Match function -@{ -bool match(edge_iter iter) -{ -if (iter != ordered_edges.end()) { - ordered_edge edge = *iter; - size_type k_num = edge.k_num; - vertex1_t k = dfs_vertices[k_num]; - vertex1_t u; - if (edge.source != -1) // might be a ficticious edge - u = dfs_vertices[edge.source]; - vertex1_t v = dfs_vertices[edge.target]; - if (edge.source == -1) { // root node - @<$v$ is a DFS tree root@> - } else if (f_assigned[v] == false) { - @<$v$ is an unmatched vertex, $(u,v)$ is a tree edge@> - } else { - @ - } -} else - return true; -return false; -} // match() -@} - - - - - - -The basic idea will be to examine $G_1$ one edge at a time, trying to -create a vertex mapping such that each edge matches one in $G_2$. We -are going to consider the edges of $G_1$ in a specific order, so we -will label the edges $0,\ldots,|E_1|-1$. - -At each stage of the recursion we -start with an isomorphism $f_{k-1}$ between $G_1[k-1]$ and a subgraph -of $G_2$, which we denote by $G_2[S]$, so $G_1[k-1] \isomorphic -G_2[S]$. The vertex set $S$ is the subset of $V_2$ that corresponds -via $f_{k-1}$ to the first $k-1$ vertices in $G_1$. - -We also order the edges of $G_1$ - - - -We try to extend the isomorphism by finding a vertex $v \in V_2 - S$ -that matches with vertex $k$. If a matching vertex is found, we have a -new isomorphism $f_k$ with $G_1[k] \isomorphic G_2[S \union \{ v \}]$. - - - - -\begin{tabbing} -IS\=O\=M\=O\=RPH($k$, $S$, $f_{k-1}$) $\equiv$ \\ -\>\textbf{if} ($k = |V_1|+1$) \\ -\>\>\textbf{return} true \\ -\>\textbf{for} each vertex $v \in V_2 - S$ \\ -\>\>\textbf{if} (MATCH($k$, $v$)) \\ -\>\>\>$f_k = f_{k-1} \union \pair{k}{v}$ \\ -\>\>\>ISOMORPH($k+1$, $S \union \{ v \}$, $f_k$)\\ -\>\>\textbf{else}\\ -\>\>\>\textbf{return} false \\ -\\ -ISOMORPH($0$, $G_1$, $\emptyset$, $G_2$) -\end{tabbing} - -The basic idea of the match operation is to check whether $G_1[k]$ is -isomorphic to $G_2[S \union \{ v \}]$. We already know that $G_1[k-1] -\isomorphic G_2[S]$ with the mapping $f_{k-1}$, so all we need to do -is verify that the edges in $E_1[k] - E_1[k-1]$ connect vertices that -correspond to the vertices connected by the edges in $E_2[S \union \{ -v \}] - E_2[S]$. The edges in $E_1[k] - E_1[k-1]$ are all the -out-edges $(k,j)$ and in-edges $(j,k)$ of $k$ where $j$ is less than -or equal to $k$ according to the ordering. The edges in $E_2[S \union -\{ v \}] - E_2[S]$ consists of all the out-edges $(v,u)$ and -in-edges $(u,v)$ of $v$ where $u \in S$. - -\begin{tabbing} -M\=ATCH($k$, $v$) $\equiv$ \\ -\>$out_k \leftarrow \forall (k,j) \in E_1[k] - E_1[k-1] \Big( (v,f(j)) \in E_2[S \union \{ v \}] - E_2[S] \Big)$ \\ -\>$in_k \leftarrow \forall (j,k) \in E_1[k] - E_1[k-1] \Big( (f(j),v) \in E_2[S \union \{ v \}] - E_2[S] \Big)$ \\ -\>$out_v \leftarrow \forall (v,u) \in E_2[S \union \{ v \}] - E_2[S] \Big( (k,f^{-1}(u)) \in E_1[k] - E_1[k-1] \Big)$ \\ -\>$in_v \leftarrow \forall (u,v) \in E_2[S \union \{ v \}] - E_2[S] \Big( (f^{-1}(u),k) \in E_1[k] - E_1[k-1] \Big)$ \\ -\>\textbf{return} $out_k \Land in_k \Land out_v \Land in_v$ -\end{tabbing} - -The problem with the exhaustive backtracking algorithm is that there -are $N!$ possible vertex mappings, and $N!$ gets very large as $N$ -increases, so we need to prune the search space. We use the pruning -techniques described in -\cite{deo77:_new_algo_digraph_isomorph,fortin96:_isomorph,reingold77:_combin_algo} -that originated in -\cite{sussenguth65:_isomorphism,unger64:_isomorphism}. - -\section{Vertex Invariants} -\label{sec:vertex-invariants} - -One way to reduce the search space is through the use of \emph{vertex -invariants}. The idea is to compute a number for each vertex $i(v)$ -such that $i(v) = i(v')$ if there exists some isomorphism $f$ where -$f(v) = v'$. Then when we look for a match to some vertex $v$, we only -need to consider those vertices that have the same vertex invariant -number. The number of vertices in a graph with the same vertex -invariant number $i$ is called the \emph{invariant multiplicity} for -$i$. In this implementation, by default we use the out-degree of the -vertex as the vertex invariant, though the user can also supply there -own invariant function. The ability of the invariant function to prune -the search space varies widely with the type of graph. - -As a first check to rule out graphs that have no possibility of -matching, one can create a list of computed vertex invariant numbers -for the vertices in each graph, sort the two lists, and then compare -them. If the two lists are different then the two graphs are not -isomorphic. If the two lists are the same then the two graphs may be -isomorphic. - -Also, we extend the MATCH operation to use the vertex invariants to -help rule out vertices. - -\section{Vertex Order} - -A good choice of the labeling for the vertices (which determines the -order in which the subgraph $G_1[k]$ is grown) can also reduce the -search space. In the following we discuss two labeling heuristics. - -\subsection{Most Constrained First} - -Consider the most constrained vertices first. That is, examine -lower-degree vertices before higher-degree vertices. This reduces the -search space because it chops off a trunk before the trunk has a -chance to blossom out. We can generalize this to use vertex -invariants. We examine vertices with low invariant multiplicity -before examining vertices with high invariant multiplicity. - -\subsection{Adjacent First} - -The MATCH operation only considers edges when the other vertex already -has a mapping defined. This means that the MATCH operation can only -weed out vertices that are adjacent to vertices that have already been -matched. Therefore, when choosing the next vertex to examine, it is -desirable to choose one that is adjacent a vertex already in $S_1$. - -\subsection{DFS Order, Starting with Lowest Multiplicity} - -For this implementation, we combine the above two heuristics in the -following way. To implement the ``adjacent first'' heuristic we apply -DFS to the graph, and use the DFS discovery order as our vertex -order. To comply with the ``most constrained first'' heuristic we -order the roots of our DFS trees by invariant multiplicity. - - - -\section{Implementation} - -The following is the public interface for the \code{isomorphism} -function. The input to the function is the two graphs $G_1$ and $G_2$, -mappings from the vertices in the graphs to integers (in the range -$[0,|V|)$), and a vertex invariant function object. The output of the -function is an isomorphism $f$ if there is one. The \code{isomorphism} -function returns true if the graphs are isomorphic and false -otherwise. The invariant parameters are function objects that compute -the vertex invariants for vertices of the two graphs. The -\code{max\_invariant} parameter is to specify one past the largest -integer that a vertex invariant number could be (the invariants -numbers are assumed to span from zero to the number). The -requirements on type template parameters are described below in the -``Concept checking'' part. - - -@d Isomorphism function interface -@{ -template -bool isomorphism(const Graph1& G1, const Graph2& G2, IsoMapping f, - Invariant1 invariant1, Invariant2 invariant2, - std::size_t max_invariant, - IndexMap1 index_map1, IndexMap2 index_map2) -@} - - -The function body consists of the concept checks followed by a quick -check for empty graphs or graphs of different size and then construct -an algorithm object. We then call the \code{test\_isomorphism} member -function, which runs the algorithm. The reason that we implement the -algorithm using a class is that there are a fair number of internal -data structures required, and it is easier to make these data members -of a class and make each section of the algorithm a member -function. This relieves us from the burden of passing lots of -arguments to each function, while at the same time avoiding the evils -of global variables (non-reentrant, etc.). - - -@d Isomorphism function body -@{ -{ - @ - @ - detail::isomorphism_algo - algo(G1, G2, f, invariant1, invariant2, max_invariant, - index_map1, index_map2); - return algo.test_isomorphism(); -} -@} - - -\noindent If there are no vertices in either graph, then they are -trivially isomorphic. If the graphs have different numbers of vertices -then they are not isomorphic. - -@d Quick return based on size -@{ -if (num_vertices(G1) != num_vertices(G2)) - return false; -if (num_vertices(G1) == 0 && num_vertices(G2) == 0) - return true; -@} - -We use the Boost Concept Checking Library to make sure that the type -arguments to the function fulfill there requirements. The graph types -must model the \bglconcept{VertexListGraph} and -\bglconcept{AdjacencyGraph} concepts. The vertex invariants must model -the \stlconcept{AdaptableUnaryFunction} concept, with a vertex as -their argument and an integer return type. The \code{IsoMapping} type -that represents the isomorphism $f$ must be a -\pmconcept{ReadWritePropertyMap} that maps from vertices in $G_1$ to -vertices in $G_2$. The two other index maps are -\pmconcept{ReadablePropertyMap}s from vertices in $G_1$ and $G_2$ to -unsigned integers. - - -@d Concept checking -@{ -// Graph requirements -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( EdgeListGraphConcept )); -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( BidirectionalGraphConcept )); - -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::vertices_size_type size_type; - -// Vertex invariant requirement -BOOST_CONCEPT_ASSERT(( AdaptableUnaryFunctionConcept )); -BOOST_CONCEPT_ASSERT(( AdaptableUnaryFunctionConcept )); - -// Property map requirements -BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept )); -typedef typename property_traits::value_type IsoMappingValue; -BOOST_STATIC_ASSERT((is_same::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap1Value; -BOOST_STATIC_ASSERT((is_convertible::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap2Value; -BOOST_STATIC_ASSERT((is_convertible::value)); -@} - -The following is the outline of the isomorphism algorithm class. The -class is templated on all of the same parameters of the -\code{isomorphism} function, and all of the parameter values are -stored in the class as data members, in addition to the internal data -structures. - -@d Isomorphism algorithm class -@{ -template -class isomorphism_algo -{ - @ - @ - @ - @ - friend struct compare_multiplicity; - @ - @ -public: - @ - @ -private: - @ -}; -@} - -The interesting parts of this class are the \code{test\_isomorphism} -function, and the \code{match} function. We focus on those in in the -following sections, and mention the other parts of the class when -needed (and a few are left to the appendix). - -The \code{test\_isomorphism} function does all of the setup required -of the algorithm. This consists of sorting the vertices according to -invariant multiplicity, and then by DFS order. The edges are then -sorted by the DFS order of vertices incident on the edges. More -details about this to come. The last step of this function is to -invoke the recursive \code{match} function which performs the -backtracking search. - - -@d Test isomorphism member function -@{ -bool test_isomorphism() -{ - @ - @ - @ - @ - - return this->match(ordered_edges.begin()); -} -@} - -As discussed in \S\ref{sec:vertex-invariants}, we can quickly rule out -the possibility of any isomorphism between two graphs by checking to -see if the vertex invariants can match up. We sort both vectors of vertex -invariants, and then check to see if they are equal. - -@d Quick return if the vertex invariants do not match up -@{ -{ - std::vector invar1_array; - BGL_FORALL_VERTICES_T(v, G1, Graph1) - invar1_array.push_back(invariant1(v)); - std::sort(invar1_array.begin(), invar1_array.end()); - - std::vector invar2_array; - BGL_FORALL_VERTICES_T(v, G2, Graph2) - invar2_array.push_back(invariant2(v)); - std::sort(invar2_array.begin(), invar2_array.end()); - - if (!std::equal(invar1_array.begin(), invar1_array.end(), invar2_array.begin())) - return false; -} -@} - -Next we compute the invariant multiplicity, the number of vertices -with the same invariant number. The \code{invar\_mult} vector is -indexed by invariant number. We loop through all the vertices in the -graph to record the multiplicity. We then order the vertices by their -invariant multiplicity. This will allow us to search the more -constrained vertices first. - -@d Sort vertices according to invariant multiplicity -@{ -std::vector V_mult; -BGL_FORALL_VERTICES_T(v, G1, Graph1) - V_mult.push_back(v); -{ - std::vector multiplicity(max_invariant, 0); - BGL_FORALL_VERTICES_T(v, G1, Graph1) - ++multiplicity[invariant1(v)]; - - std::sort(V_mult.begin(), V_mult.end(), compare_multiplicity(*this, &multiplicity[0])); -} -@} - -\noindent The definition of the \code{compare\_multiplicity} predicate -is shown below. This predicate provides the glue that binds -\code{std::sort} to our current purpose. - -@d Invariant multiplicity comparison functor -@{ -struct compare_multiplicity -{ - compare_multiplicity(isomorphism_algo& algo, size_type* multiplicity) - : algo(algo), multiplicity(multiplicity) { } - bool operator()(const vertex1_t& x, const vertex1_t& y) const { - return multiplicity[algo.invariant1(x)] < multiplicity[algo.invariant1(y)]; - } - isomorphism_algo& algo; - size_type* multiplicity; -}; -@} - -\subsection{Backtracking Search and Matching} - - - - - - -\subsection{Ordering by DFS Discover Time} - -To implement the ``visit adjacent vertices first'' heuristic, we order -the vertices according to DFS discover time. This will give us the -order that the subgraph $G_1[k]$ will be expanded. As described in -\S\ref{sec:backtracking}, when trying to match $k$ with some vertex -$v$ in $V_2 - S$, we need to examine the edges in $E_1[k] - -E_1[k-1]$. It would be nice if we had the edges of $G_1$ arranged so -that when we are interested in vertex $k$, the edges in $E_1[k] - -E_1[k-1]$ are easy to find. This can be achieved by creating an array -of edges sorted by the DFS number of the larger of the source and -target vertex. The following array of ordered edges corresponds -to the graph in Figure~\ref{fig:edge-order}. - -\begin{tabular}{cccccccccc} - &0&1&2&3&4&5&6&7&8\\ \hline -source&0&1&1&3&3&4&4&5&6\\ -target&1&2&3&1&2&3&5&6&4 -\end{tabular} - -The backtracking algorithm will scan through the edge array from left -to right to extend isomorphic subgraphs, and move back to the right -when a match fails. We will want to - - - - - - - - - - -For example, suppose we have already matched the vertices -\{0,1,2\}, and - - - -\vizfig{edge-order}{Vertices with DFS numbering. The DFS trees are the solid edges.} - -@c edge-order.dot -@{ -digraph G { -size="3,2" -ratio=fill -node[shape=circle] -0 -> 1[style=bold] -1 -> 2[style=bold] -1 -> 3[style=bold] -3 -> 1[style=dashed] -3 -> 2[style=dashed] -4 -> 3[style=dashed] -4 -> 5[style=bold] -5 -> 6[style=bold] -6 -> 4[style=dashed] -} -@} - - - - -We implement the outer-loop of the DFS here, instead of calling the -\code{depth\_first\_search} function, because we want the roots of the -DFS tree's to be ordered by invariant multiplicity. We call -\code{depth\_\-first\_\-visit} to implement the recursive portion of -the DFS. The \code{record\_dfs\_order} adapts the DFS to record the -order in which DFS discovers the vertices, storing the results in in -the \code{dfs\_vertices} and \code{ordered\_edges} arrays. We then -create the \code{dfs\_number} array which provides a mapping from -vertex to DFS number, and renumber the edges with the DFS numbers. - -@d Order vertices and edges by DFS -@{ -std::vector color_vec(num_vertices(G1)); -safe_iterator_property_map::iterator, IndexMap1> - color_map(color_vec.begin(), color_vec.size(), index_map1); -record_dfs_order dfs_visitor(dfs_vertices, ordered_edges); -typedef color_traits Color; -for (vertex_iter u = V_mult.begin(); u != V_mult.end(); ++u) { - if (color_map[*u] == Color::white()) { - dfs_visitor.start_vertex(*u, G1); - depth_first_visit(G1, *u, dfs_visitor, color_map); - } -} -// Create the dfs_number array and dfs_number_map -dfs_number_vec.resize(num_vertices(G1)); -dfs_number = make_safe_iterator_property_map(dfs_number_vec.begin(), - dfs_number_vec.size(), index_map1); -size_type n = 0; -for (vertex_iter v = dfs_vertices.begin(); v != dfs_vertices.end(); ++v) - dfs_number[*v] = n++; - -// Renumber ordered_edges array according to DFS number -for (edge_iter e = ordered_edges.begin(); e != ordered_edges.end(); ++e) { - if (e->source >= 0) - e->source = dfs_number_vec[e->source]; - e->target = dfs_number_vec[e->target]; -} -@} - -\noindent The definition of the \code{record\_dfs\_order} visitor -class is as follows. EXPLAIN ficticious edges - -@d DFS visitor to record vertex and edge order -@{ -struct record_dfs_order : default_dfs_visitor -{ - record_dfs_order(std::vector& v, std::vector& e) - : vertices(v), edges(e) { } - - void start_vertex(vertex1_t v, const Graph1&) const { - edges.push_back(ordered_edge(-1, v)); - } - void discover_vertex(vertex1_t v, const Graph1&) const { - vertices.push_back(v); - } - void examine_edge(edge1_t e, const Graph1& G1) const { - edges.push_back(ordered_edge(source(e, G1), target(e, G1))); - } - std::vector& vertices; - std::vector& edges; -}; -@} - - -Reorder the edges so that all edges belonging to $G_1[k]$ -appear before any edges not in $G_1[k]$, for $k=1,...,n$. - -The order field needs a better name. How about k? - -@d Sort edges according to vertex DFS order -@{ -std::stable_sort(ordered_edges.begin(), ordered_edges.end()); -// Fill in i->k_num field -if (!ordered_edges.empty()) { - ordered_edges[0].k_num = 0; - for (edge_iter i = next(ordered_edges.begin()); i != ordered_edges.end(); ++i) - i->k_num = std::max(prior(i)->source, prior(i)->target); -} -@} - - - - - - -@d Typedefs for commonly used types -@{ -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::edge_descriptor edge1_t; -typedef typename graph_traits::vertices_size_type size_type; -typedef typename Invariant1::result_type invar1_value; -typedef typename Invariant2::result_type invar2_value; -@} - -@d Data members for the parameters -@{ -const Graph1& G1; -const Graph2& G2; -IsoMapping f; -Invariant1 invariant1; -Invariant2 invariant2; -std::size_t max_invariant; -IndexMap1 index_map1; -IndexMap2 index_map2; -@} - -@d Internal data structures -@{ -std::vector dfs_vertices; -typedef std::vector::iterator vertex_iter; -std::vector dfs_number_vec; -safe_iterator_property_map::iterator, IndexMap1> - dfs_number; -std::vector ordered_edges; -typedef std::vector::iterator edge_iter; - -std::vector f_inv_vec; -safe_iterator_property_map::iterator, - IndexMap2> f_inv; - -std::vector f_assigned_vec; -safe_iterator_property_map::iterator, - IndexMap1> f_assigned; - -std::vector f_inv_assigned_vec; -safe_iterator_property_map::iterator, - IndexMap2> f_inv_assigned; - -int num_edges_incident_on_k; -@} - -@d Isomorphism algorithm constructor -@{ -isomorphism_algo(const Graph1& G1, const Graph2& G2, IsoMapping f, - Invariant1 invariant1, Invariant2 invariant2, std::size_t max_invariant, - IndexMap1 index_map1, IndexMap2 index_map2) - : G1(G1), G2(G2), f(f), invariant1(invariant1), invariant2(invariant2), - max_invariant(max_invariant), - index_map1(index_map1), index_map2(index_map2) -{ - f_assigned_vec.resize(num_vertices(G1)); - f_assigned = make_safe_iterator_property_map - (f_assigned_vec.begin(), f_assigned_vec.size(), index_map1); - f_inv_vec.resize(num_vertices(G1)); - f_inv = make_safe_iterator_property_map - (f_inv_vec.begin(), f_inv_vec.size(), index_map2); - - f_inv_assigned_vec.resize(num_vertices(G1)); - f_inv_assigned = make_safe_iterator_property_map - (f_inv_assigned_vec.begin(), f_inv_assigned_vec.size(), index_map2); -} -@} - - - - -@d Degree vertex invariant functor -@{ -template -class degree_vertex_invariant -{ - typedef typename graph_traits::vertex_descriptor vertex_t; - typedef typename graph_traits::degree_size_type size_type; -public: - typedef vertex_t argument_type; - typedef size_type result_type; - - degree_vertex_invariant(const InDegreeMap& in_degree_map, const Graph& g) - : m_in_degree_map(in_degree_map), m_g(g) { } - - size_type operator()(vertex_t v) const { - return (num_vertices(m_g) + 1) * out_degree(v, m_g) - + get(m_in_degree_map, v); - } - // The largest possible vertex invariant number - size_type max() const { - return num_vertices(m_g) * num_vertices(m_g) + num_vertices(m_g); - } -private: - InDegreeMap m_in_degree_map; - const Graph& m_g; -}; -@} - - - -ficticiuos edges for the DFS tree roots -Use \code{ordered\_edge} instead of \code{edge1\_t} so that we can create ficticious -edges for the DFS tree roots. - -@d Ordered edge class -@{ -struct ordered_edge { - ordered_edge(int s, int t) : source(s), target(t) { } - - bool operator<(const ordered_edge& e) const { - using namespace std; - int m1 = max(source, target); - int m2 = max(e.source, e.target); - // lexicographical comparison of (m1,source,target) and (m2,e.source,e.target) - return make_pair(m1, make_pair(source, target)) < make_pair(m2, make_pair(e.source, e.target)); - } - int source; - int target; - int k_num; -}; -@} - - - - - - -\subsection{Recursive Match Function} - - - - - -@d $v$ is a DFS tree root -@{ -// Try all possible mappings -BGL_FORALL_VERTICES_T(y, G2, Graph2) { - if (invariant1(v) == invariant2(y) && f_inv_assigned[y] == false) { - f[v] = y; f_assigned[v] = true; - f_inv[y] = v; f_inv_assigned[y] = true; - num_edges_incident_on_k = 0; - if (match(next(iter))) - return true; - f_assigned[v] = false; - f_inv_assigned[y] = false; - } -} -@} - -Growing the subgraph. - -@d $v$ is an unmatched vertex, $(u,v)$ is a tree edge -@{ -@ -@ -if (num_edges_incident_on_k != 0) - return false; -@ -@} -@d Count out-edges of $f(k)$ in $G_2[S]$ -@{ -BGL_FORALL_ADJACENT_T(f[k], w, G2, Graph2) - if (f_inv_assigned[w] == true) - --num_edges_incident_on_k; -@} - -@d Count in-edges of $f(k)$ in $G_2[S]$ -@{ -for (std::size_t jj = 0; jj < k_num; ++jj) { - vertex1_t j = dfs_vertices[jj]; - BGL_FORALL_ADJACENT_T(f[j], w, G2, Graph2) - if (w == f[k]) - --num_edges_incident_on_k; -} -@} - -@d Assign $v$ to some vertex in $V_2 - S$ -@{ -BGL_FORALL_ADJACENT_T(f[u], y, G2, Graph2) - if (invariant1(v) == invariant2(y) && f_inv_assigned[y] == false) { - f[v] = y; f_assigned[v] = true; - f_inv[y] = v; f_inv_assigned[y] = true; - num_edges_incident_on_k = 1; - if (match(next(iter))) - return true; - f_assigned[v] = false; - f_inv_assigned[y] = false; - } -@} - - - -@d Check to see if there is an edge in $G_2$ to match $(u,v)$ -@{ -bool verify = false; -assert(f_assigned[u] == true); -BGL_FORALL_ADJACENT_T(f[u], y, G2, Graph2) { - if (y == f[v]) { - verify = true; - break; - } -} -if (verify == true) { - ++num_edges_incident_on_k; - if (match(next(iter))) - return true; -} -@} - - - -@o isomorphism-v2.hpp -@{ -// Copyright (C) 2001 Jeremy Siek, Douglas Gregor, Brian Osman -// -// Permission to copy, use, sell and distribute this software is granted -// provided this copyright notice appears in all copies. -// Permission to modify the code and to distribute modified code is granted -// provided this copyright notice appears in all copies, and a notice -// that the code was modified is included with the copyright notice. -// -// This software is provided "as is" without express or implied warranty, -// and with no claim as to its suitability for any purpose. -#ifndef BOOST_GRAPH_ISOMORPHISM_HPP -#define BOOST_GRAPH_ISOMORPHISM_HPP - -#include -#include -#include -#include -#include -#include -#include -#include - -namespace boost { - -namespace detail { - -@ - -template -void compute_in_degree(const Graph& g, InDegreeMap in_degree_map) -{ - BGL_FORALL_VERTICES_T(v, g, Graph) - put(in_degree_map, v, 0); - - BGL_FORALL_VERTICES_T(u, g, Graph) - BGL_FORALL_ADJACENT_T(u, v, g, Graph) - put(in_degree_map, v, get(in_degree_map, v) + 1); -} - -} // namespace detail - - -@ - -@ -@ - -namespace detail { - -template -bool isomorphism_impl(const Graph1& G1, const Graph2& G2, - IsoMapping f, IndexMap1 index_map1, IndexMap2 index_map2, - const bgl_named_params& params) -{ - std::vector in_degree1_vec(num_vertices(G1)); - typedef safe_iterator_property_map::iterator, IndexMap1> InDeg1; - InDeg1 in_degree1(in_degree1_vec.begin(), in_degree1_vec.size(), index_map1); - compute_in_degree(G1, in_degree1); - - std::vector in_degree2_vec(num_vertices(G2)); - typedef safe_iterator_property_map::iterator, IndexMap2> InDeg2; - InDeg2 in_degree2(in_degree2_vec.begin(), in_degree2_vec.size(), index_map2); - compute_in_degree(G2, in_degree2); - - degree_vertex_invariant invariant1(in_degree1, G1); - degree_vertex_invariant invariant2(in_degree2, G2); - - return isomorphism(G1, G2, f, - choose_param(get_param(params, vertex_invariant1_t()), invariant1), - choose_param(get_param(params, vertex_invariant2_t()), invariant2), - choose_param(get_param(params, vertex_max_invariant_t()), invariant2.max()), - index_map1, index_map2 - ); -} - -} // namespace detail - - -// Named parameter interface -template -bool isomorphism(const Graph1& g1, - const Graph2& g2, - const bgl_named_params& params) -{ - typedef typename graph_traits::vertex_descriptor vertex2_t; - typename std::vector::size_type n = num_vertices(g1); - std::vector f(n); - return detail::isomorphism_impl - (g1, g2, - choose_param(get_param(params, vertex_isomorphism_t()), - make_safe_iterator_property_map(f.begin(), f.size(), - choose_const_pmap(get_param(params, vertex_index1), - g1, vertex_index), vertex2_t())), - choose_const_pmap(get_param(params, vertex_index1), g1, vertex_index), - choose_const_pmap(get_param(params, vertex_index2), g2, vertex_index), - params - ); -} - -// All defaults interface -template -bool isomorphism(const Graph1& g1, const Graph2& g2) -{ - return isomorphism(g1, g2, - bgl_named_params(0));// bogus named param -} - - -// Verify that the given mapping iso_map from the vertices of g1 to the -// vertices of g2 describes an isomorphism. -// Note: this could be made much faster by specializing based on the graph -// concepts modeled, but since we're verifying an O(n^(lg n)) algorithm, -// O(n^4) won't hurt us. -template -inline bool verify_isomorphism(const Graph1& g1, const Graph2& g2, IsoMap iso_map) -{ - if (num_vertices(g1) != num_vertices(g2) || num_edges(g1) != num_edges(g2)) - return false; - - for (typename graph_traits::edge_iterator e1 = edges(g1).first; - e1 != edges(g1).second; ++e1) { - bool found_edge = false; - for (typename graph_traits::edge_iterator e2 = edges(g2).first; - e2 != edges(g2).second && !found_edge; ++e2) { - if (source(*e2, g2) == get(iso_map, source(*e1, g1)) && - target(*e2, g2) == get(iso_map, target(*e1, g1))) { - found_edge = true; - } - } - - if (!found_edge) - return false; - } - - return true; -} - -} // namespace boost - -#include - -#endif // BOOST_GRAPH_ISOMORPHISM_HPP -@} - -\bibliographystyle{abbrv} -\bibliography{ggcl} - -\end{document} -% LocalWords: Isomorphism Siek isomorphism adjacency subgraph subgraphs OM DFS -% LocalWords: ISOMORPH Invariants invariants typename IsoMapping bool const -% LocalWords: VertexInvariant VertexIndexMap iterator typedef VertexG Idx num -% LocalWords: InvarValue struct invar vec iter tmp_matches mult inserter permute ui -% LocalWords: dfs cmp isomorph VertexIter edge_iter_t IndexMap desc RPH ATCH pre - -% LocalWords: iterators VertexListGraph EdgeListGraph BidirectionalGraph tmp -% LocalWords: ReadWritePropertyMap VertexListGraphConcept EdgeListGraphConcept -% LocalWords: BidirectionalGraphConcept ReadWritePropertyMapConcept indices ei -% LocalWords: IsoMappingValue ReadablePropertyMapConcept namespace InvarFun -% LocalWords: MultMap vip inline bitset typedefs fj hpp ifndef adaptor params -% LocalWords: bgl param pmap endif diff --git a/doc/isomorphism-impl-v3.w b/doc/isomorphism-impl-v3.w deleted file mode 100644 index 16740adce..000000000 --- a/doc/isomorphism-impl-v3.w +++ /dev/null @@ -1,987 +0,0 @@ -\documentclass[11pt,awpaper]{book} - -\usepackage{math} -\usepackage{jweb} -\usepackage[nolineno]{lgrind} -\usepackage{awpaper} -\usepackage{graphicx} - -\setlength{\evensidemargin}{-0.25in}% was -0.17in -\setlength{\oddsidemargin}{0in}%was -0.25in -\setlength{\textwidth}{5.625in}%was 5.75in -\setlength{\textheight}{7.75in} -\setlength{\topmargin}{-0.125in}%was -0.25 -\addtolength{\topmargin}{-\headheight} -\addtolength{\topmargin}{-\headsep} - -\newif\ifpdf -\ifx\pdfoutput\undefined - \pdffalse -\else - \pdfoutput=1 - \pdftrue -\fi - -\ifpdf - \usepackage[ - pdftex, - colorlinks=true, %change to true for the electronic version - linkcolor=blue,filecolor=blue,pagecolor=blue,urlcolor=blue - ]{hyperref} -\fi - -\ifpdf - \newcommand{\stlconcept}[1]{\href{https://boost.org/sgi/stl/#1.html}{{\small \textsf{#1}}}} - \newcommand{\bglconcept}[1]{\href{http://www.boost.org/libs/graph/doc/#1.html}{{\small \textsf{#1}}}} - \newcommand{\pmconcept}[1]{\href{http://www.boost.org/libs/property_map/#1.html}{{\small \textsf{#1}}}} - \newcommand{\myhyperref}[2]{\hyperref[#1]{#2}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.pdf}}\caption{#2}\label{fig:#1}\end{figure}} -\else - \newcommand{\myhyperref}[2]{#2} - \newcommand{\bglconcept}[1]{{\small \textsf{#1}}} - \newcommand{\pmconcept}[1]{{\small \textsf{#1}}} - \newcommand{\stlconcept}[1]{{\small \textsf{#1}}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.eps}}\caption{#2}\label{fig:#1}\end{figure}} -\fi - -\newcommand{\code}[1]{{\small{\em \textbf{#1}}}} - - -\newcommand{\isomorphic}{\cong} - -\begin{document} - -\title{An Implementation of Graph Isomorphism Testing} -\author{Jeremy G. Siek} - -\maketitle - -% Ideas: use BFS instead of DFS, don't have to sort edges? -% No, you would still have to sort the edges. -% -%Figure~\ref{fig:iso-eg2}. -% 0 0 0 1 1 2 5 6 6 7 -% 1 2 3 4 2 4 6 3 7 5 -%\vizfig{iso-eg2}{Vertices numbered by BFS discover time. The BFS tree -%edges are the solid lines. Nodes $0$ and $5$ are BFS tree root nodes.} -% -% You could do a modified Dijkstra, where the priority in the queue -% would be the BFS discover time of the target vertex. - -% Use w(u,v) = |Adj[u] \intersect Adj[v]| as an edge invariant. -% Has anyone used edge invariants before? - - -\section{Introduction} - -This paper documents the implementation of the \code{isomorphism()} -function of the Boost Graph Library. The implementation was by Jeremy -Siek with algorithmic improvements and test code from Douglas Gregor -and Brian Osman. The \code{isomorphism()} function answers the -question, ``are these two graphs equal?'' By \emph{equal} we mean -the two graphs have the same structure---the vertices and edges are -connected in the same way. The mathematical name for this kind of -equality is \emph{isomorphism}. - -More precisely, an \emph{isomorphism} is a one-to-one mapping of the -vertices in one graph to the vertices of another graph such that -adjacency is preserved. Another words, given graphs $G_{1} = -(V_{1},E_{1})$ and $G_{2} = (V_{2},E_{2})$, an isomorphism is a -function $f$ such that for all pairs of vertices $a,b$ in $V_{1}$, -edge $(a,b)$ is in $E_{1}$ if and only if edge $(f(a),f(b))$ is in -$E_{2}$. - -The graph $G_1$ is \emph{isomorphic} to $G_2$ if an isomorphism exists -between the two graphs, which we denote by $G_1 \isomorphic G_2$. -Both graphs must be the same size, so let $N = |V_1| = |V_2|$. - -In the following discussion we will need to use several more notions -from graph theory. The graph $G_s=(V_s,E_s)$ is a \emph{subgraph} of -graph $G=(V,E)$ if $V_s \subseteq V$ and $E_s \subseteq E$. An -\emph{induced subgraph}, denoted by $G[V_s]$, of a graph $G=(V,E)$ -consists of the vertices in $V_s$, which is a subset of $V$, and every -edge $(u,v)$ in $E$ such that both $u$ and $v$ are in $V_s$. We use -the notation $E[V_s]$ to mean the edges in $G[V_s]$. - -\section{Backtracking Search} -\label{sec:backtracking} - -The algorithm used by the \code{isomorphism()} function is, at first -approximation, an exhaustive search implemented via backtracking. The -backtracking algorithm is a recursive function. At each stage we will -try to extend the match that we have found so far. So suppose that we -have already determined that some subgraph of $G_1$ is isomorphic to a -subgraph of $G_2$. We then try to add a vertex to each subgraph such -that the new subgraphs are still isomorphic to one another. At some -point we may hit a dead end---there are no vertices that can be added -to extend the isomorphic subgraphs. We then backtrack to previous -smaller matching subgraphs, and try extending with a different vertex -choice. The process ends by either finding a complete mapping between -$G_1$ and $G_2$ and returning true, or by exhausting all possibilities -and returning false. - -The problem with the exhaustive backtracking algorithm is that there -are $N!$ possible vertex mappings, and $N!$ gets very large as $N$ -increases, so we need to prune the search space. We use the pruning -techniques described in -\cite{deo77:_new_algo_digraph_isomorph,fortin96:_isomorph,reingold77:_combin_algo}, -some of which originated in -\cite{sussenguth65:_isomorphism,unger64:_isomorphism}. Also, the -specific backtracking method we use is the one from -\cite{deo77:_new_algo_digraph_isomorph}. - -We consider the vertices of $G_1$ for addition to the matched subgraph -in a specific order, so assume that the vertices of $G_1$ are labeled -$1,\ldots,N$ according to that order. As we will see later, a good -ordering of the vertices is by DFS discover time. Let $G_1[k]$ denote -the subgraph of $G_1$ induced by the first $k$ vertices, with $G_1[0]$ -being an empty graph. We also consider the edges of $G_1$ in a -specific order. We always examine edges in the current subgraph -$G_1[k]$ first, that is, edges $(u,v)$ where both $u \leq k$ and $v -\leq k$. This ordering of edges can be acheived by sorting each edge -$(u,v)$ by lexicographical comparison on the tuple $\langle \max(u,v), -u, v \rangle$. Figure~\ref{fig:iso-eg} shows an example of a graph -with the vertices labelled by DFS discover time. The edge ordering for -this graph is as follows: - -\begin{tabular}{lccccccccc} -source: &0&1&0&1&3&0&5&6&6\\ -target: &1&2&3&3&2&4&6&4&7 -\end{tabular} - -\vizfig{iso-eg}{Vertices numbered by DFS discover time. The DFS tree -edges are the solid lines. Nodes $0$ and $5$ are DFS tree root nodes.} - -Each step of the backtracking search moves from left to right though -the ordered edges. At each step it examines an edge $(i,j)$ of $G_1$ -and decides whether to continue to the left or to go back. There are -three cases to consider: - -\begin{enumerate} -\item \label{case:1} $i > k$ -\item \label{case:2} $i \leq k$ and $j > k$. -\item \label{case:3} $i \leq k$ and $j \leq k$. -\end{enumerate} - -\paragraph{Case 1: $i > k$.} -$i$ is not in the matched subgraph $G_1[k]$. This situation only -happens at the very beginning of the search, or when $i$ is not -reachable from any of the vertices in $G_1[k]$. This means that we -are finished with $G_1[k]$. We increment $k$ and find a match for it -amongst any of the eligible vertices in $V_2 - S$. We then proceed to -Case 2. It is usually the case that $i$ is equal to the new $k$, but -when there is another DFS root $r$ with no in-edges or out-edges -and if $r < i$ then it will be the new $k$. - -\paragraph{Case 2: $i \leq k$ and $j > k$.} -$i$ is in the matched subgraph $G_1[k]$, but $j$ is not. We are about -to increment $k$ to try and grow the matched subgraph to include -$j$. However, first we need to finish verifying that $G_1[k] -\isomorphic G_2[S]$. In previous steps we proved that $G_1[k-1] -\isomorphic G_2[S-\{f(k)\}]$, so now we just need to verify the -extension of the isomorphism to $k$. At this point we are guaranteed -to have seen all the edges to and from vertex $k$ (because the edges -are sorted), and in previous steps we have checked that for each edge -incident on $k$ in $E_1[k]$ there is a matching edge in -$E_2[S]$. However we still need to check the ``only if'' part of the -``if and only if''. So we check that for every edge $(u,v)$ incident -on $f(k)$ there is $(f^{-1}(u),f^{-1}(v)) \in E_1[k]$. A quick way to -verify this is to make sure that the number of edges incident on $k$ -in $E_1[k]$ is the same as the number of edges incident on $f(k)$ in -$E_2[S]$. We create an edge counter that we increment every time we -see an edge incident on $k$ and decrement for each edge incident on -$f(k)$. If the counter gets back to zero we know the edges match up. - -Once we have verified that $G_1[k] \isomorphic G_2[S]$ we add $f(k)$ -to $S$, increment $k$, and then try assigning $j$ to -any of the eligible vertices in $V_2 - S$. More about what -``eligible'' means below. - -\paragraph{Case 3: $i \leq k$ and $j \leq k$.} -Both $i$ and $j$ are in $G_1[k]$. We check to make sure that -$(f(i),f(j)) \in E_2[S]$ and then proceed to the next edge. - - -\subsection{Vertex Invariants} -\label{sec:vertex-invariants} - -One way to reduce the search space is through the use of \emph{vertex -invariants}. The idea is to compute a number for each vertex $i(v)$ -such that $i(v) = i(v')$ if there exists some isomorphism $f$ where -$f(v) = v'$. Then when we look for a match to some vertex $v$, only -those vertices that have the same vertex invariant number are -``eligible''. The number of vertices in a graph with the same vertex -invariant number $i$ is called the \emph{invariant multiplicity} for -$i$. In this implementation, by default we use the function $i(v) = -(|V|+1) \times \outdegree(v) + \indegree(v)$, though the user can also -supply there own invariant function. The ability of the invariant -function to prune the search space varies widely with the type of -graph. - -The following is the definition of the functor that implements the -default vertex invariant. The functor models the -\stlconcept{AdaptableUnaryFunction} concept. - -@d Degree vertex invariant functor -@{ -template -class degree_vertex_invariant -{ - typedef typename graph_traits::vertex_descriptor vertex_t; - typedef typename graph_traits::degree_size_type size_type; -public: - typedef vertex_t argument_type; - typedef size_type result_type; - - degree_vertex_invariant(const InDegreeMap& in_degree_map, const Graph& g) - : m_in_degree_map(in_degree_map), m_g(g) { } - - size_type operator()(vertex_t v) const { - return (num_vertices(m_g) + 1) * out_degree(v, m_g) - + get(m_in_degree_map, v); - } - // The largest possible vertex invariant number - size_type max() const { - return num_vertices(m_g) * num_vertices(m_g) + num_vertices(m_g); - } -private: - InDegreeMap m_in_degree_map; - const Graph& m_g; -}; -@} - - -\subsection{Vertex Order} - -A good choice of the labeling for the vertices (which determines the -order in which the subgraph $G_1[k]$ is grown) can also reduce the -search space. In the following we discuss two labeling heuristics. - -\subsubsection{Most Constrained First} - -Consider the most constrained vertices first. That is, examine -lower-degree vertices before higher-degree vertices. This reduces the -search space because it chops off a trunk before the trunk has a -chance to blossom out. We can generalize this to use vertex -invariants. We examine vertices with low invariant multiplicity -before examining vertices with high invariant multiplicity. - -\subsubsection{Adjacent First} - -It only makes sense to examine an edge if one or more of its vertices -has been assigned a mapping. This means that we should visit vertices -adjacent to those in the current matched subgraph before proceeding. - -\subsubsection{DFS Order, Starting with Lowest Multiplicity} - -For this implementation, we combine the above two heuristics in the -following way. To implement the ``adjacent first'' heuristic we apply -DFS to the graph, and use the DFS discovery order as our vertex -order. To comply with the ``most constrained first'' heuristic we -order the roots of our DFS trees by invariant multiplicity. - - -\subsection{Implementation of the \code{match} function} - - -The \code{match} function implements the recursive backtracking, -handling the four cases described in \S\ref{sec:backtracking}. - -@d Match function -@{ -bool match(edge_iter iter, int dfs_num_k) -{ - if (iter != ordered_edges.end()) { - vertex1_t i = source(*iter, G1), j = target(*iter, G2); - if (dfs_num[i] > dfs_num_k) { - @ - } - else if (dfs_num[j] > dfs_num_k) { - @ - } - else { - @ - } - } else - return true; - return false; -} -@} - -\noindent Now to describe how each of the four cases is implemented. - -\paragraph{Case 1: $i \not\in G_1[k]$.} -We increment $k$ and try to map it to any of the eligible vertices of -$V_2 - S$. After matching the new $k$ we proceed by invoking -\code{match}. We do not yet move on to the next edge, since we have -not yet found a match for edge, or for target $j$. We reset the edge -counter to zero. - -@d Find a match for the DFS tree root $k+1$ -@{ -vertex1_t kp1 = dfs_vertices[dfs_num_k + 1]; -BGL_FORALL_VERTICES_T(u, G2, Graph2) { - if (invariant1(kp1) == invariant2(u) && in_S[u] == false) { - f[kp1] = u; - in_S[u] = true; - num_edges_on_k = 0; - if (match(iter, dfs_num_k + 1)); - return true; - in_S[u] = false; - } -} -@} - - -\paragraph{Case 2: $i \in G_1[k]$ and $j \not\in G_1[k]$.} -Before we extend the subgraph by incrementing $k$, we need to finish -verifying that $G_1[k]$ and $G_2[S]$ are isomorphic. We decrement the -edge counter for every edge incident to $f(k)$ in $G_2[S]$, which -should bring the counter back down to zero. If not we return false. - -@d Verify $G_1[k] \isomorphic G_2[S]$ and then find match for $j$ -@{ -vertex1_t k = dfs_vertices[dfs_num_k]; -@ -@ -if (num_edges_on_k != 0) - return false; -@ -@} - -\noindent We decrement the edge counter for every vertex in -$Adj[f(k)]$ that is also in $S$. We call \code{count\_if} to do the -counting, using \code{boost::bind} to create the predicate functor. - -@d Count out-edges of $f(k)$ in $G_2[S]$ -@{ -num_edges_on_k -= - count_if(adjacent_vertices(f[k], G2), make_indirect_pmap(in_S)); -@} - -\noindent Next we iterate through all the vertices in $S$ and for each -we decrement the counter for each edge whose target is $k$. - -% We could specialize this for the case when G_2 is bidirectional. - -@d Count in-edges of $f(k)$ in $G_2[S]$ -@{ -for (int jj = 0; jj < dfs_num_k; ++jj) { - vertex1_t j = dfs_vertices[jj]; - num_edges_on_k -= count(adjacent_vertices(f[j], G2), f[k]); -} -@} - -Now that we have finished verifying that $G_1[k] \isomorphic G_2[S]$, -we can now consider extending the isomorphism. We need to find a match -for $j$ in $V_2 - S$. Since $j$ is adjacent to $i$, we can further -narrow down the search by only considering vertices adjacent to -$f(i)$. Also, the vertex must have the same vertex invariant. Once we -have a matching vertex $v$ we extend the matching subgraphs by -incrementing $k$ and adding $v$ to $S$, we set $f(j) = v$, and we set -the edge counter to $1$ (since $(i,j)$ is the first edge incident on -our new $k$). We continue to the next edge by calling \code{match}. If -that fails we undo the assignment $f(j) = v$. - -@d Find a match for $j$ and continue -@{ -BGL_FORALL_ADJ_T(f[i], v, G2, Graph2) - if (invariant2(v) == invariant1(j) && in_S[v] == false) { - f[j] = v; - in_S[v] = true; - num_edges_on_k = 1; - int next_k = std::max(dfs_num_k, std::max(dfs_num[i], dfs_num[j])); - if (match(next(iter), next_k)) - return true; - in_S[v] = false; - } -@} - -\paragraph{Case 3: both $i$ and $j$ are in $G_1[k]$.} -Our goal is to check whether $(f(i),f(j)) \in E_2[S]$. If $f(j)$ is -in $Adj[f(i)]$ then we have a match for the edge $(i,j)$, and can -increment the counter for the number of edges incident on $k$ in -$E_1[k]$. We continue by calling \code{match} on the next edge. - -@d Check to see if $(f(i),f(j)) \in E_2[S]$ and continue -@{ -edge2_t e2; -bool fi_fj_exists = false; -typename graph_traits::out_edge_iterator io, io_end; -for (tie(io, io_end) = out_edges(f[i], G2); io != io_end; ++io) - if (target(*io, G2) == f[j]) { - fi_fj_exists = true; - e2 = *io; - } - -if (fi_fj_exists && edge_compare(e2, *iter)) { - ++num_edges_on_k; - if (match(next(iter), dfs_num_k)) - return true; -} -@} - -\section{Public Interface} - -The following is the public interface for the \code{isomorphism} -function. The input to the function is the two graphs $G_1$ and $G_2$, -mappings from the vertices in the graphs to integers (in the range -$[0,|V|)$), and a vertex invariant function object. The output of the -function is an isomorphism $f$ if there is one. The \code{isomorphism} -function returns true if the graphs are isomorphic and false -otherwise. The invariant parameters are function objects that compute -the vertex invariants for vertices of the two graphs. The -\code{max\_invariant} parameter is to specify one past the largest -integer that a vertex invariant number could be (the invariants -numbers are assumed to span from zero to \code{max\_invariant-1}). -The requirements on the template parameters are described below in the -``Concept checking'' code part. - - -@d Isomorphism function interface -@{ -template -bool isomorphism(const Graph1& G1, const Graph2& G2, IsoMapping f, - Invariant1 invariant1, Invariant2 invariant2, - std::size_t max_invariant, EdgeCompare edge_compare, - IndexMap1 index_map1, IndexMap2 index_map2) -@} - - -The function body consists of the concept checks followed by a quick -check for empty graphs or graphs of different size and then constructs -an algorithm object. We then call the \code{test\_isomorphism} member -function, which runs the algorithm. The reason that we implement the -algorithm using a class is that there are a fair number of internal -data structures required, and it is easier to make these data members -of a class and make each section of the algorithm a member -function. This relieves us from the burden of passing lots of -arguments to each function, while at the same time avoiding the evils -of global variables (non-reentrant, etc.). - - -@d Isomorphism function body -@{ -{ - @ - @ - detail::isomorphism_algo - algo(G1, G2, f, invariant1, invariant2, max_invariant, - edge_compare, - index_map1, index_map2); - return algo.test_isomorphism(); -} -@} - - -\noindent If there are no vertices in either graph, then they are -trivially isomorphic. If the graphs have different numbers of vertices -then they are not isomorphic. We could also check the number of edges -here, but that would introduce the \bglconcept{EdgeListGraph} -requirement, which we otherwise do not need. - -@d Quick return based on size -@{ -if (num_vertices(G1) != num_vertices(G2)) - return false; -if (num_vertices(G1) == 0 && num_vertices(G2) == 0) - return true; -@} - -We use the Boost Concept Checking Library to make sure that the -template arguments fulfill certain requirements. The graph types must -model the \bglconcept{VertexListGraph} and \bglconcept{AdjacencyGraph} -concepts. The vertex invariants must model the -\stlconcept{AdaptableUnaryFunction} concept, with a vertex as their -argument and an integer return type. The \code{IsoMapping} type -representing the isomorphism $f$ must be a -\pmconcept{ReadWritePropertyMap} that maps from vertices in $G_1$ to -vertices in $G_2$. The two other index maps are -\pmconcept{ReadablePropertyMap}s from vertices in $G_1$ and $G_2$ to -unsigned integers. - - -@d Concept checking -@{ -// Graph requirements -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( EdgeListGraphConcept )); -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( BidirectionalGraphConcept )); - -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::vertices_size_type size_type; - -// Vertex invariant requirement -BOOST_CONCEPT_ASSERT(( AdaptableUnaryFunctionConcept )); -BOOST_CONCEPT_ASSERT(( AdaptableUnaryFunctionConcept )); - -// Property map requirements -BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept )); -typedef typename property_traits::value_type IsoMappingValue; -BOOST_STATIC_ASSERT((is_same::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap1Value; -BOOST_STATIC_ASSERT((is_convertible::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap2Value; -BOOST_STATIC_ASSERT((is_convertible::value)); -@} - - -\section{Data Structure Setup} - -The following is the outline of the isomorphism algorithm class. The -class is templated on all of the same parameters as the -\code{isomorphism} function, and all of the parameter values are -stored in the class as data members, in addition to the internal data -structures. - -@d Isomorphism algorithm class -@{ -template -class isomorphism_algo -{ - @ - @ - @ - friend struct compare_multiplicity; - @ - @ - @ -public: - @ - @ -private: - @ -}; -@} - -The interesting parts of this class are the \code{test\_isomorphism} -function and the \code{match} function. We focus on those in the -following sections, and leave the other parts of the class to the -Appendix. - -The \code{test\_isomorphism} function does all of the setup required -of the algorithm. This consists of sorting the vertices according to -invariant multiplicity, and then by DFS order. The edges are then -sorted as previously described. The last step of this function is to -begin the backtracking search. - -@d Test isomorphism member function -@{ -bool test_isomorphism() -{ - @ - @ - @ - @ - - int dfs_num_k = -1; - return this->match(ordered_edges.begin(), dfs_num_k); -} -@} - -As a first check to rule out graphs that have no possibility of -matching, one can create a list of computed vertex invariant numbers -for the vertices in each graph, sort the two lists, and then compare -them. If the two lists are different then the two graphs are not -isomorphic. If the two lists are the same then the two graphs may be -isomorphic. - -@d Quick return if the vertex invariants do not match up -@{ -{ - std::vector invar1_array; - BGL_FORALL_VERTICES_T(v, G1, Graph1) - invar1_array.push_back(invariant1(v)); - sort(invar1_array); - - std::vector invar2_array; - BGL_FORALL_VERTICES_T(v, G2, Graph2) - invar2_array.push_back(invariant2(v)); - sort(invar2_array); - if (! equal(invar1_array, invar2_array)) - return false; -} -@} - -Next we compute the invariant multiplicity, the number of vertices -with the same invariant number. The \code{invar\_mult} vector is -indexed by invariant number. We loop through all the vertices in the -graph to record the multiplicity. We then order the vertices by their -invariant multiplicity. This will allow us to search the more -constrained vertices first. - -@d Sort vertices according to invariant multiplicity -@{ -std::vector V_mult; -BGL_FORALL_VERTICES_T(v, G1, Graph1) - V_mult.push_back(v); -{ - std::vector multiplicity(max_invariant, 0); - BGL_FORALL_VERTICES_T(v, G1, Graph1) - ++multiplicity[invariant1(v)]; - sort(V_mult, compare_multiplicity(invariant1, &multiplicity[0])); -} -@} - -\noindent The definition of the \code{compare\_multiplicity} predicate -is shown below. This predicate provides the glue that binds -\code{std::sort} to our current purpose. - -@d Invariant multiplicity comparison functor -@{ -struct compare_multiplicity -{ - compare_multiplicity(Invariant1 invariant1, size_type* multiplicity) - : invariant1(invariant1), multiplicity(multiplicity) { } - bool operator()(const vertex1_t& x, const vertex1_t& y) const { - return multiplicity[invariant1(x)] < multiplicity[invariant1(y)]; - } - Invariant1 invariant1; - size_type* multiplicity; -}; -@} - -\subsection{Ordering by DFS Discover Time} - -Next we order the vertices and edges by DFS discover time. We would -normally call the BGL \code{depth\_first\_search} function to do this, -but we want the roots of the DFS tree's to be ordered by invariant -multiplicity. Therefore we implement the outer-loop of the DFS here -and then call \code{depth\_\-first\_\-visit} to handle the recursive -portion of the DFS. The \code{record\_dfs\_order} adapts the DFS to -record the ordering, storing the results in in the -\code{dfs\_vertices} and \code{ordered\_edges} arrays. We then create -the \code{dfs\_num} array which provides a mapping from vertex to DFS -number. - -@d Order vertices and edges by DFS -@{ -std::vector color_vec(num_vertices(G1)); -safe_iterator_property_map::iterator, IndexMap1> - color_map(color_vec.begin(), color_vec.size(), index_map1); -record_dfs_order dfs_visitor(dfs_vertices, ordered_edges); -typedef color_traits Color; -for (vertex_iter u = V_mult.begin(); u != V_mult.end(); ++u) { - if (color_map[*u] == Color::white()) { - dfs_visitor.start_vertex(*u, G1); - depth_first_visit(G1, *u, dfs_visitor, color_map); - } -} -// Create the dfs_num array and dfs_num_map -dfs_num_vec.resize(num_vertices(G1)); -dfs_num = make_safe_iterator_property_map(dfs_num_vec.begin(), - dfs_num_vec.size(), index_map1); -size_type n = 0; -for (vertex_iter v = dfs_vertices.begin(); v != dfs_vertices.end(); ++v) - dfs_num[*v] = n++; -@} - -\noindent The definition of the \code{record\_dfs\_order} visitor -class is as follows. - -@d DFS visitor to record vertex and edge order -@{ -struct record_dfs_order : default_dfs_visitor -{ - record_dfs_order(std::vector& v, std::vector& e) - : vertices(v), edges(e) { } - - void discover_vertex(vertex1_t v, const Graph1&) const { - vertices.push_back(v); - } - void examine_edge(edge1_t e, const Graph1& G1) const { - edges.push_back(e); - } - std::vector& vertices; - std::vector& edges; -}; -@} - -The final stage of the setup is to reorder the edges so that all edges -belonging to $G_1[k]$ appear before any edges not in $G_1[k]$, for -$k=1,...,n$. - -@d Sort edges according to vertex DFS order -@{ -sort(ordered_edges, edge_cmp(G1, dfs_num)); -@} - -\noindent The edge comparison function object is defined as follows. - -@d Edge comparison predicate -@{ -struct edge_cmp { - edge_cmp(const Graph1& G1, DFSNumMap dfs_num) - : G1(G1), dfs_num(dfs_num) { } - bool operator()(const edge1_t& e1, const edge1_t& e2) const { - using namespace std; - vertex1_t u1 = dfs_num[source(e1,G1)], v1 = dfs_num[target(e1,G1)]; - vertex1_t u2 = dfs_num[source(e2,G1)], v2 = dfs_num[target(e2,G1)]; - int m1 = max(u1, v1); - int m2 = max(u2, v2); - // lexicographical comparison - return make_pair(m1, make_pair(u1, v1)) - < make_pair(m2, make_pair(u2, v2)); - } - const Graph1& G1; - DFSNumMap dfs_num; -}; -@} - - -\section{Appendix} - - -@d Typedefs for commonly used types -@{ -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::edge_descriptor edge1_t; -typedef typename graph_traits::edge_descriptor edge2_t; -typedef typename graph_traits::vertices_size_type size_type; -typedef typename Invariant1::result_type invar1_value; -typedef typename Invariant2::result_type invar2_value; -@} - -@d Data members for the parameters -@{ -const Graph1& G1; -const Graph2& G2; -IsoMapping f; -Invariant1 invariant1; -Invariant2 invariant2; -std::size_t max_invariant; -EdgeCompare edge_compare; -IndexMap1 index_map1; -IndexMap2 index_map2; -@} - -@d Internal data structures -@{ -std::vector dfs_vertices; -typedef typename std::vector::iterator vertex_iter; -std::vector dfs_num_vec; -typedef safe_iterator_property_map::iterator, - IndexMap1> DFSNumMap; -DFSNumMap dfs_num; -std::vector ordered_edges; -typedef typename std::vector::iterator edge_iter; - -std::vector in_S_vec; -typedef safe_iterator_property_map::iterator, - IndexMap2> InSMap; -InSMap in_S; - -int num_edges_on_k; -@} - -@d Isomorphism algorithm constructor -@{ -isomorphism_algo(const Graph1& G1, const Graph2& G2, IsoMapping f, - Invariant1 invariant1, Invariant2 invariant2, - std::size_t max_invariant, - EdgeCompare edge_compare, - IndexMap1 index_map1, IndexMap2 index_map2) - : G1(G1), G2(G2), f(f), invariant1(invariant1), invariant2(invariant2), - max_invariant(max_invariant), edge_compare(edge_compare), - index_map1(index_map1), index_map2(index_map2) -{ - in_S_vec.resize(num_vertices(G1)); - in_S = make_safe_iterator_property_map - (in_S_vec.begin(), in_S_vec.size(), index_map2); -} -@} - - -@o isomorphism.hpp -@{ -// Copyright (C) 2001 Jeremy Siek, Douglas Gregor, Brian Osman -// -// Permission to copy, use, sell and distribute this software is granted -// provided this copyright notice appears in all copies. -// Permission to modify the code and to distribute modified code is granted -// provided this copyright notice appears in all copies, and a notice -// that the code was modified is included with the copyright notice. -// -// This software is provided "as is" without express or implied warranty, -// and with no claim as to its suitability for any purpose. -#ifndef BOOST_GRAPH_ISOMORPHISM_HPP -#define BOOST_GRAPH_ISOMORPHISM_HPP - -#include -#include -#include -#include -#include -#include -#include -#include -#include // for make_indirect_pmap - -namespace boost { - -namespace detail { - -@ - -template -void compute_in_degree(const Graph& g, InDegreeMap in_degree_map) -{ - BGL_FORALL_VERTICES_T(v, g, Graph) - put(in_degree_map, v, 0); - - BGL_FORALL_VERTICES_T(u, g, Graph) - BGL_FORALL_ADJ_T(u, v, g, Graph) - put(in_degree_map, v, get(in_degree_map, v) + 1); -} - -} // namespace detail - - -@ - -@ -@ - -namespace detail { - -struct default_edge_compare { - template - bool operator()(Edge1 e1, Edge2 e2) const { return true; } -}; - -template -bool isomorphism_impl(const Graph1& G1, const Graph2& G2, - IsoMapping f, IndexMap1 index_map1, IndexMap2 index_map2, - const bgl_named_params& params) -{ - std::vector in_degree1_vec(num_vertices(G1)); - typedef safe_iterator_property_map::iterator, - IndexMap1> InDeg1; - InDeg1 in_degree1(in_degree1_vec.begin(), in_degree1_vec.size(), index_map1); - compute_in_degree(G1, in_degree1); - - std::vector in_degree2_vec(num_vertices(G2)); - typedef safe_iterator_property_map::iterator, - IndexMap2> InDeg2; - InDeg2 in_degree2(in_degree2_vec.begin(), in_degree2_vec.size(), index_map2); - compute_in_degree(G2, in_degree2); - - degree_vertex_invariant invariant1(in_degree1, G1); - degree_vertex_invariant invariant2(in_degree2, G2); - default_edge_compare edge_cmp; - - return isomorphism(G1, G2, f, - choose_param(get_param(params, vertex_invariant1_t()), invariant1), - choose_param(get_param(params, vertex_invariant2_t()), invariant2), - choose_param(get_param(params, vertex_max_invariant_t()), - invariant2.max()), - choose_param(get_param(params, edge_compare_t()), edge_cmp), - index_map1, index_map2 - ); -} - -} // namespace detail - - -// Named parameter interface -template -bool isomorphism(const Graph1& g1, - const Graph2& g2, - const bgl_named_params& params) -{ - typedef typename graph_traits::vertex_descriptor vertex2_t; - typename std::vector::size_type n = num_vertices(g1); - std::vector f(n); - return detail::isomorphism_impl - (g1, g2, - choose_param(get_param(params, vertex_isomorphism_t()), - make_safe_iterator_property_map(f.begin(), f.size(), - choose_const_pmap(get_param(params, vertex_index1), - g1, vertex_index), vertex2_t())), - choose_const_pmap(get_param(params, vertex_index1), g1, vertex_index), - choose_const_pmap(get_param(params, vertex_index2), g2, vertex_index), - params - ); -} - -// All defaults interface -template -bool isomorphism(const Graph1& g1, const Graph2& g2) -{ - return isomorphism(g1, g2, - bgl_named_params(0));// bogus named param -} - - -// Verify that the given mapping iso_map from the vertices of g1 to the -// vertices of g2 describes an isomorphism. -// Note: this could be made much faster by specializing based on the graph -// concepts modeled, but since we're verifying an O(n^(lg n)) algorithm, -// O(n^4) won't hurt us. -template -inline bool verify_isomorphism(const Graph1& g1, const Graph2& g2, IsoMap iso_map) -{ -#if 0 - // problematic for filtered_graph! - if (num_vertices(g1) != num_vertices(g2) || num_edges(g1) != num_edges(g2)) - return false; -#endif - - for (typename graph_traits::edge_iterator e1 = edges(g1).first; - e1 != edges(g1).second; ++e1) { - bool found_edge = false; - for (typename graph_traits::edge_iterator e2 = edges(g2).first; - e2 != edges(g2).second && !found_edge; ++e2) { - if (source(*e2, g2) == get(iso_map, source(*e1, g1)) && - target(*e2, g2) == get(iso_map, target(*e1, g1))) { - found_edge = true; - } - } - - if (!found_edge) - return false; - } - - return true; -} - -} // namespace boost - -#include - -#endif // BOOST_GRAPH_ISOMORPHISM_HPP -@} - -\bibliographystyle{abbrv} -\bibliography{ggcl} - -\end{document} -% LocalWords: Isomorphism Siek isomorphism adjacency subgraph subgraphs OM DFS -% LocalWords: ISOMORPH Invariants invariants typename IsoMapping bool const -% LocalWords: VertexInvariant VertexIndexMap iterator typedef VertexG Idx num -% LocalWords: InvarValue struct invar vec iter tmp_matches mult inserter permute ui -% LocalWords: dfs cmp isomorph VertexIter edge_iter_t IndexMap desc RPH ATCH pre - -% LocalWords: iterators VertexListGraph EdgeListGraph BidirectionalGraph tmp -% LocalWords: ReadWritePropertyMap VertexListGraphConcept EdgeListGraphConcept -% LocalWords: BidirectionalGraphConcept ReadWritePropertyMapConcept indices ei -% LocalWords: IsoMappingValue ReadablePropertyMapConcept namespace InvarFun -% LocalWords: MultMap vip inline bitset typedefs fj hpp ifndef adaptor params -% LocalWords: bgl param pmap endif diff --git a/doc/isomorphism-impl.pdf b/doc/isomorphism-impl.pdf deleted file mode 100644 index c182ec511..000000000 Binary files a/doc/isomorphism-impl.pdf and /dev/null differ diff --git a/doc/isomorphism-impl.w b/doc/isomorphism-impl.w deleted file mode 100644 index 48c086a3e..000000000 --- a/doc/isomorphism-impl.w +++ /dev/null @@ -1,1206 +0,0 @@ -\documentclass[11pt]{report} - -%\input{defs} -\usepackage{math} -\usepackage{jweb} -\usepackage{lgrind} -\usepackage{times} -\usepackage{fullpage} -\usepackage{graphicx} - -\newif\ifpdf -\ifx\pdfoutput\undefined - \pdffalse -\else - \pdfoutput=1 - \pdftrue -\fi - -\ifpdf - \usepackage[ - pdftex, - colorlinks=true, %change to true for the electronic version - linkcolor=blue,filecolor=blue,pagecolor=blue,urlcolor=blue - ]{hyperref} -\fi - -\ifpdf - \newcommand{\stlconcept}[1]{\href{https://boost.org/sgi/stl/#1.html}{{\small \textsf{#1}}}} - \newcommand{\bglconcept}[1]{\href{http://www.boost.org/libs/graph/doc/#1.html}{{\small \textsf{#1}}}} - \newcommand{\pmconcept}[1]{\href{http://www.boost.org/libs/property_map/#1.html}{{\small \textsf{#1}}}} - \newcommand{\myhyperref}[2]{\hyperref[#1]{#2}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.pdf}}\caption{#2}\label{fig:#1}\end{figure}} -\else - \newcommand{\myhyperref}[2]{#2} - \newcommand{\bglconcept}[1]{{\small \textsf{#1}}} - \newcommand{\pmconcept}[1]{{\small \textsf{#1}}} - \newcommand{\stlconcept}[1]{{\small \textsf{#1}}} - \newcommand{\vizfig}[2]{\begin{figure}[htbp]\centerline{\includegraphics*{#1.eps}}\caption{#2}\label{fig:#1}\end{figure}} -\fi - -\newcommand{\code}[1]{{\small{\em \textbf{#1}}}} - - -% jweb -np isomorphism-impl.w; dot -Tps out.dot -o out.eps; dot -Tps in.dot -o in.eps; latex isomorphism-impl.tex; dvips isomorphism-impl.dvi -o isomorphism-impl.ps - -\setlength\overfullrule{5pt} -\tolerance=10000 -\sloppy -\hfuzz=10pt - -\makeindex - -\newcommand{\isomorphic}{\cong} - -\begin{document} - -\title{An Implementation of Isomorphism Testing} -\author{Jeremy G. Siek} - -\maketitle - -\section{Introduction} - -This paper documents the implementation of the \code{isomorphism()} -function of the Boost Graph Library. The implementation was by Jeremy -Siek with algorithmic improvements and test code from Douglas Gregor. -The \code{isomorphism()} function answers the question, ``are these -two graphs equal?'' By \emph{equal}, we mean the two graphs have the -same structure---the vertices and edges are connected in the same -way. The mathematical name for this kind of equality is -\emph{isomorphic}. - -An \emph{isomorphism} is a one-to-one mapping of the vertices in one -graph to the vertices of another graph such that adjacency is -preserved. Another words, given graphs $G_{1} = (V_{1},E_{1})$ and -$G_{2} = (V_{2},E_{2})$, an isomorphism is a function $f$ such that -for all pairs of vertices $a,b$ in $V_{1}$, edge $(a,b)$ is in $E_{1}$ -if and only if edge $(f(a),f(b))$ is in $E_{2}$. - -Both graphs must be the same size, so let $N = |V_1| = |V_2|$. The -graph $G_1$ is \emph{isomorphic} to $G_2$ if an isomorphism exists -between the two graphs, which we denote by $G_1 \isomorphic G_2$. - -In the following discussion we will need to use several notions from -graph theory. The graph $G_s=(V_s,E_s)$ is a \emph{subgraph} of graph -$G=(V,E)$ if $V_s \subseteq V$ and $E_s \subseteq E$. An -\emph{induced subgraph}, denoted by $G[V_s]$, of a graph $G=(V,E)$ -consists of the vertices in $V_s$, which is a subset of $V$, and every -edge $(u,v)$ in $E$ such that both $u$ and $v$ are in $V_s$. We use -the notation $E[V_s]$ to mean the edges in $G[V_s]$. - -In some places we express a function as a set of pairs, so the set $f -= \{ \pair{a_1}{b_1}, \ldots, \pair{a_n}{b_n} \}$ -means $f(a_i) = b_i$ for $i=1,\ldots,n$. - -\section{Exhaustive Backtracking Search} - -The algorithm used by the \code{isomorphism()} function is, at -first approximation, an exhaustive search implemented via -backtracking. The backtracking algorithm is a recursive function. At -each stage we will try to extend the match that we have found so far. -So suppose that we have already determined that some subgraph of $G_1$ -is isomorphic to a subgraph of $G_2$. We then try to add a vertex to -each subgraph such that the new subgraphs are still isomorphic to one -another. At some point we may hit a dead end---there are no vertices -that can be added to extend the isomorphic subgraphs. We then -backtrack to previous smaller matching subgraphs, and try extending -with a different vertex choice. The process ends by either finding a -complete mapping between $G_1$ and $G_2$ and return true, or by -exhausting all possibilities and returning false. - -We are going to consider the vertices of $G_1$ in a specific order -(more about this later), so assume that the vertices of $G_1$ are -labeled $1,\ldots,N$ according to the order that we plan to add them -to the subgraph. Let $G_1[k]$ denote the subgraph of $G_1$ induced by -the first $k$ vertices, with $G_1[0]$ being an empty graph. At each -stage of the recursion we start with an isomorphism $f_{k-1}$ between -$G_1[k-1]$ and a subgraph of $G_2$, which we denote by $G_2[S]$, so -$G_1[k-1] \isomorphic G_2[S]$. The vertex set $S$ is the subset of -$V_2$ that corresponds via $f_{k-1}$ to the first $k-1$ vertices in -$G_1$. We try to extend the isomorphism by finding a vertex $v \in V_2 -- S$ that matches with vertex $k$. If a matching vertex is found, we -have a new isomorphism $f_k$ with $G_1[k] \isomorphic G_2[S \union \{ -v \}]$. - -\begin{tabbing} -IS\=O\=M\=O\=RPH($k$, $S$, $f_{k-1}$) $\equiv$ \\ -\>\textbf{if} ($k = |V_1|+1$) \\ -\>\>\textbf{return} true \\ -\>\textbf{for} each vertex $v \in V_2 - S$ \\ -\>\>\textbf{if} (MATCH($k$, $v$)) \\ -\>\>\>$f_k = f_{k-1} \union \pair{k}{v}$ \\ -\>\>\>ISOMORPH($k+1$, $S \union \{ v \}$, $f_k$)\\ -\>\>\textbf{else}\\ -\>\>\>\textbf{return} false \\ -\\ -ISOMORPH($0$, $G_1$, $\emptyset$, $G_2$) -\end{tabbing} - -The basic idea of the match operation is to check whether $G_1[k]$ is -isomorphic to $G_2[S \union \{ v \}]$. We already know that $G_1[k-1] -\isomorphic G_2[S]$ with the mapping $f_{k-1}$, so all we need to do -is verify that the edges in $E_1[k] - E_1[k-1]$ connect vertices that -correspond to the vertices connected by the edges in $E_2[S \union \{ -v \}] - E_2[S]$. The edges in $E_1[k] - E_1[k-1]$ are all the -out-edges $(k,j)$ and in-edges $(j,k)$ of $k$ where $j$ is less than -or equal to $k$ according to the ordering. The edges in $E_2[S \union -\{ v \}] - E_2[S]$ consists of all the out-edges $(v,u)$ and -in-edges $(u,v)$ of $v$ where $u \in S$. - -\begin{tabbing} -M\=ATCH($k$, $v$) $\equiv$ \\ -\>$out \leftarrow \forall (k,j) \in E_1[k] - E_1[k-1] \Big( (v,f(j)) \in E_2[S \union \{ v \}] - E_2[S] \Big)$ \\ -\>$in \leftarrow \forall (j,k) \in E_1[k] - E_1[k-1] \Big( (f(j),v) \in E_2[S \union \{ v \}] - E_2[S] \Big)$ \\ -\>\textbf{return} $out \Land in$ -\end{tabbing} - -The problem with the exhaustive backtracking algorithm is that there -are $N!$ possible vertex mappings, and $N!$ gets very large as $N$ -increases, so we need to prune the search space. We use the pruning -techniques described in -\cite{deo77:_new_algo_digraph_isomorph,fortin96:_isomorph,reingold77:_combin_algo} -that originated in -\cite{sussenguth65:_isomorphism,unger64:_isomorphism}. - -\section{Vertex Invariants} -\label{sec:vertex-invariants} - -One way to reduce the search space is through the use of \emph{vertex -invariants}. The idea is to compute a number for each vertex $i(v)$ -such that $i(v) = i(v')$ if there exists some isomorphism $f$ where -$f(v) = v'$. Then when we look for a match to some vertex $v$, we only -need to consider those vertices that have the same vertex invariant -number. The number of vertices in a graph with the same vertex -invariant number $i$ is called the \emph{invariant multiplicity} for -$i$. In this implementation, by default we use the out-degree of the -vertex as the vertex invariant, though the user can also supply their -own invariant function. The ability of the invariant function to prune -the search space varies widely with the type of graph. - -As a first check to rule out graphs that have no possibility of -matching, one can create a list of computed vertex invariant numbers -for the vertices in each graph, sort the two lists, and then compare -them. If the two lists are different then the two graphs are not -isomorphic. If the two lists are the same then the two graphs may be -isomorphic. - -Also, we extend the MATCH operation to use the vertex invariants to -help rule out vertices. - -\begin{tabbing} -M\=A\=T\=C\=H-INVAR($k$, $v$) $\equiv$ \\ -\>$out \leftarrow \forall (k,j) \in E_1[k] - E_1[k-1] \Big( (v,f(j)) \in E_2[S \union \{ v \}] - E_2[S] \Land i(v) = i(k) \Big)$ \\ -\>$in \leftarrow \forall (j,k) \in E_1[k] - E_1[k-1] \Big( (f(j),v) \in E_2[S \union \{ v \}] - E_2[S] \Land i(v) = i(k) \Big)$ \\ -\>\textbf{return} $out \Land in$ -\end{tabbing} - -\section{Vertex Order} - -A good choice of the labeling for the vertices (which determines the -order in which the subgraph $G_1[k]$ is grown) can also reduce the -search space. In the following we discuss two labeling heuristics. - -\subsection{Most Constrained First} - -Consider the most constrained vertices first. That is, examine -lower-degree vertices before higher-degree vertices. This reduces the -search space because it chops off a trunk before the trunk has a -chance to blossom out. We can generalize this to use vertex -invariants. We examine vertices with low invariant multiplicity -before examining vertices with high invariant multiplicity. - -\subsection{Adjacent First} - -The MATCH operation only considers edges when the other vertex already -has a mapping defined. This means that the MATCH operation can only -weed out vertices that are adjacent to vertices that have already been -matched. Therefore, when choosing the next vertex to examine, it is -desirable to choose one that is adjacent a vertex already in $S_1$. - -\subsection{DFS Order, Starting with Lowest Multiplicity} - -For this implementation, we combine the above two heuristics in the -following way. To implement the ``adjacent first'' heuristic we apply -DFS to the graph, and use the DFS discovery order as our vertex -order. To comply with the ``most constrained first'' heuristic we -order the roots of our DFS trees by invariant multiplicity. - - -\section{Implementation} - -The following is the public interface for the \code{isomorphism} -function. The input to the function is the two graphs $G_1$ and $G_2$, -mappings from the vertices in the graphs to integers (in the range -$[0,|V|)$), and a vertex invariant function object. The output of the -function is an isomorphism $f$ if there is one. The \code{isomorphism} -function returns true if the graphs are isomorphic and false -otherwise. The requirements on type template parameters are described -below in the section ``Concept checking''. - -@d Isomorphism Function Interface -@{ -template -bool isomorphism(const Graph1& g1, const Graph2& g2, - IndexMapping f, - VertexInvariant1 invariant1, VertexInvariant2 invariant2, - IndexMap1 index_map1, IndexMap2 index_map2) -@} - -The main outline of the \code{isomorphism} function is as -follows. Most of the steps in this function are for setting up the -vertex ordering, first ordering the vertices by invariant multiplicity -and then by DFS order. The last step is the call to the -\code{isomorph} function which starts the backtracking search. - -@d Isomorphism Function Body -@{ -{ - @ - @ - @ - @ - @ - @ - @ - @ - @ - @ -} -@} - -There are some types that will be used throughout the function, which -we create shortened names for here. We will also need vertex -iterators for \code{g1} and \code{g2} in several places, so we define -them here. - -@d Some type definitions and iterator declarations -@{ -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::vertices_size_type size_type; -typename graph_traits::vertex_iterator i1, i1_end; -typename graph_traits::vertex_iterator i2, i2_end; -@} - -We use the Boost Concept Checking Library to make sure that the type -arguments to the function fulfill there requirements. The -\code{Graph1} type must be a \bglconcept{VertexListGraph} and a -\bglconcept{EdgeListGraph}. The \code{Graph2} type must be a -\bglconcept{VertexListGraph} and a -\bglconcept{BidirectionalGraph}. The \code{IndexMapping} type that -represents the isomorphism $f$ must be a -\pmconcept{ReadWritePropertyMap} that maps from vertices in $G_1$ to -vertices in $G_2$. The two other index maps are -\pmconcept{ReadablePropertyMap}s from vertices in $G_1$ and $G_2$ to -unsigned integers. - -@d Concept checking -@{ -// Graph requirements -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( EdgeListGraphConcept )); -BOOST_CONCEPT_ASSERT(( VertexListGraphConcept )); -BOOST_CONCEPT_ASSERT(( BidirectionalGraphConcept )); - -// Property map requirements -BOOST_CONCEPT_ASSERT(( ReadWritePropertyMapConcept )); -typedef typename property_traits::value_type IndexMappingValue; -BOOST_STATIC_ASSERT((is_same::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap1Value; -BOOST_STATIC_ASSERT((is_convertible::value)); - -BOOST_CONCEPT_ASSERT(( ReadablePropertyMapConcept )); -typedef typename property_traits::value_type IndexMap2Value; -BOOST_STATIC_ASSERT((is_convertible::value)); -@} - - -\noindent If there are no vertices in either graph, then they are trivially -isomorphic. - -@d Quick return with false if $|V_1| \neq |V_2|$ -@{ -if (num_vertices(g1) != num_vertices(g2)) - return false; -@} - - -\subsection{Ordering by Vertex Invariant Multiplicity} - -The user can supply the vertex invariant functions as a -\stlconcept{AdaptableUnaryFunction} (with the addition of the -\code{max} function) in the \code{invariant1} and \code{invariant2} -parameters. We also define a default which uses the out-degree and -in-degree of a vertex. The following is the definition of the function -object for the default vertex invariant. User-defined vertex invariant -function objects should follow the same pattern. - -@d Degree vertex invariant -@{ -template -class degree_vertex_invariant -{ -public: - typedef typename graph_traits::vertex_descriptor argument_type; - typedef typename graph_traits::degree_size_type result_type; - - degree_vertex_invariant(const InDegreeMap& in_degree_map, const Graph& g) - : m_in_degree_map(in_degree_map), m_g(g) { } - - result_type operator()(argument_type v) const { - return (num_vertices(m_g) + 1) * out_degree(v, m_g) - + get(m_in_degree_map, v); - } - // The largest possible vertex invariant number - result_type max() const { - return num_vertices(m_g) * num_vertices(m_g) + num_vertices(m_g); - } -private: - InDegreeMap m_in_degree_map; - const Graph& m_g; -}; -@} - -Since the invariant function may be expensive to compute, we -pre-compute the invariant numbers for every vertex in the two -graphs. The variables \code{invar1} and \code{invar2} are property -maps for accessing the stored invariants, which are described next. - -@d Compute vertex invariants -@{ -@ -for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - invar1[*i1] = invariant1(*i1); -for (tie(i2, i2_end) = vertices(g2); i2 != i2_end; ++i2) - invar2[*i2] = invariant2(*i2); -@} - -\noindent We store the invariants in two vectors, indexed by the vertex indices -of the two graphs. We then create property maps for accessing these -two vectors in a more convenient fashion (they go directly from vertex -to invariant, instead of vertex to index to invariant). - -@d Setup storage for vertex invariants -@{ -typedef typename VertexInvariant1::result_type InvarValue1; -typedef typename VertexInvariant2::result_type InvarValue2; -typedef std::vector invar_vec1_t; -typedef std::vector invar_vec2_t; -invar_vec1_t invar1_vec(num_vertices(g1)); -invar_vec2_t invar2_vec(num_vertices(g2)); -typedef typename invar_vec1_t::iterator vec1_iter; -typedef typename invar_vec2_t::iterator vec2_iter; -iterator_property_map - invar1(invar1_vec.begin(), index_map1); -iterator_property_map - invar2(invar2_vec.begin(), index_map2); -@} - -As discussed in \S\ref{sec:vertex-invariants}, we can quickly rule out -the possibility of any isomorphism between two graphs by checking to -see if the vertex invariants can match up. We sort both vectors of vertex -invariants, and then check to see if they are equal. - -@d Quick return if the graph's invariants do not match -@{ -{ // check if the graph's invariants do not match - invar_vec1_t invar1_tmp(invar1_vec); - invar_vec2_t invar2_tmp(invar2_vec); - std::sort(invar1_tmp.begin(), invar1_tmp.end()); - std::sort(invar2_tmp.begin(), invar2_tmp.end()); - if (! std::equal(invar1_tmp.begin(), invar1_tmp.end(), - invar2_tmp.begin())) - return false; -} -@} - -Next we compute the invariant multiplicity, the number of vertices -with the same invariant number. The \code{invar\_mult} vector is -indexed by invariant number. We loop through all the vertices in the -graph to record the multiplicity. - -@d Compute invariant multiplicity -@{ -std::vector invar_mult(invariant1.max(), 0); -for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - ++invar_mult[invar1[*i1]]; -@} - -\noindent We then order the vertices by their invariant multiplicity. -This will allow us to search the more constrained vertices first. -Since we will need to know the permutation from the original order to -the new order, we do not sort the vertices directly. Instead we sort -the vertex indices, creating the \code{perm} array. Once sorted, this -array provides a mapping from the new index to the old index. -We then use the \code{permute} function to sort the vertices of -the graph, which we store in the \code{g1\_vertices} vector. - -@d Sort vertices by invariant multiplicity -@{ -std::vector perm; -integer_range range(0, num_vertices(g1)); -std::copy(range.begin(), range.end(), std::back_inserter(perm)); -std::sort(perm.begin(), perm.end(), - detail::compare_invariant_multiplicity(invar1_vec.begin(), - invar_mult.begin())); - -std::vector g1_vertices; -for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - g1_vertices.push_back(*i1); -permute(g1_vertices.begin(), g1_vertices.end(), perm.begin()); -@} - -\noindent The definition of the \code{compare\_multiplicity} predicate -is shown below. This predicate provides the glue that binds -\code{std::sort} to our current purpose. - -@d Compare multiplicity predicate -@{ -namespace detail { - template - struct compare_invariant_multiplicity_predicate - { - compare_invariant_multiplicity_predicate(InvarMap i, MultMap m) - : m_invar(i), m_mult(m) { } - - template - bool operator()(const Vertex& x, const Vertex& y) const - { return m_mult[m_invar[x]] < m_mult[m_invar[y]]; } - - InvarMap m_invar; - MultMap m_mult; - }; - template - compare_invariant_multiplicity_predicate - compare_invariant_multiplicity(InvarMap i, MultMap m) { - return compare_invariant_multiplicity_predicate(i,m); - } -} // namespace detail -@} - - -\subsection{Ordering by DFS Discover Time} - -To implement the ``visit adjacent vertices first'' heuristic, we order -the vertices according to DFS discover time. We replace the ordering -in \code{perm} with the new DFS ordering. Again, we use \code{permute} -to sort the vertices of graph \code{g1}. - -@d Order the vertices by DFS discover time -@{ -{ - perm.clear(); - @ - g1_vertices.clear(); - for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - g1_vertices.push_back(*i1); - permute(g1_vertices.begin(), g1_vertices.end(), perm.begin()); -} -@} - -We implement the outer-loop of the DFS here, instead of calling the -\code{depth\_first\_search} function, because we want the roots of the -DFS tree's to be ordered by invariant multiplicity. We call -\code{depth\_\-first\_\-visit} to implement the recursive portion of -the DFS. The \code{record\_dfs\_order} adapts the DFS to record -the order in which DFS discovers the vertices. - -@d Compute DFS discover times -@{ -std::vector color_vec(num_vertices(g1)); -for (typename std::vector::iterator ui = g1_vertices.begin(); - ui != g1_vertices.end(); ++ui) { - if (color_vec[get(index_map1, *ui)] - == color_traits::white()) { - depth_first_visit - (g1, *ui, detail::record_dfs_order(perm, - index_map1), - make_iterator_property_map(&color_vec[0], index_map1, - color_vec[0])); - } -} -@} - -\noindent The definition of the \code{record\_dfs\_order} visitor -class is as follows. The index of each vertex is recorded in the -\code{dfs\_order} vector (which is the \code{perm} vector) in the -\code{discover\_vertex} event point. - -@d Record DFS ordering visitor -@{ -namespace detail { - template - struct record_dfs_order : public default_dfs_visitor { - typedef typename graph_traits::vertices_size_type size_type; - typedef typename graph_traits::vertex_descriptor vertex; - - record_dfs_order(std::vector& dfs_order, IndexMap1 index) - : dfs_order(dfs_order), index(index) { } - - void discover_vertex(vertex v, const Graph1& g) const { - dfs_order.push_back(get(index, v)); - } - std::vector& dfs_order; - IndexMap1 index; - }; -} // namespace detail -@} - - -In the MATCH operation, we need to examine all the edges in the set -$E_1[k] - E_1[k-1]$. That is, we need to loop through all the edges of -the form $(k,j)$ or $(j,k)$ where $j \leq k$. To do this efficiently, -we create an array of all the edges in $G_1$ that has been sorted so -that $E_1[k] - E_1[k-1]$ forms a contiguous range. To each edge -$e=(u,v)$ we assign the number $\max(u,v)$, and then sort the edges by -this number. All the edges $(u,v) \in E_1[k] - E_1[k-1]$ can then be -identified because $\max(u,v) = k$. The following code creates an -array of edges and then sorts them. The \code{edge\_\-ordering\_\-fun} -function object is described next. - -@d Order the edges by DFS discover time -@{ -typedef typename graph_traits::edge_descriptor edge1_t; -std::vector edge_set; -std::copy(edges(g1).first, edges(g1).second, std::back_inserter(edge_set)); - -std::sort(edge_set.begin(), edge_set.end(), - detail::edge_ordering - (make_iterator_property_map(perm.begin(), index_map1, perm[0]), g1)); -@} - -\noindent The \code{edge\_order} function computes the ordering number -for an edge, which for edge $e=(u,v)$ is $\max(u,v)$. The -\code{edge\_\-ordering\_\-fun} function object simply returns -comparison of two edge's ordering numbers. - -@d Isomorph edge ordering predicate -@{ -namespace detail { - - template - std::size_t edge_order(const typename graph_traits::edge_descriptor e, - VertexIndexMap index_map, const Graph& g) { - return std::max(get(index_map, source(e, g)), get(index_map, target(e, g))); - } - - template - class edge_ordering_fun { - public: - edge_ordering_fun(VertexIndexMap vip, const Graph& g) - : m_index_map(vip), m_g(g) { } - template - bool operator()(const Edge& e1, const Edge& e2) const { - return edge_order(e1, m_index_map, m_g) < edge_order(e2, m_index_map, m_g); - } - VertexIndexMap m_index_map; - const Graph& m_g; - }; - template - inline edge_ordering_fun - edge_ordering(VertexIndexMap vip, const G& g) - { - return edge_ordering_fun(vip, g); - } -} // namespace detail -@} - - -We are now ready to enter the main part of the algorithm, the -backtracking search implemented by the \code{isomorph} function (which -corresponds to the ISOMORPH algorithm). The set $S$ is not -represented directly; instead we represent $V_2 - S$. Initially $S = -\emptyset$ so $V_2 - S = V_2$. We use the permuted indices for the -vertices of graph \code{g1}. We represent $V_2 - S$ with a bitset. We -use \code{std::vector} instead of \code{boost::dyn\_bitset} for speed -instead of space. - -@d Invoke recursive \code{isomorph} function -@{ -std::vector not_in_S_vec(num_vertices(g2), true); -iterator_property_map - not_in_S(¬_in_S_vec[0], index_map2); - -return detail::isomorph(g1_vertices.begin(), g1_vertices.end(), - edge_set.begin(), edge_set.end(), g1, g2, - make_iterator_property_map(perm.begin(), index_map1, perm[0]), - index_map2, f, invar1, invar2, not_in_S); -@} - - -\subsection{Implementation of ISOMORPH} - -The ISOMORPH algorithm is implemented with the \code{isomorph} -function. The vertices of $G_1$ are searched in the order specified by -the iterator range \code{[k\_iter,last)}. The function returns true if -a isomorphism is found between the vertices of $G_1$ in -\code{[k\_iter,last)} and the vertices of $G_2$ in \code{not\_in\_S}. -The mapping is recorded in the parameter \code{f}. - -@d Signature for the recursive isomorph function -@{ -template -bool isomorph(VertexIter k_iter, VertexIter last, - EdgeIter edge_iter, EdgeIter edge_iter_end, - const Graph1& g1, const Graph2& g2, - IndexMap1 index_map1, - IndexMap2 index_map2, - IndexMapping f, Invar1 invar1, Invar2 invar2, - const Set& not_in_S) -@} - -\noindent The steps for this function are as follows. - -@d Body of the isomorph function -@{ -{ - @ - @ - @ - @ - @ -} -@} - -\noindent Here we create short names for some often-used types -and declare some variables. - -@d Some typedefs and variable declarations -@{ -typedef typename graph_traits::vertex_descriptor vertex1_t; -typedef typename graph_traits::vertex_descriptor vertex2_t; -typedef typename graph_traits::vertices_size_type size_type; - -vertex1_t k = *k_iter; -@} - -\noindent We have completed creating an isomorphism if \code{k\_iter == last}. - -@d Return true if matching is complete -@{ -if (k_iter == last) - return true; -@} - - -In the pseudo-code for ISOMORPH, we iterate through each vertex in $v -\in V_2 - S$ and check if $k$ and $v$ can match. A more efficient -approach is to directly iterate through the potential matches for $k$, -for this often is many fewer vertices than $V_2 - S$. Let $M$ be the -set of potential matches for $k$. $M$ consists of all the vertices $v -\in V_2 - S$ such that if $(k,j)$ or $(j,k) \in E_1[k] - E_1[k-1]$ -then $(v,f(j)$ or $(f(j),v) \in E_2$ with $i(v) = i(k)$. Note that -this means if there are no edges in $E_1[k] - E_1[k-1]$ then $M = V_2 -- S$. In the case where there are edges in $E_1[k] - E_1[k-1]$ we -break the computation of $M$ into two parts, computing $out$ sets -which are vertices that can match according to an out-edge of $k$, and -computing $in$ sets which are vertices that can match according to an -in-edge of $k$. - -The implementation consists of a loop through the edges of $E_1[k] - -E_1[k-1]$. The straightforward implementation would initialize $M -\leftarrow V_2 - S$, and then intersect $M$ with the $out$ or $in$ set -for each edge. However, to reduce the cost of the intersection -operation, we start with $M \leftarrow \emptyset$, and on the first -iteration of the loop we do $M \leftarrow out$ or $M \leftarrow in$ -instead of an intersection operation. - -@d Compute $M$, the potential matches for $k$ -@{ -std::vector potential_matches; -bool some_edges = false; - -for (; edge_iter != edge_iter_end; ++edge_iter) { - if (get(index_map1, k) != edge_order(*edge_iter, index_map1, g1)) - break; - if (k == source(*edge_iter, g1)) { // (k,j) - @ - if (some_edges == false) { - @ - } else { - @ - } - some_edges = true; - } else { // (j,k) - @ - if (some_edges == false) { - @ - } else { - @ - } - some_edges = true; - } - if (potential_matches.empty()) - break; -} // for edge_iter -if (some_edges == false) { - @ -} -@} - -To compute the $out$ set, we iterate through the out-edges $(k,j)$ of -$k$, and for each $j$ we iterate through the in-edges $(v,f(j))$ of -$f(j)$, putting all of the $v$'s in $out$ that have the same vertex -invariant as $k$, and which are in $V_2 - S$. Figure~\ref{fig:out} -depicts the computation of the $out$ set. The implementation is as -follows. - -@d Compute the $out$ set -@{ -vertex1_t j = target(*edge_iter, g1); -std::vector out; -typename graph_traits::in_edge_iterator ei, ei_end; -for (tie(ei, ei_end) = in_edges(get(f, j), g2); ei != ei_end; ++ei) { - vertex2_t v = source(*ei, g2); // (v,f[j]) - if (invar1[k] == invar2[v] && not_in_S[v]) - out.push_back(v); -} -@} - -\noindent Here initialize $M$ with the $out$ set. Since we are -representing sets with sorted vectors, we sort \code{out} before -copying to \code{potential\_matches}. - -@d Perform $M \leftarrow out$ -@{ -indirect_cmp > cmp(index_map2); -std::sort(out.begin(), out.end(), cmp); -std::copy(out.begin(), out.end(), std::back_inserter(potential_matches)); -@} - -\noindent We use \code{std::set\_intersection} to implement $M -\leftarrow M \intersect out$. Since there is no version of -\code{std::set\_intersection} that works in-place, we create a -temporary for the result and then swap. - -@d Perform $M \leftarrow M \intersect out$ -@{ -indirect_cmp > cmp(index_map2); -std::sort(out.begin(), out.end(), cmp); -std::vector tmp_matches; -std::set_intersection(out.begin(), out.end(), - potential_matches.begin(), potential_matches.end(), - std::back_inserter(tmp_matches), cmp); -std::swap(potential_matches, tmp_matches); -@} - -% Shoot, there is some problem with f(j). Could have to do with the -% change from the edge set to just using out_edges and in_edges. -% Yes, have to visit edges in correct order to we don't hit -% part of f that is not yet defined. - -\vizfig{out}{Computing the $out$ set.} - -@c out.dot -@{ -digraph G { - node[shape=circle] - size="4,2" - ratio="fill" - - subgraph cluster0 { label="G_1" - k -> j_1 - k -> j_2 - k -> j_3 - } - - subgraph cluster1 { label="G_2" - - subgraph cluster2 { label="out" v_1 v_2 v_3 v_4 v_5 v_6 } - - v_1 -> fj_1 - v_2 -> fj_1 - v_3 -> fj_1 - - v_4 -> fj_2 - - v_5 -> fj_3 - v_6 -> fj_3 - - fj_1[label="f(j_1)"] - fj_2[label="f(j_2)"] - fj_3[label="f(j_3)"] - } - - j_1 -> fj_1[style=dotted] - j_2 -> fj_2[style=dotted] - j_3 -> fj_3[style=dotted] -} -@} - -The $in$ set is is constructed by iterating through the in-edges -$(j,k)$ of $k$, and for each $j$ we iterate through the out-edges -$(f(j),v)$ of $f(j)$. We put all of the $v$'s in $in$ that have the -same vertex invariant as $k$, and which are in $V_2 - -S$. Figure~\ref{fig:in} depicts the computation of the $in$ set. The -following code computes the $in$ set. - -@d Compute the $in$ set -@{ -vertex1_t j = source(*edge_iter, g1); -std::vector in; -typename graph_traits::out_edge_iterator ei, ei_end; -for (tie(ei, ei_end) = out_edges(get(f, j), g2); ei != ei_end; ++ei) { - vertex2_t v = target(*ei, g2); // (f[j],v) - if (invar1[k] == invar2[v] && not_in_S[v]) - in.push_back(v); -} -@} - -\noindent Here initialize $M$ with the $in$ set. Since we are -representing sets with sorted vectors, we sort \code{in} before -copying to \code{potential\_matches}. - -@d Perform $M \leftarrow in$ -@{ -indirect_cmp > cmp(index_map2); -std::sort(in.begin(), in.end(), cmp); -std::copy(in.begin(), in.end(), std::back_inserter(potential_matches)); -@} - -\noindent Again we use \code{std::set\_intersection} on -sorted vectors to implement $M \leftarrow M \intersect in$. - -@d Perform $M \leftarrow M \intersect in$ -@{ -indirect_cmp > cmp(index_map2); -std::sort(in.begin(), in.end(), cmp); -std::vector tmp_matches; -std::set_intersection(in.begin(), in.end(), - potential_matches.begin(), potential_matches.end(), - std::back_inserter(tmp_matches), cmp); -std::swap(potential_matches, tmp_matches); -@} - -\vizfig{in}{Computing the $in$ set.} - -@c in.dot -@{ -digraph G { - node[shape=circle] - size="3,2" - ratio="fill" - subgraph cluster0 { label="G1" - j_1 -> k - j_2 -> k - } - - subgraph cluster1 { label="G2" - - subgraph cluster2 { label="in" v_1 v_2 v_3 } - - v_1 -> fj_1 - v_2 -> fj_1 - - v_3 -> fj_2 - - fj_1[label="f(j_1)"] - fj_2[label="f(j_2)"] - } - - j_1 -> fj_1[style=dotted] - j_2 -> fj_2[style=dotted] - -} -@} - -In the case where there were no edges in $E_1[k] - E_1[k-1]$, then $M -= V_2 - S$, so here we insert all the vertices from $V_2$ that are not -in $S$. - -@d Perform $M \leftarrow V_2 - S$ -@{ -typename graph_traits::vertex_iterator vi, vi_end; -for (tie(vi, vi_end) = vertices(g2); vi != vi_end; ++vi) - if (not_in_S[*vi]) - potential_matches.push_back(*vi); -@} - -For each vertex $v$ in the potential matches $M$, we will create an -extended isomorphism $f_k = f_{k-1} \union \pair{k}{v}$. First -we create a local copy of $f_{k-1}$. - -@d Create a copy of $f_{k-1}$ which will become $f_k$ -@{ -std::vector my_f_vec(num_vertices(g1)); -typedef typename std::vector::iterator vec_iter; -iterator_property_map - my_f(my_f_vec.begin(), index_map1); - -typename graph_traits::vertex_iterator i1, i1_end; -for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - my_f[*i1] = get(f, *i1); -@} - -Next we enter the loop through every vertex $v$ in $M$, and extend the -isomorphism with $\pair{k}{v}$. We then update the set $S$ (by -removing $v$ from $V_2 - S$) and make the recursive call to -\code{isomorph}. If \code{isomorph} returns successfully, we have -found an isomorphism for the complete graph, so we copy our local -mapping into the mapping from the previous calling function. - -@d Invoke isomorph for each vertex in $M$ -@{ -for (std::size_t j = 0; j < potential_matches.size(); ++j) { - my_f[k] = potential_matches[j]; - @ - if (isomorph(boost::next(k_iter), last, edge_iter, edge_iter_end, g1, g2, - index_map1, index_map2, - my_f, invar1, invar2, my_not_in_S)) { - for (tie(i1, i1_end) = vertices(g1); i1 != i1_end; ++i1) - put(f, *i1, my_f[*i1]); - return true; - } -} -return false; -@} - -We need to create the new set $S' = S - \{ v \}$, which will be the -$S$ for the next invocation to \code{isomorph}. As before, we -represent $V_2 - S'$ instead of $S'$ and use a bitset. - -@d Perform $S' = S - \{ v \}$ -@{ -std::vector my_not_in_S_vec(num_vertices(g2)); -iterator_property_map - my_not_in_S(&my_not_in_S_vec[0], index_map2); -typename graph_traits::vertex_iterator vi, vi_end; -for (tie(vi, vi_end) = vertices(g2); vi != vi_end; ++vi) - my_not_in_S[*vi] = not_in_S[*vi];; -my_not_in_S[potential_matches[j]] = false; -@} - - -\section{Appendix} - -Here we output the header file \code{isomorphism.hpp}. We add a -copyright statement, include some files, and then pull the top-level -code parts into namespace \code{boost}. - -@o isomorphism.hpp -d -@{ - -// (C) Copyright Jeremy Siek 2001. Permission to copy, use, modify, -// sell and distribute this software is granted provided this -// copyright notice appears in all copies. This software is provided -// "as is" without express or implied warranty, and with no claim as -// to its suitability for any purpose. - -// See http://www.boost.org/libs/graph/doc/isomorphism-impl.pdf -// for a description of the implementation of the isomorphism function -// defined in this header file. - -#ifndef BOOST_GRAPH_ISOMORPHISM_HPP -#define BOOST_GRAPH_ISOMORPHISM_HPP - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -namespace boost { - - @ - - namespace detail { - @ - @ - } // namespace detail - - @ - @ - @ - - @ - @ - - namespace detail { - // Should move this, make is public - template - void compute_in_degree(const Graph& g, const InDegreeMap& in_degree_map, - Cat) - { - typename graph_traits::vertex_iterator vi, vi_end; - typename graph_traits::out_edge_iterator ei, ei_end; - for (tie(vi, vi_end) = vertices(g); vi != vi_end; ++vi) - for (tie(ei, ei_end) = out_edges(*vi, g); ei != ei_end; ++ei) { - typename graph_traits::vertex_descriptor v = target(*ei, g); - put(in_degree_map, v, get(in_degree_map, v) + 1); - } - } - template - void compute_in_degree(const Graph& g, const InDegreeMap& in_degree_map, - edge_list_graph_tag) - { - typename graph_traits::edge_iterator ei, ei_end; - for (tie(ei, ei_end) = edges(g); ei != ei_end; ++ei) { - typename graph_traits::vertex_descriptor v = target(*ei, g); - put(in_degree_map, v, get(in_degree_map, v) + 1); - } - } - template - void compute_in_degree(const Graph& g, const InDegreeMap& in_degree_map) - { - typename graph_traits::traversal_category cat; - compute_in_degree(g, in_degree_map, cat); - } - - - template - bool isomorphism_impl(const Graph1& g1, const Graph2& g2, - IndexMapping f, - IndexMap1 index_map1, IndexMap2 index_map2, - const bgl_named_params& params) - { - typedef typename graph_traits::vertices_size_type size_type; - - // Compute the in-degrees - std::vector in_degree_vec1(num_vertices(g1), 0); - typedef iterator_property_map InDegreeMap1; - InDegreeMap1 in_degree_map1(&in_degree_vec1[0], index_map1); - detail::compute_in_degree(g1, in_degree_map1); - degree_vertex_invariant - default_invar1(in_degree_map1, g1); - - std::vector in_degree_vec2(num_vertices(g2), 0); - typedef iterator_property_map InDegreeMap2; - InDegreeMap2 in_degree_map2(&in_degree_vec2[0], index_map2); - detail::compute_in_degree(g2, in_degree_map2); - degree_vertex_invariant - default_invar2(in_degree_map2, g2); - - return isomorphism(g1, g2, f, - choose_param(get_param(params, vertex_invariant_t()), default_invar1), - choose_param(get_param(params, vertex_invariant_t()), default_invar2), - index_map1, index_map2); - } - - } // namespace detail - - // Named parameter interface - template - bool isomorphism(const Graph1& g1, - const Graph2& g2, - const bgl_named_params& params) - { - typedef typename graph_traits::vertex_descriptor vertex2_t; - typename std::vector::size_type - n = is_default_param(get_param(params, vertex_isomorphism_t())) - ? num_vertices(g1) : 1; - std::vector f(n); - vertex2_t x; - return detail::isomorphism_impl - (g1, g2, - choose_param(get_param(params, vertex_isomorphism_t()), - make_iterator_property_map(f.begin(), - choose_const_pmap(get_param(params, vertex_index1), - g1, vertex_index), x)), - choose_const_pmap(get_param(params, vertex_index1), - g1, vertex_index), - choose_const_pmap(get_param(params, vertex_index2), - g2, vertex_index), - params); - } - - // All defaults interface - template - bool isomorphism(const Graph1& g1, const Graph2& g2) - { - typedef typename graph_traits::vertices_size_type size_type; - typedef typename graph_traits::vertex_descriptor vertex2_t; - std::vector f(num_vertices(g1)); - - // Compute the in-degrees - std::vector in_degree_vec1(num_vertices(g1), 0); - typedef typename property_map::const_type IndexMap1; - typedef iterator_property_map InDegreeMap1; - InDegreeMap1 in_degree_map1(&in_degree_vec1[0], get(vertex_index, g1)); - detail::compute_in_degree(g1, in_degree_map1); - degree_vertex_invariant - invariant1(in_degree_map, g1); - - std::vector in_degree_vec2(num_vertices(g2), 0); - typedef typename property_map::const_type IndexMap2; - typedef iterator_property_map InDegreeMap2; - InDegreeMap2 in_degree_map2(&in_degree_vec2[0], get(vertex_index, g2)); - detail::compute_in_degree(g2, in_degree_map2); - degree_vertex_invariant - invariant2(in_degree_map, g2); - - return isomorphism - (g1, g2, make_iterator_property_map(f.begin(), get(vertex_index, g1), vertex2_t()), - invariant1, invariant2, get(vertex_index, g1), get(vertex_index, g2)); - } - - // Verify that the given mapping iso_map from the vertices of g1 to the - // vertices of g2 describes an isomorphism. - // Note: this could be made much faster by specializing based on the graph - // concepts modeled, but since we're verifying an O(n^(lg n)) algorithm, - // O(n^4) won't hurt us. - template - inline bool verify_isomorphism(const Graph1& g1, const Graph2& g2, - IsoMap iso_map) - { - if (num_vertices(g1) != num_vertices(g2) || num_edges(g1) != num_edges(g2)) - return false; - - for (typename graph_traits::edge_iterator e1 = edges(g1).first; - e1 != edges(g1).second; ++e1) { - bool found_edge = false; - for (typename graph_traits::edge_iterator e2 = edges(g2).first; - e2 != edges(g2).second && !found_edge; ++e2) { - if (source(*e2, g2) == get(iso_map, source(*e1, g1)) && - target(*e2, g2) == get(iso_map, target(*e1, g1))) { - found_edge = true; - } - } - - if (!found_edge) - return false; - } - - return true; - } - -} // namespace boost - -#endif // BOOST_GRAPH_ISOMORPHISM_HPP -@} - -\bibliographystyle{abbrv} -\bibliography{ggcl} - -\end{document} -% LocalWords: Isomorphism Siek isomorphism adjacency subgraph subgraphs OM DFS -% LocalWords: ISOMORPH Invariants invariants typename IndexMapping bool const -% LocalWords: VertexInvariant VertexIndexMap iterator typedef VertexG Idx num -% LocalWords: InvarValue struct invar vec iter tmp_matches mult inserter permute ui -% LocalWords: dfs cmp isomorph VertexIter EdgeIter IndexMap desc RPH ATCH pre - -% LocalWords: iterators VertexListGraph EdgeListGraph BidirectionalGraph tmp -% LocalWords: ReadWritePropertyMap VertexListGraphConcept EdgeListGraphConcept -% LocalWords: BidirectionalGraphConcept ReadWritePropertyMapConcept indices ei -% LocalWords: IndexMappingValue ReadablePropertyMapConcept namespace InvarMap -% LocalWords: MultMap vip inline bitset typedefs fj hpp ifndef adaptor params -% LocalWords: bgl param pmap endif diff --git a/doc/isomorphism.html b/doc/isomorphism.html deleted file mode 100644 index 524ce9c75..000000000 --- a/doc/isomorphism.html +++ /dev/null @@ -1,186 +0,0 @@ - - - -Boost Graph Library: Isomorphism - -C++ Boost - -
- -

-(Python) -isomorphism -

- - -
-// named parameter version
-template <class Graph1, class Graph2, class P, class T, class R>
-bool isomorphism(const Graph1& g1, const Graph2& g2,
-                 const bgl_named_params<P,T,R>& params = all defaults)
-
-// non-named parameter version
-template <typename Graph1, typename Graph2, typename IsoMap,
-          typename VertexInvariant1, typename VertexInvariant2,
-          typename V1Map, typename V2Map>
-bool isomorphism(const Graph1& g1, const Graph2& g2,
-		 IsoMap f, VertexInvariant1 invariant2, VertexInvariant2 invariant2,
-		 std::size_t max_invariant, VertexIndex1Map i1_map, VertexIndex2Map i2_map)
-
- -

-An isomorphism is a 1-to-1 mapping of the vertices in -one graph to the vertices of another graph such that adjacency is -preserved. Another words, given graphs G1 = -(V1,E1) and G2 = -(V2,E2) an isomorphism is a function -f such that for all pairs of vertices a,b in -V1, edge (a,b) is in E1 if -and only if edge (f(a),f(b)) is in E2. -

- -

-This function returns true if there exists an isomorphism -between graph 1 and graph 2 and false otherwise. Also, if a -isomorphism map named parameter is provided then an isomorphism is -recorded in the map. -

- -

-The current implementation is based on descriptions of a backtracking -algorithm in [46,48]. The file -isomorphism-impl.pdf contains a (somewhat out-of-date) -"literate" description of the implementation. The algorithm -used is simple but slow. A more efficient (and much more complex) -algorithm is described in [47]. When (and -if) a version of this algorithm is ported to the BGL interface it -should replace the current algorithm. -

- -

Where Defined

- -boost/graph/isomorphism.hpp - -

Parameters

- -IN: const Graph1& g1 -
-A directed or undirected graph. The graph type must model of Vertex List Graph and Edge List Graph. -
- -IN: const Graph2& g2 -
-A directed or undirected graph. The graph type must model Bidirectional Graph and Vertex List Graph. -
- -

Named Parameters

- -OUT: isomorphism_map(IsoMap f) -
-The mapping from vertices in graph 1 to vertices in graph 2. IsoMap -must be a Read/Write -Property Map.
Default: an iterator_property_map -constructed from a std::vector of graph 2's vertex -descriptor type and the vertex index map for graph 1.
-Python: Must be a vertex_vertex_map for the first graph. -
- -IN: vertex_invariant1(VertexInvariant1 i1) -IN: vertex_invariant2(VertexInvariant2 i2) -
-Mappings from vertices to integers which restrict which vertices may be -considered isomorphic. If a candidate isomorphism maps v1 to v2 -but i1(v1) != i2(v2), that candidate is rejected. -This mapping can be used either to speed up the search (as is done by the -default value, which requires that the degrees of v1 and v2 are -equal) or to impose extra conditions on the result. The -VertexInvariant1 and VertexInvariant2 types must model AdaptableUnaryFunction, -with the argument type of vertex_invariant1 being Graph1's vertex -descriptor type, the argument type of vertex_invariant2 being -Graph2's vertex descriptor type, and both functions sharing a -result type that is totally ordered and hashable, such as an integer. -
-Default: degree_vertex_invariant for both arguments
-Python: Unsupported parameter. -
- -IN: vertex_max_invariant(std::size_t max_invariant) -
-This parameter is ignored as it is no longer necessary, but kept for backwards -compatibility. -
- -IN: vertex_index1_map(VertexIndex1Map i1_map) -
-This maps each vertex to an integer in the range [0, -num_vertices(g)). This is necessary for efficient updates of the -heap data structure when an edge is relaxed. The type -VertexIndex1Map must be a model of Readable Property -Map. The value type of the map must be an integer type. The vertex -descriptor type of graph 1 needs to be usable as the key type of the -map.
-Default: get(vertex_index, g1) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-Python: Unsupported parameter. -
- -IN: vertex_index2_map(VertexIndex2Map i2_map) -
-This maps each vertex to an integer in the range [0, -num_vertices(g)). This is necessary for efficient updates of the -heap data structure when an edge is relaxed. The type -VertexIndex2Map must be a model of Readable Property -Map. The value type of the map must be an integer type. The vertex -descriptor type of graph 2 needs to be usable as the key type of the -map.
-Default: get(vertex_index, g2) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-Python: Unsupported parameter. -
- - -

Complexity

- -The worst-case time complexity is O(|V|!). - -

Example

- -See libs/graph/example/isomorphism.cpp. - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/johnson_all_pairs_shortest.html b/doc/johnson_all_pairs_shortest.html deleted file mode 100644 index b78f0f62a..000000000 --- a/doc/johnson_all_pairs_shortest.html +++ /dev/null @@ -1,211 +0,0 @@ - - - -Johnson All Pairs Shortest Paths - -C++ Boost - -
- -

-johnson_all_pairs_shortest_paths -

- -
-// named parameter version
-  template <class VertexAndEdgeListGraph, class DistanceMatrix,
-            class VertexID, class Weight, class BinaryPredicate,
-            class BinaryFunction, class Infinity, class DistanceZero>
-  bool
-  johnson_all_pairs_shortest_paths(VertexAndEdgeListGraph& g1,
-               DistanceMatrix& D,
-               VertexID id1, Weight w1, const BinaryPredicate& compare,
-               const BinaryFunction& combine, const Infinity& inf,
-               DistanceZero zero);
-
-template <typename Graph, typename DistanceMatrix, typename P, typename T, typename R>
-bool johnson_all_pairs_shortest_paths(Graph& g, DistanceMatrix& D,
-  const bgl_named_params<P, T, R>& params = all defaults)
-
-// non-named parameter version
-template <typename Graph, typename DistanceMatrix,
-          typename VertexIndex, typename WeightMap, typename DT>
-bool
-johnson_all_pairs_shortest_paths(VertexAndEdgeListGraph& g1,
-  DistanceMatrix& D,
-  VertexIndex i_map, WeightMap w_map, DT zero)
-
- -

-This algorithm finds the shortest distance between every pair of -vertices in the graph. The algorithm returns false if there is a -negative weight cycle in the graph and true otherwise. The distance -between each pair of vertices is stored in the distance matrix -D. This is one of the more time intensive graph algorithms, -having a time complexity of O(V E log V). - -

This algorithm should be used to compute shortest paths between -every pair of vertices for sparse graphs. For dense graphs, use floyd_warshall_all_pairs_shortest_paths. - -

Where Defined

- -

-boost/graph/johnson_all_pairs_shortest.hpp - - -

Parameters

- -IN: Graph& g -
-A directed or undirected graph. The graph type must be a model of -Vertex List Graph, -Edge List Graph, -and Incidence Graph. -
- -OUT: DistanceMatrix& D -
-The length of the shortest path between each pair of vertices -u,v in the graph is stored in D[u][v]. The tuple of -types (DistanceMatrix, vertices_size_type, D) must be a model -of BasicMatrix where D is the -value type of the DistanceMap. There must be implicit conversions -between the value type of the distance matrix and the value type of the weight -map. -
- - -

Named Parameters

- -IN: weight_map(WeightMap w_map) -
- The weight or "length" of each edge in the graph. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type of the weight map must support a subtraction operation.
- Default: get(edge_weight, g) -
- -UTIL: weight_map2(WeightMap2 w2_map) -
- This parameter is no longer needed, and will be ignored. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure in the internal call to Dijkstra's algorithm. 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 - usable as the key type of the map.
- Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-
- - -UTIL: distance_map(DistanceMap d_map) -
- This parameter is no longer needed, and will be ignored. -
- -IN: distance_compare(CompareFunction cmp) -
- This function is use to compare distances to determine - which vertex is closer to the source vertex. - The CompareFunction type must be a model of - Binary Predicate - and have argument types that - match the value type of the WeightMap property map.
- Default: std::less<DT> with - DT=typename property_traits<WeightMap>::value_type -
- -IN: distance_combine(CombineFunction cmb) -
- This function is used to combine distances to compute the distance - of a path. The CombineFunction type must be a model of Binary - Function. Both argument types and the return type of the binary function - must match the value type of the WeightMap property map. This operation is required to act as the sum operation for the weight type; in particular, it must be the inverse of the binary - operator on that type.
- Default: std::plus<DT> with - DT=typename property_traits<WeightMap>::value_type -
- -IN: distance_inf(DT inf) -
- This value is used to initialize the distance for each - vertex before the start of the algorithm. - The type DT must be the value type of the WeightMap.
- Default: std::numeric_limits::max() -
- -IN: distance_zero(DT zero) -
- This value is used to initialize the distance for the source - vertex before the start of the algorithm. The type DT - must be the value type of the WeightMap.
- Default: 0 -
- -UTIL/OUT: color_map(ColorMap c_map) -
- This is used during the execution of the algorithm to mark the - vertices. The vertices start out white and become gray when they are - inserted in the queue. They then turn black when they are removed - from the queue. At the end of the algorithm, vertices reachable from - the source vertex will have been colored black. All other vertices - will still be white. The type ColorMap must be a model of - Read/Write - Property Map. A vertex descriptor must be usable as the key type - of the map, and the value type of the map must be a model of - Color Value.
- Default: an - iterator_property_map created from a std::vector - of default_color_type of size num_vertices(g) and - using the i_map for the index map. -
- - -

Complexity

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

Example

- -

-The file example/johnson-eg.cpp applies -Johnson's algorithm for all-pairs shortest paths to the example graph -from page 568 of the CLR [8]. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/jwebfrob.pl b/doc/jwebfrob.pl deleted file mode 100644 index 0ad4d2625..000000000 --- a/doc/jwebfrob.pl +++ /dev/null @@ -1,77 +0,0 @@ -# Copyright (c) 2002 Trustees of Indiana University -# -# Distributed under the Boost Software License, Version 1.0. -# (See accompanying file LICENSE_1_0.txt or copy at -# http://www.boost.org/LICENSE_1_0.txt) - - -$lastpage = 0; -$thispage = 1; -$counter = 1; -$alphabet = "\@abcdefghijklmnopqrstuvwxyz"; -$Alphabet = "\@ABCDEFGHIJKLMNOPQRSTUVWXYZ"; -$out = ""; -$saved_full = ""; -$saved_empty = ""; - -while(<>) { - -# These changes are so that it works when we aren't using hyperref - -# if (/(\\newlabel.*\{\{)([0-9]+)(\}\{)([0-9ivx]+)(\}.*JWebCtr\.)([0-9]+)(.*)/) { - if (/\\newlabel\{sec:.*/) { - # make sure not to munge normal (non jweb part) section labels - print ; - } elsif (/\\newlabel\{class:.*/) { - # make sure not to munge normal (non jweb part) class labels - print ; - } elsif (/\\newlabel\{tab:.*/) { - # make sure not to munge normal (non jweb part) table labels - print ; - } elsif (/\\newlabel\{concept:.*/) { - # make sure not to munge normal (non jweb part) concept labels - print ; - } elsif (/\\newlabel\{fig:.*/) { - # make sure not to munge normal (non jweb part) class labels - print ; - } elsif (/(\\newlabel.*\{\{)([0-9\.]+)(\}\{)([0-9ivx]+)(\}.*)(.*)/) { - $thispage = $4; - - if ($thispage ne $lastpage) { - - $counter = 1; - - print $saved_empty; - -# $saved_full = "$1".substr($alphabet,$counter,1)."$3$4$5$6$7\n"; -# $saved_empty = "$1"."$3$4$5$6$7\n"; - $saved_full = "$1".substr($alphabet,$counter,1)."$3$4$5\n"; - $saved_empty = "$1"."$3$4$5\n"; - - } else { - print $saved_full; -# print "$1".substr($alphabet,$counter,1)."$3$4$5$counter$7\n"; - print "$1".substr($alphabet,$counter,1)."$3$4$5\n"; - $saved_full = ""; - $saved_empty = ""; - } - - $lastpage = $thispage; - $counter++; - - } else { - print ; - } -} -print $saved_empty; - - - -# get a line -# cases -# - ref -# - if it is first, save off someplace -# - if there is a first saved, dump the empty version -# - else -# - if there is a first saved, dump the non empty version -# - not a ref diff --git a/doc/kamada_kawai_spring_layout.html b/doc/kamada_kawai_spring_layout.html deleted file mode 100644 index abc3ce662..000000000 --- a/doc/kamada_kawai_spring_layout.html +++ /dev/null @@ -1,323 +0,0 @@ - - - - - - -Function kamada_kawai_spring_layout - - - - - - - - - - - -
-"boost.pngHomeLibrariesPeopleFAQMore
-
-
-
-
-

(Python)Function kamada_kawai_spring_layout

-

boost::kamada_kawai_spring_layout — Kamada-Kawai spring -layout for connected, undirected graphs.

-
-

Synopsis

-
-
-template<typename Topology, typename Graph, typename PositionMap, typename WeightMap, typename T,
-         bool EdgeOrSideLength, typename Done, typename VertexIndexMap,
-         typename DistanceMatrix, typename SpringStrengthMatrix,
-         typename PartialDerivativeMap>
-  bool kamada_kawai_spring_layout(const Graph & g, PositionMap position,
-                                  WeightMap weight,
-                                  const Topology& space,
-                                  unspecified edge_or_side_length, Done done,
-                                  typename property_traits< WeightMap >::value_type spring_constant,
-                                  VertexIndexMap index,
-                                  DistanceMatrix distance,
-                                  SpringStrengthMatrix spring_strength,
-                                  PartialDerivativeMap partial_derivatives);
-template<typename Topology, typename Graph, typename PositionMap, typename WeightMap, typename T,
-         bool EdgeOrSideLength, typename Done, typename VertexIndexMap>
-  bool kamada_kawai_spring_layout(const Graph & g, PositionMap position,
-                                  WeightMap weight,
-                                  const Topology& space,
-                                  unspecified edge_or_side_length, Done done,
-                                  typename property_traits< WeightMap >::value_type spring_constant,
-                                  VertexIndexMap index);
-template<typename Topology, typename Graph, typename PositionMap, typename WeightMap, typename T,
-         bool EdgeOrSideLength, typename Done>
-  bool kamada_kawai_spring_layout(const Graph & g, PositionMap position,
-                                  WeightMap weight,
-                                  const Topology& space,
-                                  unspecified edge_or_side_length, Done done,
-                                  typename property_traits< WeightMap >::value_type spring_constant = typename property_traits< WeightMap >::value_type(1));
-template<typename Topology, typename Graph, typename PositionMap, typename WeightMap, typename T,
-         bool EdgeOrSideLength>
-  bool kamada_kawai_spring_layout(const Graph & g, PositionMap position,
-                                  WeightMap weight,
-                                  const Topology& space,
-                                  unspecified edge_or_side_length);
-
-
-

Where Defined

-boost/graph/kamada_kawai_spring_layout.hpp - -

Description

-

This algorithm [57] performs graph layout (in two -dimensions) for connected, undirected graphs. It operates by -relating the layout of graphs to a dynamic spring system and -minimizing the energy within that system. The strength of a spring -between two vertices is inversely proportional to the square of the -shortest distance (in graph terms) between those two vertices. -Essentially, vertices that are closer in the graph-theoretic sense -(i.e., by following edges) will have stronger springs and will -therefore be placed closer together.

-

Prior to invoking this algorithm, it is recommended that the -vertices be placed along the vertices of a regular n-sided polygon -via circle_layout.

-

-Returns: true if layout -was successful or false if a -negative weight cycle was detected or the graph is -disconnected.

- -

Parameters

-IN: const Graph& g -
- The graph, whose type Graph must model the - VertexListGraph, - EdgeListGraph, and - IncidenceGraph concepts. The - graph must be undirected and connected.
- Python: This parameter is named graph in Python. -
- -OUT: PositionMap position -
- This property map is used to store the position of each vertex. The - type PositionMap must be a model of Writable Property - Map, with the graph's vertex descriptor type as its key type and - Topology::point_type as its value type.
- - Python: The position map must be a vertex_point2d_map for - the graph.
- Python default: graph.get_vertex_point2d_map("position") -
- -IN: weight_map(WeightMap w_map) -
- The weight or ``length'' of each edge in the graph. The weights - must all be non-negative, and the algorithm will throw a - negative_edge - exception is one of the edges is negative. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map. The value type for this map must be - the same as the value type of the distance map.
- Default: get(edge_weight, g)
- - Python: Must be an edge_double_map for the graph.
- Python default: graph.get_edge_double_map("weight") -
- -IN: const Topology& space -
-The topology used to lay out the vertices. This parameter describes both the -size and shape of the layout area, as well as its dimensionality; up to three -dimensions are supported by the current implementation. Topologies are -described in more detail -(with a list of BGL-provided topologies) in separate -documentation. -
- -IN: EdgeOrSideLength edge_or_side_length -
-Provides either the unit length e of -an edge in the layout or the length of a side s of the display area, and must be -either boost::edge_length(e) or boost::side_length(s) , respectively. -Python: In Python, this value always refers to the side length -and may only be a double. -
- -IN: Done done -
-A 4-argument function object that is passed the current -value of delta_p (i.e., the energy of vertex p ), the vertex p , the graph g , and a boolean flag indicating whether -delta_p is the maximum energy in -the system (when true ) or the -energy of the vertex being moved. -Default: layout_tolerance instantiated over the -value type of the weight map.
-Python: Any callable Python object with an appropriate signature suffices. -
- -IN: typename property_traits<WeightMap>::value_type spring_constant -
-The constant multiplied by each spring's strength. -Larger values create systems with more energy that can take longer -to stabilize; smaller values create systems with less energy that -stabilize quickly but do not necessarily result in pleasing -layouts.
-Default: 1. -
- -IN: VertexIndexMap index -
-As a mapping from vertices to index values between 0 and -num_vertices(g) .
-Default:get(vertex_index,g). - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-Python: Unsupported parameter. -
- -UTIL/OUT: DistanceMap distance -
-This parameter will be used to store the distance from every vertex to -every other vertex, which is computed in the first stages of the -algorithm. This value's type must be a model of BasicMatrix with value type equal to -the value type of the weight map.
-Default: A vector of vectors.
-Python: Unsupported parameter. -
- -UTIL/OUT: SpringStrengthMatrix spring_strength -
- -This matrix will be used to store the strength of the spring between -every pair of vertices. This value's type must be a model of BasicMatrix with value type equal to the -value type of the weight map.
-Default: A vector of vectors of the value type of the weight map.
-Python: Unsupported parameter. -
- -UTIL: PartialDerivativeMap partial_derivatives -
-A property map that will be used to store the partial derivatives of -each vertex with respect to the vertex's current coordinates. -coordinates. This must be a -Read/Write -Property Map whose value type is Topology::point_difference_type. -The default is an iterator property map built using the graph's vertex index -map.
-Default: An iterator_property_map created from -an std::vector of Topology::point_difference_type.
-Python: Unsupported parameter. -
- -Python IN: bool progressive -
- When false, performs layout of the graph on a circle before - running the Kamada-Kawai algorithm. If true, the algorithm - is executing starting with the vertex configuration in - the position map.
- Default: False. -
- -
-
-
- - - - - -
-
- - - - - -
Copyright © 2004, 2010 Trustees of Indiana UniversityDouglas Gregor, -Indiana University (dgregor -at cs.indiana.edu)
-Andrew Lumsdaine, Indiana -University (lums@osl.iu.edu)
- - diff --git a/doc/kevin_bacon.html b/doc/kevin_bacon.html deleted file mode 100644 index 07eeaa1f6..000000000 --- a/doc/kevin_bacon.html +++ /dev/null @@ -1,317 +0,0 @@ - - - -Kevin Bacon Example - -C++ Boost - -
- -

Six Degrees of Kevin Bacon

- -

-A fun application of graph theory comes up in the popular game ``Six -Degrees of Kevin Bacon''. The idea of the game is to connect an actor -to Kevin Bacon through a trail of actors who appeared together in -movies, and do so in less than six steps. For example, Theodore -Hesburgh (President Emeritus of the University of Notre Dame) was in -the movie ``Rudy'' with the actor Gerry Becker, who was in the movie -``Sleepers'' with Kevin Bacon. Why Kevin Bacon? For some reason the -three students who invented the game, Mike Ginelli, Craig Fass, and -Brian Turtle decided that Kevin Bacon is the center of the -entertainment world. The Kevin Bacon game is quite similar to the Erdös -Number which has ``been a part of the folklore of -mathematicians throughout the world for many years''. - -

-The ``Six Degrees of Kevin Bacon'' game is really a graph problem. If -you assign each actor to a vertex, and add an edge between two actors -if they have appeared together in a movie, then you have a graph that -represents the data for this game. Then the problem of finding a trail -of actors to Kevin Bacon becomes a traditional graph problem: that of -finding a path between two vertices. Since we wish to find a -path that is shorter than six steps, ideally we would find the -shortest path between the vertices. One might think to apply -Dijkstra's shortest path algorithm to this problem, but that would be -overkill since Dijkstra's algorithm is meant for situations when each -edge has an associated length (or weight) and the goal is to find the -path with the shortest cumulative length. Since we are only concerned -with finding the shortest paths in terms of the number of edges the -breadth-first search algorithm will solve the problem (and use less -time than Dijkstra's). - -

- -

Input File and Graph Setup

- -

-For this example we will use a much smaller graph than all movies and -all actors. The full source code for this example is in examples/kevin-bacon.cpp. -We have supplied a file kevin-bacon.dat which contains a list -of actor pairs who appeared in the same movie. Each line of the file -contains an actor's name, a movie, and another actor that appeared in -the movie. The ``;'' character is used as a separator. Here is an -excerpt. - -

-

-Patrick Stewart;Prince of Egypt, The (1998);Steve Martin
-
- -

-Our first task will be to read in the file and create a graph from -it. We use a std::ifstream to input the file. - -

-

-  std::ifstream datafile("./kevin-bacon.dat");
-  if (!datafile) {
-    std::cerr << "No ./kevin-bacon.dat file" << std::endl;
-    return EXIT_FAILURE;
-  }
-
- -

-We will want to attach the actor's names to the vertices in the graph, -and the movie names to the edges. We use the property class to -specify the addition of these vertex and edge properties to the graph. -We choose to use an undirected graph, because the relationship of -actors appearing together in a movie is symmetric. - -

-

-  using namespace boost;
-  typedef adjacency_list<vecS, vecS, undirectedS,
-    property<vertex_name_t, string>,
-    property<edge_name_t, string > >
-  > Graph;
-
- -

-To access the properties, we will need to obtain property map -objects from the graph. The following code shows how this is done. - -

-

-  property_map<Graph, vertex_name_t>::type actor_name = get(vertex_name, g);
-  property_map<Graph, edge_name_t>::type connecting_movie = get(edge_name, g);
-
- -

-Next we can start to loop through the file, parsing each line into a -sequence of tokens using the Boost -Tokenizer Library. - -

-

-  for (std::string line; std::getline(datafile, line);) {
-    char_delimiters_separator<char> sep(false, "", ";");
-    tokenizer<> line_toks(line, sep);
-    ...
-  }
-
- -

-Each line of the input corresponds to an edge in the graph, with the -two actors as the vertices incident to the edge, and the movie name -will be a property attached to the edge. One challenge in creating the -graph from this format of input is that the edges are specified by a -pair of actor names. As we add vertices to the graph, we'll need to -create a map from actor names to their vertices so that later -appearances of the same actor (on a different edge) can be linked with -the correct vertex in the graph. The std::map -can be used to implement this mapping. - -

-

-  typedef graph_traits<Graph>::vertex_descriptor Vertex;
-  typedef std::map<string, Vertex> NameVertexMap;
-  NameVertexMap actors;
-
- -

-The first token will be an actor's name. If the actor is not already -in our actor's map we will add a vertex to the graph, set the name -property of the vertex, and record the vertex descriptor in the map. -If the actor is already in the graph, we will retrieve the vertex -descriptor from the map's pos iterator. - -

-

-  NameVertexMap::iterator pos;
-  bool inserted;
-  Vertex u, v;
-
-  tokenizer<>::iterator i = line_toks.begin();
-  std::string actors_name = *i++;
-
-  boost::tie(pos, inserted) = actors.insert(std::make_pair(actors_name, Vertex()));
-  if (inserted) {
-    u = add_vertex(g);
-    actor_name[u] = actors_name;
-    pos->second = u;
-  } else
-    u = pos->second;
-
- -

-The second token is the name of the movie, and the third token is the -other actor. We use the same technique as above to insert the second -actor into the graph. - -

-

-  std::string movie_name = *i++;
-
-  boost::tie(pos, inserted) = actors.insert(std::make_pair(*i, Vertex()));
-  if (inserted) {
-    v = add_vertex(g);
-    actor_name[v] = *i;
-    pos->second = v;
-  } else
-    v = pos->second;
-
- -

-The final step is to add an edge connecting the two actors, and record -the name of the connecting movie. - -

-

-  graph_traits<Graph>::edge_descriptor e;
-  boost::tie(e, inserted) = add_edge(u, v, g);
-  if (inserted)
-    connecting_movie[e] = movie_name;
-
- -

- -

A Custom Visitor Class

- -

-We create a custom visitor class to record the Kevin Bacon -numbers. The Kevin Bacon number will be the shortest distances from -each actor to Kevin Bacon. This distance has also been referred to as -the ``Bacon Number'' in memory of the ``Erdos Number'' used to rank -mathematicians according to how many publications separate them from -Paul Erdos. The shortest distance to from Kevin Bacon to each actor -will follow the breadth-first tree. The BFS algorithm identifies edges -that belong to the breadth-first tree and calls our visitor's -tree_edge function. We record the distance to the target -vertex as one plus the distance to the source vertex. - - -

-  template <typename DistanceMap>
-  class bacon_number_recorder : public default_bfs_visitor
-  {
-  public:
-    bacon_number_recorder(DistanceMap dist) : d(dist) { }
-
-    template <typename Edge, typename Graph>
-    void tree_edge(Edge e, const Graph& g) const
-    {
-      typename graph_traits<Graph>::vertex_descriptor
-	u = source(e, g), v = target(e, g);
-	d[v] = d[u] + 1;
-    }
-  private:
-      DistanceMap d;
-  };
-  // Convenience function
-  template <typename DistanceMap>
-  bacon_number_recorder<DistanceMap>
-  record_bacon_number(DistanceMap d)
-  {
-    return bacon_number_recorder<DistanceMap>(d);
-  }
-
- -

-We will use a vector to store the bacon numbers. - -

-

-  std::vector<int> bacon_number(num_vertices(g));
-
- -

Apply the Breadth-First Search

- -

-The BFS algorithm requires a source vertex as input; of course this -will be Kevin Bacon. We now call the BGL BFS algorithm, passing in the -graph, source vertex, and the visitor. - -

-

-  Vertex src = actors["Kevin Bacon"];
-  bacon_number[src] = 0;
-
-  breadth_first_search(g, src, visitor(record_bacon_number(&bacon_number[0])));
-
- -

-We can output the Bacon number for each actor simply by looping -through all the vertices in the graph and use them to index into the -bacon_number vector. - -

-

-  graph_traits<Graph>::vertex_iterator i, end;
-  for (boost::tie(i, end) = vertices(g); i != end; ++i)
-    std::cout << actor_name[*i] << "'s bacon number is "
-              << bacon_number[*i] << std::endl;
-
- -

-Note that vertex descriptor objects can not always be used as indices -into vectors or arrays such as bacon_number. This is valid -with the adjacency_list class with VertexList=vecS, -but not with other variations of adjacency_list. A more -generic way to index based on vertices is to use the ID property -map (vertex_index_t) in coordination with the iterator_property_map. - -

-Here are some excepts from the output of the program. -

-William Shatner's bacon number is 2
-Denise Richards's bacon number is 1
-Kevin Bacon's bacon number is 0
-Patrick Stewart's bacon number is 2
-Steve Martin's bacon number is 1
-...
-
- - - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - - - - - diff --git a/doc/king_ordering.html b/doc/king_ordering.html deleted file mode 100644 index 044db9e18..000000000 --- a/doc/king_ordering.html +++ /dev/null @@ -1,235 +0,0 @@ - - - - - -Boost Graph Library: King Ordering - -C++ Boost - -
- -

-(Python) -king_ordering -

- - -

-

- - - - - - - - - - -
Graphs:undirected
Properties:color, degree
Complexity:time: O(m2log(m)|E|) where m = max { degree(v) | v in V }
-
- - -
-  (1)
-  template <class IncidenceGraph, class OutputIterator,
-            class ColorMap, class DegreeMap, class VertexIndexMap>
-  OutputIterator
-  king_ordering(const IncidenceGraph& g,
-                typename graph_traits<Graph>::vertex_descriptor s,
-                OutputIterator inverse_permutation,
-                ColorMap color, DegreeMap degree, VertexIndexMap index_map);
-
-  (2)
-  template <class IncidenceGraph, class OutputIterator>
-  OutputIterator
-  king_ordering(const IncidenceGraph& g, OutputIterator inverse_permutation);
-
-  template <class IncidenceGraph, class OutputItrator, class VertexIndexMap>
-  OutputIterator
-  king_ordering(const IncidenceGraph& g, OutputIterator inverse_permutation,
-                VertexIndexMap index_map);
-
-  template <class VertexListGraph, class OutputIterator,
-            class ColorMap, class DegreeMap, class VertexIndexMap>
-  OutputIterator
-  king_ordering(const VertexListGraph& G, OutputIterator inverse_permutation,
-                ColorMap color, DegreeMap degree, VertexIndexMap index_map);
-
-  (3)
-  template <class IncidenceGraph, class OutputIterator,
-            class ColorMap, class DegreeMap, class VertexIndexMap>
-  OutputIterator
-  king_ordering(const IncidenceGraph& g,
-    		std::deque< typename
-		graph_traits<Graph>::vertex_descriptor > vertex_queue,
-                OutputIterator permutation,
-                ColorMap color, DegreeMap degree, VertexIndexMap index_map);
-
- - - -The goal of the King ordering -algorithm [62]is to reduce the bandwidth of a graph by reordering the -indices assigned to each vertex. The King ordering algorithm -works by a local minimization of the i-th bandwidths. The vertices are -basically assigned a breadth-first search order, except that at each -step, the adjacent vertices are placed in the queue in order of -increasing pseudo-degree, where pseudo-degree is defined as the number of -outgoing edges with white endpoints (vertices yet to be examined). - -

-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. -

- -

-The output of the algorithm are the vertices in the new ordering. -Storing the output into a vector gives you the -permutation from the new ordering to the old ordering. - -

-  inv_perm[new_index[u]] == u
-
- -

-Often times, it is the opposite permutation that you want, the -permutation from the old index to the new index. This can easily be -computed in the following way. -

- -
-  for (size_type i = 0; i != inv_perm.size(); ++i)
-    perm[old_index[inv_perm[i]]] = i;
-
- - - -

Parameters

- -For version 1: - - - - -For version 2: - - - - -For version 3: - - - - - -

Example

- -See example/king_ordering.cpp. - -

See Also

- -bandwidth, -and degree_property_map in boost/graph/properties.hpp. - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/known_problems.html b/doc/known_problems.html deleted file mode 100644 index c236af6ed..000000000 --- a/doc/known_problems.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -Known Problems - -C++ Boost - -
- -

Known Problems and Workarounds

- -This is a list of known problems compiling the BGL for different compilers and -versions. - -
    -
  1. The subgraph adaptor has several known problems: -
      -
    • Each instance of subgraph has its own copy of internal - vertex and edge properties. Only at the root subgraph are the - properties valid.
      • - -
    • Edge and vertex removal functions are unimplemented.
      • - -
    • The graph is required to have vertex descriptors of integral - type (that are the same as the vertex index). Practically - speaking, that means subgraph only applies to adjacency lists - with VertexListS = vecS.
      • -
    2. - -
  2. The EdgeListS parameter to the adjacency list is - essentially fixed to listS: other selectors are - unlikely to work.
    3. - -
  3. Using a GraphProperty with adjacency_list may cause a VC++ internal compiler error.
    4. -
  4. Using get(property, graph, edge) may cause a VC++ internal compiler error.
    5. -
  5. "using boost::tie;" may cause VC++ internal compiler error. -
- -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/kruskal_min_spanning_tree.html b/doc/kruskal_min_spanning_tree.html deleted file mode 100644 index 7e0ca35cc..000000000 --- a/doc/kruskal_min_spanning_tree.html +++ /dev/null @@ -1,199 +0,0 @@ - - - -Boost Graph Library: Kruskal Minimum Spanning Tree - -C++ Boost - -
- - -

-(Python) -kruskal_minimum_spanning_tree -

- -
-template <class Graph, class OutputIterator, class P, class T, class R>
-OutputIterator
-kruskal_minimum_spanning_tree(Graph& g, OutputIterator tree_edges,
-    const bgl_named_params<P, T, R>& params = all defaults);
-
- -

-The kruskal_minimum_spanning_tree() function find a minimum -spanning tree (MST) in an undirected graph with weighted edges. A MST is a -set of edges that connects all the vertices in the graph where the -total weight of the edges in the tree is minimized. For more details, -see section Minimum -Spanning Tree Problem. The edges in the MST are output to the -tree_edges output iterator. This function uses Kruskal's -algorithm to compute the MST [18,8,27,15]. -

-

-Kruskal's algorithm starts with each vertex in a tree by itself, and -with no edges in the minimum spanning tree T. The algorithm -then examines each edge in the graph in order of increasing edge -weight. If an edge connects two vertices in different trees the -algorithm merges the two trees into a single tree and adds the edge to -T. We use the ``union by rank'' and ``path compression'' -heuristics to provide fast implementations of the disjoint set -operations (MAKE-SET, FIND-SET, and -UNION-SET). The algorithm is as follows: -

- -
-KRUSKAL-MST(G, w)
-  T := Ø
-  for each vertex u in V
-    MAKE-SET(DS, u)
-  end for
-  for each edge (u,v) in E in order of nondecreasing weight
-    if FIND-SET(DS, u) != FIND-SET(DS, v)
-      UNION-SET(DS, u, v)
-      T := T U {(u,v)}
-  end for
-  return T
-
- - -

Where Defined

- -

-boost/graph/kruskal_min_spanning_tree.hpp - -

- -

Parameters

- -IN: const Graph& g -
- An undirected graph. The graph type must be a model of - Vertex List Graph - and Edge List Graph.
- - Python: The parameter is named graph. -
- -IN: OutputIterator spanning_tree_edges -
- The edges of the minimum spanning tree are output to this Output - Iterator.
- - Python: This parameter is not used in Python. Instead, a - Python list containing all of the spanning tree edges is - returned. -
- - -

Named Parameters

- -IN: weight_map(WeightMap w_map) -
-The weight or ``length'' of - each edge in the graph. The WeightMap type must be a model - of Readable - Property Map and its value type must be Less Than - Comparable. The key type of this map needs to be the graph's - edge descriptor type.
- Default: get(edge_weight, g)
- Python: Must be an edge_double_map for the graph.
- Python default: graph.get_edge_double_map("weight") -
- -UTIL: rank_map(RankMap r_map) -
- This is used by the disjoint sets data structure. - The type RankMap must be a model of Read/Write - Property Map. The vertex descriptor type of the graph needs to - be usable as the key type of the rank map. The value type of the - rank map must be an integer type.
- Default: an - iterator_property_map created from a - std::vector of the integers of size - num_vertices(g) and using the i_map for the index - map.
- - Python: Unsupported parameter. -
- -UTIL: predecessor_map(PredecessorMap p_map) -
- This is used by the disjoint sets data structure, and is not - used for storing predecessors in the spanning tree. The predecessors - of the spanning tree can be obtained from the spanning tree edges - output. The type PredecessorMap must be a model of Read/Write - Property Map. The key type value types of the predecessor map - must be the vertex descriptor type of the graph.
- Default: an - iterator_property_map created from a - std::vector of vertex descriptors of size - num_vertices(g) and using the i_map for the index - map.
- - Python: Unsupported parameter. -
- -IN: vertex_index_map(VertexIndexMap i_map) -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is only necessary if the default is used - for the rank or predecessor maps. 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 usable as the key - type of the map.
- Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- - Python: Unsupported parameter. -
- - -

Complexity

- -

-The time complexity is O(E log E) - -

Example

- -

-The file examples/kruskal-example.cpp -contains an example of using Kruskal's algorithm. - - -
-

- - -
Copyright © 2000-2001 -Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/layout_tolerance.html b/doc/layout_tolerance.html deleted file mode 100644 index 5aa5512fd..000000000 --- a/doc/layout_tolerance.html +++ /dev/null @@ -1,21 +0,0 @@ - -Struct template layout_tolerance
boost.png (6897 bytes)HomeLibrariesPeopleFAQMore

Struct template layout_tolerance

boost::layout_tolerance — Determines when to terminate layout of a particular graph based on a given relative tolerance.

Synopsis

template<typename T = double>
-struct layout_tolerance {
-  // construct/copy/destruct
-  layout_tolerance(const T & = T(0.001));
-
-  // public member functions
-  template<typename Graph>
-    bool operator()(T,
-                    typename boost::graph_traits< Graph >::vertex_descriptor,
-                    const Graph &, bool) ;
-};

Where Defined

boost/graph/kamada_kawai_spring_layout.hpp

layout_tolerance construct/copy/destruct

  1. layout_tolerance(const T & tolerance = T(0.001));

layout_tolerance public member functions

  1. template<typename Graph>
-  bool operator()(T delta_p,
-                  typename boost::graph_traits< Graph >::vertex_descriptor p,
-                  const Graph & g, bool global) ;
diff --git a/doc/leda_conversion.html b/doc/leda_conversion.html deleted file mode 100644 index c9e0e3254..000000000 --- a/doc/leda_conversion.html +++ /dev/null @@ -1,263 +0,0 @@ - - - -Boost Graph Library: Converting Existing Graphs to BGL - -C++ Boost - -
- - -

How to Convert Existing Graphs to BGL

- -

-Though the main goal of BGL is to aid the development of new -applications and graph algorithms, there are quite a few existing codes -that could benefit from using BGL algorithms. One way to use the BGL -algorithms with existing graph data structures is to copy data from -the older graph format into a BGL graph which could then be used in -the BGL algorithms. The problem with this approach is that it can be -expensive to make this copy. Another approach is to wrap the existing -graph data structure with a BGL interface. - -

-The Adaptor pattern [12] typically requires -that the adaptee object be contained inside a new class that provides the -desired interface. This containment is not required when wrapping a -graph for BGL because the BGL graph interface consists solely of -free (global) functions. Instead of creating a new graph class, you -need to overload all the free functions required by the interface. We -call this free function wrapper approach external adaptation. - -

-One of the more commonly used graph classes is the LEDA parameterized -GRAPH -class [22]. In -this section we will show how to create a BGL interface for this -class. The first question is which BGL interfaces (or concepts) we -should implement. The following concepts are straightforward and easy -to implement on top of LEDA: VertexListGraph, BidirectionalGraph, and MutableGraph. - -

-All types associated with a BGL graph class are accessed though the -graph_traits class. We can partially specialize this traits -class for the LEDA GRAPH class in the following way. The -node and edge are the LEDA types for representing -vertices and edges. The LEDA GRAPH is for directed graphs, so -we choose directed_tag for the directed_category. -The LEDA GRAPH does not automatically prevent the insertion -of parallel edges, so we choose allow_parallel_edge_tag for -the edge_parallel_category. The return type for the LEDA -function number_of_nodes() and number_of_edges() is -int, so we choose that type for the -vertices_size_type and edges_size_type of the -graph. The iterator types will be more complicated, so we leave that -for later. - -

-

-namespace boost {
-  template <class vtype, class etype>
-  struct graph_traits< GRAPH<vtype,etype> > {
-    typedef node vertex_descriptor;
-    typedef edge edge_descriptor;
-
-    // iterator typedefs...
-
-    typedef directed_tag directed_category;
-    typedef allow_parallel_edge_tag edge_parallel_category;
-    typedef int vertices_size_type;
-    typedef int edges_size_type;
-  };
-} // namespace boost
-
- -

-First we will write the source() and target() -functions of the IncidenceGraph -concept, which is part of the VertexListGraph concept. We use the -LEDA GRAPH type for the graph parameter, and use -graph_traits to specify the edge parameter and the vertex -return type. We could also just use the LEDA types node and -edge here, but it is better practice to always use -graph_traits. If there is a need to change the associated -vertex or edge type, you will only need to do it in one place, inside -the specialization of graph_traits instead of throughout your -code. LEDA provides source() and target() functions, -so we merely call them. - -

-

-namespace boost {
-  template <class vtype, class etype>
-  typename graph_traits< GRAPH<vtype,etype> >::vertex_descriptor
-  source(
-    typename graph_traits< GRAPH<vtype,etype> >::edge_descriptor e,
-    const GRAPH<vtype,etype>& g)
-  {
-    return source(e);
-  }
-
-  template <class vtype, class etype>
-  typename graph_traits< GRAPH<vtype,etype> >::vertex_descriptor
-  target(
-    typename graph_traits< GRAPH<vtype,etype> >::edge_descriptor e,
-    const GRAPH<vtype,etype>& g)
-  {
-    return target(e);
-  }
-} // namespace boost
-
- -

-The next function from IncidenceGraph that we need to -implement is out_edges(). This function returns a pair of -out-edge iterators. Since LEDA does not use STL-style iterators we -need to implement some. There is a very handy boost utility for -implementing iterators, called iterator_adaptor. Writing a -standard conforming iterator classes is actually quite difficult, -harder than you may think. With the iterator_adaptor class, -you just implement a policy class and the rest is taken care of. The -following code is the policy class for our out-edge iterator. In LEDA, -the edge object itself is used like an iterator. It has functions -Succ_Adj_Edge() and Pred_Adj_Edge() to move to the -next and previous (successor and predecessor) edge. One gotcha in -using the LEDA edge as an iterator comes up in the -dereference() function, which merely returns the edge -object. The dereference operator for standard compliant iterators must -be a const member function, which is why the edge argument is -const. However, the return type should not be const, hence the need -for const_cast. - -

-

-namespace boost {
-  struct out_edge_iterator_policies
-  {
-    static void increment(edge& e)
-    { e = Succ_Adj_Edge(e,0); }
-
-    static void decrement(edge& e)
-    { e = Pred_Adj_Edge(e,0); }
-
-    template <class Reference>
-    static Reference dereference(type<Reference>, const edge& e)
-    { return const_cast<Reference>(e); }
-
-    static bool equal(const edge& x, const edge& y)
-    { return x == y; }
-  };
-} // namespace boost
-
- -

-Now we go back to the graph_traits class, and use -iterator_adaptor to fill in the -out_edge_iterator. We use the iterator type -to specify the associated types of the iterator, including iterator -category and value type. - -

-

-  namespace boost {
-    template <class vtype, class etype>
-    struct graph_traits< GRAPH<vtype,etype> > {
-      // ...
-      typedef iterator_adaptor<edge,
-        out_edge_iterator_policies,
-        iterator<std::bidirectional_iterator_tag,edge>
-      > out_edge_iterator;
-      // ...
-    };
-  } // namespace boost
-
- -

-With the out_edge_iterator defined in graph_traits we -are ready to define the out_edges() function. The following -definition looks complicated at first glance, but it is really quite -simple. The return type should be a pair of out-edge iterators, so we -use std::pair and then graph_traits to access the -out-edge iterator types. In the body of the function we construct the -out-edge iterators by passing in the first adjacenct edge for the -begin iterator, and 0 for the end iterator (which is used in LEDA as -the end sentinel). The 0 argument to First_Adj_Edge tells -LEDA we want out-edges (and not in-edges). - -

-

-namespace boost {
-  template <class vtype, class etype>
-  inline std::pair<
-    typename graph_traits< GRAPH<vtype,etype> >::out_edge_iterator,
-    typename graph_traits< GRAPH<vtype,etype> >::out_edge_iterator >
-  out_edges(
-    typename graph_traits< GRAPH<vtype,etype> >::vertex_descriptor u,
-    const GRAPH<vtype,etype>& g)
-  {
-    typedef typename graph_traits< GRAPH<vtype,etype> >
-      ::out_edge_iterator Iter;
-    return std::make_pair( Iter(First_Adj_Edge(u,0)), Iter(0) );
-  }
-} // namespace boost
-
- -

-The rest of the iterator types and interface functions are constructed -using the same techniques as above. The complete code for the LEDA -wrapper interface is in boost/graph/leda_graph.hpp. In -the following code we use the BGL concept checks to make sure that we -correctly implemented the BGL interface. These checks do not test the -run-time behaviour of the implementation; that is tested in test/graph.cpp. - -

-

-  #include <boost/graph/graph_concepts.hpp>
-  #include <boost/graph/leda_graph.hpp>
-
-  int
-  main(int,char*[])
-  {
-    typedef GRAPH<int,int> Graph;
-    BOOST_CONCEPT_ASSERT(( VertexListGraphConcept<Graph> ));
-    BOOST_CONCEPT_ASSERT(( BidirectionalGraphConcept<Graph> ));
-    BOOST_CONCEPT_ASSERT(( MutableGraphConcept<Graph> ));
-    return 0;
-  }
-
- - - -
-
- - -
Copyright © 2000-2001 -Jeremy Siek, -Indiana University (jsiek@osl.iu.edu)
-Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Andrew Lumsdaine, -Indiana University (lums@osl.iu.edu) -
- - - diff --git a/doc/lengauer_tarjan_dominator.htm b/doc/lengauer_tarjan_dominator.htm deleted file mode 100644 index 2f1e61b5f..000000000 --- a/doc/lengauer_tarjan_dominator.htm +++ /dev/null @@ -1,183 +0,0 @@ - - - -Boost Graph Library: Lengauer-Tarjan Dominator Tree Algorithm - -C++ Boost - -
- -

-lengauer_tarjan_dominator_tree -

- - -

-

-// The simplest version:
-// Data structures for depth first search is created internally,
-// and depth first search runs internally.
-template <class Graph, class DomTreePredMap>
-void
-lengauer_tarjan_dominator_tree
-  (const Graph& g,
-   const typename graph_traits<Graph>::vertex_descriptor& entry,
-   DomTreePredMap domTreePredMap)
-
-// The version providing data structures for depth first search:
-// After calling this function,
-// user can reuse the depth first search related information
-// filled in property maps.
-template <class Graph, class IndexMap, class TimeMap, class PredMap,
-             class VertexVector, class DomTreePredMap>
-void
-lengauer_tarjan_dominator_tree
-  (const Graph& g,
-   const typename graph_traits<Graph>::vertex_descriptor& entry,
-   const IndexMap& indexMap,
-   TimeMap dfnumMap, PredMap parentMap, VertexVector& verticesByDFNum,
-   DomTreePredMap domTreePredMap)
-
-// The version without depth first search:
-// The caller should provide depth first search related information
-// evaluated before.
-template <class Graph, class IndexMap, class TimeMap, class PredMap,
-             class VertexVector, class DomTreePredMap>
-void
-lengauer_tarjan_dominator_tree_without_dfs(
-  (const Graph& g,
-   const typename graph_traits<Graph>::vertex_descriptor& entry,
-   const IndexMap& indexMap,
-   TimeMap dfnumMap, PredMap parentMap, VertexVector& verticesByDFNum,
-   DomTreePredMap domTreePredMap)
-
- -

This algorithm [65,66,67] builds the dominator tree for -directed graph. There are three options for dealing the depth first -search related values. The simplest version creates data structures -and run depth first search internally. However, chances are that a -user wants to reuse the depth first search data, so we have two -versions.

- -

A vertex u dominates a vertex v, if every path of -directed graph from the entry to v must go through u. In -the left graph of Figure 1, -vertex 1 dominates vertex 2, 3, 4, 5, 6 and 7, because we have to pass -vertex 1 to reach those vertex. Note that vertex 4 dominates vertex 6, -even though vertex 4 is a successor of vertex 6. Dominator -relationship is useful in many applications especially for compiler -optimization. We can define the immediate dominator for each vertex -such that idom(n) dominates n but does not dominate any other -dominator of n. For example, vertex 1, 3 and 4 are dominators -of vertex 6, but vertex 4 is the immediate dominator, because vertex 1 -and 3 dominates vertex 4. If we make every idom of each vertex as its -parent, we can build the dominator tree like the right part of Figure 1

- -

-
- - - - - - - -
Figure 1: -An example graph and its dominator tree.
        
-

- -

An easy way to build dominator tree is to use iterative bit vector -algorithm, but it may be slow in the worst case. We implemented -Lengauer-Tarjan algorithm whose time complexity is -O((V+E)log(V+E)).

- -

Lengauer-Tarjan algorithm utilizes two techniques. The first one -is, as an intermediate step, finding semidominator which is relatively -easier to evaluate than immediate dominator, and the second one is the -path compression. For the detail of the algorithm, see [65].

- -

Where Defined

- -boost/graph/dominator_tree.hpp - -

Parameters

- -IN: const Graph& g -
- The graph object on which the algorithm will be applied. - The type Graph must be a model of - Vertex List Graph - and Bidirectional Graph.
-
- -IN: vertex_descriptor entry -
- The entry vertex. The dominator tree will be rooted at this vertex. -
- -IN: IndexMap indexMap -
- This maps each vertex to an integer in the range [0, 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 - usable as the key type of the map. -
- -IN/OUT: TimeMap dfnumMap -
- The sequence number of depth first search. The type TimeMap must be a model of Read/Write Property Map. The vertex descriptor type of the graph needs to be usable as the key type of the TimeMap. -
- -IN/OUT: PredMap parentMap -
- The predecessor map records the parent of the depth first search tree. The PredMap type must be a Read/Write Property Map whose key and value types are the same as the vertex descriptor type of the graph. -
- -IN/OUT: VertexVector verticesByDFNum -
- The vector containing vertices in depth first search order. If we access this vector sequentially, it's equivalent to access vertices by depth first search order. -
- -OUT: DomTreePredMap domTreePredMap -
- The dominator tree where parents are each children's immediate dominator. -
- -

Complexity

- -

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

Example

- -

-See -test/dominator_tree_test.cpp for an example of using Dijkstra's -algorithm. - -
-

- - -
Copyright © 2005 -JongSoo Park, Stanford University -
- - - - diff --git a/doc/lgrind.sty b/doc/lgrind.sty deleted file mode 100644 index 3257be4d0..000000000 --- a/doc/lgrind.sty +++ /dev/null @@ -1,238 +0,0 @@ -%% -%% This is file `lgrind.sty', -%% generated with the docstrip utility. -%% -%% The original source files were: -%% -%% lgrind.dtx (with options: `package') -%% -%% LGrind is used to format source code of different programming -%% languages for LaTeX. -%% -%% LGrind is a major adaptation of Jerry Leichter's tgrind for LaTeX, -%% which was a notable improvement upon Van Jacobsen's tgrind for -%% plain TeX, which was adapted from vgrind, a troff prettyprinter. -%% -%% Author: Michael Piefel, piefel@cs.tu-berlin.de -%% Based on Van Jacobson's ``tgrindmac'', a macro package for TeX. -%% Modified, 1987 by Jerry Leichter. Put '@' in all internal names. -%% Modified, 1991 by George Reilly. Changed name from tgrind to lgrind. -%% Modified, 1995 by Michael Piefel. Made it work with \LaTeXe. -%% -1999 Hundreds of bells and whistles. No changelog here. -\NeedsTeXFormat{LaTeX2e}[1996/06/01] -\ProvidesPackage{lgrind} - [1999/05/28 v3.6 LGrind environment and supporting stuff] -%%stopzone % VIM syncing -\newcount\lc@unt -\newcount\ln@xt -\newcount\LGnuminterval -\LGnuminterval=10 -\DeclareOption{nolineno}{\LGnuminterval=50000} -\DeclareOption{lineno5}{\LGnuminterval=5} -\DeclareOption{lineno1}{\LGnuminterval=1} -\newif\ifLGleftnum -\DeclareOption{leftno}{\LGleftnumtrue} -\newskip\LGindent -\LGindent=1.0\parindent -\DeclareOption{noindent}{\LGindent=0pt} -\newif\ifLGnorules -\DeclareOption{norules}{\LGnorulestrue} -\newlength{\LGsloppy} -\setlength{\LGsloppy}{7.2pt} -\DeclareOption{fussy}{\LGsloppy=0pt} -\newcommand{\DefaultProc}{\@gobble} -\newcommand{\DefaultProcCont}{\@gobble} -\DeclareOption{procnames}{ -\renewcommand{\DefaultProc}[1]{\renewcommand{\Procname}{#1}% -\global\setbox\procbox=\hbox{\PNsize #1}} -\renewcommand{\DefaultProcCont}[1]{\renewcommand\Procname{#1} -\global\setbox\procbox=\hbox{\PNsize\dots #1}}} -\newbox\procbox -\newcommand{\Procname}{} -\newif\ifLGnoprocindex -\DeclareOption{noprocindex}{\LGnoprocindextrue} -\ProcessOptions -%\def\BGfont{\sffamily} -\def\BGfont{\ttfamily\bfseries} -\def\CMfont{\rmfamily\itshape} -\def\NOfont{\sffamily} -%\def\NOfont{\ttfamily} -%\def\KWfont{\rmfamily\bfseries} -\def\KWfont{\rmfamily\itshape\bfseries} -%\def\KWfont{\ttfamily} -%\def\STfont{\ttfamily} -\def\STfont{\rmfamily\itshape\bfseries} -%\def\TTfont{\ttfamily\upshape} -\def\TTfont{\rmfamily\itshape\bfseries} -%\def\VRfont{\ttfamily} -\def\VRfont{\rmfamily\itshape\bfseries} -\def\PNsize{\BGfont\small} -\def\LGsize{\small} -\def\LGfsize{\footnotesize} -\newif\ifLGinline -\newif\ifLGd@fault -\def\LGbegin{\ifLGinline$\hbox\else$$\vbox\fi\bgroup\LGd@faulttrue} -\def\LGend{\ifLGd@fault\egroup\ifLGinline$\else$$\fi\LGd@faultfalse\fi} -%%stopzone % VIM syncing -\newif\ifc@mment -\newif\ifstr@ng -\newif\ifright@ -\newbox\ls@far -\newbox\tb@x -\newdimen\TBw@d -\newdimen\@ts -{\catcode`\_=\active \gdef\@setunder{\let_=\sp@ce}} -\newcommand{\lgrindhead}{} -\newcommand{\lgrindfilename}{}\newcommand{\lgrindfilesize}{} -\newcommand{\lgrindmodyear}{}\newcommand{\lgrindmodmonth}{} -\newcommand{\lgrindmodday}{}\newcommand{\lgrindmodtime}{} -\newenvironment{lgrind}[1][1]{% -\def\Line##1{\L{\LB{##1}}}% -\newcommand{\Head}[1]{\gdef\lgrindhead{##1}}% -\newcommand{\File}[6]{\gdef\lgrindfilename{##1}\message{(LGround: ##1)}% - \gdef\lgrindmodyear{##2}\gdef\lgrindmodmonth{##3}% - \gdef\lgrindmodday{##4}\gdef\lgrindmodtime{##5}% - \gdef\lgrindfilesize{##6}}% -\let\Proc=\DefaultProc% -\let\ProcCont=\DefaultProcCont% -\ifLGnoprocindex% - \let\index\@gobble% -\fi% -\hfuzz=\LGsloppy -\def\NewPage{\filbreak\bigskip}% -\ifLGinline - \def\L##1{\setbox\ls@far\null{\CF\strut##1}\ignorespaces}% -\else - \let\r@ghtlno\relax\let\l@ftlno\relax - \ifnum\LGnuminterval>\z@ - \ifLGleftnum - \def\l@ftlno{\ifnum\lc@unt>\ln@xt - \global\advance\ln@xt by\LGnuminterval - \llap{{\normalfont\scriptsize\the\lc@unt\quad}}\fi} - \def\r@ghtlno{\rlap{\enspace\box\procbox}}% - \else - \def\r@ghtlno{\ifnum\lc@unt>\ln@xt - \global\advance\ln@xt by\LGnuminterval - \rlap{{\normalfont\scriptsize\enspace\the\lc@unt% - \enspace\box\procbox}} - \else\rlap{\enspace\box\procbox}\fi}% - \fi - \fi - \def\L##1{\@@par\setbox\ls@far=\null\strut - \global\advance\lc@unt by1% - \hbox to \linewidth{\hskip\LGindent\l@ftlno ##1\egroup% - \hfil\r@ghtlno}% - \ignorespaces}% -\fi -\lc@unt=#1\advance\lc@unt by-1% -\ln@xt=\LGnuminterval\advance\ln@xt by-1% -\loop\ifnum\lc@unt>\ln@xt\advance\ln@xt by\LGnuminterval\repeat% -\def\LB{\hbox\bgroup\bgroup\box\ls@far\CF\let\next=}% -\def\Tab##1{\egroup\setbox\tb@x=\lastbox\TBw@d=\wd\tb@x% - \advance\TBw@d by 1\@ts\ifdim\TBw@d>##1\@ts - \setbox\ls@far=\hbox{\box\ls@far \box\tb@x \sp@ce}\else - \setbox\ls@far=\hbox to ##1\@ts{\box\ls@far \box\tb@x \hfil}\fi\LB}% -\ifLGinline\def\sp@ce{{\hskip .3333em}}% -\else \setbox\tb@x=\hbox{\texttt{0}}% - \@ts=0.8\wd\tb@x \def\sp@ce{{\hskip 1\@ts}}\fi -\catcode`\_=\active \@setunder -\def\CF{\ifc@mment\CMfont\else\ifstr@ng\STfont\fi\fi} -\def\N##1{{\NOfont ##1}\global\futurelet\next\ic@r}% -\def\K##1{{\KWfont ##1}\global\futurelet\next\ic@r}% -\def\V##1{{\VRfont ##1}\global\futurelet\next\ic@r}% -\def\ic@r{\let\@tempa\/\ifx.\next\let\@tempa\relax% - \else\ifx,\next\let\@tempa\relax\fi\fi\@tempa}% -\def\C{\egroup\bgroup\CMfont \global\c@mmenttrue \global\right@false}% -\def\CE{\egroup\bgroup \global\c@mmentfalse}% -\def\S{\egroup\bgroup\STfont \global\str@ngtrue}% -\def\SE{\egroup\bgroup \global\str@ngfalse}% -\def\,{\relax \ifmmode\mskip\thinmuskip \else\thinspace \fi}% -\def\!{\relax \ifmmode\mskip-\thinmuskip \else\negthinspace \fi}% -%%stopzone % VIM syncing -\def\CH##1##2##3{\relax\ifmmode ##1\relax -\else\ifstr@ng ##2\relax\else$##3$\fi\fi }% -\def\|{\CH|||}% not necessary for T1 -\def\<{\CH<<<}% dto. -\def\>{\CH>>>}% dto. -\def\-{\CH---}% minus sign nicer than hyphen -\def\_{\ifstr@ng {\char'137}\else - \leavevmode \kern.06em \vbox{\hrule width.35em}% - \ifdim\fontdimen\@ne\font=\z@ \kern.06em \fi\fi }% -\def\#{{\STfont\char'043}}% -\def\2{\CH\backslash {\char'134}\backslash }% % \ -\def\3{\ifc@mment\ifright@ ''\global\right@false% - \else``\global\right@true \fi - \else{\texttt{\char'042}}\fi}% % " -\def\5{{\texttt{\char'136}}}% % ^ -\parindent\z@\parskip\z@ plus 1pt% -\bgroup\BGfont -} -{\egroup\@@par} % end of environment lgrind -\def\lgrinde{\ifLGinline\else\LGsize\fi\begin{lgrind}} -\def\endlgrinde{\end{lgrind}} -\def\lagrind{\@ifstar{\@slagrind}{\@lagrind}} - -\def\@lagrind{\@ifnextchar[{\@@lagrind}{\@@lagrind[t]}} -\def\@slagrind{\@ifnextchar[{\@@slagrind}{\@@slagrind[t]}} -\def\@@lagrind[#1]#2#3#4{% - \begin{figure}[#1] -\ifLGnorules\else\hrule\fi -\vskip .5\baselineskip -\begin{minipage}\columnwidth\LGsize\LGindent\z@ - \begin{lgrind} -\input #2\relax - \end{lgrind} -\end{minipage} -\vskip .5\baselineskip plus .5\baselineskip -\ifLGnorules\else\hrule\fi\vskip .5\baselineskip -\begingroup - \setbox\z@=\hbox{#4}% - \ifdim\wd\z@>\z@ -\caption{#3}% -\label{#4}% - \else -\captcont{#3}% - \fi -\endgroup -\vskip 2pt - \end{figure} -} -\def\@@slagrind[#1]#2#3#4{% - \begin{figure*}[#1] -\ifLGnorules\else\hrule\fi -\vskip .5\baselineskip -\begin{minipage}\linewidth\LGsize\LGindent\z@ - \begin{lgrind} -\input #2\relax - \end{lgrind} -\end{minipage} -\vskip .5\baselineskip plus .5\baselineskip -\ifLGnorules\else\hrule\fi\vskip .5\baselineskip -\begingroup - \setbox\z@=\hbox{#4}% - \ifdim\wd\z@>\z@ -\caption{#3}% -\label{#4}% - \else -\captcont{#3}% - \fi -\endgroup -\vskip 2pt - \end{figure*} -} -\def\lgrindfile#1{% - \par\addvspace{0.1in} - \ifLGnorules\else\hrule\fi - \vskip .5\baselineskip - \begingroup\LGfsize\LGindent\z@ -\begin{lgrind} - \input #1\relax -\end{lgrind} - \endgroup - \vskip .5\baselineskip - \ifLGnorules\else\hrule\fi - \addvspace{0.1in} -} -\endinput -%% -%% End of file `lgrind.sty'. diff --git a/doc/louvain_clustering.html b/doc/louvain_clustering.html deleted file mode 100644 index cf688bffb..000000000 --- a/doc/louvain_clustering.html +++ /dev/null @@ -1,256 +0,0 @@ - - - - -Boost Graph Library: Louvain Clustering - - -C++ Boost - -
- -

-louvain_clustering -

- -
-template <typename QualityFunction = newman_and_girvan,
-          typename Graph, typename ComponentMap,
-          typename WeightMap, typename URBG>
-typename property_traits<WeightMap>::value_type
-louvain_clustering(const Graph& g,
-                   ComponentMap components,
-                   const WeightMap& w,
-                   URBG&& gen,
-                   QualityFunction f = QualityFunction{},
-                   typename property_traits<WeightMap>::value_type min_improvement_inner = 0,
-                   typename property_traits<WeightMap>::value_type min_improvement_outer = 0);
-
- -

-This algorithm implements the Louvain method for community detection -[1]. It finds a partition of the vertices into communities -that approximately maximizes a quality function (by default, -Newman–Girvan -modularity). - -

The algorithm alternates two phases: -

    -
  1. Local optimization. Each vertex is moved to the neighboring - community that yields the largest improvement in the quality function. - Vertices are visited in random order and the process repeats until no - single-vertex move improves the quality by more than - min_improvement_inner. - -
  2. Aggregation. The graph is contracted by collapsing each - community into a single super-vertex. Edge weights between - super-vertices are the sums of the original inter-community edge - weights and self-loops carry the total intra-community weight. -
- -

These two phases are applied repeatedly on the coarsened graph, - discovering communities of communities, until - the quality improvement between successive levels falls below - min_improvement_outer, or the graph can no longer be - coarsened. - -

Once every level has converged, the algorithm iterates - from the coarsest aggregated graph down to the original graph to - trace assignment of vertices to communities to produce the final - community label written into components. - -

The speed of the local optimization phase depends on the quality - function's interface. A quality function that only models - - GraphPartitionQualityFunctionConcept requires a full - O(V+E) recomputation of the quality for every candidate vertex move. - A quality function that also models - - GraphPartitionQualityFunctionIncrementalConcept - evaluates each candidate move in O(1) using incremental - bookkeeping, making the total cost per vertex O(degree). - The algorithm detects which interface is available at - compile time and selects the appropriate code path automatically. - -

Where Defined

- -

-boost/graph/louvain_clustering.hpp - -

Parameters

- -IN: const Graph& g -
- An undirected graph. Must model - Vertex List Graph and - Incidence Graph. - The graph is not modified by the algorithm. - Passing a directed graph produces a compile-time error. -
- -OUT: ComponentMap components -
- Records the community each vertex belongs to. After the call, - get(components, v) returns a contiguous integer label - in the range [0, k) where k is the number of - communities found. Two vertices with the same label are in the - same community. This matches the convention used by - connected_components.
- Must model - Read/Write - Property Map with the graph's vertex descriptor as key type - and an integer type (e.g. std::size_t) as value type. -
- -IN: const WeightMap& w -
- Edge weights. Must model - Readable - Property Map with the graph's edge descriptor as key type. - Weights must be non-negative. -
- -IN: URBG&& gen -
- A random number generator used to shuffle the vertex processing - order at each pass. Any type meeting the C++ - UniformRandomBitGenerator requirements works - (e.g. std::mt19937). -
- -IN: QualityFunction f -
- An instance of the quality function to use for evaluating and - incrementally updating partition quality.
- Default: QualityFunction{} -
- -IN: weight_type min_improvement_inner -
- The inner loop (local optimization) stops when a full pass over - all vertices improves quality by less than this value.
- Default: 0 -
- -IN: weight_type min_improvement_outer -
- The outer loop (aggregation) stops when quality improves by less - than this value between successive levels.
- Default: 0 -
- -

Template Parameters

- -QualityFunction -
- The partition quality metric to maximize. Must model - - GraphPartitionQualityFunctionConcept. If it also models - - GraphPartitionQualityFunctionIncrementalConcept, the - faster incremental code path is selected automatically.
- Default: - newman_and_girvan -
- -

Return Value

-

The quality (e.g. modularity) of the best partition found. -For Newman–Girvan modularity this is a value in -[−0.5, 1). - -

Complexity

-

With the incremental quality function (the default), each local -optimization pass costs O(E) since every vertex is visited once and -each visit scans its neighbors. With a non-incremental quality function, -each candidate move requires a full O(V+E) traversal, making each pass -O(E · (V+E)). The number of passes per level and the -number of aggregation levels are both small in practice, so the -incremental path typically runs in O(E log V) overall on -sparse graphs. - -

Preconditions

- - -

Example

-
-#include <boost/graph/adjacency_list.hpp>
-#include <boost/graph/louvain_clustering.hpp>
-#include <random>
-#include <iostream>
-
-int main()
-{
-    using Graph = boost::adjacency_list<
-        boost::vecS, boost::vecS, boost::undirectedS,
-        boost::no_property,
-        boost::property<boost::edge_weight_t, double>>;
-
-    // Two triangles connected by a weak bridge
-    Graph g(6);
-    boost::add_edge(0, 1, 1.0, g);
-    boost::add_edge(1, 2, 1.0, g);
-    boost::add_edge(0, 2, 1.0, g);
-    boost::add_edge(3, 4, 1.0, g);
-    boost::add_edge(4, 5, 1.0, g);
-    boost::add_edge(3, 5, 1.0, g);
-    boost::add_edge(2, 3, 0.1, g);
-
-    std::vector<std::size_t> communities(boost::num_vertices(g));
-    auto cmap = boost::make_iterator_property_map(
-        communities.begin(), boost::get(boost::vertex_index, g));
-
-    std::mt19937 rng(42);
-    double Q = boost::louvain_clustering(
-        g, cmap, boost::get(boost::edge_weight, g), rng);
-
-    std::cout << "Modularity: " << Q << "\n";
-    for (auto v : boost::make_iterator_range(boost::vertices(g)))
-        std::cout << "  vertex " << v
-                  << " -> community " << boost::get(cmap, v) << "\n";
-}
-
- -

See Also

-

-Louvain Quality Function Concepts, -betweenness_centrality_clustering - -

References

- -

[1] V. D. Blondel, J.‑L. Guillaume, -R. Lambiotte, and E. Lefebvre, -“Fast unfolding of communities in large networks,” -Journal of Statistical Mechanics: Theory and Experiment, -vol. 2008, no. 10, P10008, 2008. -doi:10.1088/1742-5468/2008/10/P10008 - -

[2] V. A. Traag, L. Waltman, and -N. J. van Eck, -“From Louvain to Leiden: guaranteeing well-connected communities,” -Scientific Reports, vol. 9, 5233, 2019. -doi:10.1038/s41598-019-41695-z - -
-

- - -
Copyright © 2026 -Arnaud Becheler -
- - - diff --git a/doc/louvain_quality_functions.html b/doc/louvain_quality_functions.html deleted file mode 100644 index bb6662016..000000000 --- a/doc/louvain_quality_functions.html +++ /dev/null @@ -1,435 +0,0 @@ - - - - -Boost Graph Library: Louvain Quality Function Concepts - - -C++ Boost - -
- -

Louvain Quality Function Concepts

- -

-These concepts define the interface used by -louvain_clustering() -to evaluate and incrementally update partition quality. -A quality function measures how well a given partition of the -vertices splits the graph into communities. - -

Where Defined

- -

-boost/graph/louvain_quality_functions.hpp - - - -

-

-Concept GraphPartitionQualityFunctionConcept -

- -

-A type QF models this concept if it provides a -member function that evaluates the quality of a vertex partition by -traversing the graph. - -

Refinement of

- -Copy Constructible -(copying a quality function should be a lightweight operation). -The type must also be Default Constructible. - -

Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
QFA type that is a model of GraphPartitionQualityFunctionConcept.
fAn object of type QF.
GraphA type that models Vertex List Graph -and Incidence Graph.
gAn object of type const Graph&.
CommunityMapA type that models -Read/Write Property Map -with vertex descriptor as key type.
cAn object of type const CommunityMap&.
WeightMapA type that models -Readable Property Map -with edge descriptor as key type.
wAn object of type const WeightMap&.
weight_typeproperty_traits<WeightMap>::value_type
- -

Associated Types

- -none -

- -

Valid Expressions

- - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Full evaluationf.quality(g, c, w)weight_type -Evaluate the quality of the partition defined by c on -graph g with edge weights w. -Traverses the entire graph. -
- -

Concept Checking Class

- -
-  template <class QualityFunction, class Graph,
-            class CommunityMap, class WeightMap>
-  struct GraphPartitionQualityFunctionConcept
-  {
-      void constraints()
-      {
-          QualityFunction f;
-          weight_type q = f.quality(g, cmap, wmap);
-          boost::ignore_unused(q);
-      }
-      Graph g;
-      CommunityMap cmap;
-      WeightMap wmap;
-  };
-
- -

Models

- - - - - -
-

-Concept GraphPartitionQualityFunctionIncrementalConcept -

- -

Refinement of

- -GraphPartitionQualityFunctionConcept - -

-A quality function that also models this concept supports O(1) -incremental updates when a single vertex is moved between -communities. This avoids a full O(V+E) graph traversal for every -candidate move during local optimization. - -

Additional Notation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
community_typeproperty_traits<CommunityMap>::value_type
kA writable property map that maps each vertex to its weighted degree.
inA writable property map that maps each community to its internal edge weight (double-counted).
totA writable property map that maps each community to its total degree weight.
mAn object of type weight_type&. Total edge weight (half the sum of all degrees).
nAn object of type std::size_t. Number of communities.
commAn object of type community_type.
k_vAn object of type weight_type. Weighted degree of a vertex.
k_v_inAn object of type weight_type. Sum of edge weights from a vertex to vertices in comm.
w_selfAn object of type weight_type. Self-loop weight of a vertex.
- -

Associated Types

- -none -

- -

Valid Expressions

- -

-In addition to the expressions required by -GraphPartitionQualityFunctionConcept: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameExpressionReturn TypeDescription
Full evaluation with auxiliary mapsf.quality(g, c, w, k, in, tot, m)weight_type -Evaluate partition quality by traversing the graph while populating the -auxiliary maps k, in, tot, and m. -
Fast evaluation from statisticsf.quality(in, tot, m, n)weight_type -Compute quality from the incrementally maintained community-level -statistics without traversing the graph. -
Remove vertexf.remove(in, tot, comm, k_v, k_v_in, w_self)void -Update in and tot to reflect the removal of a -vertex with weighted degree k_v from community comm. -
Insert vertexf.insert(in, tot, comm, k_v, k_v_in, w_self)void -Update in and tot to reflect the insertion of a -vertex into community comm. -
Gainf.gain(tot, m, comm, k_v_in, k_v)weight_type -Compute the change in quality that would result from moving a vertex -(already removed from its old community) into community comm. -
- -

Concept Checking Class

- -
-  template <class QualityFunction, class Graph,
-            class CommunityMap, class WeightMap>
-  struct GraphPartitionQualityFunctionIncrementalConcept
-    : GraphPartitionQualityFunctionConcept<QualityFunction, Graph,
-                                           CommunityMap, WeightMap>
-  {
-      void constraints()
-      {
-          GraphPartitionQualityFunctionConcept<
-              QualityFunction, Graph, CommunityMap, WeightMap
-          >::constraints();
-
-          QualityFunction f;
-          weight_type q2 = f.quality(g, cmap, wmap, k, in, tot, m);
-          weight_type q3 = f.quality(in, tot, m, num_communities);
-          f.remove(in, tot, comm, weight_val, weight_val, weight_val);
-          f.insert(in, tot, comm, weight_val, weight_val, weight_val);
-          weight_type gain = f.gain(tot, m, comm, weight_val, weight_val);
-          boost::ignore_unused(q2, q3, gain);
-      }
-      Graph g;
-      CommunityMap cmap;
-      WeightMap wmap;
-      vector_property_map<weight_type> k;
-      associative_property_map<...> in, tot;
-      weight_type m, weight_val;
-      community_type comm;
-      std::size_t num_communities;
-  };
-
- -

Models

- - - - - -
-

-Model: newman_and_girvan -

- -

-The default quality function for -louvain_clustering(). -It implements Newman–Girvan modularity [1]: - -

-Q = (1 / 2m) ∑c -[ Σin(c) − -Σtot(c)2 / 2m ] -
- -

-where m is the total edge weight, -Σin(c) is the sum of edge weights inside community -c (counted twice, once per endpoint), and -Σtot(c) is the sum of weighted degrees of all -vertices in community c. - -

-newman_and_girvan models both -GraphPartitionQualityFunctionConcept -and -GraphPartitionQualityFunctionIncrementalConcept. - - - -

-

-Writing a Custom Quality Function -

- -

-To use a custom quality metric with -louvain_clustering(), -define a struct with the required member functions. - -

-Minimal (non-incremental): Implement only -quality(g, c, w). The algorithm will use full recomputation -at each step, which is correct but slow. - -

-struct my_quality
-{
-    template <typename Graph, typename CommunityMap, typename WeightMap>
-    typename boost::property_traits<WeightMap>::value_type
-    quality(const Graph& g, const CommunityMap& c, const WeightMap& w)
-    {
-        // compute and return your metric
-    }
-};
-
-boost::louvain_clustering<my_quality>(g, components, weights, rng);
-
- -

-Full (incremental): Also implement the three quality -overloads plus remove, insert, and -gain as member functions. The algorithm will automatically -detect this and use the fast path. - - - -

See Also

-

-louvain_clustering, -betweenness_centrality_clustering - -

References

- -

-[1] M. E. J. Newman and M. Girvan, -“Finding and evaluating community structure in networks,” -Physical Review E, vol. 69, no. 2, 026113, 2004. -doi:10.1103/PhysRevE.69.026113 - -

-[2] R. Campigotto, P. C. Céspedes, and -J. L. Guillaume, -“A generalized and adaptive method for community detection,” -2014. - -
-

- - -
Copyright © 2026 -Arnaud Becheler -
- - - diff --git a/doc/make_biconnected_planar.html b/doc/make_biconnected_planar.html deleted file mode 100644 index f86c06bed..000000000 --- a/doc/make_biconnected_planar.html +++ /dev/null @@ -1,117 +0,0 @@ - - - -Boost Graph Library: make_biconnected_planar - -C++ Boost - -
- -

make_biconnected_planar

- -

- -

-template <typename Graph, typename PlanarEmbedding, typename EdgeIndexMap, typename AddEdgeVisitor>
-void make_biconnected_planar(Graph& g, PlanarEmbedding embedding, EdgeIndexMap em, AddEdgeVisitor& vis);
-
- -

- -A graph G is biconnected if, for every pair of vertices u,v in -G, there is a cycle containing both u and v. -Alternatively, a graph is biconnected if it is connected and cannot be made -disconnected by removing any single vertex. make_biconnected_planar -takes a connected -planar graph g as input and adds zero -or more edges to make g biconnected while preserving planarity. -

-The default behavior of make_biconnected_planar is to modify the -graph g by calling add_edge(u,v,g) for every pair of -vertices (u,v) where an edge needs to be added to make g -biconnected. This behavior can be overriden by providing a vistor as the -AddEdgeVisitor parameter. The only requirement for an -AddEdgeVisitor is that it define a member function with the -following signature: -

-template <typename Graph, typename Vertex>
-void visit_vertex_pair(Vertex u, Vertex v, Graph& g);
-
-This event point can also be used as a hook to update the underlying edge -index map automatically as edges are added. See the -documentation for the AddEdgeVisitor -concept for more information. - -

Where Defined

- -

- -boost/graph/make_biconnected_planar.hpp - - -

Parameters

- -IN/OUT: Graph& g - -
-An undirected graph. The graph type must be a model of Vertex List Graph, Incidence Graph, and -a Mutable Graph
-
- -IN: PlanarEmbedding embedding - -
-A model of PlanarEmbedding. -
- -IN: EdgeIndexMap vm - -
-A Readable Property Map - that maps edges from g to distinct integers in the range -[0, num_edges(g) )
-Default: get(edge_index,g)
-
- -IN: AddEdgeVisitor - -
-A model of AddEdgeVisitor -.
-Default: default_add_edge_visitor, a class defines -visit_vertex_pair to dispatch its calls to add_edge. -
- - -

Complexity

- -On a planar graph with n vertices, make_biconnected_planar -runs in time O(n) - -

Example

- -

- -examples/make_biconnected_planar.cpp - - -

See Also

- -Planar Graphs in the Boost Graph Library - -
-
-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/make_connected.html b/doc/make_connected.html deleted file mode 100644 index 0f18e10ec..000000000 --- a/doc/make_connected.html +++ /dev/null @@ -1,116 +0,0 @@ - - - -Boost Graph Library: make_connected - -C++ Boost - -
- -

make_connected

- -

- -

-template <typename Graph, typename VertexIndexMap, typename AddEdgeVisitor>
-make_connected(Graph& g, VertexIndexMap vm, AddEdgeVisitor& vis);
-
- -

- -A undirected graph G is connected if, for every pair of vertices -u,v in G, there is a path from u to v. -make_connected adds the minimum number of edges needed to make the -input graph connected. The algorithm first identifies all of the -connected components in the graph, -then adds edges to connect those components together in a path. For example, if -a graph contains three connected components A, B, and C, -make_connected will add two edges. The two edges added might consist -of one connecting a vertex in A with a vertex in B and one -connecting a vertex in B with a vertex in C. -

-The default behavior of make_connected is to modify the graph -g by calling add_edge(u,v,g) for every pair of vertices -(u,v) where an edge needs to be added to connect g. This -behavior can be overriden by providing a vistor as the AddEdgeVisitor -parameter. The only requirement for an AddEdgeVisitor is that it -define a member function with the following signature: -

-template <typename Graph, typename Vertex>
-void visit_vertex_pair(Vertex u, Vertex v, Graph& g);
-
-This event point can also be used as a hook to update the underlying edge -index map automatically as edges are added. See the -documentation for the AddEdgeVisitor -concept for more information. - - -

Where Defined

- -

- -boost/graph/make_connected.hpp - - -

Parameters

- -IN/OUT: Graph& g - -
-An undirected graph. The graph type must be a model of Vertex List Graph, Incidence Graph, and -a Mutable Graph
-
- -IN: VertexIndexMap vm - -
-A Readable Property Map - that maps vertices from g to distinct integers in the range -[0, num_vertices(g) )
-Default: get(vertex_index,g)
-
- -IN: AddEdgeVisitor - -
-A model of AddEdgeVisitor -.
-Default: default_add_edge_visitor, a class defines -visit_vertex_pair to dispatch -its calls to add_edge. -
- - - -

Complexity

- -On a graph with n vertices and m edges, make_connected -runs in time O(n + m) - -

Example

- -

- -../example/make_connected.cpp - - -

See Also

- -Planar Graphs in the Boost Graph Library - -
-
-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/make_maximal_planar.html b/doc/make_maximal_planar.html deleted file mode 100644 index e635e583c..000000000 --- a/doc/make_maximal_planar.html +++ /dev/null @@ -1,128 +0,0 @@ - - - -Boost Graph Library: make_maximal_planar - -C++ Boost - -
- -

make_maximal_planar

- -

- -

-template <typename Graph, typename PlanarEmbedding, typename VertexIndexMap, typename EdgeIndexMap, typename AddEdgeVisitor>
-void make_maximal_planar(Graph& g, PlanarEmbedding embedding, VertexIndexMap vm, EdgeIndexMap em, AddEdgeVisitor vis);
-
- -

-A planar graph G is -maximal planar if no additional edges (except parallel edges and -self-loops) can be added to G without creating a non-planar graph. By -Euler's formula, a maximal -planar graph on n vertices (n > 2) always has 3n - 6 edges - and -2n - 4 faces. The input graph to make_maximal_planar must be a -biconnected planar graph with at -least 3 vertices. -

-The default behavior of make_maximal_planar is to modify the graph -g by calling add_edge(u,v,g) for every pair of vertices -(u,v) where an edge needs to be added to make g maximal planar. -This behavior can be overriden by providing a vistor as the -AddEdgeVisitor parameter. The only requirement for an -AddEdgeVisitor is that it define a member function with the following -signature: -

-template <typename Graph, typename Vertex>
-void visit_vertex_pair(Vertex u, Vertex v, Graph& g);
-
-This event point can also be used as a hook to update the underlying edge -index map automatically as edges are added. See the -documentation for the AddEdgeVisitor -concept for more information. - -

Where Defined

- -

- -boost/graph/make_maximal_planar.hpp - - -

Parameters

- -IN/OUT: Graph& g - -
-An undirected graph. The graph type must be a model of Vertex List Graph, Incidence Graph, and -a Mutable Graph
-
- -IN: PlanarEmbedding embedding - -
-A Readable Property Map - that models the PlanarEmbedding -concept. -
- -IN: VertexIndexMap vm - -
-A Readable Property Map - that maps vertices from g to distinct integers in the range -[0, num_vertices(g) )
-Default: get(vertex_index,g)
-
- -IN: EdgeIndexMap vm - -
-A Readable Property Map - that maps edges from g to distinct integers in the range -[0, num_edges(g) )
-Default: get(edge_index,g)
-
- -IN: AddEdgeVisitor vis - -
-A model of AddEdgeVisitor.
-Default: default_add_edge_visitor, a class defines -visit_vertex_pair to dispatch its calls to add_edge. -
- - -

Complexity

- -On a graph with n vertices and m edges, -make_maximal_planar runs in time O(n + m) - -

Example

- -

- -examples/make_maximal_planar.cpp - - -

See Also

- -Planar Graphs in the Boost Graph Library - -
-
-Copyright © 2007 Aaron Windsor ( -aaron.windsor@gmail.com) - - diff --git a/doc/math.sty b/doc/math.sty deleted file mode 100644 index b5c8c3eb5..000000000 --- a/doc/math.sty +++ /dev/null @@ -1,76 +0,0 @@ -% Style helpers for use in Math M413 - -\usepackage[leqno]{amsmath} -\usepackage{amsfonts} -\usepackage{amssymb} -\usepackage{amsthm} -\usepackage{latexsym} - -\numberwithin{equation}{section} - -\DeclareMathOperator{\suchthat}{s.t.} -\DeclareMathOperator{\st}{\;|\;} -\DeclareMathOperator{\lub}{lub} -\DeclareMathOperator{\glb}{glb} -\DeclareMathOperator{\C}{C} -\DeclareMathOperator{\Rl}{R_L} -\DeclareMathOperator{\Rm}{R_M} -\DeclareMathOperator{\Poly}{\mathcal{P}} -\DeclareMathOperator{\NPoly}{\mathcal{NP}} -\DeclareMathOperator{\outdegree}{out-degree} -\DeclareMathOperator{\indegree}{in-degree} - -% Abbreviations for Commonly used sets -\newcommand{\field}[1]{\mathbb{#1}} -\newcommand{\Q}{\field{Q}} % Rational numbers -\newcommand{\N}{\field{N}} % Natural numbers -\newcommand{\R}{\field{R}} % Real numbers -\newcommand{\Z}{\field{Z}} % Integers -\newcommand{\Zp}{\field{Z}^+} % Positive Integers - -% Theorem declarations -\theoremstyle{plain} -\newtheorem{theorem}{Theorem}[section] -\newtheorem{lemma}{Lemma}[section] -\newtheorem{correllary}{Correllary}[section] -\newtheorem{proposition}{Proposition}[section] - -\theoremstyle{definition} -\newtheorem{definition}{Definition}[section] -\newtheorem{example}{Example}[section] - -\theoremstyle{remark} -\newtheorem*{remark}{Remark} -\newtheorem*{note}{Note} -\newtheorem{case}{Case} - - -% Meaningful abbreviations, etc -\newcommand{\onlyif}{\Rightarrow} -\newcommand{\thus}{\Longrightarrow} -\newcommand{\contradicts}{\rightarrow\leftarrow} -\newcommand{\Union}{\bigcup} -\newcommand{\union}{\cup} -\newcommand{\Intersect}{\bigcap} -\newcommand{\intersect}{\cap} -\newcommand{\setdiff}{\setminus} -\newcommand{\divides}{|} -\newcommand{\Land}{\;\bigwedge\;} -\newcommand{\Lor}{\;\bigvee\;} -\newcommand{\floor}[1]{\lfloor#1\rfloor} -\newcommand{\inverse}[1]{\ensuremath\frac{1}{#1}} -\newcommand{\abs}[1]{\ensuremath \lvert#1\rvert} -\newcommand{\norm}[1]{\ensuremath \lVert#1\rVert} -\newcommand{\inner}[2]{\ensuremath #1 \cdot #2} - -\newcommand{\cross}{\times} -\newcommand{\setcomplement}[1]{\overline{#1}} -\newcommand{\emptystring}{\epsilon} -\newcommand{\concat}[2]{#1 \cdot #2} -\newcommand{\pair}[2]{\langle #1, #2 \rangle} -\newcommand{\closure}[1]{#1^*} -\newcommand{\strlen}[1]{\abs{#1}} - -\newcommand{\produce}{\rightarrow} -\newcommand{\derive}{\Rightarrow} -\newcommand{\derives}{\stackrel{*}{\Rightarrow}} diff --git a/doc/maximum_adjacency_search.html b/doc/maximum_adjacency_search.html deleted file mode 100644 index 74aedc625..000000000 --- a/doc/maximum_adjacency_search.html +++ /dev/null @@ -1,284 +0,0 @@ - - - -Boost Graph Library: Maximum Adjacency Search - -C++ Boost - -

-maximum_adjacency_search -

- -

-

-// named parameter versions
-template <class Graph, class class P, class T, class R>
-void
-maximum_adjacency_search(const Graph& g,
-       const bgl_named_params<P, T, R>& params);
-
-// non-named parameter versions
-template <class Graph, class WeightMap, class MASVisitor>
-void
-maximum_adjacency_search(const Graph& g, WeightMap weights, MASVisitor vis,
-       const typename graph_traits<Graph>::vertex_descriptor start);
-
-
- -

-The maximum_adjacency_search() function performs a traversal -of the vertices in an undirected graph. The next vertex visited is the -vertex that has the most visited neighbors at any time. In the case of -an unweighted, undirected graph, the number of visited neighbors of the -very last vertex visited in the graph is also the number of edge-disjoint -paths between that vertex and the next-to-last vertex visited. These can be -retrieved from a visitor, an example of which is in the test harness -mas_test.cpp. -

- -

-The maximum_adjacency_search() function invokes user-defined -actions at certain event-points within the algorithm. This provides a -mechanism for adapting the generic MAS algorithm to the many situations -in which it can be used. In the pseudo-code below, the event points -for MAS are the labels on the right. The user-defined actions must be -provided in the form of a visitor object, that is, an object whose type -meets the requirements for a MAS Visitor. -

- - - - - - -
-
-MAS(G)
-  for each vertex u in V
-    reach_count[u] := 0
-  end for
-  // for the starting vertex s
-  reach_count[s] := 1
-  for each unvisited vertex u in V
-    call MAS-VISIT(G, u)
-    remove u from the list on unvisited vertices
-    for each out edge from u to t
-       if t has not yet been visited
-         increment reach_count[t]
-       end if
-    end for each out edge
-    call MAS-VISIT(G, u)
-  end for each unvisited vertex
-
-
 -
--
--
-initialize vertex u
--
--
--
--
-examine vertex u
--
-examine edge (u,t)
--
--
--
--
-finish vertex u
--
-
-
- -

Where Defined

- -

-boost/graph/maximum_adjacency_search.hpp

- -

Parameters

- -IN: const UndirectedGraph& g

-
- A connected, directed graph. The graph type must - be a model of Incidence Graph - and Vertex List Graph.
-
- -

Named Parameters

- -

IN: WeightMap weights

-
- The weight or length of each edge in the graph. The - WeightMap type must be a model of - Readable - Property Map and its value type must be - Less Than Comparable and summable. The key type of this map - needs to be the graph's edge descriptor type. - Default: get(edge_weight, g)
-
- -IN: visitor(MASVisitor vis)

-
- A visitor object that is invoked inside the algorithm at the - event-points specified by the MAS Visitor concept. The visitor - object is passed by value [1].
- Default: mas_visitor<null_visitor>
-
- -IN: root_vertex(typename -graph_traits<VertexListGraph>::vertex_descriptor start)

-
- This specifies the vertex that the depth-first search should - originate from. The type is the type of a vertex descriptor for the - given graph.
- Default: *vertices(g).first
-
- -

Expert Parameters

- -

IN: vertex_index_map(VertexIndexMap vertexIndices)

-
- This maps each vertex to an integer in the range - [0, num_vertices(g)). This is only necessary if the default is - used for the assignment, index-in-heap, or distance maps. - VertexIndexMap must be a model of Readable Property - Map. The value type of the map must be an integer type. The - key type must be the graph's vertex descriptor type.
- Default: get(boost::vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
- -

UTIL: vertex_assignment_map(AssignmentMap assignments)

-
- AssignmentMap must be a model of Read/Write Property - Map. The key and value types must be the graph's vertex descriptor - type.
- Default: A boost::iterator_property_map using a - std::vector of num_vertices(g) vertex descriptors and - vertexIndices for the index map. -
- -

UTIL: max_priority_queue(MaxPriorityQueue& pq)

-
- MaxPriorityQueue must be a model of Keyed Updatable Queue and a - max- - Updatable Priority Queue. The value type must be the graph's vertex - descriptor and the key type must be the weight type. - Default: A boost::d_ary_heap_indirect using a default - index-in-heap and distance map. -
- -

UTIL: index_in_heap_map(IndexInHeapMap indicesInHeap)

-
- This parameter only has an effect when the default max-priority queue is used.
- IndexInHeapMap must be a model of Read/Write Property - Map. The key type must be the graph's vertex descriptor type. The - value type must be a size type - (typename std::vector<vertex_descriptor>::size_type).
- Default: A boost::iterator_property_map using a - std::vector of num_vertices(g) size type objects and - vertexIndices for the index map. -
- -

UTIL: distance_map(DistanceMap wAs)

-
- This parameter only has an effect when the default max-priority queue is used.
- DistanceMap must be a model of Read/Write Property - Map. The key type must be the graph's vertex descriptor type. The - value type must be the weight type - (typename boost::property_traits<WeightMap>::value_type). -
- Default: A boost::iterator_property_map using a - std::vector of num_vertices(g) weight type objects - and vertexIndices for the index map. -
- -

Returns

-

void

- -

Throws

- -

bad_graph -

- If num_vertices(g) is less than 2 -

- -

std::invalid_argument -

- If a max-priority queue is given as an argument and it is not empty -
. - -

-Complexity -

- -

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

- -

References

- - -

Visitor Event Points

- - - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference.

- -
- - -
Copyright © 2012 -Fernando Vilas -
- - - diff --git a/doc/maximum_matching.html b/doc/maximum_matching.html deleted file mode 100644 index d0d3adf49..000000000 --- a/doc/maximum_matching.html +++ /dev/null @@ -1,273 +0,0 @@ -Boost Graph Library: Maximum Cardinality Matching - -C++ Boost -
-

-Maximum Cardinality Matching -

-
-template <typename Graph, typename MateMap>
-void edmonds_maximum_cardinality_matching(const Graph& g, MateMap mate);
-
-template <typename Graph, typename MateMap, typename VertexIndexMap>
-void edmonds_maximum_cardinality_matching(const Graph& g, MateMap mate, VertexIndexMap vm);
-
-template <typename Graph, typename MateMap>
-bool checked_edmonds_maximum_cardinality_matching(const Graph& g, MateMap mate);
-
-template <typename Graph, typename MateMap, typename VertexIndexMap>
-bool checked_edmonds_maximum_cardinality_matching(const Graph& g, MateMap mate, VertexIndexMap vm);
-
-

-A matching is a subset of the edges -of a graph such that no two edges share a common vertex. -Two different matchings in the same graph are illustrated below (edges in the -matching are colored blue.) The matching on the left is a maximal matching, -meaning that its size can't be increased by adding edges. The matching on the -right is a maximum cardinality matching, meaning that is has maximum size -over all matchings in the graph. - -

- - - - - - -
-
- -

-Both edmonds_maximum_cardinality_matching and -checked_edmonds_maximum_cardinality_matching find the -maximum cardinality matching in any undirected graph. The matching is returned in a -MateMap, which is a -ReadWritePropertyMap -that maps vertices to vertices. In the mapping returned, each vertex is either mapped -to the vertex it's matched to, or to graph_traits<Graph>::null_vertex() if it -doesn't participate in the matching. If no VertexIndexMap is provided, both functions -assume that the VertexIndexMap is provided as an internal graph property accessible -by calling get(vertex_index,g). The only difference between -edmonds_maximum_cardinality_matching and -checked_edmonds_maximum_cardinality_matching is that as a final step, -the latter algorithm runs a simple verification on the matching computed and -returns true if and only if the matching is indeed -a maximum cardinality matching. - -

-Given a matching M, any vertex that isn't covered by an edge in M is called free. Any -simple path containing exactly 2n + 1 edges that starts and ends at free vertices and contains -n edges from M is called an alternating path. Given an alternating path p, all matching and -non-matching edges on p can be swapped, resulting in a new matching that's larger than the -original matching by exactly one edge. This method of incrementally increasing the size of matching, along -with the following fact, forms the basis of Edmonds' matching algorithm: - -

-An alternating path through the matching M exists if and only if M is not a maximum cardinality matching. -
- -The difficult part is, of course, finding an augmenting path whenever one exists. -The algorithm we use for finding a maximum cardinality matching consists of three basic steps: -
    -
  1. Create an initial matching. -
  2. Repeatedly find an augmenting path and use it to increase the size of the matching until no augmenting path exists. -
  3. Verify that the matching found is a maximum cardinality matching. -
- -If you use checked_edmonds_maximum_cardinality_matching or -edmonds_maximum_cardinality_matching, all three of these -steps are chosen for you, but it's easy to plug in different algorithms for these three steps -using a generic matching function discussed below - in fact, both checked_edmonds_maximum_cardinality_matching -and edmonds_maximum_cardinality_matching are just inlined specializations of this function. - -

-When quoting time bounds for algorithms, we assume that VertexIndexMap is a property map -that allows for constant-time mapping between vertices and indices (which is easily achieved if, -for instance, the vertices are stored in contiguous memory.) We use n and m to represent the size -of the vertex and edge sets, respectively, of the input graph. - -

Algorithms for Creating an Initial Matching

- - - -

Algorithms for Finding an Augmenting Path

- - - -

Verification Algorithms

- - - -Why is a verification algorithm needed? Edmonds' algorithm is fairly complex, and it's nearly -impossible for a human without a few days of spare time to figure out if the matching produced by -edmonds_matching on a graph with, say, 100 vertices and 500 edges is indeed a maximum cardinality -matching. A verification algorithm can do this mechanically, and it's much easier to verify by inspection -that the verification algorithm has been implemented correctly than it is to verify by inspection that -Edmonds' algorithm has been implemented correctly. -The Boost Graph library makes it incredibly simple to perform the subroutines needed by the verifier -(such as finding all the connected components of odd cardinality in a graph, or creating the induced graph -on all vertices with a certain label) in just a few lines of code. - -

-Understanding how the verifier works requires a few graph-theoretic facts. -Let m(G) be the size of a maximum cardinality matching in the graph G. -Denote by o(G) the number of connected components in G of odd cardinality, and for a set of -vertices X, denote by G - X the induced graph on the vertex set V(G) - X. Then the -Tutte-Berge Formula says that -

-2 * m(G) = min ( |V(G)| + |X| - o(G-X) ) -
-Where the minimum is taken over all subsets X of the vertex set V(G). A side effect of the -Edmonds Blossom-Shrinking algorithm is that it computes what is known as the Edmonds-Gallai decomposition -of a graph: it decomposes the graph into three disjoint sets of vertices, one of which achieves the minimum -in the Tutte-Berge Formula. - -An outline of our verification procedure is: - -Given a Graph g and MateMap mate, -
    -
  1. Check to make sure that mate is a valid matching on g. -
  2. Run edmonds_augmenting_path_finder once on g and mate. If it finds an augmenting -path, the matching isn't a maximum cardinality matching. Otherwise, we retrieve a copy of the vertex_state -map used by the edmonds_augmenting_path_finder. The Edmonds-Gallai decomposition tells us that the set -of vertices labeled V_ODD by the vertex_state map can be used as the set X to achieve the -minimum in the Tutte-Berge Formula. -
  3. Count the number of vertices labeled V_ODD, store this in num_odd_vertices. -
  4. Create a filtered_graph -consisting of all vertices that aren't labeled V_ODD. Count the number of odd connected components -in this graph and store the result in num_odd_connected_components. -
  5. Test to see if equality holds in the Tutte-Berge formula using |X| = num_odd_vertices and o(G-X) = num_odd_connected_components. Return true if it holds, false otherwise. -
- -Assuming these steps are implemented correctly, the verifier will never return a false positive, -and will only return a false negative if edmonds_augmenting_path_finder doesn't compute the -vertex_state map correctly, in which case the edmonds_augmenting_path_finder -isn't working correctly. - - -

Creating Your Own Matching Algorithms

- -Creating a matching algorithm is as simple as plugging the algorithms described above into a generic -matching function, which has the following signature: -
-template <typename Graph,
-	  typename MateMap,
-	  typename VertexIndexMap,
-	  template <typename, typename, typename> class AugmentingPathFinder,
-	  template <typename, typename> class InitialMatchingFinder,
-	  template <typename, typename, typename> class MatchingVerifier>
-  bool matching(const Graph& g, MateMap mate, VertexIndexMap vm)
-
-The matching functions provided for you are just inlined specializations of this function: -edmonds_maximum_cardinality_matching uses edmonds_augmenting_path_finder -as the AugmentingPathFinder, extra_greedy_matching as the InitialMatchingFinder, -and no_matching_verifier as the MatchingVerifier. -checked_edmonds_maximum_cardinality_matching uses the same parameters except that -maximum_cardinality_matching_verifier is used for the MatchingVerifier. - -

-These aren't necessarily the best choices for any situation - for example, it's been claimed in the literature -that for sparse graphs, Edmonds' algorithm converges to the maximum cardinality matching more quickly if it -isn't supplied with an intitial matching. Such an algorithm can be easily assembled by calling matching with -

-and choosing the MatchingVerifier depending on how careful you're feeling. - -

-Suppose instead that you want a relatively large matching quickly, but are not exactly interested in a maximum matching. -Both extra_greedy_matching and greedy_matching find maximal matchings, which means they're guaranteed to be at -least half the size of a maximum cardinality matching, so you could call matching with -

-The resulting algorithm will find an extra greedy matching in time O(m log n) without looking for -augmenting paths. As a bonus, the return value of this function is true if and only if the extra greedy -matching happens to be a maximum cardinality matching. - -

Where Defined

- -

-boost/graph/max_cardinality_matching.hpp - - -

Parameters

- -IN: const Graph& g -
-An undirected graph. The graph type must be a model of -Vertex and Edge List Graph and -Incidence Graph.
-
- -IN: VertexIndexMap vm -
-Must be a model of ReadablePropertyMap, mapping vertices to integer indices. -
- -OUT: MateMap mate -
-Must be a model of ReadWritePropertyMap, mapping -vertices to vertices. For any vertex v in the graph, get(mate,v) will be the vertex that v is matched to, or -graph_traits::null_vertex() if v isn't matched. -
- -

Complexity

- -

-Let m and n be the number of edges and vertices in the input graph, respectively. Assuming the -VertexIndexMap supplied allows constant-time lookups, the time complexity for both -edmonds_matching and checked_edmonds_matching is O(mn alpha(m,n)). -alpha(m,n) is a slow growing function that is at most 4 for any feasible input. -

- -

Example

- -

The file example/matching_example.cpp -contains an example. - -
-

- - -
Copyright © 2005 -Aaron Windsor (aaron.windsor@gmail.com)
-
- - diff --git a/doc/maximum_weighted_matching.html b/doc/maximum_weighted_matching.html deleted file mode 100644 index ca3f221a7..000000000 --- a/doc/maximum_weighted_matching.html +++ /dev/null @@ -1,221 +0,0 @@ -Boost Graph Library: Maximum Weighted Matching - -C++ Boost -
-

-Maximum Weighted Matching -

-
-template <typename Graph, typename MateMap>
-void maximum_weighted_matching(const Graph& g, MateMap mate);
-
-template <typename Graph, typename MateMap, typename VertexIndexMap>
-void maximum_weighted_matching(const Graph& g, MateMap mate, VertexIndexMap vm);
-
-template <typename Graph, typename MateMap, typename VertexIndexMap, typename EdgeWeightMap>
-void maximum_weighted_matching(const Graph& g, MateMap mate, VertexIndexMap vm, EdgeWeightMap weights);
-
-template <typename Graph, typename MateMap>
-void brute_force_maximum_weighted_matching(const Graph& g, MateMap mate);
-
-template <typename Graph, typename MateMap, typename VertexIndexMap>
-void brute_force_maximum_weighted_matching(const Graph& g, MateMap mate, VertexIndexMap vm);
-
-

-Before you continue, it is recommended to read -about maximal cardinality matching first. -A maximum weighted matching of an edge-weighted graph is a matching -for which the sum of the weights of the edges is maximum. -Two different matchings (edges in the matching are colored blue) in the same graph are illustrated below. -The matching on the left is a maximum cardinality matching of size 8 and a maximal -weighted matching of weight sum 30, meaning that is has maximum size over all matchings in the graph -and its weight sum can't be increased by adding edges. -The matching on the right is a maximum weighted matching of size 7 and weight sum 38, meaning that it has maximum -weight sum over all matchings in the graph. - -

- - - - - - -
-
- -

-Both maximum_weighted_matching and -brute_force_maximum_weighted_matching find a -maximum weighted matching in any undirected graph. The matching is returned in a -MateMap, which is a -ReadWritePropertyMap -that maps vertices to vertices. In the mapping returned, each vertex is either mapped -to the vertex it's matched to, or to graph_traits<Graph>::null_vertex() if it -doesn't participate in the matching. -

- -

Algorithm Description

- -

-The maximum weighted matching problem was solved by Edmonds in -[74]. -Subsequently, Gabow [75] and -Lawler [20] developed methods -to reduce the run time from O(V4) to O(V3). -The implementation of maximum_weighted_matching follows a description -of the O(V3) algorithm by Galil [77]. -

- -

-Starting from an empty matching, the algorithm repeatedly augments the matching until no further improvement is possible. -Alternating trees and blossoms are used to find an augmenting path, in a way that is similar to maximum cardinality matching. -A linear programming technique is used to ensure that the selected augmenting path has maximum weight. -This involves assigning dual variables to vertices and blossoms, and computing slack values for edges. -

- -

-The outline of the algorithm is as follows: -

- -
    -
  1. Start with an empty matching and initialize dual variables to half of the maximum edge weight.
    2. -
  2. (Labeling) Root a tree at each non-matched vertex, and proceed to construct alternating trees by labeling, using only edges with zero slack value. -If an augmenting path is found, go to step 2. If a blossom is formed, go to step 3. Otherwise, go to step 4.
    3. -
  3. (Augmentation) Find the augmenting path, tracing the path through shrunken blossoms. Augment the matching. -Deconstruct and unlabel the alternating trees traversed by the augmenting path. -Go to step 1.
    4. -
  4. (Blossoming) Identify the blossoms in the alternating cycle and shrink these into a newly formed blossom. -Return to step 1.
    5. -
  5. (Updating dual variables) Adjust the dual variables based on the primal-dual method. -If this enables further growth of the alternating trees, return to step 1. -Otherwise, halt the algorithm; the matching has maximum weight.
    6. -
- -

-The implementation deviates from the description in [77] on a few points: -

- - - -

-If edge weights are integers, the algorithm uses only integer computations. -This is achieved by internally multiplying edge weights by 2, which ensures that all dual variables are also integers. -

- -

-A brute-force implementation brute_force_maximum_weighted_matching is also provided. -This algorithm simply searches all possible matchings and selects one with the maximum weight sum. -

- -

Where Defined

- -

-boost/graph/maximum_weighted_matching.hpp -

- -

Parameters

- -IN: const Graph& g -
-An undirected graph. The graph type must be a model of -Vertex and Edge List Graph and -Incidence Graph. -The graph may not contain parallel edges. -
- -IN: VertexIndexMap vm -
-Must be a model of ReadablePropertyMap, -mapping vertices to integer indices in the range [0, num_vertices(g)). -If this parameter is not explicitly specified, it is obtained from the internal vertex property of the graph -by calling get(vertex_index, g). -
- -IN: EdgeWeightMap weights -
-Must be a model of ReadablePropertyMap, mapping edges to weights. -Edge weights must be integers or floating point values. -If this parameter is not explicitly specified, it is obtained from the internal edge property of the graph -by calling get(edge_weight, g). -
- -OUT: MateMap mate -
-Must be a model of ReadWritePropertyMap, mapping -vertices to vertices. For any vertex v in the graph, get(mate,v) will be the vertex that v is matched to, or -graph_traits::null_vertex() if v isn't matched. -
- -

Complexity

- -

-Let m and n be the number of edges and vertices in the input graph, respectively. Assuming the -VertexIndexMap and EdgeWeightMap both provide constant-time lookup, the time complexity for -maximum_weighted_matching is O(n3). -For brute_force_maximum_weighted_matching, the time complexity is exponential in m. -

- -

-Note that the best known time complexity for maximum weighted matching in general graph -is O(nm+n2log(n)) by [76], but relies on an -efficient algorithm for solving nearest ancestor problem on trees, which is not provided in Boost C++ libraries. -

- -

Example

- -

The file example/weighted_matching_example.cpp -contains an example. -

- -
- - -
Copyright © 2018, 2025 -Yi Ji (jiy@pku.edu.cn), -Joris van Rantwijk -
- - diff --git a/doc/mcgregor_common_subgraphs.html b/doc/mcgregor_common_subgraphs.html deleted file mode 100644 index a38228540..000000000 --- a/doc/mcgregor_common_subgraphs.html +++ /dev/null @@ -1,451 +0,0 @@ - - - - - Boost Graph Library: McGregor Common Subgraphs - - - - C++ Boost -
-

- mcgregor_common_subgraphs -

- 
-// named parameter version
-template <typename GraphFirst,
-          typename GraphSecond,
-          typename SubGraphCallback,
-          typename Param,
-          typename Tag,
-          typename Rest>
-  void mcgregor_common_subgraphs
-  (const GraphFirst& graph1,
-   const GraphSecond& graph2,
-   SubGraphCallback user_callback,
-   bool only_connected_subgraphs,
-   const bgl_named_params& params);
-
-// non-named parameter version
-template <typename GraphFirst,
-          typename GraphSecond,
-          typename VertexIndexMapFirst,
-          typename VertexIndexMapSecond,
-          typename EdgeEquivalencePredicate,
-          typename VertexEquivalencePredicate,
-          typename SubGraphCallback>
-  void mcgregor_common_subgraphs
-  (const GraphFirst& graph1,
-   const GraphSecond& graph2,
-   const VertexIndexMapFirst vindex_map1,
-   const VertexIndexMapSecond vindex_map2,
-   EdgeEquivalencePredicate edges_equivalent,
-   VertexEquivalencePredicate vertices_equivalent,
-   bool only_connected_subgraphs,
-   SubGraphCallback user_callback);
-
- -

- This algorithm finds all common subgraphs - between graph1 and graph2 and outputs them - to user_callback. The edges_equivalent - and vertices_equivalent predicates are used to - determine edges and vertex equivalence between the two graphs. - To use property maps for equivalence, look at - the make_property_map_equivalent - function. By - default, always_equivalent - is used, which returns true for any pair of edges or vertices. -

-

- McGregor's algorithm does a depth-first search on the space of - possible common subgraphs. At each level, every unvisited pair - of vertices from graph1 and graph2 are checked - to see if they can extend the current subgraph. This is done in - three steps (assume vertex1 is - from graph1 and vertex2 is - from graph2): -

    -
  1. - Verify that the vertex1 and vertex2 are - equivalent using the vertices_equivalent predicate. -
    2. -
  2. - For every vertex pair - (existing_vertex1, existing_vertex2) in - the current subgraph, ensure that any edges - between vertex1 and existing_vertex1 - in graph1 and between vertex2 - and existing_vertex2 in graph2 match - (i.e. either both exist of both don't exist). If both edges - exist, they are checked for equivalence using - the edges_equivalent predicate. -
    3. -
  3. - Lastly (and optionally), make sure that the new subgraph - vertex has at least one edge connecting it to the existing - subgraph. When the only_connected_subgraphs - parameter is false, this step is skipped. -
    4. -
-

- -

Where Defined

- boost/graph/mcgregor_common_subgraphs.hpp -

- All functions are defined in the boost namespace. -

- -

Parameters

- - IN: const GraphFirst& graph1 -
- The first graph of the pair to be searched. The - type GraphFirst must be a model of - Vertex List Graph - and Incidence Graph. All - parameters with a "1" - (i.e. vindex_map1, correspondence_map_1_to_2) - use this graph's vertices as keys. -
- - IN: const GraphSecond& graph2 -
- The second graph of the pair to be searched. The - type Graphsecond must be a model of - Vertex List Graph - and Incidence Graph. All - parameters with a "2" - (i.e. vindex_map2, correspondence_map_2_to_1) - use this graph's vertices as keys. -
- - IN: bool only_connected_subgraphs -
- If true, subgraphs are expanded only when matching vertices - have at least one edge connecting them to the existing subgraph. -
- - OUT: SubGraphCallback user_callback -
- A function object that will be invoked when a subgraph has been discovered. The operator() must have the following form: - 
-template <typename CorrespondenceMapFirstToSecond,
-          typename CorrespondenceMapSecondToFirst>
-bool operator()(CorrespondenceMapFirstToSecond correspondence_map_1_to_2,
-                CorrespondenceMapSecondToFirst correspondence_map_2_to_1,
-                typename graph_traits<GraphFirst>::vertices_size_type subgraph_size);
-
- Both the CorrespondenceMapFirstToSecond - and CorresondenceMapSecondToFirst types are models - of Readable - Property Map and map equivalent vertices across the two - graphs given to mcgregor_common_subgraphs. For - example, if vertex1 is - from graph1, vertex2 is from graph2, - and the vertices can be considered equivalent in the subgraph, - then get(correspondence_map_1_to_2, vertex1) will - be vertex2 and get(correspondence_map_2_to_1, - vertex2) will be vertex1. If any vertex, - say vertex1 in graph1, doesn't match a vertex - in the other graph (graph2 in this example), - then get(correspondence_map_1_to_2, vertex1) will - be graph_traits<GraphSecond>::null_vertex(). - Likewise for any un-matched vertices from graph2, - get(correspondence_map_2_to_1, vertex2) will - be graph_traits<GraphFirst>::null_vertex(). -

The subgraph_size parameter is the number - of vertices in the subgraph, or the number of matched vertex - pairs contained in the correspondence maps. This can be used to - quickly filter out subgraphs whose sizes do not fall within the - desired range.

Returning false from the - callback will abort the search immediately. Otherwise, the - entire search space will be explored [1]. -
- -

Named Parameters

- - IN: vertex_index1(VertexIndexMapFirst vindex_map1) -
- This maps each vertex to an integer in the range [0, - num_vertices(graph1)]. This is necessary for efficient storage - of the subgraphs. The type VertexIndexMapFirst must be a model of - Readable Property Map. -
- Default: get(vertex_index, graph1) -
- - IN: vertex_index2(VertexIndexMapsecond vindex_map2) -
- This maps each vertex to an integer in the range [0, - num_vertices(graph2)]. This is necessary for efficient storage - of the subgraphs. The type VertexIndexMapFirst must be a model of - Readable Property Map. -
- Default: get(vertex_index, graph2) -
- - IN: edges_equivalent(EdgeEquivalencePredicate edges_equivalent) -
- This function is used to determine if edges - between graph1 and graph2 are equivalent. - The EdgeEquivalencePredicate type must be a model - of Binary - Predicate and have argument types - of graph_traits<GraphFirst>::edge_descriptor - and graph_traits<GraphSecond>::edge_descriptor. - A return value of true indicates that the edges are - equivalent.
- Default: always_equivalent -
- - IN: vertices_equivalent(VertexEquivalencePredicate vertices_equivalent) -
- This function is used to determine if vertices - between graph1 and graph2 are equivalent. - The VertexEquivalencePredicate type must be a model - of Binary - Predicate and have argument types - of graph_traits<GraphFirst>::vertex_descriptor - and graph_traits<GraphSecond>::vertex_descriptor. - A return value of true indicates that the vertices are - equivalent.
- Default: always_equivalent -
- -

Related Functions

-

- Each mcgregor_common_subgraphs_* function below takes - the same parameters as mcgregor_common_subgraphs. -

- mcgregor_common_subgraphs_unique(...); -
- Keeps an internal cache of all discovered subgraphs and - only invokes the user_callback for unique - subgraphs. Returning false - from user_callback will terminate the search as - expected. -
- - mcgregor_common_subgraphs_maximum(...); -
- Explores the entire search space and invokes - the user_callback afterward with each of the largest - discovered subgraphs. Returning false from - the user_callback will not terminate the search - because it is invoked after the search has been completed. -
- - mcgregor_common_subgraphs_maximum_unique(...); -
- Explores the entire search space and invokes - the user_callback afterward with each of the largest, - unique discovered subgraphs. Returning false from - the user_callback will not terminate the search - because it is invoked after the search has been completed. -
- -

Utility Functions/Structs

- -property_map_equivalent<PropertyMapFirst, PropertyMapSecond>
-  make_property_map_equivalent(const PropertyMapFirst property_map1, const PropertyMapSecond property_map2); - -
- Returns a binary predicate function object - (property_map_equivalent<PropertyMapFirst, - PropertyMapSecond>) that compares vertices or edges - between graphs using property maps. If, for - example, vertex1 and vertex2 are the two - parameters given when the function object is invoked, - the operator() is effectively: - return (get(m_property_map1, vertex1) == get(m_property_map2, vertex2)); -
- - struct always_equivalent -
- A binary function object that returns true for any pair of items. -
- - -void fill_membership_map<GraphSecond>
-(const GraphFirst& graph1, const CorrespondenceMapFirstToSecond correspondence_map_1_to_2, MembershipMapFirst membership_map1); - -
- Takes a subgraph (represented as a correspondence map) and fills - the vertex membership map (vertex -> bool) (true means - the vertex is present in the subgraph). - MembershipMapFirst must - model Writable - Property Map. -
- - -typename membership_filtered_graph_traits<Graph, MembershipMap>::graph_type
-  make_membership_filtered_graph(const Graph& graph, MembershipMap& membership_map); - -
- Creates a Filtered Graph from - a subgraph, represented here as a vertex membership map (vertex - -> bool where a value of true means that the vertex is - present in the subgraph). All edges between the included - vertices are preserved. See the example section for details. -
- -

Complexity

-

- The time complexity for searching the entire space is O(V1 * - V2) where V1 is number of vertices in the first graph and - V2 is the number of vertices in the second graph. -

- -

Examples

-

- Before calling any of the mcregor_common_subgraphs - algorithms, you must create a function object to act as a callback: -

- 
-template <typename GraphFirst,
-          typename GraphSecond>
-struct print_callback {
-
-  print_callback(const GraphFirst& graph1,
-                 const GraphSecond& graph2) :
-    m_graph1(graph1), m_graph2(graph2) { }
-
-template <typename CorrespondenceMapFirstToSecond,
-          typename CorrespondenceMapSecondToFirst>
-  bool operator()(CorrespondenceMapFirstToSecond correspondence_map_1_to_2,
-                  CorrespondenceMapSecondToFirst correspondence_map_2_to_1,
-                  typename graph_traits<GraphFirst>::vertices_size_type subgraph_size) {
-
-    // Print out correspondences between vertices
-    BGL_FORALL_VERTICES_T(vertex1, m_graph1, GraphFirst) {
-
-      // Skip unmapped vertices
-      if (get(correspondence_map_1_to_2, vertex1) != graph_traits<GraphSecond>::null_vertex()) {
-        std::cout << vertex1 << " <-> " << get(correspondence_map_1_to_2, vertex1) << std::endl;
-      }
-
-    }
-
-    std::cout << "---" << std::endl;
-
-    return (true);
-  }
-
-  private:
-    const GraphFirst& m_graph1;
-    const GraphSecond& m_graph2;
-
-};
-
-// Assuming the graph types GraphFirst and GraphSecond have already been defined
-GraphFirst graph1;
-GraphSecond graph2;
-
-print_callback<GraphFirst, GraphSecond> my_callback(graph1, graph2);
-
- -

Example 1

-

- If all the vertices and edges in your graph are identical, you - can start enumerating subgraphs immediately: -

- 
-// Print out all connected common subgraphs between graph1 and graph2.
-// All vertices and edges are assumed to be equivalent and both graph1 and graph2
-// have implicit vertex index properties.
-mcgregor_common_subgraphs(graph1, graph2, true, my_callback);
-
- -

Example 2

-

- If the vertices and edges of your graphs can be differentiated - with property maps, you can use - the make_property_map_equivalent function to create a - binary predicate for vertex or edge equivalence: -

- - 
-// Assume both graphs were defined with implicit vertex name,
-// edge name, and vertex index properties
-property_map<GraphFirst, vertex_name_t> vname_map1 = get(vertex_name, graph1);
-property_map<GraphSecond, vertex_name_t> vname_map1 = get(vertex_name, graph2);
-
-property_map<GraphFirst, edge_name_t> ename_map1 = get(edge_name, graph1);
-property_map<GraphSecond, edge_name_t> ename_map1 = get(edge_name, graph2);
-
-// Print out all connected common subgraphs between graph1 and graph2.
-mcgregor_common_subgraphs(graph1, graph2, true, my_callback,
-  edges_equivalent(make_property_map_equivalent(ename_map1, ename_map2)).
-  vertices_equivalent(make_property_map_equivalent(vname_map1, vname_map2)));
-
- -

Example 3

-

- There are some helper functions that can be used to obtain a - filtered graph from the correspondence maps given in your - callback: -

- 
-// Assuming we're inside the operator() of the callback with a member variable m_graph1 representing the first graph passed to mcgregor_common_subgraphs.
-// ...
-
-// Step 1: Transform a correspondence map into a membership map. Any vertex -> bool property map will work
-typedef shared_array_property_map MembershipMap;
-MembershipMap membership_map1(num_vertices(m_graph1), get(vertex_index, m_graph1));
-
-// Fill the membership map for m_graph1. GraphSecond is the type of the second graph given to mcgregor_common_subgraphs.
-fill_membership_map<GraphSecond>(m_graph1, correspondence_map_1_to_2, membership_map1);
-
-// Step 2: Use the membership map from Step 1 to obtain a filtered graph
-typedef typename membership_filtered_graph_traits<GraphFirst, MembershipMap>::graph_type
-  MembershipFilteredGraph;
-
-MembershipFilteredGraph subgraph1 = make_membership_filtered_graph(m_graph1, membership_map1);
-
-// The filtered graph can be used like a regular BGL graph...
-BGL_FORALL_VERTICES_T(vertex1, subgraph1, MembershipFilteredGraph) {
-  std::cout << vertex1 << " is present in the subgraph of graph1" << std::endl;
-}
-
- -

Notes

-

- [1] - For mcgregor_common_subgraphs_maximum - and mcgregor_common_subgraphs_maximum_unique the entire - search space is always explored, so the return value of the - callback has no effect. -

- -
- Copyright © 2009 Trustees of Indiana University - - - diff --git a/doc/metric_tsp_approx.html b/doc/metric_tsp_approx.html deleted file mode 100644 index 40cf5b326..000000000 --- a/doc/metric_tsp_approx.html +++ /dev/null @@ -1,204 +0,0 @@ - - - -Boost Graph Library: Metric Traveling Salesperson Approximation - -C++ Boost - -
- - - -

-metric_tsp_approx -

- -

-

-template <typename VertexListGraph,
-          typename WeightMap,
-          typename VertexIndexMap,
-          typename TSPVertexVisitor>
-void metric_tsp_approx_from_vertex(
-        const VertexListGraph& g,
-        typename graph_traits<VertexListGraph>::vertex_descriptor start,
-        WeightMap weightmap,
-        VertexIndexMap indexmap,
-        TSPVertexVisitor vis)
-
-// Overloads
-template<typename VertexListGraph, typename OutputIterator>
-void metric_tsp_approx_tour(VertexListGraph& g, OutputIterator o)
-
-template<typename VertexListGraph, typename WeightMap, typename OutputIterator>
-void metric_tsp_approx_tour(VertexListGraph& g, WeightMap w,
-    OutputIterator o)
-
-template<typename VertexListGraph, typename OutputIterator>
-void metric_tsp_approx_tour_from_vertex(VertexListGraph& g,
-    typename graph_traits<VertexListGraph>::vertex_descriptor start,
-    OutputIterator o)
-
-template<typename VertexListGraph, typename WeightMap,
-    typename OutputIterator>
-void metric_tsp_approx_tour_from_vertex(VertexListGraph& g,
-    typename graph_traits<VertexListGraph>::vertex_descriptor start,
-    WeightMap w, OutputIterator o)
-
-// visitor versions
-template<typename VertexListGraph, typename TSPVertexVisitor>
-void metric_tsp_approx(VertexListGraph& g, TSPVertexVisitor vis)
-
-template<typename VertexListGraph, typename Weightmap,
-    typename VertexIndexMap, typename TSPVertexVisitor>
-void metric_tsp_approx(VertexListGraph& g, Weightmap w,
-    TSPVertexVisitor vis)
-
-template<typename VertexListGraph, typename WeightMap,
-    typename VertexIndexMap, typename TSPVertexVisitor>
-void metric_tsp_approx(VertexListGraph& g, WeightMap w, VertexIndexMap id,
-    TSPVertexVisitor vis)
-
-template<typename VertexListGraph, typename WeightMap,
-    typename TSPVertexVisitor>
-void metric_tsp_approx_from_vertex(VertexListGraph& g,
-    typename graph_traits<VertexListGraph>::vertex_descriptor start,
-    WeightMap w, TSPVertexVisitor vis)
-
-
- -

-This is a traveling salesperson heuristic for generating a tour of vertices -for a fully connected undirected graph with weighted edges that obey the triangle inequality. -The current implementation is based off of the algorithm presented in Introduction to Algorithms -on page 1029. This implementation generates solutions that are twice as long as the optimal tour in the worst case. -The pseudo-code is listed below. -

- - - - - -
-
-TSP-APPROX(G, w)
-  select a vertex r in V[G]
-  compute a minimum spanning tree T for G from root r
-    using PRIM-MST(G, r, w)
-  let L be the list of vertices visited in a preorder traversal of T
-  return (the Hamiltonian cycle H that visites the vertices in the order L)
-
-
- - -

Where Defined

- -

-boost/graph/metric_tsp_approx.hpp - -

- -

Parameters

- -IN: const Graph& g -
- An undirected graph. The type Graph must be a - model of Vertex List Graph - and Incidence Graph [2].
-
- -IN: vertex_descriptor start -
- The vertex that will be the start (and end) of the tour.
- Default: *vertices(g).first -
- -IN: WeightMap weightmap -
- The weight of each edge in the graph. - The type WeightMap must be a model of - Readable Property Map. The edge descriptor type of - the graph needs to be usable as the key type for the weight - map.
- Default: get(edge_weight, g)
-
- -IN: VertexIndexMap indexmap -
- This maps each vertex to an integer in the range [0, - num_vertices(g)). This is necessary for efficient updates of the - heap data structure when an edge is relaxed. 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 - usable as the key type of the map.
- Default: get(vertex_index, g) - Note: if you use this default, make sure your graph has - an internal vertex_index property. For example, - adjacency_list with VertexList=listS does - not have an internal vertex_index property. -
-
- -OUT: OutputIterator o -
- The OutputIterator holds the vertices of the tour. - The type OutputIterator must be a model of the - OutputIterator concept. -
- -OUT: TSPTourVisitor vis -
- Use this to specify actions that you would like to happen - when the algorithm visits a vertex of the tour. - The type TSPTourVisitor must be a model of the TSP Tour Visitor - concept. - The visitor object is passed by value [1].
-
- -

Complexity

- -

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

- -

Example

- -

-The file test/metric_tsp_approx.cpp -contains an example of using this TSP approximation algorithm. - - -

Notes

- -

[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 - passed in. Therefore you may want the visitor to hold this state by - pointer or reference. -

-

[2] - Passing an adjacency_list with a vertex not set selected by - vecS will result in O(n2) performance. -

-
- - -
Copyright © 2008 -Matyas Egyhazy -
- - - diff --git a/doc/minimum_degree_ordering.html b/doc/minimum_degree_ordering.html deleted file mode 100644 index 880839d66..000000000 --- a/doc/minimum_degree_ordering.html +++ /dev/null @@ -1,178 +0,0 @@ - - - -Boost Graph Library: Minimum Degree Ordering - -C++ Boost - -
- -

-(Python) -minimum_degree_ordering -

- - -
-  template <class AdjacencyGraph, class OutDegreeMap,
-           class InversePermutationMap,
-           class PermutationMap, class SuperNodeSizeMap, class VertexIndexMap>
-  void minimum_degree_ordering
-    (AdjacencyGraph& G,
-     OutDegreeMap outdegree,
-     InversePermutationMap inverse_perm,
-     PermutationMap perm,
-     SuperNodeSizeMap supernode_size, int delta, VertexIndexMap id)
-
- -

The minimum degree ordering algorithm [21, 35] is a fill-in -reduction matrix reordering algorithm. When solving a system of -equations such as A x = b using a sparse version of Cholesky -factorization (which is a variant of Gaussian elimination for -symmetric matrices), often times elements in the matrix that were once -zero become non-zero due to the elimination process. This is what is -referred to as "fill-in", and fill-in is bad because it -makes the matrix less sparse and therefore consume more time and space -in later stages of the elimintation and in computations that use the -resulting factorization. Now it turns out that reordering the rows of -a matrix can have a dramatic affect on the amount of fill-in that -occurs. So instead of solving A x = b, we instead solve the -reordered (but equivalent) system (P A PT)(P x) = P -b. Finding the optimal ordering is an NP-complete problem (e.i., -it can not be solved in a reasonable amount of time) so instead we -just find an ordering that is "good enough" using -heuristics. The minimum degree ordering algorithm is one such -approach. - -

-A symmetric matrix A is typically represented with an -undirected graph, however for this function we require the input to be -a directed graph. Each nonzero matrix entry A(i, j) must be -represented by two directed edges (e(i,j) and -e(j,i)) in G. - -

-The output of the algorithm are the vertices in the new ordering. -

-  inverse_perm[new_index[u]] == old_index[u]
-
-

and the permutation from the old index to the new index. -

-  perm[old_index[u]] == new_index[u]
-
-

The following equations are always held. -

-  for (size_type i = 0; i != inverse_perm.size(); ++i)
-    perm[inverse_perm[i]] == i;
-
- -

Parameters

- - - - -

Example

- -See example/minimum_degree_ordering.cpp. - - -

Implementation Notes

- -

UNDER CONSTRUCTION - -

It chooses the vertex with minimum degree in the graph at each step of -simulating Gaussian elimination process. - -

This implementation provided a number of enhancements -including mass elimination, incomplete degree update, multiple -elimination, and external degree. See [35] for a historical -survey of the minimum degree algorithm. - -

-An elimination graph Gv is obtained from the -graph G by removing vertex v and all of its incident -edges and by then adding edges to make all of the vertices adjacent to -v into a clique (that is, add an edge between each pair of -adjacent vertices if an edge doesn't already exist). - -Suppose that graph G is the graph representing the nonzero -structure of a matrix A. Then performing a step of Guassian -elimination on row i of matrix A is equivalent to - - - - - -
-

- - -
Copyright © 2001 -Lie-Quan Lee, Indiana University (llee@cs.indiana.edu)
-Jeremy Siek, Indiana University (jsiek@osl.iu.edu) -
- - - diff --git a/doc/minimum_degree_ordering.w b/doc/minimum_degree_ordering.w deleted file mode 100644 index 9de5b11de..000000000 --- a/doc/minimum_degree_ordering.w +++ /dev/null @@ -1,318 +0,0 @@ -\documentclass[11pt]{report} - -\input{defs} - - -\setlength\overfullrule{5pt} -\tolerance=10000 -\sloppy -\hfuzz=10pt - -\makeindex - -\begin{document} - -\title{An Implementation of the Multiple Minimum Degree Algorithm} -\author{Jeremy G. Siek and Lie Quan Lee} - -\maketitle - -\section{Introduction} - -The minimum degree ordering algorithm \cite{LIU:MMD,George:evolution} -reorders a matrix to reduce fill-in. Fill-in is the term used to refer -to the zero elements of a matrix that become non-zero during the -gaussian elimination process. Fill-in is bad because it makes the -matrix less sparse and therefore consume more time and space in later -stages of the elimintation and in computations that use the resulting -factorization. Reordering the rows of a matrix can have a dramatic -affect on the amount of fill-in that occurs. So instead of solving -\begin{eqnarray} -A x = b -\end{eqnarray} -we instead solve the reordered (but equivalent) system -\begin{eqnarray} -(P A P^T)(P x) = P b. -\end{eqnarray} -where $P$ is a permutation matrix. - -Finding the optimal ordering is an NP-complete problem (e.i., it can -not be solved in a reasonable amount of time) so instead we just find -an ordering that is ``good enough'' using heuristics. The minimum -degree ordering algorithm is one such approach. - -A symmetric matrix $A$ is typically represented with an undirected -graph, however for this function we require the input to be a directed -graph. Each nonzero matrix entry $A_{ij}$ must be represented by two -directed edges, $(i,j)$ and $(j,i)$, in $G$. - -An \keyword{elimination graph} $G_v$ is formed by removing vertex $v$ -and all of its incident edges from graph $G$ and then adding edges to -make the vertices adjacent to $v$ into a clique\footnote{A clique is a -complete subgraph. That is, it is a subgraph where each vertex is -adjacent to every other vertex in the subgraph}. - - -quotient graph -set of cliques in the graph - - -Mass elmination: if $y$ is selected as the minimum degree node then -the the vertices adjacent to $y$ with degree equal to $degree(y) - 1$ -can be selected next (in any order). - -Two nodes are \keyword{indistinguishable} if they have identical -neighborhood sets. That is, -\begin{eqnarray} -Adj[u] \cup \{ u \} = Adj[v] \bigcup \{ v \} -\end{eqnarray} -Nodes that are indistiguishable can be eliminated at the same time. - -A representative for a set of indistiguishable nodes is called a -\keyword{supernode}. - -incomplete degree update -external degree - - - - -\section{Algorithm Overview} - -@d MMD Algorithm Overview @{ - @ - -@} - - - - -@d Set up a mapping from integers to vertices @{ -size_type vid = 0; -typename graph_traits::vertex_iterator v, vend; -for (tie(v, vend) = vertices(G); v != vend; ++v, ++vid) - index_vertex_vec[vid] = *v; -index_vertex_map = IndexVertexMap(&index_vertex_vec[0]); -@} - - -@d Insert vertices into bucket sorter (bucket number equals degree) @{ -for (tie(v, vend) = vertices(G); v != vend; ++v) { - put(degree, *v, out_degree(*v, G)); - degreelists.push(*v); -} -@} - - -@d Eliminate isolated nodes (nodes with zero degree) @{ -typename DegreeLists::stack list_isolated = degreelists[0]; -while (!list_isolated.empty()) { - vertex_t node = list_isolated.top(); - marker.mark_done(node); - numbering(node); - numbering.increment(); - list_isolated.pop(); -} -@} - - -@d Find first non-empty degree bucket -@{ -size_type min_degree = 1; -typename DegreeLists::stack list_min_degree = degreelists[min_degree]; -while (list_min_degree.empty()) { - ++min_degree; - list_min_degree = degreelists[min_degree]; -} -@} - - - -@d Main Loop -@{ -while (!numbering.all_done()) { - eliminated_nodes = work_space.make_stack(); - if (delta >= 0) - while (true) { - @ - @