Changeset 418:ad483acf1654 in lemonmain for doc/groups.dox
 Timestamp:
 12/02/08 16:33:22 (13 years ago)
 Branch:
 default
 Children:
 419:9afe81e4c543, 420:6a2a33ad261b, 430:09e416d35896, 446:d369e885d196, 501:7f8560cb9d65
 Parents:
 413:d8b87e9b90c3 (diff), 417:6ff53afe98b5 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.  Phase:
 public
 Files:

 2 edited
Legend:
 Unmodified
 Added
 Removed

doc/groups.dox
r406 r418 60 60 61 61 <b>See also:</b> \ref graph_concepts "Graph Structure Concepts". 62 */ 63 64 /** 65 @defgroup graph_adaptors Adaptor Classes for graphs 66 @ingroup graphs 67 \brief This group contains several adaptor classes for digraphs and graphs 68 69 The main parts of LEMON are the different graph structures, generic 70 graph algorithms, graph concepts which couple these, and graph 71 adaptors. While the previous notions are more or less clear, the 72 latter one needs further explanation. Graph adaptors are graph classes 73 which serve for considering graph structures in different ways. 74 75 A short example makes this much clearer. Suppose that we have an 76 instance \c g of a directed graph type say ListDigraph and an algorithm 77 \code 78 template <typename Digraph> 79 int algorithm(const Digraph&); 80 \endcode 81 is needed to run on the reverse oriented graph. It may be expensive 82 (in time or in memory usage) to copy \c g with the reversed 83 arcs. In this case, an adaptor class is used, which (according 84 to LEMON digraph concepts) works as a digraph. The adaptor uses the 85 original digraph structure and digraph operations when methods of the 86 reversed oriented graph are called. This means that the adaptor have 87 minor memory usage, and do not perform sophisticated algorithmic 88 actions. The purpose of it is to give a tool for the cases when a 89 graph have to be used in a specific alteration. If this alteration is 90 obtained by a usual construction like filtering the arcset or 91 considering a new orientation, then an adaptor is worthwhile to use. 92 To come back to the reverse oriented graph, in this situation 93 \code 94 template<typename Digraph> class ReverseDigraph; 95 \endcode 96 template class can be used. The code looks as follows 97 \code 98 ListDigraph g; 99 ReverseDigraph<ListGraph> rg(g); 100 int result = algorithm(rg); 101 \endcode 102 After running the algorithm, the original graph \c g is untouched. 103 This techniques gives rise to an elegant code, and based on stable 104 graph adaptors, complex algorithms can be implemented easily. 105 106 In flow, circulation and bipartite matching problems, the residual 107 graph is of particular importance. Combining an adaptor implementing 108 this, shortest path algorithms and minimum mean cycle algorithms, 109 a range of weighted and cardinality optimization algorithms can be 110 obtained. For other examples, the interested user is referred to the 111 detailed documentation of particular adaptors. 112 113 The behavior of graph adaptors can be very different. Some of them keep 114 capabilities of the original graph while in other cases this would be 115 meaningless. This means that the concepts that they are models of depend 116 on the graph adaptor, and the wrapped graph(s). 117 If an arc of \c rg is deleted, this is carried out by deleting the 118 corresponding arc of \c g, thus the adaptor modifies the original graph. 119 120 But for a residual graph, this operation has no sense. 121 Let us stand one more example here to simplify your work. 122 RevGraphAdaptor has constructor 123 \code 124 ReverseDigraph(Digraph& digraph); 125 \endcode 126 This means that in a situation, when a <tt>const ListDigraph&</tt> 127 reference to a graph is given, then it have to be instantiated with 128 <tt>Digraph=const ListDigraph</tt>. 129 \code 130 int algorithm1(const ListDigraph& g) { 131 RevGraphAdaptor<const ListDigraph> rg(g); 132 return algorithm2(rg); 133 } 134 \endcode 62 135 */ 63 136 
doc/groups.dox
r416 r418 16 16 * 17 17 */ 18 19 namespace lemon { 18 20 19 21 /** … … 162 164 163 165 This group describes maps that are specifically designed to assign 164 values to the nodes and arcs of graphs. 166 values to the nodes and arcs/edges of graphs. 167 168 If you are looking for the standard graph maps (\c NodeMap, \c ArcMap, 169 \c EdgeMap), see the \ref graph_concepts "Graph Structure Concepts". 165 170 */ 166 171 … … 173 178 maps from other maps. 174 179 175 Most of them are \ref lemon::concepts::ReadMap "readonly maps".180 Most of them are \ref concepts::ReadMap "readonly maps". 176 181 They can make arithmetic and logical operations between one or two maps 177 182 (negation, shifting, addition, multiplication, logical 'and', 'or', … … 275 280 \brief Common graph search algorithms. 276 281 277 This group describes the common graph search algorithms like278 BreadthFirst Search (BFS) and DepthFirst Search (DFS).282 This group describes the common graph search algorithms, namely 283 \e breadthfirst \e search (BFS) and \e depthfirst \e search (DFS). 279 284 */ 280 285 … … 284 289 \brief Algorithms for finding shortest paths. 285 290 286 This group describes the algorithms for finding shortest paths in graphs. 291 This group describes the algorithms for finding shortest paths in digraphs. 292 293  \ref Dijkstra algorithm for finding shortest paths from a source node 294 when all arc lengths are nonnegative. 295  \ref BellmanFord "BellmanFord" algorithm for finding shortest paths 296 from a source node when arc lenghts can be either positive or negative, 297 but the digraph should not contain directed cycles with negative total 298 length. 299  \ref FloydWarshall "FloydWarshall" and \ref Johnson "Johnson" algorithms 300 for solving the \e allpairs \e shortest \e paths \e problem when arc 301 lenghts can be either positive or negative, but the digraph should 302 not contain directed cycles with negative total length. 303  \ref Suurballe A successive shortest path algorithm for finding 304 arcdisjoint paths between two nodes having minimum total length. 287 305 */ 288 306 … … 295 313 feasible circulations. 296 314 297 The maximum flow problem is to find a flow between a single source and 298 a single target that is maximum. Formally, there is a \f$G=(V,A)\f$ 299 directed graph, an \f$c_a:A\rightarrow\mathbf{R}^+_0\f$ capacity 300 function and given \f$s, t \in V\f$ source and target node. The 301 maximum flow is the \f$f_a\f$ solution of the next optimization problem: 302 303 \f[ 0 \le f_a \le c_a \f] 304 \f[ \sum_{v\in\delta^{}(u)}f_{vu}=\sum_{v\in\delta^{+}(u)}f_{uv} 305 \qquad \forall u \in V \setminus \{s,t\}\f] 306 \f[ \max \sum_{v\in\delta^{+}(s)}f_{uv}  \sum_{v\in\delta^{}(s)}f_{vu}\f] 315 The \e maximum \e flow \e problem is to find a flow of maximum value between 316 a single source and a single target. Formally, there is a \f$G=(V,A)\f$ 317 digraph, a \f$cap:A\rightarrow\mathbf{R}^+_0\f$ capacity function and 318 \f$s, t \in V\f$ source and target nodes. 319 A maximum flow is an \f$f:A\rightarrow\mathbf{R}^+_0\f$ solution of the 320 following optimization problem. 321 322 \f[ \max\sum_{a\in\delta_{out}(s)}f(a)  \sum_{a\in\delta_{in}(s)}f(a) \f] 323 \f[ \sum_{a\in\delta_{out}(v)} f(a) = \sum_{a\in\delta_{in}(v)} f(a) 324 \qquad \forall v\in V\setminus\{s,t\} \f] 325 \f[ 0 \leq f(a) \leq cap(a) \qquad \forall a\in A \f] 307 326 308 327 LEMON contains several algorithms for solving maximum flow problems: 309  \ref lemon::EdmondsKarp "EdmondsKarp"310  \ref lemon::Preflow "Goldberg's Preflow algorithm"311  \ref lemon::DinitzSleatorTarjan "Dinitz's blocking flow algorithm with dynamic trees"312  \ref lemon::GoldbergTarjan "Preflow algorithm with dynamic trees"313 314 In most cases the \ref lemon::Preflow "Preflow" algorithm provides the315 fastest method to compute the maximum flow. All impelementations316 provides functions to query the minimum cut, which is the dual linear317 pro gramming problem of the maximum flow.328  \ref EdmondsKarp EdmondsKarp algorithm. 329  \ref Preflow GoldbergTarjan's preflow pushrelabel algorithm. 330  \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees. 331  \ref GoldbergTarjan Preflow pushrelabel algorithm with dynamic trees. 332 333 In most cases the \ref Preflow "Preflow" algorithm provides the 334 fastest method for computing a maximum flow. All implementations 335 provides functions to also query the minimum cut, which is the dual 336 problem of the maximum flow. 318 337 */ 319 338 … … 326 345 This group describes the algorithms for finding minimum cost flows and 327 346 circulations. 347 348 The \e minimum \e cost \e flow \e problem is to find a feasible flow of 349 minimum total cost from a set of supply nodes to a set of demand nodes 350 in a network with capacity constraints and arc costs. 351 Formally, let \f$G=(V,A)\f$ be a digraph, 352 \f$lower, upper: A\rightarrow\mathbf{Z}^+_0\f$ denote the lower and 353 upper bounds for the flow values on the arcs, 354 \f$cost: A\rightarrow\mathbf{Z}^+_0\f$ denotes the cost per unit flow 355 on the arcs, and 356 \f$supply: V\rightarrow\mathbf{Z}\f$ denotes the supply/demand values 357 of the nodes. 358 A minimum cost flow is an \f$f:A\rightarrow\mathbf{R}^+_0\f$ solution of 359 the following optimization problem. 360 361 \f[ \min\sum_{a\in A} f(a) cost(a) \f] 362 \f[ \sum_{a\in\delta_{out}(v)} f(a)  \sum_{a\in\delta_{in}(v)} f(a) = 363 supply(v) \qquad \forall v\in V \f] 364 \f[ lower(a) \leq f(a) \leq upper(a) \qquad \forall a\in A \f] 365 366 LEMON contains several algorithms for solving minimum cost flow problems: 367  \ref CycleCanceling Cyclecanceling algorithms. 368  \ref CapacityScaling Successive shortest path algorithm with optional 369 capacity scaling. 370  \ref CostScaling Pushrelabel and augmentrelabel algorithms based on 371 cost scaling. 372  \ref NetworkSimplex Primal network simplex algorithm with various 373 pivot strategies. 328 374 */ 329 375 … … 336 382 This group describes the algorithms for finding minimum cut in graphs. 337 383 338 The minimum cutproblem is to find a nonempty and noncomplete339 \f$X\f$ subset of the vertices with minimum overall capacity on340 outgoing arcs. Formally, there is \f$G=(V,A)\f$ directed graph, an341 \f$c _a:A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum384 The \e minimum \e cut \e problem is to find a nonempty and noncomplete 385 \f$X\f$ subset of the nodes with minimum overall capacity on 386 outgoing arcs. Formally, there is a \f$G=(V,A)\f$ digraph, a 387 \f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum 342 388 cut is the \f$X\f$ solution of the next optimization problem: 343 389 344 390 \f[ \min_{X \subset V, X\not\in \{\emptyset, V\}} 345 \sum_{uv\in A, u\in X, v\not\in X}c_{uv}\f]391 \sum_{uv\in A, u\in X, v\not\in X}cap(uv) \f] 346 392 347 393 LEMON contains several algorithms related to minimum cut problems: 348 394 349  \ref lemon::HaoOrlin "HaoOrlin algorithm" to calculateminimum cut350 in directed graphs 351  \ref lemon::NagamochiIbaraki "NagamochiIbaraki algorithm" to352 calculat e minimum cut in undirected graphs353  \ref lemon::GomoryHuTree "GomoryHu tree computation" to calculate all354 pairs minimum cut in undirected graphs395  \ref HaoOrlin "HaoOrlin algorithm" for calculating minimum cut 396 in directed graphs. 397  \ref NagamochiIbaraki "NagamochiIbaraki algorithm" for 398 calculating minimum cut in undirected graphs. 399  \ref GomoryHuTree "GomoryHu tree computation" for calculating 400 allpairs minimum cut in undirected graphs. 355 401 356 402 If you want to find minimum cut just between two distinict nodes, 357 please see the \ref max_flow "Maximum Flow page".403 see the \ref max_flow "maximum flow problem". 358 404 */ 359 405 … … 394 440 graphs. The matching problems in bipartite graphs are generally 395 441 easier than in general graphs. The goal of the matching optimization 396 can be thefinding maximum cardinality, maximum weight or minimum cost442 can be finding maximum cardinality, maximum weight or minimum cost 397 443 matching. The search can be constrained to find perfect or 398 444 maximum cardinality matching. 399 445 400 LEMON contains the next algorithms: 401  \ref lemon::MaxBipartiteMatching "MaxBipartiteMatching" HopcroftKarp 402 augmenting path algorithm for calculate maximum cardinality matching in 403 bipartite graphs 404  \ref lemon::PrBipartiteMatching "PrBipartiteMatching" PushRelabel 405 algorithm for calculate maximum cardinality matching in bipartite graphs 406  \ref lemon::MaxWeightedBipartiteMatching "MaxWeightedBipartiteMatching" 407 Successive shortest path algorithm for calculate maximum weighted matching 408 and maximum weighted bipartite matching in bipartite graph 409  \ref lemon::MinCostMaxBipartiteMatching "MinCostMaxBipartiteMatching" 410 Successive shortest path algorithm for calculate minimum cost maximum 411 matching in bipartite graph 412  \ref lemon::MaxMatching "MaxMatching" Edmond's blossom shrinking algorithm 413 for calculate maximum cardinality matching in general graph 414  \ref lemon::MaxWeightedMatching "MaxWeightedMatching" Edmond's blossom 415 shrinking algorithm for calculate maximum weighted matching in general 416 graph 417  \ref lemon::MaxWeightedPerfectMatching "MaxWeightedPerfectMatching" 418 Edmond's blossom shrinking algorithm for calculate maximum weighted 419 perfect matching in general graph 446 The matching algorithms implemented in LEMON: 447  \ref MaxBipartiteMatching HopcroftKarp augmenting path algorithm 448 for calculating maximum cardinality matching in bipartite graphs. 449  \ref PrBipartiteMatching Pushrelabel algorithm 450 for calculating maximum cardinality matching in bipartite graphs. 451  \ref MaxWeightedBipartiteMatching 452 Successive shortest path algorithm for calculating maximum weighted 453 matching and maximum weighted bipartite matching in bipartite graphs. 454  \ref MinCostMaxBipartiteMatching 455 Successive shortest path algorithm for calculating minimum cost maximum 456 matching in bipartite graphs. 457  \ref MaxMatching Edmond's blossom shrinking algorithm for calculating 458 maximum cardinality matching in general graphs. 459  \ref MaxWeightedMatching Edmond's blossom shrinking algorithm for calculating 460 maximum weighted matching in general graphs. 461  \ref MaxWeightedPerfectMatching 462 Edmond's blossom shrinking algorithm for calculating maximum weighted 463 perfect matching in general graphs. 420 464 421 465 \image html bipartite_matching.png … … 429 473 430 474 This group describes the algorithms for finding a minimum cost spanning 431 tree in a graph 475 tree in a graph. 432 476 */ 433 477 … … 620 664 \anchor demoprograms 621 665 622 @defgroup demos Demo programs666 @defgroup demos Demo Programs 623 667 624 668 Some demo programs are listed here. Their full source codes can be found in … … 630 674 631 675 /** 632 @defgroup tools Standalone utility applications676 @defgroup tools Standalone Utility Applications 633 677 634 678 Some utility applications are listed here. … … 638 682 */ 639 683 684 }
Note: See TracChangeset
for help on using the changeset viewer.