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