alpar@209
|
1 |
/* -*- mode: C++; indent-tabs-mode: nil; -*-
|
alpar@40
|
2 |
*
|
alpar@209
|
3 |
* This file is a part of LEMON, a generic C++ optimization library.
|
alpar@40
|
4 |
*
|
alpar@40
|
5 |
* Copyright (C) 2003-2008
|
alpar@40
|
6 |
* Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
|
alpar@40
|
7 |
* (Egervary Research Group on Combinatorial Optimization, EGRES).
|
alpar@40
|
8 |
*
|
alpar@40
|
9 |
* Permission to use, modify and distribute this software is granted
|
alpar@40
|
10 |
* provided that this copyright notice appears in all copies. For
|
alpar@40
|
11 |
* precise terms see the accompanying LICENSE file.
|
alpar@40
|
12 |
*
|
alpar@40
|
13 |
* This software is provided "AS IS" with no warranty of any kind,
|
alpar@40
|
14 |
* express or implied, and with no claim as to its suitability for any
|
alpar@40
|
15 |
* purpose.
|
alpar@40
|
16 |
*
|
alpar@40
|
17 |
*/
|
alpar@40
|
18 |
|
kpeter@406
|
19 |
namespace lemon {
|
kpeter@406
|
20 |
|
alpar@40
|
21 |
/**
|
alpar@40
|
22 |
@defgroup datas Data Structures
|
kpeter@50
|
23 |
This group describes the several data structures implemented in LEMON.
|
alpar@40
|
24 |
*/
|
alpar@40
|
25 |
|
alpar@40
|
26 |
/**
|
alpar@40
|
27 |
@defgroup graphs Graph Structures
|
alpar@40
|
28 |
@ingroup datas
|
alpar@40
|
29 |
\brief Graph structures implemented in LEMON.
|
alpar@40
|
30 |
|
alpar@209
|
31 |
The implementation of combinatorial algorithms heavily relies on
|
alpar@209
|
32 |
efficient graph implementations. LEMON offers data structures which are
|
alpar@209
|
33 |
planned to be easily used in an experimental phase of implementation studies,
|
alpar@209
|
34 |
and thereafter the program code can be made efficient by small modifications.
|
alpar@40
|
35 |
|
alpar@40
|
36 |
The most efficient implementation of diverse applications require the
|
alpar@40
|
37 |
usage of different physical graph implementations. These differences
|
alpar@40
|
38 |
appear in the size of graph we require to handle, memory or time usage
|
alpar@40
|
39 |
limitations or in the set of operations through which the graph can be
|
alpar@40
|
40 |
accessed. LEMON provides several physical graph structures to meet
|
alpar@40
|
41 |
the diverging requirements of the possible users. In order to save on
|
alpar@40
|
42 |
running time or on memory usage, some structures may fail to provide
|
kpeter@83
|
43 |
some graph features like arc/edge or node deletion.
|
alpar@40
|
44 |
|
alpar@209
|
45 |
Alteration of standard containers need a very limited number of
|
alpar@209
|
46 |
operations, these together satisfy the everyday requirements.
|
alpar@209
|
47 |
In the case of graph structures, different operations are needed which do
|
alpar@209
|
48 |
not alter the physical graph, but gives another view. If some nodes or
|
kpeter@83
|
49 |
arcs have to be hidden or the reverse oriented graph have to be used, then
|
alpar@209
|
50 |
this is the case. It also may happen that in a flow implementation
|
alpar@209
|
51 |
the residual graph can be accessed by another algorithm, or a node-set
|
alpar@209
|
52 |
is to be shrunk for another algorithm.
|
alpar@209
|
53 |
LEMON also provides a variety of graphs for these requirements called
|
alpar@209
|
54 |
\ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only
|
alpar@209
|
55 |
in conjunction with other graph representations.
|
alpar@40
|
56 |
|
alpar@40
|
57 |
You are free to use the graph structure that fit your requirements
|
alpar@40
|
58 |
the best, most graph algorithms and auxiliary data structures can be used
|
kpeter@314
|
59 |
with any graph structure.
|
kpeter@314
|
60 |
|
kpeter@314
|
61 |
<b>See also:</b> \ref graph_concepts "Graph Structure Concepts".
|
alpar@40
|
62 |
*/
|
alpar@40
|
63 |
|
alpar@40
|
64 |
/**
|
kpeter@50
|
65 |
@defgroup semi_adaptors Semi-Adaptor Classes for Graphs
|
alpar@40
|
66 |
@ingroup graphs
|
alpar@40
|
67 |
\brief Graph types between real graphs and graph adaptors.
|
alpar@40
|
68 |
|
kpeter@50
|
69 |
This group describes some graph types between real graphs and graph adaptors.
|
alpar@209
|
70 |
These classes wrap graphs to give new functionality as the adaptors do it.
|
kpeter@50
|
71 |
On the other hand they are not light-weight structures as the adaptors.
|
alpar@40
|
72 |
*/
|
alpar@40
|
73 |
|
alpar@40
|
74 |
/**
|
alpar@209
|
75 |
@defgroup maps Maps
|
alpar@40
|
76 |
@ingroup datas
|
kpeter@50
|
77 |
\brief Map structures implemented in LEMON.
|
alpar@40
|
78 |
|
kpeter@50
|
79 |
This group describes the map structures implemented in LEMON.
|
kpeter@50
|
80 |
|
kpeter@314
|
81 |
LEMON provides several special purpose maps and map adaptors that e.g. combine
|
alpar@40
|
82 |
new maps from existing ones.
|
kpeter@314
|
83 |
|
kpeter@314
|
84 |
<b>See also:</b> \ref map_concepts "Map Concepts".
|
alpar@40
|
85 |
*/
|
alpar@40
|
86 |
|
alpar@40
|
87 |
/**
|
alpar@209
|
88 |
@defgroup graph_maps Graph Maps
|
alpar@40
|
89 |
@ingroup maps
|
kpeter@83
|
90 |
\brief Special graph-related maps.
|
alpar@40
|
91 |
|
kpeter@50
|
92 |
This group describes maps that are specifically designed to assign
|
kpeter@406
|
93 |
values to the nodes and arcs/edges of graphs.
|
kpeter@406
|
94 |
|
kpeter@406
|
95 |
If you are looking for the standard graph maps (\c NodeMap, \c ArcMap,
|
kpeter@406
|
96 |
\c EdgeMap), see the \ref graph_concepts "Graph Structure Concepts".
|
alpar@40
|
97 |
*/
|
alpar@40
|
98 |
|
alpar@40
|
99 |
/**
|
alpar@40
|
100 |
\defgroup map_adaptors Map Adaptors
|
alpar@40
|
101 |
\ingroup maps
|
alpar@40
|
102 |
\brief Tools to create new maps from existing ones
|
alpar@40
|
103 |
|
kpeter@50
|
104 |
This group describes map adaptors that are used to create "implicit"
|
kpeter@50
|
105 |
maps from other maps.
|
alpar@40
|
106 |
|
kpeter@406
|
107 |
Most of them are \ref concepts::ReadMap "read-only maps".
|
kpeter@83
|
108 |
They can make arithmetic and logical operations between one or two maps
|
kpeter@83
|
109 |
(negation, shifting, addition, multiplication, logical 'and', 'or',
|
kpeter@83
|
110 |
'not' etc.) or e.g. convert a map to another one of different Value type.
|
alpar@40
|
111 |
|
kpeter@50
|
112 |
The typical usage of this classes is passing implicit maps to
|
alpar@40
|
113 |
algorithms. If a function type algorithm is called then the function
|
alpar@40
|
114 |
type map adaptors can be used comfortable. For example let's see the
|
kpeter@314
|
115 |
usage of map adaptors with the \c graphToEps() function.
|
alpar@40
|
116 |
\code
|
alpar@40
|
117 |
Color nodeColor(int deg) {
|
alpar@40
|
118 |
if (deg >= 2) {
|
alpar@40
|
119 |
return Color(0.5, 0.0, 0.5);
|
alpar@40
|
120 |
} else if (deg == 1) {
|
alpar@40
|
121 |
return Color(1.0, 0.5, 1.0);
|
alpar@40
|
122 |
} else {
|
alpar@40
|
123 |
return Color(0.0, 0.0, 0.0);
|
alpar@40
|
124 |
}
|
alpar@40
|
125 |
}
|
alpar@209
|
126 |
|
kpeter@83
|
127 |
Digraph::NodeMap<int> degree_map(graph);
|
alpar@209
|
128 |
|
kpeter@314
|
129 |
graphToEps(graph, "graph.eps")
|
alpar@40
|
130 |
.coords(coords).scaleToA4().undirected()
|
kpeter@83
|
131 |
.nodeColors(composeMap(functorToMap(nodeColor), degree_map))
|
alpar@40
|
132 |
.run();
|
alpar@209
|
133 |
\endcode
|
kpeter@83
|
134 |
The \c functorToMap() function makes an \c int to \c Color map from the
|
kpeter@314
|
135 |
\c nodeColor() function. The \c composeMap() compose the \c degree_map
|
kpeter@83
|
136 |
and the previously created map. The composed map is a proper function to
|
kpeter@83
|
137 |
get the color of each node.
|
alpar@40
|
138 |
|
alpar@40
|
139 |
The usage with class type algorithms is little bit harder. In this
|
alpar@40
|
140 |
case the function type map adaptors can not be used, because the
|
kpeter@50
|
141 |
function map adaptors give back temporary objects.
|
alpar@40
|
142 |
\code
|
kpeter@83
|
143 |
Digraph graph;
|
kpeter@83
|
144 |
|
kpeter@83
|
145 |
typedef Digraph::ArcMap<double> DoubleArcMap;
|
kpeter@83
|
146 |
DoubleArcMap length(graph);
|
kpeter@83
|
147 |
DoubleArcMap speed(graph);
|
kpeter@83
|
148 |
|
kpeter@83
|
149 |
typedef DivMap<DoubleArcMap, DoubleArcMap> TimeMap;
|
alpar@40
|
150 |
TimeMap time(length, speed);
|
alpar@209
|
151 |
|
kpeter@83
|
152 |
Dijkstra<Digraph, TimeMap> dijkstra(graph, time);
|
alpar@40
|
153 |
dijkstra.run(source, target);
|
alpar@40
|
154 |
\endcode
|
kpeter@83
|
155 |
We have a length map and a maximum speed map on the arcs of a digraph.
|
kpeter@83
|
156 |
The minimum time to pass the arc can be calculated as the division of
|
kpeter@83
|
157 |
the two maps which can be done implicitly with the \c DivMap template
|
alpar@40
|
158 |
class. We use the implicit minimum time map as the length map of the
|
alpar@40
|
159 |
\c Dijkstra algorithm.
|
alpar@40
|
160 |
*/
|
alpar@40
|
161 |
|
alpar@40
|
162 |
/**
|
alpar@209
|
163 |
@defgroup matrices Matrices
|
alpar@40
|
164 |
@ingroup datas
|
kpeter@50
|
165 |
\brief Two dimensional data storages implemented in LEMON.
|
alpar@40
|
166 |
|
kpeter@50
|
167 |
This group describes two dimensional data storages implemented in LEMON.
|
alpar@40
|
168 |
*/
|
alpar@40
|
169 |
|
alpar@40
|
170 |
/**
|
alpar@40
|
171 |
@defgroup paths Path Structures
|
alpar@40
|
172 |
@ingroup datas
|
kpeter@318
|
173 |
\brief %Path structures implemented in LEMON.
|
alpar@40
|
174 |
|
kpeter@50
|
175 |
This group describes the path structures implemented in LEMON.
|
alpar@40
|
176 |
|
kpeter@50
|
177 |
LEMON provides flexible data structures to work with paths.
|
kpeter@50
|
178 |
All of them have similar interfaces and they can be copied easily with
|
kpeter@50
|
179 |
assignment operators and copy constructors. This makes it easy and
|
alpar@40
|
180 |
efficient to have e.g. the Dijkstra algorithm to store its result in
|
alpar@40
|
181 |
any kind of path structure.
|
alpar@40
|
182 |
|
alpar@40
|
183 |
\sa lemon::concepts::Path
|
alpar@40
|
184 |
*/
|
alpar@40
|
185 |
|
alpar@40
|
186 |
/**
|
alpar@40
|
187 |
@defgroup auxdat Auxiliary Data Structures
|
alpar@40
|
188 |
@ingroup datas
|
kpeter@50
|
189 |
\brief Auxiliary data structures implemented in LEMON.
|
alpar@40
|
190 |
|
kpeter@50
|
191 |
This group describes some data structures implemented in LEMON in
|
alpar@40
|
192 |
order to make it easier to implement combinatorial algorithms.
|
alpar@40
|
193 |
*/
|
alpar@40
|
194 |
|
alpar@40
|
195 |
/**
|
alpar@40
|
196 |
@defgroup algs Algorithms
|
alpar@40
|
197 |
\brief This group describes the several algorithms
|
alpar@40
|
198 |
implemented in LEMON.
|
alpar@40
|
199 |
|
alpar@40
|
200 |
This group describes the several algorithms
|
alpar@40
|
201 |
implemented in LEMON.
|
alpar@40
|
202 |
*/
|
alpar@40
|
203 |
|
alpar@40
|
204 |
/**
|
alpar@40
|
205 |
@defgroup search Graph Search
|
alpar@40
|
206 |
@ingroup algs
|
kpeter@50
|
207 |
\brief Common graph search algorithms.
|
alpar@40
|
208 |
|
kpeter@406
|
209 |
This group describes the common graph search algorithms, namely
|
kpeter@406
|
210 |
\e breadth-first \e search (BFS) and \e depth-first \e search (DFS).
|
alpar@40
|
211 |
*/
|
alpar@40
|
212 |
|
alpar@40
|
213 |
/**
|
kpeter@314
|
214 |
@defgroup shortest_path Shortest Path Algorithms
|
alpar@40
|
215 |
@ingroup algs
|
kpeter@50
|
216 |
\brief Algorithms for finding shortest paths.
|
alpar@40
|
217 |
|
kpeter@406
|
218 |
This group describes the algorithms for finding shortest paths in digraphs.
|
kpeter@406
|
219 |
|
kpeter@406
|
220 |
- \ref Dijkstra algorithm for finding shortest paths from a source node
|
kpeter@406
|
221 |
when all arc lengths are non-negative.
|
kpeter@406
|
222 |
- \ref BellmanFord "Bellman-Ford" algorithm for finding shortest paths
|
kpeter@406
|
223 |
from a source node when arc lenghts can be either positive or negative,
|
kpeter@406
|
224 |
but the digraph should not contain directed cycles with negative total
|
kpeter@406
|
225 |
length.
|
kpeter@406
|
226 |
- \ref FloydWarshall "Floyd-Warshall" and \ref Johnson "Johnson" algorithms
|
kpeter@406
|
227 |
for solving the \e all-pairs \e shortest \e paths \e problem when arc
|
kpeter@406
|
228 |
lenghts can be either positive or negative, but the digraph should
|
kpeter@406
|
229 |
not contain directed cycles with negative total length.
|
kpeter@406
|
230 |
- \ref Suurballe A successive shortest path algorithm for finding
|
kpeter@406
|
231 |
arc-disjoint paths between two nodes having minimum total length.
|
alpar@40
|
232 |
*/
|
alpar@40
|
233 |
|
alpar@209
|
234 |
/**
|
kpeter@314
|
235 |
@defgroup max_flow Maximum Flow Algorithms
|
alpar@209
|
236 |
@ingroup algs
|
kpeter@50
|
237 |
\brief Algorithms for finding maximum flows.
|
alpar@40
|
238 |
|
alpar@40
|
239 |
This group describes the algorithms for finding maximum flows and
|
alpar@40
|
240 |
feasible circulations.
|
alpar@40
|
241 |
|
kpeter@406
|
242 |
The \e maximum \e flow \e problem is to find a flow of maximum value between
|
kpeter@406
|
243 |
a single source and a single target. Formally, there is a \f$G=(V,A)\f$
|
kpeter@406
|
244 |
digraph, a \f$cap:A\rightarrow\mathbf{R}^+_0\f$ capacity function and
|
kpeter@406
|
245 |
\f$s, t \in V\f$ source and target nodes.
|
kpeter@406
|
246 |
A maximum flow is an \f$f:A\rightarrow\mathbf{R}^+_0\f$ solution of the
|
kpeter@406
|
247 |
following optimization problem.
|
alpar@40
|
248 |
|
kpeter@406
|
249 |
\f[ \max\sum_{a\in\delta_{out}(s)}f(a) - \sum_{a\in\delta_{in}(s)}f(a) \f]
|
kpeter@406
|
250 |
\f[ \sum_{a\in\delta_{out}(v)} f(a) = \sum_{a\in\delta_{in}(v)} f(a)
|
kpeter@406
|
251 |
\qquad \forall v\in V\setminus\{s,t\} \f]
|
kpeter@406
|
252 |
\f[ 0 \leq f(a) \leq cap(a) \qquad \forall a\in A \f]
|
alpar@40
|
253 |
|
kpeter@50
|
254 |
LEMON contains several algorithms for solving maximum flow problems:
|
kpeter@406
|
255 |
- \ref EdmondsKarp Edmonds-Karp algorithm.
|
kpeter@406
|
256 |
- \ref Preflow Goldberg-Tarjan's preflow push-relabel algorithm.
|
kpeter@406
|
257 |
- \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees.
|
kpeter@406
|
258 |
- \ref GoldbergTarjan Preflow push-relabel algorithm with dynamic trees.
|
alpar@40
|
259 |
|
kpeter@406
|
260 |
In most cases the \ref Preflow "Preflow" algorithm provides the
|
kpeter@406
|
261 |
fastest method for computing a maximum flow. All implementations
|
kpeter@406
|
262 |
provides functions to also query the minimum cut, which is the dual
|
kpeter@406
|
263 |
problem of the maximum flow.
|
alpar@40
|
264 |
*/
|
alpar@40
|
265 |
|
alpar@40
|
266 |
/**
|
kpeter@314
|
267 |
@defgroup min_cost_flow Minimum Cost Flow Algorithms
|
alpar@40
|
268 |
@ingroup algs
|
alpar@40
|
269 |
|
kpeter@50
|
270 |
\brief Algorithms for finding minimum cost flows and circulations.
|
alpar@40
|
271 |
|
alpar@40
|
272 |
This group describes the algorithms for finding minimum cost flows and
|
alpar@209
|
273 |
circulations.
|
kpeter@406
|
274 |
|
kpeter@406
|
275 |
The \e minimum \e cost \e flow \e problem is to find a feasible flow of
|
kpeter@406
|
276 |
minimum total cost from a set of supply nodes to a set of demand nodes
|
kpeter@406
|
277 |
in a network with capacity constraints and arc costs.
|
kpeter@406
|
278 |
Formally, let \f$G=(V,A)\f$ be a digraph,
|
kpeter@406
|
279 |
\f$lower, upper: A\rightarrow\mathbf{Z}^+_0\f$ denote the lower and
|
kpeter@406
|
280 |
upper bounds for the flow values on the arcs,
|
kpeter@406
|
281 |
\f$cost: A\rightarrow\mathbf{Z}^+_0\f$ denotes the cost per unit flow
|
kpeter@406
|
282 |
on the arcs, and
|
kpeter@406
|
283 |
\f$supply: V\rightarrow\mathbf{Z}\f$ denotes the supply/demand values
|
kpeter@406
|
284 |
of the nodes.
|
kpeter@406
|
285 |
A minimum cost flow is an \f$f:A\rightarrow\mathbf{R}^+_0\f$ solution of
|
kpeter@406
|
286 |
the following optimization problem.
|
kpeter@406
|
287 |
|
kpeter@406
|
288 |
\f[ \min\sum_{a\in A} f(a) cost(a) \f]
|
kpeter@406
|
289 |
\f[ \sum_{a\in\delta_{out}(v)} f(a) - \sum_{a\in\delta_{in}(v)} f(a) =
|
kpeter@406
|
290 |
supply(v) \qquad \forall v\in V \f]
|
kpeter@406
|
291 |
\f[ lower(a) \leq f(a) \leq upper(a) \qquad \forall a\in A \f]
|
kpeter@406
|
292 |
|
kpeter@406
|
293 |
LEMON contains several algorithms for solving minimum cost flow problems:
|
kpeter@406
|
294 |
- \ref CycleCanceling Cycle-canceling algorithms.
|
kpeter@406
|
295 |
- \ref CapacityScaling Successive shortest path algorithm with optional
|
kpeter@406
|
296 |
capacity scaling.
|
kpeter@406
|
297 |
- \ref CostScaling Push-relabel and augment-relabel algorithms based on
|
kpeter@406
|
298 |
cost scaling.
|
kpeter@406
|
299 |
- \ref NetworkSimplex Primal network simplex algorithm with various
|
kpeter@406
|
300 |
pivot strategies.
|
alpar@40
|
301 |
*/
|
alpar@40
|
302 |
|
alpar@40
|
303 |
/**
|
kpeter@314
|
304 |
@defgroup min_cut Minimum Cut Algorithms
|
alpar@209
|
305 |
@ingroup algs
|
alpar@40
|
306 |
|
kpeter@50
|
307 |
\brief Algorithms for finding minimum cut in graphs.
|
alpar@40
|
308 |
|
alpar@40
|
309 |
This group describes the algorithms for finding minimum cut in graphs.
|
alpar@40
|
310 |
|
kpeter@406
|
311 |
The \e minimum \e cut \e problem is to find a non-empty and non-complete
|
kpeter@406
|
312 |
\f$X\f$ subset of the nodes with minimum overall capacity on
|
kpeter@406
|
313 |
outgoing arcs. Formally, there is a \f$G=(V,A)\f$ digraph, a
|
kpeter@406
|
314 |
\f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum
|
kpeter@50
|
315 |
cut is the \f$X\f$ solution of the next optimization problem:
|
alpar@40
|
316 |
|
alpar@210
|
317 |
\f[ \min_{X \subset V, X\not\in \{\emptyset, V\}}
|
kpeter@406
|
318 |
\sum_{uv\in A, u\in X, v\not\in X}cap(uv) \f]
|
alpar@40
|
319 |
|
kpeter@50
|
320 |
LEMON contains several algorithms related to minimum cut problems:
|
alpar@40
|
321 |
|
kpeter@406
|
322 |
- \ref HaoOrlin "Hao-Orlin algorithm" for calculating minimum cut
|
kpeter@406
|
323 |
in directed graphs.
|
kpeter@406
|
324 |
- \ref NagamochiIbaraki "Nagamochi-Ibaraki algorithm" for
|
kpeter@406
|
325 |
calculating minimum cut in undirected graphs.
|
kpeter@406
|
326 |
- \ref GomoryHuTree "Gomory-Hu tree computation" for calculating
|
kpeter@406
|
327 |
all-pairs minimum cut in undirected graphs.
|
alpar@40
|
328 |
|
alpar@40
|
329 |
If you want to find minimum cut just between two distinict nodes,
|
kpeter@406
|
330 |
see the \ref max_flow "maximum flow problem".
|
alpar@40
|
331 |
*/
|
alpar@40
|
332 |
|
alpar@40
|
333 |
/**
|
kpeter@314
|
334 |
@defgroup graph_prop Connectivity and Other Graph Properties
|
alpar@40
|
335 |
@ingroup algs
|
kpeter@50
|
336 |
\brief Algorithms for discovering the graph properties
|
alpar@40
|
337 |
|
kpeter@50
|
338 |
This group describes the algorithms for discovering the graph properties
|
kpeter@50
|
339 |
like connectivity, bipartiteness, euler property, simplicity etc.
|
alpar@40
|
340 |
|
alpar@40
|
341 |
\image html edge_biconnected_components.png
|
alpar@40
|
342 |
\image latex edge_biconnected_components.eps "bi-edge-connected components" width=\textwidth
|
alpar@40
|
343 |
*/
|
alpar@40
|
344 |
|
alpar@40
|
345 |
/**
|
kpeter@314
|
346 |
@defgroup planar Planarity Embedding and Drawing
|
alpar@40
|
347 |
@ingroup algs
|
kpeter@50
|
348 |
\brief Algorithms for planarity checking, embedding and drawing
|
alpar@40
|
349 |
|
alpar@210
|
350 |
This group describes the algorithms for planarity checking,
|
alpar@210
|
351 |
embedding and drawing.
|
alpar@40
|
352 |
|
alpar@40
|
353 |
\image html planar.png
|
alpar@40
|
354 |
\image latex planar.eps "Plane graph" width=\textwidth
|
alpar@40
|
355 |
*/
|
alpar@40
|
356 |
|
alpar@40
|
357 |
/**
|
kpeter@314
|
358 |
@defgroup matching Matching Algorithms
|
alpar@40
|
359 |
@ingroup algs
|
kpeter@50
|
360 |
\brief Algorithms for finding matchings in graphs and bipartite graphs.
|
alpar@40
|
361 |
|
kpeter@50
|
362 |
This group contains algorithm objects and functions to calculate
|
alpar@40
|
363 |
matchings in graphs and bipartite graphs. The general matching problem is
|
kpeter@83
|
364 |
finding a subset of the arcs which does not shares common endpoints.
|
alpar@209
|
365 |
|
alpar@40
|
366 |
There are several different algorithms for calculate matchings in
|
alpar@40
|
367 |
graphs. The matching problems in bipartite graphs are generally
|
alpar@40
|
368 |
easier than in general graphs. The goal of the matching optimization
|
kpeter@406
|
369 |
can be finding maximum cardinality, maximum weight or minimum cost
|
alpar@40
|
370 |
matching. The search can be constrained to find perfect or
|
alpar@40
|
371 |
maximum cardinality matching.
|
alpar@40
|
372 |
|
kpeter@406
|
373 |
The matching algorithms implemented in LEMON:
|
kpeter@406
|
374 |
- \ref MaxBipartiteMatching Hopcroft-Karp augmenting path algorithm
|
kpeter@406
|
375 |
for calculating maximum cardinality matching in bipartite graphs.
|
kpeter@406
|
376 |
- \ref PrBipartiteMatching Push-relabel algorithm
|
kpeter@406
|
377 |
for calculating maximum cardinality matching in bipartite graphs.
|
kpeter@406
|
378 |
- \ref MaxWeightedBipartiteMatching
|
kpeter@406
|
379 |
Successive shortest path algorithm for calculating maximum weighted
|
kpeter@406
|
380 |
matching and maximum weighted bipartite matching in bipartite graphs.
|
kpeter@406
|
381 |
- \ref MinCostMaxBipartiteMatching
|
kpeter@406
|
382 |
Successive shortest path algorithm for calculating minimum cost maximum
|
kpeter@406
|
383 |
matching in bipartite graphs.
|
kpeter@406
|
384 |
- \ref MaxMatching Edmond's blossom shrinking algorithm for calculating
|
kpeter@406
|
385 |
maximum cardinality matching in general graphs.
|
kpeter@406
|
386 |
- \ref MaxWeightedMatching Edmond's blossom shrinking algorithm for calculating
|
kpeter@406
|
387 |
maximum weighted matching in general graphs.
|
kpeter@406
|
388 |
- \ref MaxWeightedPerfectMatching
|
kpeter@406
|
389 |
Edmond's blossom shrinking algorithm for calculating maximum weighted
|
kpeter@406
|
390 |
perfect matching in general graphs.
|
alpar@40
|
391 |
|
alpar@40
|
392 |
\image html bipartite_matching.png
|
alpar@40
|
393 |
\image latex bipartite_matching.eps "Bipartite Matching" width=\textwidth
|
alpar@40
|
394 |
*/
|
alpar@40
|
395 |
|
alpar@40
|
396 |
/**
|
kpeter@314
|
397 |
@defgroup spantree Minimum Spanning Tree Algorithms
|
alpar@40
|
398 |
@ingroup algs
|
kpeter@50
|
399 |
\brief Algorithms for finding a minimum cost spanning tree in a graph.
|
alpar@40
|
400 |
|
kpeter@50
|
401 |
This group describes the algorithms for finding a minimum cost spanning
|
kpeter@406
|
402 |
tree in a graph.
|
alpar@40
|
403 |
*/
|
alpar@40
|
404 |
|
alpar@40
|
405 |
/**
|
kpeter@314
|
406 |
@defgroup auxalg Auxiliary Algorithms
|
alpar@40
|
407 |
@ingroup algs
|
kpeter@50
|
408 |
\brief Auxiliary algorithms implemented in LEMON.
|
alpar@40
|
409 |
|
kpeter@50
|
410 |
This group describes some algorithms implemented in LEMON
|
kpeter@50
|
411 |
in order to make it easier to implement complex algorithms.
|
alpar@40
|
412 |
*/
|
alpar@40
|
413 |
|
alpar@40
|
414 |
/**
|
kpeter@314
|
415 |
@defgroup approx Approximation Algorithms
|
kpeter@314
|
416 |
@ingroup algs
|
kpeter@50
|
417 |
\brief Approximation algorithms.
|
alpar@40
|
418 |
|
kpeter@50
|
419 |
This group describes the approximation and heuristic algorithms
|
kpeter@50
|
420 |
implemented in LEMON.
|
alpar@40
|
421 |
*/
|
alpar@40
|
422 |
|
alpar@40
|
423 |
/**
|
alpar@40
|
424 |
@defgroup gen_opt_group General Optimization Tools
|
alpar@40
|
425 |
\brief This group describes some general optimization frameworks
|
alpar@40
|
426 |
implemented in LEMON.
|
alpar@40
|
427 |
|
alpar@40
|
428 |
This group describes some general optimization frameworks
|
alpar@40
|
429 |
implemented in LEMON.
|
alpar@40
|
430 |
*/
|
alpar@40
|
431 |
|
alpar@40
|
432 |
/**
|
kpeter@314
|
433 |
@defgroup lp_group Lp and Mip Solvers
|
alpar@40
|
434 |
@ingroup gen_opt_group
|
alpar@40
|
435 |
\brief Lp and Mip solver interfaces for LEMON.
|
alpar@40
|
436 |
|
alpar@40
|
437 |
This group describes Lp and Mip solver interfaces for LEMON. The
|
alpar@40
|
438 |
various LP solvers could be used in the same manner with this
|
alpar@40
|
439 |
interface.
|
alpar@40
|
440 |
*/
|
alpar@40
|
441 |
|
alpar@209
|
442 |
/**
|
kpeter@314
|
443 |
@defgroup lp_utils Tools for Lp and Mip Solvers
|
alpar@40
|
444 |
@ingroup lp_group
|
kpeter@50
|
445 |
\brief Helper tools to the Lp and Mip solvers.
|
alpar@40
|
446 |
|
alpar@40
|
447 |
This group adds some helper tools to general optimization framework
|
alpar@40
|
448 |
implemented in LEMON.
|
alpar@40
|
449 |
*/
|
alpar@40
|
450 |
|
alpar@40
|
451 |
/**
|
alpar@40
|
452 |
@defgroup metah Metaheuristics
|
alpar@40
|
453 |
@ingroup gen_opt_group
|
alpar@40
|
454 |
\brief Metaheuristics for LEMON library.
|
alpar@40
|
455 |
|
kpeter@50
|
456 |
This group describes some metaheuristic optimization tools.
|
alpar@40
|
457 |
*/
|
alpar@40
|
458 |
|
alpar@40
|
459 |
/**
|
alpar@209
|
460 |
@defgroup utils Tools and Utilities
|
kpeter@50
|
461 |
\brief Tools and utilities for programming in LEMON
|
alpar@40
|
462 |
|
kpeter@50
|
463 |
Tools and utilities for programming in LEMON.
|
alpar@40
|
464 |
*/
|
alpar@40
|
465 |
|
alpar@40
|
466 |
/**
|
alpar@40
|
467 |
@defgroup gutils Basic Graph Utilities
|
alpar@40
|
468 |
@ingroup utils
|
kpeter@50
|
469 |
\brief Simple basic graph utilities.
|
alpar@40
|
470 |
|
alpar@40
|
471 |
This group describes some simple basic graph utilities.
|
alpar@40
|
472 |
*/
|
alpar@40
|
473 |
|
alpar@40
|
474 |
/**
|
alpar@40
|
475 |
@defgroup misc Miscellaneous Tools
|
alpar@40
|
476 |
@ingroup utils
|
kpeter@50
|
477 |
\brief Tools for development, debugging and testing.
|
kpeter@50
|
478 |
|
kpeter@50
|
479 |
This group describes several useful tools for development,
|
alpar@40
|
480 |
debugging and testing.
|
alpar@40
|
481 |
*/
|
alpar@40
|
482 |
|
alpar@40
|
483 |
/**
|
kpeter@314
|
484 |
@defgroup timecount Time Measuring and Counting
|
alpar@40
|
485 |
@ingroup misc
|
kpeter@50
|
486 |
\brief Simple tools for measuring the performance of algorithms.
|
kpeter@50
|
487 |
|
kpeter@50
|
488 |
This group describes simple tools for measuring the performance
|
alpar@40
|
489 |
of algorithms.
|
alpar@40
|
490 |
*/
|
alpar@40
|
491 |
|
alpar@40
|
492 |
/**
|
alpar@40
|
493 |
@defgroup exceptions Exceptions
|
alpar@40
|
494 |
@ingroup utils
|
kpeter@50
|
495 |
\brief Exceptions defined in LEMON.
|
kpeter@50
|
496 |
|
kpeter@50
|
497 |
This group describes the exceptions defined in LEMON.
|
alpar@40
|
498 |
*/
|
alpar@40
|
499 |
|
alpar@40
|
500 |
/**
|
alpar@40
|
501 |
@defgroup io_group Input-Output
|
kpeter@50
|
502 |
\brief Graph Input-Output methods
|
alpar@40
|
503 |
|
alpar@209
|
504 |
This group describes the tools for importing and exporting graphs
|
kpeter@314
|
505 |
and graph related data. Now it supports the \ref lgf-format
|
kpeter@314
|
506 |
"LEMON Graph Format", the \c DIMACS format and the encapsulated
|
kpeter@314
|
507 |
postscript (EPS) format.
|
alpar@40
|
508 |
*/
|
alpar@40
|
509 |
|
alpar@40
|
510 |
/**
|
kpeter@351
|
511 |
@defgroup lemon_io LEMON Graph Format
|
alpar@40
|
512 |
@ingroup io_group
|
kpeter@314
|
513 |
\brief Reading and writing LEMON Graph Format.
|
alpar@40
|
514 |
|
alpar@210
|
515 |
This group describes methods for reading and writing
|
ladanyi@236
|
516 |
\ref lgf-format "LEMON Graph Format".
|
alpar@40
|
517 |
*/
|
alpar@40
|
518 |
|
alpar@40
|
519 |
/**
|
kpeter@314
|
520 |
@defgroup eps_io Postscript Exporting
|
alpar@40
|
521 |
@ingroup io_group
|
alpar@40
|
522 |
\brief General \c EPS drawer and graph exporter
|
alpar@40
|
523 |
|
kpeter@50
|
524 |
This group describes general \c EPS drawing methods and special
|
alpar@209
|
525 |
graph exporting tools.
|
alpar@40
|
526 |
*/
|
alpar@40
|
527 |
|
alpar@40
|
528 |
/**
|
kpeter@388
|
529 |
@defgroup dimacs_group DIMACS format
|
kpeter@388
|
530 |
@ingroup io_group
|
kpeter@388
|
531 |
\brief Read and write files in DIMACS format
|
kpeter@388
|
532 |
|
kpeter@388
|
533 |
Tools to read a digraph from or write it to a file in DIMACS format data.
|
kpeter@388
|
534 |
*/
|
kpeter@388
|
535 |
|
kpeter@388
|
536 |
/**
|
kpeter@351
|
537 |
@defgroup nauty_group NAUTY Format
|
kpeter@351
|
538 |
@ingroup io_group
|
kpeter@351
|
539 |
\brief Read \e Nauty format
|
kpeter@388
|
540 |
|
kpeter@351
|
541 |
Tool to read graphs from \e Nauty format data.
|
kpeter@351
|
542 |
*/
|
kpeter@351
|
543 |
|
kpeter@351
|
544 |
/**
|
alpar@40
|
545 |
@defgroup concept Concepts
|
alpar@40
|
546 |
\brief Skeleton classes and concept checking classes
|
alpar@40
|
547 |
|
alpar@40
|
548 |
This group describes the data/algorithm skeletons and concept checking
|
alpar@40
|
549 |
classes implemented in LEMON.
|
alpar@40
|
550 |
|
alpar@40
|
551 |
The purpose of the classes in this group is fourfold.
|
alpar@209
|
552 |
|
kpeter@318
|
553 |
- These classes contain the documentations of the %concepts. In order
|
alpar@40
|
554 |
to avoid document multiplications, an implementation of a concept
|
alpar@40
|
555 |
simply refers to the corresponding concept class.
|
alpar@40
|
556 |
|
alpar@40
|
557 |
- These classes declare every functions, <tt>typedef</tt>s etc. an
|
kpeter@318
|
558 |
implementation of the %concepts should provide, however completely
|
alpar@40
|
559 |
without implementations and real data structures behind the
|
alpar@40
|
560 |
interface. On the other hand they should provide nothing else. All
|
alpar@40
|
561 |
the algorithms working on a data structure meeting a certain concept
|
alpar@40
|
562 |
should compile with these classes. (Though it will not run properly,
|
alpar@40
|
563 |
of course.) In this way it is easily to check if an algorithm
|
alpar@40
|
564 |
doesn't use any extra feature of a certain implementation.
|
alpar@40
|
565 |
|
alpar@40
|
566 |
- The concept descriptor classes also provide a <em>checker class</em>
|
kpeter@50
|
567 |
that makes it possible to check whether a certain implementation of a
|
alpar@40
|
568 |
concept indeed provides all the required features.
|
alpar@40
|
569 |
|
alpar@40
|
570 |
- Finally, They can serve as a skeleton of a new implementation of a concept.
|
alpar@40
|
571 |
*/
|
alpar@40
|
572 |
|
alpar@40
|
573 |
/**
|
alpar@40
|
574 |
@defgroup graph_concepts Graph Structure Concepts
|
alpar@40
|
575 |
@ingroup concept
|
alpar@40
|
576 |
\brief Skeleton and concept checking classes for graph structures
|
alpar@40
|
577 |
|
kpeter@50
|
578 |
This group describes the skeletons and concept checking classes of LEMON's
|
alpar@40
|
579 |
graph structures and helper classes used to implement these.
|
alpar@40
|
580 |
*/
|
alpar@40
|
581 |
|
kpeter@314
|
582 |
/**
|
kpeter@314
|
583 |
@defgroup map_concepts Map Concepts
|
kpeter@314
|
584 |
@ingroup concept
|
kpeter@314
|
585 |
\brief Skeleton and concept checking classes for maps
|
kpeter@314
|
586 |
|
kpeter@314
|
587 |
This group describes the skeletons and concept checking classes of maps.
|
alpar@40
|
588 |
*/
|
alpar@40
|
589 |
|
alpar@40
|
590 |
/**
|
alpar@40
|
591 |
\anchor demoprograms
|
alpar@40
|
592 |
|
kpeter@406
|
593 |
@defgroup demos Demo Programs
|
alpar@40
|
594 |
|
alpar@40
|
595 |
Some demo programs are listed here. Their full source codes can be found in
|
alpar@40
|
596 |
the \c demo subdirectory of the source tree.
|
alpar@40
|
597 |
|
alpar@41
|
598 |
It order to compile them, use <tt>--enable-demo</tt> configure option when
|
alpar@41
|
599 |
build the library.
|
alpar@40
|
600 |
*/
|
alpar@40
|
601 |
|
alpar@40
|
602 |
/**
|
kpeter@406
|
603 |
@defgroup tools Standalone Utility Applications
|
alpar@40
|
604 |
|
alpar@209
|
605 |
Some utility applications are listed here.
|
alpar@40
|
606 |
|
alpar@40
|
607 |
The standard compilation procedure (<tt>./configure;make</tt>) will compile
|
alpar@209
|
608 |
them, as well.
|
alpar@40
|
609 |
*/
|
alpar@40
|
610 |
|
kpeter@406
|
611 |
}
|