1 | /* -*- mode: C++; indent-tabs-mode: nil; -*- |
---|
2 | * |
---|
3 | * This file is a part of LEMON, a generic C++ optimization library. |
---|
4 | * |
---|
5 | * Copyright (C) 2003-2013 |
---|
6 | * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport |
---|
7 | * (Egervary Research Group on Combinatorial Optimization, EGRES). |
---|
8 | * |
---|
9 | * Permission to use, modify and distribute this software is granted |
---|
10 | * provided that this copyright notice appears in all copies. For |
---|
11 | * precise terms see the accompanying LICENSE file. |
---|
12 | * |
---|
13 | * This software is provided "AS IS" with no warranty of any kind, |
---|
14 | * express or implied, and with no claim as to its suitability for any |
---|
15 | * purpose. |
---|
16 | * |
---|
17 | */ |
---|
18 | |
---|
19 | namespace lemon { |
---|
20 | |
---|
21 | /** |
---|
22 | @defgroup datas Data Structures |
---|
23 | This group contains the several data structures implemented in LEMON. |
---|
24 | */ |
---|
25 | |
---|
26 | /** |
---|
27 | @defgroup graphs Graph Structures |
---|
28 | @ingroup datas |
---|
29 | \brief Graph structures implemented in LEMON. |
---|
30 | |
---|
31 | The implementation of combinatorial algorithms heavily relies on |
---|
32 | efficient graph implementations. LEMON offers data structures which are |
---|
33 | planned to be easily used in an experimental phase of implementation studies, |
---|
34 | and thereafter the program code can be made efficient by small modifications. |
---|
35 | |
---|
36 | The most efficient implementation of diverse applications require the |
---|
37 | usage of different physical graph implementations. These differences |
---|
38 | appear in the size of graph we require to handle, memory or time usage |
---|
39 | limitations or in the set of operations through which the graph can be |
---|
40 | accessed. LEMON provides several physical graph structures to meet |
---|
41 | the diverging requirements of the possible users. In order to save on |
---|
42 | running time or on memory usage, some structures may fail to provide |
---|
43 | some graph features like arc/edge or node deletion. |
---|
44 | |
---|
45 | Alteration of standard containers need a very limited number of |
---|
46 | operations, these together satisfy the everyday requirements. |
---|
47 | In the case of graph structures, different operations are needed which do |
---|
48 | not alter the physical graph, but gives another view. If some nodes or |
---|
49 | arcs have to be hidden or the reverse oriented graph have to be used, then |
---|
50 | this is the case. It also may happen that in a flow implementation |
---|
51 | the residual graph can be accessed by another algorithm, or a node-set |
---|
52 | is to be shrunk for another algorithm. |
---|
53 | LEMON also provides a variety of graphs for these requirements called |
---|
54 | \ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only |
---|
55 | in conjunction with other graph representations. |
---|
56 | |
---|
57 | You are free to use the graph structure that fit your requirements |
---|
58 | the best, most graph algorithms and auxiliary data structures can be used |
---|
59 | with any graph structure. |
---|
60 | |
---|
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 Adaptor classes for digraphs and graphs |
---|
68 | |
---|
69 | This group contains several useful adaptor classes for digraphs and graphs. |
---|
70 | |
---|
71 | The main parts of LEMON are the different graph structures, generic |
---|
72 | graph algorithms, graph concepts, which couple them, and graph |
---|
73 | adaptors. While the previous notions are more or less clear, the |
---|
74 | latter one needs further explanation. Graph adaptors are graph classes |
---|
75 | which serve for considering graph structures in different ways. |
---|
76 | |
---|
77 | A short example makes this much clearer. Suppose that we have an |
---|
78 | instance \c g of a directed graph type, say ListDigraph and an algorithm |
---|
79 | \code |
---|
80 | template <typename Digraph> |
---|
81 | int algorithm(const Digraph&); |
---|
82 | \endcode |
---|
83 | is needed to run on the reverse oriented graph. It may be expensive |
---|
84 | (in time or in memory usage) to copy \c g with the reversed |
---|
85 | arcs. In this case, an adaptor class is used, which (according |
---|
86 | to LEMON \ref concepts::Digraph "digraph concepts") works as a digraph. |
---|
87 | The adaptor uses the original digraph structure and digraph operations when |
---|
88 | methods of the reversed oriented graph are called. This means that the adaptor |
---|
89 | have minor memory usage, and do not perform sophisticated algorithmic |
---|
90 | actions. The purpose of it is to give a tool for the cases when a |
---|
91 | graph have to be used in a specific alteration. If this alteration is |
---|
92 | obtained by a usual construction like filtering the node or the arc set or |
---|
93 | considering a new orientation, then an adaptor is worthwhile to use. |
---|
94 | To come back to the reverse oriented graph, in this situation |
---|
95 | \code |
---|
96 | template<typename Digraph> class ReverseDigraph; |
---|
97 | \endcode |
---|
98 | template class can be used. The code looks as follows |
---|
99 | \code |
---|
100 | ListDigraph g; |
---|
101 | ReverseDigraph<ListDigraph> rg(g); |
---|
102 | int result = algorithm(rg); |
---|
103 | \endcode |
---|
104 | During running the algorithm, the original digraph \c g is untouched. |
---|
105 | This techniques give rise to an elegant code, and based on stable |
---|
106 | graph adaptors, complex algorithms can be implemented easily. |
---|
107 | |
---|
108 | In flow, circulation and matching problems, the residual |
---|
109 | graph is of particular importance. Combining an adaptor implementing |
---|
110 | this with shortest path algorithms or minimum mean cycle algorithms, |
---|
111 | a range of weighted and cardinality optimization algorithms can be |
---|
112 | obtained. For other examples, the interested user is referred to the |
---|
113 | detailed documentation of particular adaptors. |
---|
114 | |
---|
115 | Since the adaptor classes conform to the \ref graph_concepts "graph concepts", |
---|
116 | an adaptor can even be applied to another one. |
---|
117 | The following image illustrates a situation when a \ref SubDigraph adaptor |
---|
118 | is applied on a digraph and \ref Undirector is applied on the subgraph. |
---|
119 | |
---|
120 | \image html adaptors2.png |
---|
121 | \image latex adaptors2.eps "Using graph adaptors" width=\textwidth |
---|
122 | |
---|
123 | The behavior of graph adaptors can be very different. Some of them keep |
---|
124 | capabilities of the original graph while in other cases this would be |
---|
125 | meaningless. This means that the concepts that they meet depend |
---|
126 | on the graph adaptor, and the wrapped graph. |
---|
127 | For example, if an arc of a reversed digraph is deleted, this is carried |
---|
128 | out by deleting the corresponding arc of the original digraph, thus the |
---|
129 | adaptor modifies the original digraph. |
---|
130 | However in case of a residual digraph, this operation has no sense. |
---|
131 | |
---|
132 | Let us stand one more example here to simplify your work. |
---|
133 | ReverseDigraph has constructor |
---|
134 | \code |
---|
135 | ReverseDigraph(Digraph& digraph); |
---|
136 | \endcode |
---|
137 | This means that in a situation, when a <tt>const %ListDigraph&</tt> |
---|
138 | reference to a graph is given, then it have to be instantiated with |
---|
139 | <tt>Digraph=const %ListDigraph</tt>. |
---|
140 | \code |
---|
141 | int algorithm1(const ListDigraph& g) { |
---|
142 | ReverseDigraph<const ListDigraph> rg(g); |
---|
143 | return algorithm2(rg); |
---|
144 | } |
---|
145 | \endcode |
---|
146 | */ |
---|
147 | |
---|
148 | /** |
---|
149 | @defgroup maps Maps |
---|
150 | @ingroup datas |
---|
151 | \brief Map structures implemented in LEMON. |
---|
152 | |
---|
153 | This group contains the map structures implemented in LEMON. |
---|
154 | |
---|
155 | LEMON provides several special purpose maps and map adaptors that e.g. combine |
---|
156 | new maps from existing ones. |
---|
157 | |
---|
158 | <b>See also:</b> \ref map_concepts "Map Concepts". |
---|
159 | */ |
---|
160 | |
---|
161 | /** |
---|
162 | @defgroup graph_maps Graph Maps |
---|
163 | @ingroup maps |
---|
164 | \brief Special graph-related maps. |
---|
165 | |
---|
166 | This group contains maps that are specifically designed to assign |
---|
167 | values to the nodes and arcs/edges of graphs. |
---|
168 | |
---|
169 | If you are looking for the standard graph maps (\c NodeMap, \c ArcMap, |
---|
170 | \c EdgeMap), see the \ref graph_concepts "Graph Structure Concepts". |
---|
171 | */ |
---|
172 | |
---|
173 | /** |
---|
174 | \defgroup map_adaptors Map Adaptors |
---|
175 | \ingroup maps |
---|
176 | \brief Tools to create new maps from existing ones |
---|
177 | |
---|
178 | This group contains map adaptors that are used to create "implicit" |
---|
179 | maps from other maps. |
---|
180 | |
---|
181 | Most of them are \ref concepts::ReadMap "read-only maps". |
---|
182 | They can make arithmetic and logical operations between one or two maps |
---|
183 | (negation, shifting, addition, multiplication, logical 'and', 'or', |
---|
184 | 'not' etc.) or e.g. convert a map to another one of different Value type. |
---|
185 | |
---|
186 | The typical usage of this classes is passing implicit maps to |
---|
187 | algorithms. If a function type algorithm is called then the function |
---|
188 | type map adaptors can be used comfortable. For example let's see the |
---|
189 | usage of map adaptors with the \c graphToEps() function. |
---|
190 | \code |
---|
191 | Color nodeColor(int deg) { |
---|
192 | if (deg >= 2) { |
---|
193 | return Color(0.5, 0.0, 0.5); |
---|
194 | } else if (deg == 1) { |
---|
195 | return Color(1.0, 0.5, 1.0); |
---|
196 | } else { |
---|
197 | return Color(0.0, 0.0, 0.0); |
---|
198 | } |
---|
199 | } |
---|
200 | |
---|
201 | Digraph::NodeMap<int> degree_map(graph); |
---|
202 | |
---|
203 | graphToEps(graph, "graph.eps") |
---|
204 | .coords(coords).scaleToA4().undirected() |
---|
205 | .nodeColors(composeMap(functorToMap(nodeColor), degree_map)) |
---|
206 | .run(); |
---|
207 | \endcode |
---|
208 | The \c functorToMap() function makes an \c int to \c Color map from the |
---|
209 | \c nodeColor() function. The \c composeMap() compose the \c degree_map |
---|
210 | and the previously created map. The composed map is a proper function to |
---|
211 | get the color of each node. |
---|
212 | |
---|
213 | The usage with class type algorithms is little bit harder. In this |
---|
214 | case the function type map adaptors can not be used, because the |
---|
215 | function map adaptors give back temporary objects. |
---|
216 | \code |
---|
217 | Digraph graph; |
---|
218 | |
---|
219 | typedef Digraph::ArcMap<double> DoubleArcMap; |
---|
220 | DoubleArcMap length(graph); |
---|
221 | DoubleArcMap speed(graph); |
---|
222 | |
---|
223 | typedef DivMap<DoubleArcMap, DoubleArcMap> TimeMap; |
---|
224 | TimeMap time(length, speed); |
---|
225 | |
---|
226 | Dijkstra<Digraph, TimeMap> dijkstra(graph, time); |
---|
227 | dijkstra.run(source, target); |
---|
228 | \endcode |
---|
229 | We have a length map and a maximum speed map on the arcs of a digraph. |
---|
230 | The minimum time to pass the arc can be calculated as the division of |
---|
231 | the two maps which can be done implicitly with the \c DivMap template |
---|
232 | class. We use the implicit minimum time map as the length map of the |
---|
233 | \c Dijkstra algorithm. |
---|
234 | */ |
---|
235 | |
---|
236 | /** |
---|
237 | @defgroup paths Path Structures |
---|
238 | @ingroup datas |
---|
239 | \brief %Path structures implemented in LEMON. |
---|
240 | |
---|
241 | This group contains the path structures implemented in LEMON. |
---|
242 | |
---|
243 | LEMON provides flexible data structures to work with paths. |
---|
244 | All of them have similar interfaces and they can be copied easily with |
---|
245 | assignment operators and copy constructors. This makes it easy and |
---|
246 | efficient to have e.g. the Dijkstra algorithm to store its result in |
---|
247 | any kind of path structure. |
---|
248 | |
---|
249 | \sa \ref concepts::Path "Path concept" |
---|
250 | */ |
---|
251 | |
---|
252 | /** |
---|
253 | @defgroup heaps Heap Structures |
---|
254 | @ingroup datas |
---|
255 | \brief %Heap structures implemented in LEMON. |
---|
256 | |
---|
257 | This group contains the heap structures implemented in LEMON. |
---|
258 | |
---|
259 | LEMON provides several heap classes. They are efficient implementations |
---|
260 | of the abstract data type \e priority \e queue. They store items with |
---|
261 | specified values called \e priorities in such a way that finding and |
---|
262 | removing the item with minimum priority are efficient. |
---|
263 | The basic operations are adding and erasing items, changing the priority |
---|
264 | of an item, etc. |
---|
265 | |
---|
266 | Heaps are crucial in several algorithms, such as Dijkstra and Prim. |
---|
267 | The heap implementations have the same interface, thus any of them can be |
---|
268 | used easily in such algorithms. |
---|
269 | |
---|
270 | \sa \ref concepts::Heap "Heap concept" |
---|
271 | */ |
---|
272 | |
---|
273 | /** |
---|
274 | @defgroup auxdat Auxiliary Data Structures |
---|
275 | @ingroup datas |
---|
276 | \brief Auxiliary data structures implemented in LEMON. |
---|
277 | |
---|
278 | This group contains some data structures implemented in LEMON in |
---|
279 | order to make it easier to implement combinatorial algorithms. |
---|
280 | */ |
---|
281 | |
---|
282 | /** |
---|
283 | @defgroup geomdat Geometric Data Structures |
---|
284 | @ingroup auxdat |
---|
285 | \brief Geometric data structures implemented in LEMON. |
---|
286 | |
---|
287 | This group contains geometric data structures implemented in LEMON. |
---|
288 | |
---|
289 | - \ref lemon::dim2::Point "dim2::Point" implements a two dimensional |
---|
290 | vector with the usual operations. |
---|
291 | - \ref lemon::dim2::Box "dim2::Box" can be used to determine the |
---|
292 | rectangular bounding box of a set of \ref lemon::dim2::Point |
---|
293 | "dim2::Point"'s. |
---|
294 | */ |
---|
295 | |
---|
296 | /** |
---|
297 | @defgroup matrices Matrices |
---|
298 | @ingroup auxdat |
---|
299 | \brief Two dimensional data storages implemented in LEMON. |
---|
300 | |
---|
301 | This group contains two dimensional data storages implemented in LEMON. |
---|
302 | */ |
---|
303 | |
---|
304 | /** |
---|
305 | @defgroup algs Algorithms |
---|
306 | \brief This group contains the several algorithms |
---|
307 | implemented in LEMON. |
---|
308 | |
---|
309 | This group contains the several algorithms |
---|
310 | implemented in LEMON. |
---|
311 | */ |
---|
312 | |
---|
313 | /** |
---|
314 | @defgroup search Graph Search |
---|
315 | @ingroup algs |
---|
316 | \brief Common graph search algorithms. |
---|
317 | |
---|
318 | This group contains the common graph search algorithms, namely |
---|
319 | \e breadth-first \e search (BFS) and \e depth-first \e search (DFS) |
---|
320 | \cite clrs01algorithms. |
---|
321 | */ |
---|
322 | |
---|
323 | /** |
---|
324 | @defgroup shortest_path Shortest Path Algorithms |
---|
325 | @ingroup algs |
---|
326 | \brief Algorithms for finding shortest paths. |
---|
327 | |
---|
328 | This group contains the algorithms for finding shortest paths in digraphs |
---|
329 | \cite clrs01algorithms. |
---|
330 | |
---|
331 | - \ref Dijkstra algorithm for finding shortest paths from a source node |
---|
332 | when all arc lengths are non-negative. |
---|
333 | - \ref BellmanFord "Bellman-Ford" algorithm for finding shortest paths |
---|
334 | from a source node when arc lenghts can be either positive or negative, |
---|
335 | but the digraph should not contain directed cycles with negative total |
---|
336 | length. |
---|
337 | - \ref FloydWarshall "Floyd-Warshall" and \ref Johnson "Johnson" algorithms |
---|
338 | for solving the \e all-pairs \e shortest \e paths \e problem when arc |
---|
339 | lenghts can be either positive or negative, but the digraph should |
---|
340 | not contain directed cycles with negative total length. |
---|
341 | - \ref Suurballe A successive shortest path algorithm for finding |
---|
342 | arc-disjoint paths between two nodes having minimum total length. |
---|
343 | */ |
---|
344 | |
---|
345 | /** |
---|
346 | @defgroup spantree Minimum Spanning Tree Algorithms |
---|
347 | @ingroup algs |
---|
348 | \brief Algorithms for finding minimum cost spanning trees and arborescences. |
---|
349 | |
---|
350 | This group contains the algorithms for finding minimum cost spanning |
---|
351 | trees and arborescences \cite clrs01algorithms. |
---|
352 | */ |
---|
353 | |
---|
354 | /** |
---|
355 | @defgroup max_flow Maximum Flow Algorithms |
---|
356 | @ingroup algs |
---|
357 | \brief Algorithms for finding maximum flows. |
---|
358 | |
---|
359 | This group contains the algorithms for finding maximum flows and |
---|
360 | feasible circulations \cite clrs01algorithms, \cite amo93networkflows. |
---|
361 | |
---|
362 | The \e maximum \e flow \e problem is to find a flow of maximum value between |
---|
363 | a single source and a single target. Formally, there is a \f$G=(V,A)\f$ |
---|
364 | digraph, a \f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function and |
---|
365 | \f$s, t \in V\f$ source and target nodes. |
---|
366 | A maximum flow is an \f$f: A\rightarrow\mathbf{R}^+_0\f$ solution of the |
---|
367 | following optimization problem. |
---|
368 | |
---|
369 | \f[ \max\sum_{sv\in A} f(sv) - \sum_{vs\in A} f(vs) \f] |
---|
370 | \f[ \sum_{uv\in A} f(uv) = \sum_{vu\in A} f(vu) |
---|
371 | \quad \forall u\in V\setminus\{s,t\} \f] |
---|
372 | \f[ 0 \leq f(uv) \leq cap(uv) \quad \forall uv\in A \f] |
---|
373 | |
---|
374 | LEMON contains several algorithms for solving maximum flow problems: |
---|
375 | - \ref EdmondsKarp Edmonds-Karp algorithm |
---|
376 | \cite edmondskarp72theoretical. |
---|
377 | - \ref Preflow Goldberg-Tarjan's preflow push-relabel algorithm |
---|
378 | \cite goldberg88newapproach. |
---|
379 | - \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees |
---|
380 | \cite dinic70algorithm, \cite sleator83dynamic. |
---|
381 | - \ref GoldbergTarjan !Preflow push-relabel algorithm with dynamic trees |
---|
382 | \cite goldberg88newapproach, \cite sleator83dynamic. |
---|
383 | |
---|
384 | In most cases the \ref Preflow algorithm provides the |
---|
385 | fastest method for computing a maximum flow. All implementations |
---|
386 | also provide functions to query the minimum cut, which is the dual |
---|
387 | problem of maximum flow. |
---|
388 | |
---|
389 | \ref Circulation is a preflow push-relabel algorithm implemented directly |
---|
390 | for finding feasible circulations, which is a somewhat different problem, |
---|
391 | but it is strongly related to maximum flow. |
---|
392 | For more information, see \ref Circulation. |
---|
393 | */ |
---|
394 | |
---|
395 | /** |
---|
396 | @defgroup min_cost_flow_algs Minimum Cost Flow Algorithms |
---|
397 | @ingroup algs |
---|
398 | |
---|
399 | \brief Algorithms for finding minimum cost flows and circulations. |
---|
400 | |
---|
401 | This group contains the algorithms for finding minimum cost flows and |
---|
402 | circulations \cite amo93networkflows. For more information about this |
---|
403 | problem and its dual solution, see: \ref min_cost_flow |
---|
404 | "Minimum Cost Flow Problem". |
---|
405 | |
---|
406 | LEMON contains several algorithms for this problem. |
---|
407 | - \ref NetworkSimplex Primal Network Simplex algorithm with various |
---|
408 | pivot strategies \cite dantzig63linearprog, \cite kellyoneill91netsimplex. |
---|
409 | - \ref CostScaling Cost Scaling algorithm based on push/augment and |
---|
410 | relabel operations \cite goldberg90approximation, \cite goldberg97efficient, |
---|
411 | \cite bunnagel98efficient. |
---|
412 | - \ref CapacityScaling Capacity Scaling algorithm based on the successive |
---|
413 | shortest path method \cite edmondskarp72theoretical. |
---|
414 | - \ref CycleCanceling Cycle-Canceling algorithms, two of which are |
---|
415 | strongly polynomial \cite klein67primal, \cite goldberg89cyclecanceling. |
---|
416 | |
---|
417 | In general, \ref NetworkSimplex and \ref CostScaling are the most efficient |
---|
418 | implementations. |
---|
419 | \ref NetworkSimplex is usually the fastest on relatively small graphs (up to |
---|
420 | several thousands of nodes) and on dense graphs, while \ref CostScaling is |
---|
421 | typically more efficient on large graphs (e.g. hundreds of thousands of |
---|
422 | nodes or above), especially if they are sparse. |
---|
423 | However, other algorithms could be faster in special cases. |
---|
424 | For example, if the total supply and/or capacities are rather small, |
---|
425 | \ref CapacityScaling is usually the fastest algorithm |
---|
426 | (without effective scaling). |
---|
427 | |
---|
428 | These classes are intended to be used with integer-valued input data |
---|
429 | (capacities, supply values, and costs), except for \ref CapacityScaling, |
---|
430 | which is capable of handling real-valued arc costs (other numerical |
---|
431 | data are required to be integer). |
---|
432 | |
---|
433 | For more details about these implementations and for a comprehensive |
---|
434 | experimental study, see the paper \cite KiralyKovacs12MCF. |
---|
435 | It also compares these codes to other publicly available |
---|
436 | minimum cost flow solvers. |
---|
437 | */ |
---|
438 | |
---|
439 | /** |
---|
440 | @defgroup min_cut Minimum Cut Algorithms |
---|
441 | @ingroup algs |
---|
442 | |
---|
443 | \brief Algorithms for finding minimum cut in graphs. |
---|
444 | |
---|
445 | This group contains the algorithms for finding minimum cut in graphs. |
---|
446 | |
---|
447 | The \e minimum \e cut \e problem is to find a non-empty and non-complete |
---|
448 | \f$X\f$ subset of the nodes with minimum overall capacity on |
---|
449 | outgoing arcs. Formally, there is a \f$G=(V,A)\f$ digraph, a |
---|
450 | \f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum |
---|
451 | cut is the \f$X\f$ solution of the next optimization problem: |
---|
452 | |
---|
453 | \f[ \min_{X \subset V, X\not\in \{\emptyset, V\}} |
---|
454 | \sum_{uv\in A: u\in X, v\not\in X}cap(uv) \f] |
---|
455 | |
---|
456 | LEMON contains several algorithms related to minimum cut problems: |
---|
457 | |
---|
458 | - \ref HaoOrlin "Hao-Orlin algorithm" for calculating minimum cut |
---|
459 | in directed graphs. |
---|
460 | - \ref NagamochiIbaraki "Nagamochi-Ibaraki algorithm" for |
---|
461 | calculating minimum cut in undirected graphs. |
---|
462 | - \ref GomoryHu "Gomory-Hu tree computation" for calculating |
---|
463 | all-pairs minimum cut in undirected graphs. |
---|
464 | |
---|
465 | If you want to find minimum cut just between two distinict nodes, |
---|
466 | see the \ref max_flow "maximum flow problem". |
---|
467 | */ |
---|
468 | |
---|
469 | /** |
---|
470 | @defgroup min_mean_cycle Minimum Mean Cycle Algorithms |
---|
471 | @ingroup algs |
---|
472 | \brief Algorithms for finding minimum mean cycles. |
---|
473 | |
---|
474 | This group contains the algorithms for finding minimum mean cycles |
---|
475 | \cite amo93networkflows, \cite karp78characterization. |
---|
476 | |
---|
477 | The \e minimum \e mean \e cycle \e problem is to find a directed cycle |
---|
478 | of minimum mean length (cost) in a digraph. |
---|
479 | The mean length of a cycle is the average length of its arcs, i.e. the |
---|
480 | ratio between the total length of the cycle and the number of arcs on it. |
---|
481 | |
---|
482 | This problem has an important connection to \e conservative \e length |
---|
483 | \e functions, too. A length function on the arcs of a digraph is called |
---|
484 | conservative if and only if there is no directed cycle of negative total |
---|
485 | length. For an arbitrary length function, the negative of the minimum |
---|
486 | cycle mean is the smallest \f$\epsilon\f$ value so that increasing the |
---|
487 | arc lengths uniformly by \f$\epsilon\f$ results in a conservative length |
---|
488 | function. |
---|
489 | |
---|
490 | LEMON contains three algorithms for solving the minimum mean cycle problem: |
---|
491 | - \ref KarpMmc Karp's original algorithm \cite karp78characterization. |
---|
492 | - \ref HartmannOrlinMmc Hartmann-Orlin's algorithm, which is an improved |
---|
493 | version of Karp's algorithm \cite hartmann93finding. |
---|
494 | - \ref HowardMmc Howard's policy iteration algorithm |
---|
495 | \cite dasdan98minmeancycle, \cite dasdan04experimental. |
---|
496 | |
---|
497 | In practice, the \ref HowardMmc "Howard" algorithm turned out to be by far the |
---|
498 | most efficient one, though the best known theoretical bound on its running |
---|
499 | time is exponential. |
---|
500 | Both \ref KarpMmc "Karp" and \ref HartmannOrlinMmc "Hartmann-Orlin" algorithms |
---|
501 | run in time O(nm) and use space O(n<sup>2</sup>+m). |
---|
502 | */ |
---|
503 | |
---|
504 | /** |
---|
505 | @defgroup matching Matching Algorithms |
---|
506 | @ingroup algs |
---|
507 | \brief Algorithms for finding matchings in graphs and bipartite graphs. |
---|
508 | |
---|
509 | This group contains the algorithms for calculating |
---|
510 | matchings in graphs and bipartite graphs. The general matching problem is |
---|
511 | finding a subset of the edges for which each node has at most one incident |
---|
512 | edge. |
---|
513 | |
---|
514 | There are several different algorithms for calculate matchings in |
---|
515 | graphs. The matching problems in bipartite graphs are generally |
---|
516 | easier than in general graphs. The goal of the matching optimization |
---|
517 | can be finding maximum cardinality, maximum weight or minimum cost |
---|
518 | matching. The search can be constrained to find perfect or |
---|
519 | maximum cardinality matching. |
---|
520 | |
---|
521 | The matching algorithms implemented in LEMON: |
---|
522 | - \ref MaxBipartiteMatching Hopcroft-Karp augmenting path algorithm |
---|
523 | for calculating maximum cardinality matching in bipartite graphs. |
---|
524 | - \ref PrBipartiteMatching Push-relabel algorithm |
---|
525 | for calculating maximum cardinality matching in bipartite graphs. |
---|
526 | - \ref MaxWeightedBipartiteMatching |
---|
527 | Successive shortest path algorithm for calculating maximum weighted |
---|
528 | matching and maximum weighted bipartite matching in bipartite graphs. |
---|
529 | - \ref MinCostMaxBipartiteMatching |
---|
530 | Successive shortest path algorithm for calculating minimum cost maximum |
---|
531 | matching in bipartite graphs. |
---|
532 | - \ref MaxMatching Edmond's blossom shrinking algorithm for calculating |
---|
533 | maximum cardinality matching in general graphs. |
---|
534 | - \ref MaxWeightedMatching Edmond's blossom shrinking algorithm for calculating |
---|
535 | maximum weighted matching in general graphs. |
---|
536 | - \ref MaxWeightedPerfectMatching |
---|
537 | Edmond's blossom shrinking algorithm for calculating maximum weighted |
---|
538 | perfect matching in general graphs. |
---|
539 | - \ref MaxFractionalMatching Push-relabel algorithm for calculating |
---|
540 | maximum cardinality fractional matching in general graphs. |
---|
541 | - \ref MaxWeightedFractionalMatching Augmenting path algorithm for calculating |
---|
542 | maximum weighted fractional matching in general graphs. |
---|
543 | - \ref MaxWeightedPerfectFractionalMatching |
---|
544 | Augmenting path algorithm for calculating maximum weighted |
---|
545 | perfect fractional matching in general graphs. |
---|
546 | |
---|
547 | \image html matching.png |
---|
548 | \image latex matching.eps "Min Cost Perfect Matching" width=\textwidth |
---|
549 | */ |
---|
550 | |
---|
551 | /** |
---|
552 | @defgroup graph_properties Connectivity and Other Graph Properties |
---|
553 | @ingroup algs |
---|
554 | \brief Algorithms for discovering the graph properties |
---|
555 | |
---|
556 | This group contains the algorithms for discovering the graph properties |
---|
557 | like connectivity, bipartiteness, euler property, simplicity etc. |
---|
558 | |
---|
559 | \image html connected_components.png |
---|
560 | \image latex connected_components.eps "Connected components" width=\textwidth |
---|
561 | */ |
---|
562 | |
---|
563 | /** |
---|
564 | @defgroup graph_isomorphism Graph Isomorphism |
---|
565 | @ingroup algs |
---|
566 | \brief Algorithms for testing (sub)graph isomorphism |
---|
567 | |
---|
568 | This group contains algorithms for finding isomorph copies of a |
---|
569 | given graph in another one, or simply check whether two graphs are isomorphic. |
---|
570 | |
---|
571 | The formal definition of subgraph isomorphism is as follows. |
---|
572 | |
---|
573 | We are given two graphs, \f$G_1=(V_1,E_1)\f$ and \f$G_2=(V_2,E_2)\f$. A |
---|
574 | function \f$f:V_1\longrightarrow V_2\f$ is called \e mapping or \e |
---|
575 | embedding if \f$f(u)\neq f(v)\f$ whenever \f$u\neq v\f$. |
---|
576 | |
---|
577 | The standard <em>Subgraph Isomorphism Problem (SIP)</em> looks for a |
---|
578 | mapping with the property that whenever \f$(u,v)\in E_1\f$, then |
---|
579 | \f$(f(u),f(v))\in E_2\f$. |
---|
580 | |
---|
581 | In case of <em>Induced Subgraph Isomorphism Problem (ISIP)</em> one |
---|
582 | also requires that if \f$(u,v)\not\in E_1\f$, then \f$(f(u),f(v))\not\in |
---|
583 | E_2\f$ |
---|
584 | |
---|
585 | In addition, the graph nodes may be \e labeled, i.e. we are given two |
---|
586 | node labelings \f$l_1:V_1\longrightarrow L\f$ and \f$l_2:V_2\longrightarrow |
---|
587 | L\f$ and we require that \f$l_1(u)=l_2(f(u))\f$ holds for all nodes \f$u \in |
---|
588 | G\f$. |
---|
589 | |
---|
590 | */ |
---|
591 | |
---|
592 | /** |
---|
593 | @defgroup planar Planar Embedding and Drawing |
---|
594 | @ingroup algs |
---|
595 | \brief Algorithms for planarity checking, embedding and drawing |
---|
596 | |
---|
597 | This group contains the algorithms for planarity checking, |
---|
598 | embedding and drawing. |
---|
599 | |
---|
600 | \image html planar.png |
---|
601 | \image latex planar.eps "Plane graph" width=\textwidth |
---|
602 | */ |
---|
603 | |
---|
604 | /** |
---|
605 | @defgroup tsp Traveling Salesman Problem |
---|
606 | @ingroup algs |
---|
607 | \brief Algorithms for the symmetric traveling salesman problem |
---|
608 | |
---|
609 | This group contains basic heuristic algorithms for the the symmetric |
---|
610 | \e traveling \e salesman \e problem (TSP). |
---|
611 | Given an \ref FullGraph "undirected full graph" with a cost map on its edges, |
---|
612 | the problem is to find a shortest possible tour that visits each node exactly |
---|
613 | once (i.e. the minimum cost Hamiltonian cycle). |
---|
614 | |
---|
615 | These TSP algorithms are intended to be used with a \e metric \e cost |
---|
616 | \e function, i.e. the edge costs should satisfy the triangle inequality. |
---|
617 | Otherwise the algorithms could yield worse results. |
---|
618 | |
---|
619 | LEMON provides five well-known heuristics for solving symmetric TSP: |
---|
620 | - \ref NearestNeighborTsp Neareast neighbor algorithm |
---|
621 | - \ref GreedyTsp Greedy algorithm |
---|
622 | - \ref InsertionTsp Insertion heuristic (with four selection methods) |
---|
623 | - \ref ChristofidesTsp Christofides algorithm |
---|
624 | - \ref Opt2Tsp 2-opt algorithm |
---|
625 | |
---|
626 | \ref NearestNeighborTsp, \ref GreedyTsp, and \ref InsertionTsp are the fastest |
---|
627 | solution methods. Furthermore, \ref InsertionTsp is usually quite effective. |
---|
628 | |
---|
629 | \ref ChristofidesTsp is somewhat slower, but it has the best guaranteed |
---|
630 | approximation factor: 3/2. |
---|
631 | |
---|
632 | \ref Opt2Tsp usually provides the best results in practice, but |
---|
633 | it is the slowest method. It can also be used to improve given tours, |
---|
634 | for example, the results of other algorithms. |
---|
635 | |
---|
636 | \image html tsp.png |
---|
637 | \image latex tsp.eps "Traveling salesman problem" width=\textwidth |
---|
638 | */ |
---|
639 | |
---|
640 | /** |
---|
641 | @defgroup approx_algs Approximation Algorithms |
---|
642 | @ingroup algs |
---|
643 | \brief Approximation algorithms. |
---|
644 | |
---|
645 | This group contains the approximation and heuristic algorithms |
---|
646 | implemented in LEMON. |
---|
647 | |
---|
648 | <b>Maximum Clique Problem</b> |
---|
649 | - \ref GrossoLocatelliPullanMc An efficient heuristic algorithm of |
---|
650 | Grosso, Locatelli, and Pullan. |
---|
651 | */ |
---|
652 | |
---|
653 | /** |
---|
654 | @defgroup auxalg Auxiliary Algorithms |
---|
655 | @ingroup algs |
---|
656 | \brief Auxiliary algorithms implemented in LEMON. |
---|
657 | |
---|
658 | This group contains some algorithms implemented in LEMON |
---|
659 | in order to make it easier to implement complex algorithms. |
---|
660 | */ |
---|
661 | |
---|
662 | /** |
---|
663 | @defgroup gen_opt_group General Optimization Tools |
---|
664 | \brief This group contains some general optimization frameworks |
---|
665 | implemented in LEMON. |
---|
666 | |
---|
667 | This group contains some general optimization frameworks |
---|
668 | implemented in LEMON. |
---|
669 | */ |
---|
670 | |
---|
671 | /** |
---|
672 | @defgroup lp_group LP and MIP Solvers |
---|
673 | @ingroup gen_opt_group |
---|
674 | \brief LP and MIP solver interfaces for LEMON. |
---|
675 | |
---|
676 | This group contains LP and MIP solver interfaces for LEMON. |
---|
677 | Various LP solvers could be used in the same manner with this |
---|
678 | high-level interface. |
---|
679 | |
---|
680 | The currently supported solvers are \cite glpk, \cite clp, \cite cbc, |
---|
681 | \cite cplex, \cite soplex. |
---|
682 | */ |
---|
683 | |
---|
684 | /** |
---|
685 | @defgroup lp_utils Tools for Lp and Mip Solvers |
---|
686 | @ingroup lp_group |
---|
687 | \brief Helper tools to the Lp and Mip solvers. |
---|
688 | |
---|
689 | This group adds some helper tools to general optimization framework |
---|
690 | implemented in LEMON. |
---|
691 | */ |
---|
692 | |
---|
693 | /** |
---|
694 | @defgroup metah Metaheuristics |
---|
695 | @ingroup gen_opt_group |
---|
696 | \brief Metaheuristics for LEMON library. |
---|
697 | |
---|
698 | This group contains some metaheuristic optimization tools. |
---|
699 | */ |
---|
700 | |
---|
701 | /** |
---|
702 | @defgroup utils Tools and Utilities |
---|
703 | \brief Tools and utilities for programming in LEMON |
---|
704 | |
---|
705 | Tools and utilities for programming in LEMON. |
---|
706 | */ |
---|
707 | |
---|
708 | /** |
---|
709 | @defgroup gutils Basic Graph Utilities |
---|
710 | @ingroup utils |
---|
711 | \brief Simple basic graph utilities. |
---|
712 | |
---|
713 | This group contains some simple basic graph utilities. |
---|
714 | */ |
---|
715 | |
---|
716 | /** |
---|
717 | @defgroup misc Miscellaneous Tools |
---|
718 | @ingroup utils |
---|
719 | \brief Tools for development, debugging and testing. |
---|
720 | |
---|
721 | This group contains several useful tools for development, |
---|
722 | debugging and testing. |
---|
723 | */ |
---|
724 | |
---|
725 | /** |
---|
726 | @defgroup timecount Time Measuring and Counting |
---|
727 | @ingroup misc |
---|
728 | \brief Simple tools for measuring the performance of algorithms. |
---|
729 | |
---|
730 | This group contains simple tools for measuring the performance |
---|
731 | of algorithms. |
---|
732 | */ |
---|
733 | |
---|
734 | /** |
---|
735 | @defgroup exceptions Exceptions |
---|
736 | @ingroup utils |
---|
737 | \brief Exceptions defined in LEMON. |
---|
738 | |
---|
739 | This group contains the exceptions defined in LEMON. |
---|
740 | */ |
---|
741 | |
---|
742 | /** |
---|
743 | @defgroup io_group Input-Output |
---|
744 | \brief Graph Input-Output methods |
---|
745 | |
---|
746 | This group contains the tools for importing and exporting graphs |
---|
747 | and graph related data. Now it supports the \ref lgf-format |
---|
748 | "LEMON Graph Format", the \c DIMACS format and the encapsulated |
---|
749 | postscript (EPS) format. |
---|
750 | */ |
---|
751 | |
---|
752 | /** |
---|
753 | @defgroup lemon_io LEMON Graph Format |
---|
754 | @ingroup io_group |
---|
755 | \brief Reading and writing LEMON Graph Format. |
---|
756 | |
---|
757 | This group contains methods for reading and writing |
---|
758 | \ref lgf-format "LEMON Graph Format". |
---|
759 | */ |
---|
760 | |
---|
761 | /** |
---|
762 | @defgroup eps_io Postscript Exporting |
---|
763 | @ingroup io_group |
---|
764 | \brief General \c EPS drawer and graph exporter |
---|
765 | |
---|
766 | This group contains general \c EPS drawing methods and special |
---|
767 | graph exporting tools. |
---|
768 | |
---|
769 | \image html graph_to_eps.png |
---|
770 | */ |
---|
771 | |
---|
772 | /** |
---|
773 | @defgroup dimacs_group DIMACS Format |
---|
774 | @ingroup io_group |
---|
775 | \brief Read and write files in DIMACS format |
---|
776 | |
---|
777 | Tools to read a digraph from or write it to a file in DIMACS format data. |
---|
778 | */ |
---|
779 | |
---|
780 | /** |
---|
781 | @defgroup nauty_group NAUTY Format |
---|
782 | @ingroup io_group |
---|
783 | \brief Read \e Nauty format |
---|
784 | |
---|
785 | Tool to read graphs from \e Nauty format data. |
---|
786 | */ |
---|
787 | |
---|
788 | /** |
---|
789 | @defgroup concept Concepts |
---|
790 | \brief Skeleton classes and concept checking classes |
---|
791 | |
---|
792 | This group contains the data/algorithm skeletons and concept checking |
---|
793 | classes implemented in LEMON. |
---|
794 | |
---|
795 | The purpose of the classes in this group is fourfold. |
---|
796 | |
---|
797 | - These classes contain the documentations of the %concepts. In order |
---|
798 | to avoid document multiplications, an implementation of a concept |
---|
799 | simply refers to the corresponding concept class. |
---|
800 | |
---|
801 | - These classes declare every functions, <tt>typedef</tt>s etc. an |
---|
802 | implementation of the %concepts should provide, however completely |
---|
803 | without implementations and real data structures behind the |
---|
804 | interface. On the other hand they should provide nothing else. All |
---|
805 | the algorithms working on a data structure meeting a certain concept |
---|
806 | should compile with these classes. (Though it will not run properly, |
---|
807 | of course.) In this way it is easily to check if an algorithm |
---|
808 | doesn't use any extra feature of a certain implementation. |
---|
809 | |
---|
810 | - The concept descriptor classes also provide a <em>checker class</em> |
---|
811 | that makes it possible to check whether a certain implementation of a |
---|
812 | concept indeed provides all the required features. |
---|
813 | |
---|
814 | - Finally, They can serve as a skeleton of a new implementation of a concept. |
---|
815 | */ |
---|
816 | |
---|
817 | /** |
---|
818 | @defgroup graph_concepts Graph Structure Concepts |
---|
819 | @ingroup concept |
---|
820 | \brief Skeleton and concept checking classes for graph structures |
---|
821 | |
---|
822 | This group contains the skeletons and concept checking classes of |
---|
823 | graph structures. |
---|
824 | */ |
---|
825 | |
---|
826 | /** |
---|
827 | @defgroup map_concepts Map Concepts |
---|
828 | @ingroup concept |
---|
829 | \brief Skeleton and concept checking classes for maps |
---|
830 | |
---|
831 | This group contains the skeletons and concept checking classes of maps. |
---|
832 | */ |
---|
833 | |
---|
834 | /** |
---|
835 | @defgroup tools Standalone Utility Applications |
---|
836 | |
---|
837 | Some utility applications are listed here. |
---|
838 | |
---|
839 | The standard compilation procedure (<tt>./configure;make</tt>) will compile |
---|
840 | them, as well. |
---|
841 | */ |
---|
842 | |
---|
843 | /** |
---|
844 | \anchor demoprograms |
---|
845 | |
---|
846 | @defgroup demos Demo Programs |
---|
847 | |
---|
848 | Some demo programs are listed here. Their full source codes can be found in |
---|
849 | the \c demo subdirectory of the source tree. |
---|
850 | |
---|
851 | In order to compile them, use the <tt>make demo</tt> or the |
---|
852 | <tt>make check</tt> commands. |
---|
853 | */ |
---|
854 | |
---|
855 | } |
---|