0
4
0
1 | 1 |
LEMON code without an explicit copyright notice is covered by the following |
2 | 2 |
copyright/license. |
3 | 3 |
|
4 |
Copyright (C) 2003- |
|
4 |
Copyright (C) 2003-2010 Egervary Jeno Kombinatorikus Optimalizalasi |
|
5 | 5 |
Kutatocsoport (Egervary Combinatorial Optimization Research Group, |
6 | 6 |
EGRES). |
7 | 7 |
|
8 | 8 |
=========================================================================== |
9 | 9 |
Boost Software License, Version 1.0 |
10 | 10 |
=========================================================================== |
11 | 11 |
|
12 | 12 |
Permission is hereby granted, free of charge, to any person or organization |
13 | 13 |
obtaining a copy of the software and accompanying documentation covered by |
14 | 14 |
this license (the "Software") to use, reproduce, display, distribute, |
15 | 15 |
execute, and transmit the Software, and to prepare derivative works of the |
16 | 16 |
Software, and to permit third-parties to whom the Software is furnished to |
17 | 17 |
do so, all subject to the following: |
18 | 18 |
|
19 | 19 |
The copyright notices in the Software and this entire statement, including |
20 | 20 |
the above license grant, this restriction and the following disclaimer, |
21 | 21 |
must be included in all copies of the Software, in whole or in part, and |
22 | 22 |
all derivative works of the Software, unless such copies or derivative |
23 | 23 |
works are solely in the form of machine-executable object code generated by |
24 | 24 |
a source language processor. |
25 | 25 |
|
26 | 26 |
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR |
27 | 27 |
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, |
28 | 28 |
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT |
29 | 29 |
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE |
30 | 30 |
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, |
31 | 31 |
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER |
32 | 32 |
DEALINGS IN THE SOFTWARE. |
1 | 1 |
/* -*- mode: C++; indent-tabs-mode: nil; -*- |
2 | 2 |
* |
3 | 3 |
* This file is a part of LEMON, a generic C++ optimization library. |
4 | 4 |
* |
5 | 5 |
* Copyright (C) 2003-2010 |
6 | 6 |
* Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport |
7 | 7 |
* (Egervary Research Group on Combinatorial Optimization, EGRES). |
8 | 8 |
* |
9 | 9 |
* Permission to use, modify and distribute this software is granted |
10 | 10 |
* provided that this copyright notice appears in all copies. For |
11 | 11 |
* precise terms see the accompanying LICENSE file. |
12 | 12 |
* |
13 | 13 |
* This software is provided "AS IS" with no warranty of any kind, |
14 | 14 |
* express or implied, and with no claim as to its suitability for any |
15 | 15 |
* purpose. |
16 | 16 |
* |
17 | 17 |
*/ |
18 | 18 |
|
19 | 19 |
namespace lemon { |
20 | 20 |
|
21 | 21 |
/** |
22 | 22 |
@defgroup datas Data Structures |
23 | 23 |
This group contains the several data structures implemented in LEMON. |
24 | 24 |
*/ |
25 | 25 |
|
26 | 26 |
/** |
27 | 27 |
@defgroup graphs Graph Structures |
28 | 28 |
@ingroup datas |
29 | 29 |
\brief Graph structures implemented in LEMON. |
30 | 30 |
|
31 | 31 |
The implementation of combinatorial algorithms heavily relies on |
32 | 32 |
efficient graph implementations. LEMON offers data structures which are |
33 | 33 |
planned to be easily used in an experimental phase of implementation studies, |
34 | 34 |
and thereafter the program code can be made efficient by small modifications. |
35 | 35 |
|
36 | 36 |
The most efficient implementation of diverse applications require the |
37 | 37 |
usage of different physical graph implementations. These differences |
38 | 38 |
appear in the size of graph we require to handle, memory or time usage |
39 | 39 |
limitations or in the set of operations through which the graph can be |
40 | 40 |
accessed. LEMON provides several physical graph structures to meet |
41 | 41 |
the diverging requirements of the possible users. In order to save on |
42 | 42 |
running time or on memory usage, some structures may fail to provide |
43 | 43 |
some graph features like arc/edge or node deletion. |
44 | 44 |
|
45 | 45 |
Alteration of standard containers need a very limited number of |
46 | 46 |
operations, these together satisfy the everyday requirements. |
47 | 47 |
In the case of graph structures, different operations are needed which do |
48 | 48 |
not alter the physical graph, but gives another view. If some nodes or |
49 | 49 |
arcs have to be hidden or the reverse oriented graph have to be used, then |
50 | 50 |
this is the case. It also may happen that in a flow implementation |
51 | 51 |
the residual graph can be accessed by another algorithm, or a node-set |
52 | 52 |
is to be shrunk for another algorithm. |
53 | 53 |
LEMON also provides a variety of graphs for these requirements called |
54 | 54 |
\ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only |
55 | 55 |
in conjunction with other graph representations. |
56 | 56 |
|
57 | 57 |
You are free to use the graph structure that fit your requirements |
58 | 58 |
the best, most graph algorithms and auxiliary data structures can be used |
59 | 59 |
with any graph structure. |
60 | 60 |
|
61 | 61 |
<b>See also:</b> \ref graph_concepts "Graph Structure Concepts". |
62 | 62 |
*/ |
63 | 63 |
|
64 | 64 |
/** |
65 | 65 |
@defgroup graph_adaptors Adaptor Classes for Graphs |
66 | 66 |
@ingroup graphs |
67 | 67 |
\brief Adaptor classes for digraphs and graphs |
68 | 68 |
|
69 | 69 |
This group contains several useful adaptor classes for digraphs and graphs. |
70 | 70 |
|
71 | 71 |
The main parts of LEMON are the different graph structures, generic |
72 | 72 |
graph algorithms, graph concepts, which couple them, and graph |
73 | 73 |
adaptors. While the previous notions are more or less clear, the |
74 | 74 |
latter one needs further explanation. Graph adaptors are graph classes |
75 | 75 |
which serve for considering graph structures in different ways. |
76 | 76 |
|
77 | 77 |
A short example makes this much clearer. Suppose that we have an |
78 | 78 |
instance \c g of a directed graph type, say ListDigraph and an algorithm |
79 | 79 |
\code |
80 | 80 |
template <typename Digraph> |
81 | 81 |
int algorithm(const Digraph&); |
82 | 82 |
\endcode |
83 | 83 |
is needed to run on the reverse oriented graph. It may be expensive |
84 | 84 |
(in time or in memory usage) to copy \c g with the reversed |
85 | 85 |
arcs. In this case, an adaptor class is used, which (according |
86 | 86 |
to LEMON \ref concepts::Digraph "digraph concepts") works as a digraph. |
87 | 87 |
The adaptor uses the original digraph structure and digraph operations when |
88 | 88 |
methods of the reversed oriented graph are called. This means that the adaptor |
89 | 89 |
have minor memory usage, and do not perform sophisticated algorithmic |
90 | 90 |
actions. The purpose of it is to give a tool for the cases when a |
91 | 91 |
graph have to be used in a specific alteration. If this alteration is |
92 | 92 |
obtained by a usual construction like filtering the node or the arc set or |
93 | 93 |
considering a new orientation, then an adaptor is worthwhile to use. |
94 | 94 |
To come back to the reverse oriented graph, in this situation |
95 | 95 |
\code |
96 | 96 |
template<typename Digraph> class ReverseDigraph; |
97 | 97 |
\endcode |
98 | 98 |
template class can be used. The code looks as follows |
99 | 99 |
\code |
100 | 100 |
ListDigraph g; |
101 | 101 |
ReverseDigraph<ListDigraph> rg(g); |
102 | 102 |
int result = algorithm(rg); |
103 | 103 |
\endcode |
104 | 104 |
During running the algorithm, the original digraph \c g is untouched. |
105 | 105 |
This techniques give rise to an elegant code, and based on stable |
106 | 106 |
graph adaptors, complex algorithms can be implemented easily. |
107 | 107 |
|
108 | 108 |
In flow, circulation and matching problems, the residual |
109 | 109 |
graph is of particular importance. Combining an adaptor implementing |
110 | 110 |
this with shortest path algorithms or minimum mean cycle algorithms, |
111 | 111 |
a range of weighted and cardinality optimization algorithms can be |
112 | 112 |
obtained. For other examples, the interested user is referred to the |
113 | 113 |
detailed documentation of particular adaptors. |
114 | 114 |
|
115 | 115 |
The behavior of graph adaptors can be very different. Some of them keep |
116 | 116 |
capabilities of the original graph while in other cases this would be |
117 | 117 |
meaningless. This means that the concepts that they meet depend |
118 | 118 |
on the graph adaptor, and the wrapped graph. |
119 | 119 |
For example, if an arc of a reversed digraph is deleted, this is carried |
120 | 120 |
out by deleting the corresponding arc of the original digraph, thus the |
121 | 121 |
adaptor modifies the original digraph. |
122 | 122 |
However in case of a residual digraph, this operation has no sense. |
123 | 123 |
|
124 | 124 |
Let us stand one more example here to simplify your work. |
125 | 125 |
ReverseDigraph has constructor |
126 | 126 |
\code |
127 | 127 |
ReverseDigraph(Digraph& digraph); |
128 | 128 |
\endcode |
129 | 129 |
This means that in a situation, when a <tt>const %ListDigraph&</tt> |
130 | 130 |
reference to a graph is given, then it have to be instantiated with |
131 | 131 |
<tt>Digraph=const %ListDigraph</tt>. |
132 | 132 |
\code |
133 | 133 |
int algorithm1(const ListDigraph& g) { |
134 | 134 |
ReverseDigraph<const ListDigraph> rg(g); |
135 | 135 |
return algorithm2(rg); |
136 | 136 |
} |
137 | 137 |
\endcode |
138 | 138 |
*/ |
139 | 139 |
|
140 | 140 |
/** |
141 | 141 |
@defgroup maps Maps |
142 | 142 |
@ingroup datas |
143 | 143 |
\brief Map structures implemented in LEMON. |
144 | 144 |
|
145 | 145 |
This group contains the map structures implemented in LEMON. |
146 | 146 |
|
147 | 147 |
LEMON provides several special purpose maps and map adaptors that e.g. combine |
148 | 148 |
new maps from existing ones. |
149 | 149 |
|
150 | 150 |
<b>See also:</b> \ref map_concepts "Map Concepts". |
151 | 151 |
*/ |
152 | 152 |
|
153 | 153 |
/** |
154 | 154 |
@defgroup graph_maps Graph Maps |
155 | 155 |
@ingroup maps |
156 | 156 |
\brief Special graph-related maps. |
157 | 157 |
|
158 | 158 |
This group contains maps that are specifically designed to assign |
159 | 159 |
values to the nodes and arcs/edges of graphs. |
160 | 160 |
|
161 | 161 |
If you are looking for the standard graph maps (\c NodeMap, \c ArcMap, |
162 | 162 |
\c EdgeMap), see the \ref graph_concepts "Graph Structure Concepts". |
163 | 163 |
*/ |
164 | 164 |
|
165 | 165 |
/** |
166 | 166 |
\defgroup map_adaptors Map Adaptors |
167 | 167 |
\ingroup maps |
168 | 168 |
\brief Tools to create new maps from existing ones |
169 | 169 |
|
170 | 170 |
This group contains map adaptors that are used to create "implicit" |
171 | 171 |
maps from other maps. |
172 | 172 |
|
173 | 173 |
Most of them are \ref concepts::ReadMap "read-only maps". |
174 | 174 |
They can make arithmetic and logical operations between one or two maps |
175 | 175 |
(negation, shifting, addition, multiplication, logical 'and', 'or', |
176 | 176 |
'not' etc.) or e.g. convert a map to another one of different Value type. |
177 | 177 |
|
178 | 178 |
The typical usage of this classes is passing implicit maps to |
179 | 179 |
algorithms. If a function type algorithm is called then the function |
180 | 180 |
type map adaptors can be used comfortable. For example let's see the |
181 | 181 |
usage of map adaptors with the \c graphToEps() function. |
182 | 182 |
\code |
183 | 183 |
Color nodeColor(int deg) { |
184 | 184 |
if (deg >= 2) { |
185 | 185 |
return Color(0.5, 0.0, 0.5); |
186 | 186 |
} else if (deg == 1) { |
187 | 187 |
return Color(1.0, 0.5, 1.0); |
188 | 188 |
} else { |
189 | 189 |
return Color(0.0, 0.0, 0.0); |
190 | 190 |
} |
191 | 191 |
} |
192 | 192 |
|
193 | 193 |
Digraph::NodeMap<int> degree_map(graph); |
194 | 194 |
|
195 | 195 |
graphToEps(graph, "graph.eps") |
196 | 196 |
.coords(coords).scaleToA4().undirected() |
197 | 197 |
.nodeColors(composeMap(functorToMap(nodeColor), degree_map)) |
198 | 198 |
.run(); |
199 | 199 |
\endcode |
200 | 200 |
The \c functorToMap() function makes an \c int to \c Color map from the |
201 | 201 |
\c nodeColor() function. The \c composeMap() compose the \c degree_map |
202 | 202 |
and the previously created map. The composed map is a proper function to |
203 | 203 |
get the color of each node. |
204 | 204 |
|
205 | 205 |
The usage with class type algorithms is little bit harder. In this |
206 | 206 |
case the function type map adaptors can not be used, because the |
207 | 207 |
function map adaptors give back temporary objects. |
208 | 208 |
\code |
209 | 209 |
Digraph graph; |
210 | 210 |
|
211 | 211 |
typedef Digraph::ArcMap<double> DoubleArcMap; |
212 | 212 |
DoubleArcMap length(graph); |
213 | 213 |
DoubleArcMap speed(graph); |
214 | 214 |
|
215 | 215 |
typedef DivMap<DoubleArcMap, DoubleArcMap> TimeMap; |
216 | 216 |
TimeMap time(length, speed); |
217 | 217 |
|
218 | 218 |
Dijkstra<Digraph, TimeMap> dijkstra(graph, time); |
219 | 219 |
dijkstra.run(source, target); |
220 | 220 |
\endcode |
221 | 221 |
We have a length map and a maximum speed map on the arcs of a digraph. |
222 | 222 |
The minimum time to pass the arc can be calculated as the division of |
223 | 223 |
the two maps which can be done implicitly with the \c DivMap template |
224 | 224 |
class. We use the implicit minimum time map as the length map of the |
225 | 225 |
\c Dijkstra algorithm. |
226 | 226 |
*/ |
227 | 227 |
|
228 | 228 |
/** |
229 | 229 |
@defgroup paths Path Structures |
230 | 230 |
@ingroup datas |
231 | 231 |
\brief %Path structures implemented in LEMON. |
232 | 232 |
|
233 | 233 |
This group contains the path structures implemented in LEMON. |
234 | 234 |
|
235 | 235 |
LEMON provides flexible data structures to work with paths. |
236 | 236 |
All of them have similar interfaces and they can be copied easily with |
237 | 237 |
assignment operators and copy constructors. This makes it easy and |
238 | 238 |
efficient to have e.g. the Dijkstra algorithm to store its result in |
239 | 239 |
any kind of path structure. |
240 | 240 |
|
241 | 241 |
\sa \ref concepts::Path "Path concept" |
242 | 242 |
*/ |
243 | 243 |
|
244 | 244 |
/** |
245 | 245 |
@defgroup heaps Heap Structures |
246 | 246 |
@ingroup datas |
247 | 247 |
\brief %Heap structures implemented in LEMON. |
248 | 248 |
|
249 | 249 |
This group contains the heap structures implemented in LEMON. |
250 | 250 |
|
251 | 251 |
LEMON provides several heap classes. They are efficient implementations |
252 | 252 |
of the abstract data type \e priority \e queue. They store items with |
253 | 253 |
specified values called \e priorities in such a way that finding and |
254 | 254 |
removing the item with minimum priority are efficient. |
255 | 255 |
The basic operations are adding and erasing items, changing the priority |
256 | 256 |
of an item, etc. |
257 | 257 |
|
258 | 258 |
Heaps are crucial in several algorithms, such as Dijkstra and Prim. |
259 | 259 |
The heap implementations have the same interface, thus any of them can be |
260 | 260 |
used easily in such algorithms. |
261 | 261 |
|
262 | 262 |
\sa \ref concepts::Heap "Heap concept" |
263 | 263 |
*/ |
264 | 264 |
|
265 | 265 |
/** |
266 |
@defgroup matrices Matrices |
|
267 |
@ingroup datas |
|
268 |
\brief Two dimensional data storages implemented in LEMON. |
|
269 |
|
|
270 |
This group contains two dimensional data storages implemented in LEMON. |
|
271 |
*/ |
|
272 |
|
|
273 |
/** |
|
274 | 266 |
@defgroup auxdat Auxiliary Data Structures |
275 | 267 |
@ingroup datas |
276 | 268 |
\brief Auxiliary data structures implemented in LEMON. |
277 | 269 |
|
278 | 270 |
This group contains some data structures implemented in LEMON in |
279 | 271 |
order to make it easier to implement combinatorial algorithms. |
280 | 272 |
*/ |
281 | 273 |
|
282 | 274 |
/** |
283 | 275 |
@defgroup geomdat Geometric Data Structures |
284 | 276 |
@ingroup auxdat |
285 | 277 |
\brief Geometric data structures implemented in LEMON. |
286 | 278 |
|
287 | 279 |
This group contains geometric data structures implemented in LEMON. |
288 | 280 |
|
289 | 281 |
- \ref lemon::dim2::Point "dim2::Point" implements a two dimensional |
290 | 282 |
vector with the usual operations. |
291 | 283 |
- \ref lemon::dim2::Box "dim2::Box" can be used to determine the |
292 | 284 |
rectangular bounding box of a set of \ref lemon::dim2::Point |
293 | 285 |
"dim2::Point"'s. |
294 | 286 |
*/ |
295 | 287 |
|
296 | 288 |
/** |
297 | 289 |
@defgroup matrices Matrices |
298 | 290 |
@ingroup auxdat |
299 | 291 |
\brief Two dimensional data storages implemented in LEMON. |
300 | 292 |
|
301 | 293 |
This group contains two dimensional data storages implemented in LEMON. |
302 | 294 |
*/ |
303 | 295 |
|
304 | 296 |
/** |
305 | 297 |
@defgroup algs Algorithms |
306 | 298 |
\brief This group contains the several algorithms |
307 | 299 |
implemented in LEMON. |
308 | 300 |
|
309 | 301 |
This group contains the several algorithms |
310 | 302 |
implemented in LEMON. |
311 | 303 |
*/ |
312 | 304 |
|
313 | 305 |
/** |
314 | 306 |
@defgroup search Graph Search |
315 | 307 |
@ingroup algs |
316 | 308 |
\brief Common graph search algorithms. |
317 | 309 |
|
318 | 310 |
This group contains the common graph search algorithms, namely |
319 | 311 |
\e breadth-first \e search (BFS) and \e depth-first \e search (DFS) |
320 | 312 |
\ref clrs01algorithms. |
321 | 313 |
*/ |
322 | 314 |
|
323 | 315 |
/** |
324 | 316 |
@defgroup shortest_path Shortest Path Algorithms |
325 | 317 |
@ingroup algs |
326 | 318 |
\brief Algorithms for finding shortest paths. |
327 | 319 |
|
328 | 320 |
This group contains the algorithms for finding shortest paths in digraphs |
329 | 321 |
\ref clrs01algorithms. |
330 | 322 |
|
331 | 323 |
- \ref Dijkstra algorithm for finding shortest paths from a source node |
332 | 324 |
when all arc lengths are non-negative. |
333 | 325 |
- \ref BellmanFord "Bellman-Ford" algorithm for finding shortest paths |
334 | 326 |
from a source node when arc lenghts can be either positive or negative, |
335 | 327 |
but the digraph should not contain directed cycles with negative total |
336 | 328 |
length. |
337 | 329 |
- \ref FloydWarshall "Floyd-Warshall" and \ref Johnson "Johnson" algorithms |
338 | 330 |
for solving the \e all-pairs \e shortest \e paths \e problem when arc |
339 | 331 |
lenghts can be either positive or negative, but the digraph should |
340 | 332 |
not contain directed cycles with negative total length. |
341 | 333 |
- \ref Suurballe A successive shortest path algorithm for finding |
342 | 334 |
arc-disjoint paths between two nodes having minimum total length. |
343 | 335 |
*/ |
344 | 336 |
|
345 | 337 |
/** |
346 | 338 |
@defgroup spantree Minimum Spanning Tree Algorithms |
347 | 339 |
@ingroup algs |
348 | 340 |
\brief Algorithms for finding minimum cost spanning trees and arborescences. |
349 | 341 |
|
350 | 342 |
This group contains the algorithms for finding minimum cost spanning |
351 | 343 |
trees and arborescences \ref clrs01algorithms. |
352 | 344 |
*/ |
353 | 345 |
|
354 | 346 |
/** |
355 | 347 |
@defgroup max_flow Maximum Flow Algorithms |
356 | 348 |
@ingroup algs |
357 | 349 |
\brief Algorithms for finding maximum flows. |
358 | 350 |
|
359 | 351 |
This group contains the algorithms for finding maximum flows and |
360 | 352 |
feasible circulations \ref clrs01algorithms, \ref amo93networkflows. |
361 | 353 |
|
362 | 354 |
The \e maximum \e flow \e problem is to find a flow of maximum value between |
363 | 355 |
a single source and a single target. Formally, there is a \f$G=(V,A)\f$ |
364 | 356 |
digraph, a \f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function and |
365 | 357 |
\f$s, t \in V\f$ source and target nodes. |
366 | 358 |
A maximum flow is an \f$f: A\rightarrow\mathbf{R}^+_0\f$ solution of the |
367 | 359 |
following optimization problem. |
368 | 360 |
|
369 | 361 |
\f[ \max\sum_{sv\in A} f(sv) - \sum_{vs\in A} f(vs) \f] |
370 | 362 |
\f[ \sum_{uv\in A} f(uv) = \sum_{vu\in A} f(vu) |
371 | 363 |
\quad \forall u\in V\setminus\{s,t\} \f] |
372 | 364 |
\f[ 0 \leq f(uv) \leq cap(uv) \quad \forall uv\in A \f] |
373 | 365 |
|
374 | 366 |
LEMON contains several algorithms for solving maximum flow problems: |
375 | 367 |
- \ref EdmondsKarp Edmonds-Karp algorithm |
376 | 368 |
\ref edmondskarp72theoretical. |
377 | 369 |
- \ref Preflow Goldberg-Tarjan's preflow push-relabel algorithm |
378 | 370 |
\ref goldberg88newapproach. |
379 | 371 |
- \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees |
380 | 372 |
\ref dinic70algorithm, \ref sleator83dynamic. |
381 | 373 |
- \ref GoldbergTarjan !Preflow push-relabel algorithm with dynamic trees |
382 | 374 |
\ref goldberg88newapproach, \ref sleator83dynamic. |
383 | 375 |
|
384 | 376 |
In most cases the \ref Preflow algorithm provides the |
385 | 377 |
fastest method for computing a maximum flow. All implementations |
386 | 378 |
also provide functions to query the minimum cut, which is the dual |
387 | 379 |
problem of maximum flow. |
388 | 380 |
|
389 | 381 |
\ref Circulation is a preflow push-relabel algorithm implemented directly |
390 | 382 |
for finding feasible circulations, which is a somewhat different problem, |
391 | 383 |
but it is strongly related to maximum flow. |
392 | 384 |
For more information, see \ref Circulation. |
393 | 385 |
*/ |
394 | 386 |
|
395 | 387 |
/** |
396 | 388 |
@defgroup min_cost_flow_algs Minimum Cost Flow Algorithms |
397 | 389 |
@ingroup algs |
398 | 390 |
|
399 | 391 |
\brief Algorithms for finding minimum cost flows and circulations. |
400 | 392 |
|
401 | 393 |
This group contains the algorithms for finding minimum cost flows and |
402 | 394 |
circulations \ref amo93networkflows. For more information about this |
403 | 395 |
problem and its dual solution, see \ref min_cost_flow |
404 | 396 |
"Minimum Cost Flow Problem". |
405 | 397 |
|
406 | 398 |
LEMON contains several algorithms for this problem. |
407 | 399 |
- \ref NetworkSimplex Primal Network Simplex algorithm with various |
408 | 400 |
pivot strategies \ref dantzig63linearprog, \ref kellyoneill91netsimplex. |
409 | 401 |
- \ref CostScaling Cost Scaling algorithm based on push/augment and |
410 | 402 |
relabel operations \ref goldberg90approximation, \ref goldberg97efficient, |
411 | 403 |
\ref bunnagel98efficient. |
412 | 404 |
- \ref CapacityScaling Capacity Scaling algorithm based on the successive |
413 | 405 |
shortest path method \ref edmondskarp72theoretical. |
414 | 406 |
- \ref CycleCanceling Cycle-Canceling algorithms, two of which are |
415 | 407 |
strongly polynomial \ref klein67primal, \ref goldberg89cyclecanceling. |
416 | 408 |
|
417 | 409 |
In general NetworkSimplex is the most efficient implementation, |
418 | 410 |
but in special cases other algorithms could be faster. |
419 | 411 |
For example, if the total supply and/or capacities are rather small, |
420 | 412 |
CapacityScaling is usually the fastest algorithm (without effective scaling). |
421 | 413 |
*/ |
422 | 414 |
|
423 | 415 |
/** |
424 | 416 |
@defgroup min_cut Minimum Cut Algorithms |
425 | 417 |
@ingroup algs |
426 | 418 |
|
427 | 419 |
\brief Algorithms for finding minimum cut in graphs. |
428 | 420 |
|
429 | 421 |
This group contains the algorithms for finding minimum cut in graphs. |
430 | 422 |
|
431 | 423 |
The \e minimum \e cut \e problem is to find a non-empty and non-complete |
432 | 424 |
\f$X\f$ subset of the nodes with minimum overall capacity on |
433 | 425 |
outgoing arcs. Formally, there is a \f$G=(V,A)\f$ digraph, a |
434 | 426 |
\f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum |
435 | 427 |
cut is the \f$X\f$ solution of the next optimization problem: |
436 | 428 |
|
437 | 429 |
\f[ \min_{X \subset V, X\not\in \{\emptyset, V\}} |
438 | 430 |
\sum_{uv\in A: u\in X, v\not\in X}cap(uv) \f] |
439 | 431 |
|
440 | 432 |
LEMON contains several algorithms related to minimum cut problems: |
441 | 433 |
|
442 | 434 |
- \ref HaoOrlin "Hao-Orlin algorithm" for calculating minimum cut |
443 | 435 |
in directed graphs. |
444 | 436 |
- \ref NagamochiIbaraki "Nagamochi-Ibaraki algorithm" for |
445 | 437 |
calculating minimum cut in undirected graphs. |
446 | 438 |
- \ref GomoryHu "Gomory-Hu tree computation" for calculating |
447 | 439 |
all-pairs minimum cut in undirected graphs. |
448 | 440 |
|
449 | 441 |
If you want to find minimum cut just between two distinict nodes, |
450 | 442 |
see the \ref max_flow "maximum flow problem". |
451 | 443 |
*/ |
452 | 444 |
|
453 | 445 |
/** |
454 | 446 |
@defgroup min_mean_cycle Minimum Mean Cycle Algorithms |
455 | 447 |
@ingroup algs |
456 | 448 |
\brief Algorithms for finding minimum mean cycles. |
457 | 449 |
|
458 | 450 |
This group contains the algorithms for finding minimum mean cycles |
459 | 451 |
\ref clrs01algorithms, \ref amo93networkflows. |
460 | 452 |
|
461 | 453 |
The \e minimum \e mean \e cycle \e problem is to find a directed cycle |
462 | 454 |
of minimum mean length (cost) in a digraph. |
463 | 455 |
The mean length of a cycle is the average length of its arcs, i.e. the |
464 | 456 |
ratio between the total length of the cycle and the number of arcs on it. |
465 | 457 |
|
466 | 458 |
This problem has an important connection to \e conservative \e length |
467 | 459 |
\e functions, too. A length function on the arcs of a digraph is called |
468 | 460 |
conservative if and only if there is no directed cycle of negative total |
469 | 461 |
length. For an arbitrary length function, the negative of the minimum |
470 | 462 |
cycle mean is the smallest \f$\epsilon\f$ value so that increasing the |
471 | 463 |
arc lengths uniformly by \f$\epsilon\f$ results in a conservative length |
472 | 464 |
function. |
473 | 465 |
|
474 | 466 |
LEMON contains three algorithms for solving the minimum mean cycle problem: |
475 |
- \ref |
|
467 |
- \ref KarpMmc Karp's original algorithm \ref amo93networkflows, |
|
476 | 468 |
\ref dasdan98minmeancycle. |
477 |
- \ref |
|
469 |
- \ref HartmannOrlinMmc Hartmann-Orlin's algorithm, which is an improved |
|
478 | 470 |
version of Karp's algorithm \ref dasdan98minmeancycle. |
479 |
- \ref |
|
471 |
- \ref HowardMmc Howard's policy iteration algorithm |
|
480 | 472 |
\ref dasdan98minmeancycle. |
481 | 473 |
|
482 |
In practice, the Howard algorithm proved to be by far the most efficient |
|
483 |
one, though the best known theoretical bound on its running time is |
|
484 |
exponential. |
|
485 |
Both Karp and HartmannOrlin algorithms run in time O(ne) and use space |
|
486 |
O(n<sup>2</sup>+e), but the latter one is typically faster due to the |
|
487 |
applied early termination scheme. |
|
474 |
In practice, the \ref HowardMmc "Howard" algorithm proved to be by far the |
|
475 |
most efficient one, though the best known theoretical bound on its running |
|
476 |
time is exponential. |
|
477 |
Both \ref KarpMmc "Karp" and \ref HartmannOrlinMmc "Hartmann-Orlin" algorithms |
|
478 |
run in time O(ne) and use space O(n<sup>2</sup>+e), but the latter one is |
|
479 |
typically faster due to the applied early termination scheme. |
|
488 | 480 |
*/ |
489 | 481 |
|
490 | 482 |
/** |
491 | 483 |
@defgroup matching Matching Algorithms |
492 | 484 |
@ingroup algs |
493 | 485 |
\brief Algorithms for finding matchings in graphs and bipartite graphs. |
494 | 486 |
|
495 | 487 |
This group contains the algorithms for calculating |
496 | 488 |
matchings in graphs and bipartite graphs. The general matching problem is |
497 | 489 |
finding a subset of the edges for which each node has at most one incident |
498 | 490 |
edge. |
499 | 491 |
|
500 | 492 |
There are several different algorithms for calculate matchings in |
501 | 493 |
graphs. The matching problems in bipartite graphs are generally |
502 | 494 |
easier than in general graphs. The goal of the matching optimization |
503 | 495 |
can be finding maximum cardinality, maximum weight or minimum cost |
504 | 496 |
matching. The search can be constrained to find perfect or |
505 | 497 |
maximum cardinality matching. |
506 | 498 |
|
507 | 499 |
The matching algorithms implemented in LEMON: |
508 | 500 |
- \ref MaxBipartiteMatching Hopcroft-Karp augmenting path algorithm |
509 | 501 |
for calculating maximum cardinality matching in bipartite graphs. |
510 | 502 |
- \ref PrBipartiteMatching Push-relabel algorithm |
511 | 503 |
for calculating maximum cardinality matching in bipartite graphs. |
512 | 504 |
- \ref MaxWeightedBipartiteMatching |
513 | 505 |
Successive shortest path algorithm for calculating maximum weighted |
514 | 506 |
matching and maximum weighted bipartite matching in bipartite graphs. |
515 | 507 |
- \ref MinCostMaxBipartiteMatching |
516 | 508 |
Successive shortest path algorithm for calculating minimum cost maximum |
517 | 509 |
matching in bipartite graphs. |
518 | 510 |
- \ref MaxMatching Edmond's blossom shrinking algorithm for calculating |
519 | 511 |
maximum cardinality matching in general graphs. |
520 | 512 |
- \ref MaxWeightedMatching Edmond's blossom shrinking algorithm for calculating |
521 | 513 |
maximum weighted matching in general graphs. |
522 | 514 |
- \ref MaxWeightedPerfectMatching |
523 | 515 |
Edmond's blossom shrinking algorithm for calculating maximum weighted |
524 | 516 |
perfect matching in general graphs. |
525 | 517 |
- \ref MaxFractionalMatching Push-relabel algorithm for calculating |
526 | 518 |
maximum cardinality fractional matching in general graphs. |
527 | 519 |
- \ref MaxWeightedFractionalMatching Augmenting path algorithm for calculating |
528 | 520 |
maximum weighted fractional matching in general graphs. |
529 | 521 |
- \ref MaxWeightedPerfectFractionalMatching |
530 | 522 |
Augmenting path algorithm for calculating maximum weighted |
531 | 523 |
perfect fractional matching in general graphs. |
532 | 524 |
|
533 | 525 |
\image html matching.png |
534 | 526 |
\image latex matching.eps "Min Cost Perfect Matching" width=\textwidth |
535 | 527 |
*/ |
536 | 528 |
|
537 | 529 |
/** |
538 | 530 |
@defgroup graph_properties Connectivity and Other Graph Properties |
539 | 531 |
@ingroup algs |
540 | 532 |
\brief Algorithms for discovering the graph properties |
541 | 533 |
|
542 | 534 |
This group contains the algorithms for discovering the graph properties |
543 | 535 |
like connectivity, bipartiteness, euler property, simplicity etc. |
544 | 536 |
|
545 | 537 |
\image html connected_components.png |
546 | 538 |
\image latex connected_components.eps "Connected components" width=\textwidth |
547 | 539 |
*/ |
548 | 540 |
|
549 | 541 |
/** |
550 | 542 |
@defgroup planar Planarity Embedding and Drawing |
551 | 543 |
@ingroup algs |
552 | 544 |
\brief Algorithms for planarity checking, embedding and drawing |
553 | 545 |
|
554 | 546 |
This group contains the algorithms for planarity checking, |
555 | 547 |
embedding and drawing. |
556 | 548 |
|
557 | 549 |
\image html planar.png |
558 | 550 |
\image latex planar.eps "Plane graph" width=\textwidth |
559 | 551 |
*/ |
560 | 552 |
|
561 | 553 |
/** |
562 | 554 |
@defgroup approx Approximation Algorithms |
563 | 555 |
@ingroup algs |
564 | 556 |
\brief Approximation algorithms. |
565 | 557 |
|
566 | 558 |
This group contains the approximation and heuristic algorithms |
567 | 559 |
implemented in LEMON. |
568 | 560 |
*/ |
569 | 561 |
|
570 | 562 |
/** |
571 | 563 |
@defgroup auxalg Auxiliary Algorithms |
572 | 564 |
@ingroup algs |
573 | 565 |
\brief Auxiliary algorithms implemented in LEMON. |
574 | 566 |
|
575 | 567 |
This group contains some algorithms implemented in LEMON |
576 | 568 |
in order to make it easier to implement complex algorithms. |
577 | 569 |
*/ |
578 | 570 |
|
579 | 571 |
/** |
580 | 572 |
@defgroup gen_opt_group General Optimization Tools |
581 | 573 |
\brief This group contains some general optimization frameworks |
582 | 574 |
implemented in LEMON. |
583 | 575 |
|
584 | 576 |
This group contains some general optimization frameworks |
585 | 577 |
implemented in LEMON. |
586 | 578 |
*/ |
587 | 579 |
|
588 | 580 |
/** |
589 | 581 |
@defgroup lp_group LP and MIP Solvers |
590 | 582 |
@ingroup gen_opt_group |
591 | 583 |
\brief LP and MIP solver interfaces for LEMON. |
592 | 584 |
|
593 | 585 |
This group contains LP and MIP solver interfaces for LEMON. |
594 | 586 |
Various LP solvers could be used in the same manner with this |
595 | 587 |
high-level interface. |
596 | 588 |
|
597 | 589 |
The currently supported solvers are \ref glpk, \ref clp, \ref cbc, |
598 | 590 |
\ref cplex, \ref soplex. |
599 | 591 |
*/ |
600 | 592 |
|
601 | 593 |
/** |
602 | 594 |
@defgroup lp_utils Tools for Lp and Mip Solvers |
603 | 595 |
@ingroup lp_group |
604 | 596 |
\brief Helper tools to the Lp and Mip solvers. |
605 | 597 |
|
606 | 598 |
This group adds some helper tools to general optimization framework |
607 | 599 |
implemented in LEMON. |
608 | 600 |
*/ |
609 | 601 |
|
610 | 602 |
/** |
611 | 603 |
@defgroup metah Metaheuristics |
612 | 604 |
@ingroup gen_opt_group |
613 | 605 |
\brief Metaheuristics for LEMON library. |
614 | 606 |
|
615 | 607 |
This group contains some metaheuristic optimization tools. |
616 | 608 |
*/ |
617 | 609 |
|
618 | 610 |
/** |
619 | 611 |
@defgroup utils Tools and Utilities |
620 | 612 |
\brief Tools and utilities for programming in LEMON |
621 | 613 |
|
622 | 614 |
Tools and utilities for programming in LEMON. |
623 | 615 |
*/ |
624 | 616 |
|
625 | 617 |
/** |
626 | 618 |
@defgroup gutils Basic Graph Utilities |
627 | 619 |
@ingroup utils |
628 | 620 |
\brief Simple basic graph utilities. |
629 | 621 |
|
630 | 622 |
This group contains some simple basic graph utilities. |
631 | 623 |
*/ |
632 | 624 |
|
633 | 625 |
/** |
634 | 626 |
@defgroup misc Miscellaneous Tools |
635 | 627 |
@ingroup utils |
636 | 628 |
\brief Tools for development, debugging and testing. |
637 | 629 |
|
638 | 630 |
This group contains several useful tools for development, |
639 | 631 |
debugging and testing. |
640 | 632 |
*/ |
641 | 633 |
|
642 | 634 |
/** |
643 | 635 |
@defgroup timecount Time Measuring and Counting |
644 | 636 |
@ingroup misc |
645 | 637 |
\brief Simple tools for measuring the performance of algorithms. |
646 | 638 |
|
647 | 639 |
This group contains simple tools for measuring the performance |
648 | 640 |
of algorithms. |
649 | 641 |
*/ |
650 | 642 |
|
651 | 643 |
/** |
652 | 644 |
@defgroup exceptions Exceptions |
653 | 645 |
@ingroup utils |
654 | 646 |
\brief Exceptions defined in LEMON. |
655 | 647 |
|
656 | 648 |
This group contains the exceptions defined in LEMON. |
657 | 649 |
*/ |
658 | 650 |
|
659 | 651 |
/** |
660 | 652 |
@defgroup io_group Input-Output |
661 | 653 |
\brief Graph Input-Output methods |
662 | 654 |
|
663 | 655 |
This group contains the tools for importing and exporting graphs |
664 | 656 |
and graph related data. Now it supports the \ref lgf-format |
665 | 657 |
"LEMON Graph Format", the \c DIMACS format and the encapsulated |
666 | 658 |
postscript (EPS) format. |
667 | 659 |
*/ |
668 | 660 |
|
669 | 661 |
/** |
670 | 662 |
@defgroup lemon_io LEMON Graph Format |
671 | 663 |
@ingroup io_group |
672 | 664 |
\brief Reading and writing LEMON Graph Format. |
673 | 665 |
|
674 | 666 |
This group contains methods for reading and writing |
675 | 667 |
\ref lgf-format "LEMON Graph Format". |
676 | 668 |
*/ |
677 | 669 |
|
678 | 670 |
/** |
679 | 671 |
@defgroup eps_io Postscript Exporting |
680 | 672 |
@ingroup io_group |
681 | 673 |
\brief General \c EPS drawer and graph exporter |
682 | 674 |
|
683 | 675 |
This group contains general \c EPS drawing methods and special |
684 | 676 |
graph exporting tools. |
685 | 677 |
*/ |
686 | 678 |
|
687 | 679 |
/** |
688 | 680 |
@defgroup dimacs_group DIMACS Format |
689 | 681 |
@ingroup io_group |
690 | 682 |
\brief Read and write files in DIMACS format |
691 | 683 |
|
692 | 684 |
Tools to read a digraph from or write it to a file in DIMACS format data. |
693 | 685 |
*/ |
694 | 686 |
|
695 | 687 |
/** |
696 | 688 |
@defgroup nauty_group NAUTY Format |
697 | 689 |
@ingroup io_group |
698 | 690 |
\brief Read \e Nauty format |
699 | 691 |
|
700 | 692 |
Tool to read graphs from \e Nauty format data. |
701 | 693 |
*/ |
702 | 694 |
|
703 | 695 |
/** |
704 | 696 |
@defgroup concept Concepts |
705 | 697 |
\brief Skeleton classes and concept checking classes |
706 | 698 |
|
707 | 699 |
This group contains the data/algorithm skeletons and concept checking |
708 | 700 |
classes implemented in LEMON. |
709 | 701 |
|
710 | 702 |
The purpose of the classes in this group is fourfold. |
711 | 703 |
|
712 | 704 |
- These classes contain the documentations of the %concepts. In order |
713 | 705 |
to avoid document multiplications, an implementation of a concept |
714 | 706 |
simply refers to the corresponding concept class. |
715 | 707 |
|
716 | 708 |
- These classes declare every functions, <tt>typedef</tt>s etc. an |
717 | 709 |
implementation of the %concepts should provide, however completely |
718 | 710 |
without implementations and real data structures behind the |
719 | 711 |
interface. On the other hand they should provide nothing else. All |
720 | 712 |
the algorithms working on a data structure meeting a certain concept |
721 | 713 |
should compile with these classes. (Though it will not run properly, |
722 | 714 |
of course.) In this way it is easily to check if an algorithm |
723 | 715 |
doesn't use any extra feature of a certain implementation. |
724 | 716 |
|
725 | 717 |
- The concept descriptor classes also provide a <em>checker class</em> |
726 | 718 |
that makes it possible to check whether a certain implementation of a |
727 | 719 |
concept indeed provides all the required features. |
728 | 720 |
|
729 | 721 |
- Finally, They can serve as a skeleton of a new implementation of a concept. |
730 | 722 |
*/ |
731 | 723 |
|
732 | 724 |
/** |
733 | 725 |
@defgroup graph_concepts Graph Structure Concepts |
734 | 726 |
@ingroup concept |
735 | 727 |
\brief Skeleton and concept checking classes for graph structures |
736 | 728 |
|
737 | 729 |
This group contains the skeletons and concept checking classes of |
738 | 730 |
graph structures. |
739 | 731 |
*/ |
740 | 732 |
|
741 | 733 |
/** |
742 | 734 |
@defgroup map_concepts Map Concepts |
743 | 735 |
@ingroup concept |
744 | 736 |
\brief Skeleton and concept checking classes for maps |
745 | 737 |
|
746 | 738 |
This group contains the skeletons and concept checking classes of maps. |
747 | 739 |
*/ |
748 | 740 |
|
749 | 741 |
/** |
750 | 742 |
@defgroup tools Standalone Utility Applications |
751 | 743 |
|
752 | 744 |
Some utility applications are listed here. |
753 | 745 |
|
754 | 746 |
The standard compilation procedure (<tt>./configure;make</tt>) will compile |
755 | 747 |
them, as well. |
756 | 748 |
*/ |
757 | 749 |
|
758 | 750 |
/** |
759 | 751 |
\anchor demoprograms |
760 | 752 |
|
761 | 753 |
@defgroup demos Demo Programs |
762 | 754 |
|
763 | 755 |
Some demo programs are listed here. Their full source codes can be found in |
764 | 756 |
the \c demo subdirectory of the source tree. |
765 | 757 |
|
766 | 758 |
In order to compile them, use the <tt>make demo</tt> or the |
767 | 759 |
<tt>make check</tt> commands. |
768 | 760 |
*/ |
769 | 761 |
|
770 | 762 |
} |
1 | 1 |
/* -*- mode: C++; indent-tabs-mode: nil; -*- |
2 | 2 |
* |
3 | 3 |
* This file is a part of LEMON, a generic C++ optimization library. |
4 | 4 |
* |
5 | 5 |
* Copyright (C) 2003-2010 |
6 | 6 |
* Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport |
7 | 7 |
* (Egervary Research Group on Combinatorial Optimization, EGRES). |
8 | 8 |
* |
9 | 9 |
* Permission to use, modify and distribute this software is granted |
10 | 10 |
* provided that this copyright notice appears in all copies. For |
11 | 11 |
* precise terms see the accompanying LICENSE file. |
12 | 12 |
* |
13 | 13 |
* This software is provided "AS IS" with no warranty of any kind, |
14 | 14 |
* express or implied, and with no claim as to its suitability for any |
15 | 15 |
* purpose. |
16 | 16 |
* |
17 | 17 |
*/ |
18 | 18 |
|
19 | 19 |
#ifndef LEMON_ARG_PARSER_H |
20 | 20 |
#define LEMON_ARG_PARSER_H |
21 | 21 |
|
22 | 22 |
#include <vector> |
23 | 23 |
#include <map> |
24 | 24 |
#include <list> |
25 | 25 |
#include <string> |
26 | 26 |
#include <iostream> |
27 | 27 |
#include <sstream> |
28 | 28 |
#include <algorithm> |
29 | 29 |
#include <lemon/assert.h> |
30 | 30 |
|
31 | 31 |
///\ingroup misc |
32 | 32 |
///\file |
33 | 33 |
///\brief A tool to parse command line arguments. |
34 | 34 |
|
35 | 35 |
namespace lemon { |
36 | 36 |
|
37 | 37 |
///Exception used by ArgParser |
38 |
|
|
39 |
///Exception used by ArgParser. |
|
40 |
/// |
|
38 | 41 |
class ArgParserException : public Exception { |
39 | 42 |
public: |
43 |
/// Reasons for failure |
|
44 |
|
|
45 |
/// Reasons for failure. |
|
46 |
/// |
|
40 | 47 |
enum Reason { |
41 |
HELP, /// <tt>--help</tt> option was given |
|
42 |
UNKNOWN_OPT, /// Unknown option was given |
|
43 |
|
|
48 |
HELP, ///< <tt>--help</tt> option was given. |
|
49 |
UNKNOWN_OPT, ///< Unknown option was given. |
|
50 |
INVALID_OPT ///< Invalid combination of options. |
|
44 | 51 |
}; |
45 | 52 |
|
46 | 53 |
private: |
47 | 54 |
Reason _reason; |
48 | 55 |
|
49 | 56 |
public: |
50 | 57 |
///Constructor |
51 | 58 |
ArgParserException(Reason r) throw() : _reason(r) {} |
52 | 59 |
///Virtual destructor |
53 | 60 |
virtual ~ArgParserException() throw() {} |
54 | 61 |
///A short description of the exception |
55 | 62 |
virtual const char* what() const throw() { |
56 | 63 |
switch(_reason) |
57 | 64 |
{ |
58 | 65 |
case HELP: |
59 | 66 |
return "lemon::ArgParseException: ask for help"; |
60 | 67 |
break; |
61 | 68 |
case UNKNOWN_OPT: |
62 | 69 |
return "lemon::ArgParseException: unknown option"; |
63 | 70 |
break; |
64 | 71 |
case INVALID_OPT: |
65 | 72 |
return "lemon::ArgParseException: invalid combination of options"; |
66 | 73 |
break; |
67 | 74 |
} |
68 | 75 |
return ""; |
69 | 76 |
} |
70 | 77 |
///Return the reason for the failure |
71 | 78 |
Reason reason() const {return _reason; } |
72 | 79 |
}; |
73 | 80 |
|
74 | 81 |
|
75 | 82 |
///Command line arguments parser |
76 | 83 |
|
77 | 84 |
///\ingroup misc |
78 | 85 |
///Command line arguments parser. |
79 | 86 |
/// |
80 | 87 |
///For a complete example see the \ref arg_parser_demo.cc demo file. |
81 | 88 |
class ArgParser { |
82 | 89 |
|
83 | 90 |
static void _showHelp(void *p); |
84 | 91 |
protected: |
85 | 92 |
|
86 | 93 |
int _argc; |
87 | 94 |
const char * const *_argv; |
88 | 95 |
|
89 | 96 |
enum OptType { UNKNOWN=0, BOOL=1, STRING=2, DOUBLE=3, INTEGER=4, FUNC=5 }; |
90 | 97 |
|
91 | 98 |
class ParData { |
92 | 99 |
public: |
93 | 100 |
union { |
94 | 101 |
bool *bool_p; |
95 | 102 |
int *int_p; |
96 | 103 |
double *double_p; |
97 | 104 |
std::string *string_p; |
98 | 105 |
struct { |
99 | 106 |
void (*p)(void *); |
100 | 107 |
void *data; |
101 | 108 |
} func_p; |
102 | 109 |
|
103 | 110 |
}; |
104 | 111 |
std::string help; |
105 | 112 |
bool mandatory; |
106 | 113 |
OptType type; |
107 | 114 |
bool set; |
108 | 115 |
bool ingroup; |
109 | 116 |
bool has_syn; |
110 | 117 |
bool syn; |
111 | 118 |
bool self_delete; |
112 | 119 |
ParData() : mandatory(false), type(UNKNOWN), set(false), ingroup(false), |
113 | 120 |
has_syn(false), syn(false), self_delete(false) {} |
114 | 121 |
}; |
115 | 122 |
|
116 | 123 |
typedef std::map<std::string,ParData> Opts; |
117 | 124 |
Opts _opts; |
118 | 125 |
|
119 | 126 |
class GroupData |
120 | 127 |
{ |
121 | 128 |
public: |
122 | 129 |
typedef std::list<std::string> Opts; |
123 | 130 |
Opts opts; |
124 | 131 |
bool only_one; |
125 | 132 |
bool mandatory; |
126 | 133 |
GroupData() :only_one(false), mandatory(false) {} |
127 | 134 |
}; |
128 | 135 |
|
129 | 136 |
typedef std::map<std::string,GroupData> Groups; |
130 | 137 |
Groups _groups; |
131 | 138 |
|
132 | 139 |
struct OtherArg |
133 | 140 |
{ |
134 | 141 |
std::string name; |
135 | 142 |
std::string help; |
136 | 143 |
OtherArg(std::string n, std::string h) :name(n), help(h) {} |
137 | 144 |
|
138 | 145 |
}; |
139 | 146 |
|
140 | 147 |
std::vector<OtherArg> _others_help; |
141 | 148 |
std::vector<std::string> _file_args; |
142 | 149 |
std::string _command_name; |
143 | 150 |
|
144 | 151 |
|
145 | 152 |
private: |
146 | 153 |
//Bind a function to an option. |
147 | 154 |
|
148 | 155 |
//\param name The name of the option. The leading '-' must be omitted. |
149 | 156 |
//\param help A help string. |
150 | 157 |
//\retval func The function to be called when the option is given. It |
151 | 158 |
// must be of type "void f(void *)" |
152 | 159 |
//\param data Data to be passed to \c func |
153 | 160 |
ArgParser &funcOption(const std::string &name, |
154 | 161 |
const std::string &help, |
155 | 162 |
void (*func)(void *),void *data); |
156 | 163 |
|
157 | 164 |
bool _exit_on_problems; |
158 | 165 |
|
159 | 166 |
void _terminate(ArgParserException::Reason reason) const; |
160 | 167 |
|
161 | 168 |
public: |
162 | 169 |
|
163 | 170 |
///Constructor |
164 | 171 |
ArgParser(int argc, const char * const *argv); |
165 | 172 |
|
166 | 173 |
~ArgParser(); |
167 | 174 |
|
168 | 175 |
///\name Options |
169 | 176 |
/// |
170 | 177 |
|
171 | 178 |
///@{ |
172 | 179 |
|
173 | 180 |
///Add a new integer type option |
174 | 181 |
|
175 | 182 |
///Add a new integer type option. |
176 | 183 |
///\param name The name of the option. The leading '-' must be omitted. |
177 | 184 |
///\param help A help string. |
178 | 185 |
///\param value A default value for the option. |
179 | 186 |
///\param obl Indicate if the option is mandatory. |
180 | 187 |
ArgParser &intOption(const std::string &name, |
181 | 188 |
const std::string &help, |
182 | 189 |
int value=0, bool obl=false); |
183 | 190 |
|
184 | 191 |
///Add a new floating point type option |
185 | 192 |
|
186 | 193 |
///Add a new floating point type option. |
187 | 194 |
///\param name The name of the option. The leading '-' must be omitted. |
188 | 195 |
///\param help A help string. |
189 | 196 |
///\param value A default value for the option. |
190 | 197 |
///\param obl Indicate if the option is mandatory. |
191 | 198 |
ArgParser &doubleOption(const std::string &name, |
192 | 199 |
const std::string &help, |
193 | 200 |
double value=0, bool obl=false); |
194 | 201 |
|
195 | 202 |
///Add a new bool type option |
196 | 203 |
|
197 | 204 |
///Add a new bool type option. |
198 | 205 |
///\param name The name of the option. The leading '-' must be omitted. |
199 | 206 |
///\param help A help string. |
200 | 207 |
///\param value A default value for the option. |
201 | 208 |
///\param obl Indicate if the option is mandatory. |
202 | 209 |
///\note A mandatory bool obtion is of very little use. |
203 | 210 |
ArgParser &boolOption(const std::string &name, |
204 | 211 |
const std::string &help, |
205 | 212 |
bool value=false, bool obl=false); |
206 | 213 |
|
207 | 214 |
///Add a new string type option |
208 | 215 |
|
209 | 216 |
///Add a new string type option. |
210 | 217 |
///\param name The name of the option. The leading '-' must be omitted. |
211 | 218 |
///\param help A help string. |
212 | 219 |
///\param value A default value for the option. |
213 | 220 |
///\param obl Indicate if the option is mandatory. |
214 | 221 |
ArgParser &stringOption(const std::string &name, |
215 | 222 |
const std::string &help, |
216 | 223 |
std::string value="", bool obl=false); |
217 | 224 |
|
218 | 225 |
///Give help string for non-parsed arguments. |
219 | 226 |
|
220 | 227 |
///With this function you can give help string for non-parsed arguments. |
221 | 228 |
///The parameter \c name will be printed in the short usage line, while |
222 | 229 |
///\c help gives a more detailed description. |
223 | 230 |
ArgParser &other(const std::string &name, |
224 | 231 |
const std::string &help=""); |
225 | 232 |
|
226 | 233 |
///@} |
227 | 234 |
|
228 | 235 |
///\name Options with External Storage |
229 | 236 |
///Using this functions, the value of the option will be directly written |
230 | 237 |
///into a variable once the option appears in the command line. |
231 | 238 |
|
232 | 239 |
///@{ |
233 | 240 |
|
234 | 241 |
///Add a new integer type option with a storage reference |
235 | 242 |
|
236 | 243 |
///Add a new integer type option with a storage reference. |
237 | 244 |
///\param name The name of the option. The leading '-' must be omitted. |
238 | 245 |
///\param help A help string. |
239 | 246 |
///\param obl Indicate if the option is mandatory. |
240 | 247 |
///\retval ref The value of the argument will be written to this variable. |
241 | 248 |
ArgParser &refOption(const std::string &name, |
242 | 249 |
const std::string &help, |
243 | 250 |
int &ref, bool obl=false); |
244 | 251 |
|
245 | 252 |
///Add a new floating type option with a storage reference |
246 | 253 |
|
247 | 254 |
///Add a new floating type option with a storage reference. |
248 | 255 |
///\param name The name of the option. The leading '-' must be omitted. |
249 | 256 |
///\param help A help string. |
250 | 257 |
///\param obl Indicate if the option is mandatory. |
251 | 258 |
///\retval ref The value of the argument will be written to this variable. |
252 | 259 |
ArgParser &refOption(const std::string &name, |
253 | 260 |
const std::string &help, |
254 | 261 |
double &ref, bool obl=false); |
255 | 262 |
|
256 | 263 |
///Add a new bool type option with a storage reference |
257 | 264 |
|
258 | 265 |
///Add a new bool type option with a storage reference. |
259 | 266 |
///\param name The name of the option. The leading '-' must be omitted. |
260 | 267 |
///\param help A help string. |
261 | 268 |
///\param obl Indicate if the option is mandatory. |
262 | 269 |
///\retval ref The value of the argument will be written to this variable. |
263 | 270 |
///\note A mandatory bool obtion is of very little use. |
264 | 271 |
ArgParser &refOption(const std::string &name, |
265 | 272 |
const std::string &help, |
266 | 273 |
bool &ref, bool obl=false); |
267 | 274 |
|
268 | 275 |
///Add a new string type option with a storage reference |
269 | 276 |
|
270 | 277 |
///Add a new string type option with a storage reference. |
271 | 278 |
///\param name The name of the option. The leading '-' must be omitted. |
272 | 279 |
///\param help A help string. |
273 | 280 |
///\param obl Indicate if the option is mandatory. |
274 | 281 |
///\retval ref The value of the argument will be written to this variable. |
275 | 282 |
ArgParser &refOption(const std::string &name, |
276 | 283 |
const std::string &help, |
277 | 284 |
std::string &ref, bool obl=false); |
278 | 285 |
|
279 | 286 |
///@} |
280 | 287 |
|
281 | 288 |
///\name Option Groups and Synonyms |
282 | 289 |
/// |
283 | 290 |
|
284 | 291 |
///@{ |
285 | 292 |
|
286 | 293 |
///Bundle some options into a group |
287 | 294 |
|
288 | 295 |
/// You can group some option by calling this function repeatedly for each |
289 | 296 |
/// option to be grouped with the same groupname. |
290 | 297 |
///\param group The group name. |
291 | 298 |
///\param opt The option name. |
292 | 299 |
ArgParser &optionGroup(const std::string &group, |
293 | 300 |
const std::string &opt); |
294 | 301 |
|
295 | 302 |
///Make the members of a group exclusive |
296 | 303 |
|
297 | 304 |
///If you call this function for a group, than at most one of them can be |
298 | 305 |
///given at the same time. |
299 | 306 |
ArgParser &onlyOneGroup(const std::string &group); |
300 | 307 |
|
301 | 308 |
///Make a group mandatory |
302 | 309 |
|
303 | 310 |
///Using this function, at least one of the members of \c group |
304 | 311 |
///must be given. |
305 | 312 |
ArgParser &mandatoryGroup(const std::string &group); |
306 | 313 |
|
307 | 314 |
///Create synonym to an option |
308 | 315 |
|
309 | 316 |
///With this function you can create a synonym \c syn of the |
310 | 317 |
///option \c opt. |
311 | 318 |
ArgParser &synonym(const std::string &syn, |
312 | 319 |
const std::string &opt); |
313 | 320 |
|
314 | 321 |
///@} |
315 | 322 |
|
316 | 323 |
private: |
317 | 324 |
void show(std::ostream &os,Opts::const_iterator i) const; |
318 | 325 |
void show(std::ostream &os,Groups::const_iterator i) const; |
319 | 326 |
void showHelp(Opts::const_iterator i) const; |
320 | 327 |
void showHelp(std::vector<OtherArg>::const_iterator i) const; |
321 | 328 |
|
322 | 329 |
void unknownOpt(std::string arg) const; |
323 | 330 |
|
324 | 331 |
void requiresValue(std::string arg, OptType t) const; |
325 | 332 |
void checkMandatories() const; |
326 | 333 |
|
327 | 334 |
void shortHelp() const; |
328 | 335 |
void showHelp() const; |
329 | 336 |
public: |
330 | 337 |
|
331 | 338 |
///Start the parsing process |
332 | 339 |
ArgParser &parse(); |
333 | 340 |
|
334 | 341 |
/// Synonym for parse() |
335 | 342 |
ArgParser &run() |
336 | 343 |
{ |
337 | 344 |
return parse(); |
338 | 345 |
} |
339 | 346 |
|
340 | 347 |
///Give back the command name (the 0th argument) |
341 | 348 |
const std::string &commandName() const { return _command_name; } |
342 | 349 |
|
343 | 350 |
///Check if an opion has been given to the command. |
344 | 351 |
bool given(std::string op) const |
345 | 352 |
{ |
346 | 353 |
Opts::const_iterator i = _opts.find(op); |
347 | 354 |
return i!=_opts.end()?i->second.set:false; |
348 | 355 |
} |
349 | 356 |
|
350 | 357 |
|
351 | 358 |
///Magic type for operator[] |
352 | 359 |
|
353 | 360 |
///This is the type of the return value of ArgParser::operator[](). |
354 | 361 |
///It automatically converts to \c int, \c double, \c bool or |
355 | 362 |
///\c std::string if the type of the option matches, which is checked |
356 | 363 |
///with an \ref LEMON_ASSERT "assertion" (i.e. it performs runtime |
357 | 364 |
///type checking). |
358 | 365 |
class RefType |
359 | 366 |
{ |
360 | 367 |
const ArgParser &_parser; |
361 | 368 |
std::string _name; |
362 | 369 |
public: |
363 | 370 |
///\e |
364 | 371 |
RefType(const ArgParser &p,const std::string &n) :_parser(p),_name(n) {} |
365 | 372 |
///\e |
366 | 373 |
operator bool() |
367 | 374 |
{ |
368 | 375 |
Opts::const_iterator i = _parser._opts.find(_name); |
369 | 376 |
LEMON_ASSERT(i!=_parser._opts.end(), |
370 | 377 |
std::string()+"Unkown option: '"+_name+"'"); |
371 | 378 |
LEMON_ASSERT(i->second.type==ArgParser::BOOL, |
372 | 379 |
std::string()+"'"+_name+"' is a bool option"); |
373 | 380 |
return *(i->second.bool_p); |
374 | 381 |
} |
375 | 382 |
///\e |
376 | 383 |
operator std::string() |
377 | 384 |
{ |
378 | 385 |
Opts::const_iterator i = _parser._opts.find(_name); |
379 | 386 |
LEMON_ASSERT(i!=_parser._opts.end(), |
380 | 387 |
std::string()+"Unkown option: '"+_name+"'"); |
381 | 388 |
LEMON_ASSERT(i->second.type==ArgParser::STRING, |
382 | 389 |
std::string()+"'"+_name+"' is a string option"); |
383 | 390 |
return *(i->second.string_p); |
384 | 391 |
} |
385 | 392 |
///\e |
386 | 393 |
operator double() |
387 | 394 |
{ |
388 | 395 |
Opts::const_iterator i = _parser._opts.find(_name); |
389 | 396 |
LEMON_ASSERT(i!=_parser._opts.end(), |
390 | 397 |
std::string()+"Unkown option: '"+_name+"'"); |
391 | 398 |
LEMON_ASSERT(i->second.type==ArgParser::DOUBLE || |
392 | 399 |
i->second.type==ArgParser::INTEGER, |
393 | 400 |
std::string()+"'"+_name+"' is a floating point option"); |
394 | 401 |
return i->second.type==ArgParser::DOUBLE ? |
395 | 402 |
*(i->second.double_p) : *(i->second.int_p); |
396 | 403 |
} |
397 | 404 |
///\e |
398 | 405 |
operator int() |
399 | 406 |
{ |
400 | 407 |
Opts::const_iterator i = _parser._opts.find(_name); |
401 | 408 |
LEMON_ASSERT(i!=_parser._opts.end(), |
402 | 409 |
std::string()+"Unkown option: '"+_name+"'"); |
403 | 410 |
LEMON_ASSERT(i->second.type==ArgParser::INTEGER, |
404 | 411 |
std::string()+"'"+_name+"' is an integer option"); |
405 | 412 |
return *(i->second.int_p); |
406 | 413 |
} |
407 | 414 |
|
408 | 415 |
}; |
409 | 416 |
|
410 | 417 |
///Give back the value of an option |
411 | 418 |
|
412 | 419 |
///Give back the value of an option. |
413 | 420 |
///\sa RefType |
414 | 421 |
RefType operator[](const std::string &n) const |
415 | 422 |
{ |
416 | 423 |
return RefType(*this, n); |
417 | 424 |
} |
418 | 425 |
|
419 | 426 |
///Give back the non-option type arguments. |
420 | 427 |
|
421 | 428 |
///Give back a reference to a vector consisting of the program arguments |
422 | 429 |
///not starting with a '-' character. |
423 | 430 |
const std::vector<std::string> &files() const { return _file_args; } |
424 | 431 |
|
425 | 432 |
///Throw instead of exit in case of problems |
426 | 433 |
void throwOnProblems() |
427 | 434 |
{ |
1 | 1 |
/* -*- mode: C++; indent-tabs-mode: nil; -*- |
2 | 2 |
* |
3 | 3 |
* This file is a part of LEMON, a generic C++ optimization library. |
4 | 4 |
* |
5 | 5 |
* Copyright (C) 2003-2010 |
6 | 6 |
* Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport |
7 | 7 |
* (Egervary Research Group on Combinatorial Optimization, EGRES). |
8 | 8 |
* |
9 | 9 |
* Permission to use, modify and distribute this software is granted |
10 | 10 |
* provided that this copyright notice appears in all copies. For |
11 | 11 |
* precise terms see the accompanying LICENSE file. |
12 | 12 |
* |
13 | 13 |
* This software is provided "AS IS" with no warranty of any kind, |
14 | 14 |
* express or implied, and with no claim as to its suitability for any |
15 | 15 |
* purpose. |
16 | 16 |
* |
17 | 17 |
*/ |
18 | 18 |
|
19 | 19 |
#ifndef LEMON_HARTMANN_ORLIN_MMC_H |
20 | 20 |
#define LEMON_HARTMANN_ORLIN_MMC_H |
21 | 21 |
|
22 | 22 |
/// \ingroup min_mean_cycle |
23 | 23 |
/// |
24 | 24 |
/// \file |
25 | 25 |
/// \brief Hartmann-Orlin's algorithm for finding a minimum mean cycle. |
26 | 26 |
|
27 | 27 |
#include <vector> |
28 | 28 |
#include <limits> |
29 | 29 |
#include <lemon/core.h> |
30 | 30 |
#include <lemon/path.h> |
31 | 31 |
#include <lemon/tolerance.h> |
32 | 32 |
#include <lemon/connectivity.h> |
33 | 33 |
|
34 | 34 |
namespace lemon { |
35 | 35 |
|
36 | 36 |
/// \brief Default traits class of HartmannOrlinMmc class. |
37 | 37 |
/// |
38 | 38 |
/// Default traits class of HartmannOrlinMmc class. |
39 | 39 |
/// \tparam GR The type of the digraph. |
40 | 40 |
/// \tparam CM The type of the cost map. |
41 |
/// It must conform to the \ref concepts:: |
|
41 |
/// It must conform to the \ref concepts::ReadMap "ReadMap" concept. |
|
42 | 42 |
#ifdef DOXYGEN |
43 | 43 |
template <typename GR, typename CM> |
44 | 44 |
#else |
45 | 45 |
template <typename GR, typename CM, |
46 | 46 |
bool integer = std::numeric_limits<typename CM::Value>::is_integer> |
47 | 47 |
#endif |
48 | 48 |
struct HartmannOrlinMmcDefaultTraits |
49 | 49 |
{ |
50 | 50 |
/// The type of the digraph |
51 | 51 |
typedef GR Digraph; |
52 | 52 |
/// The type of the cost map |
53 | 53 |
typedef CM CostMap; |
54 | 54 |
/// The type of the arc costs |
55 | 55 |
typedef typename CostMap::Value Cost; |
56 | 56 |
|
57 | 57 |
/// \brief The large cost type used for internal computations |
58 | 58 |
/// |
59 | 59 |
/// The large cost type used for internal computations. |
60 | 60 |
/// It is \c long \c long if the \c Cost type is integer, |
61 | 61 |
/// otherwise it is \c double. |
62 | 62 |
/// \c Cost must be convertible to \c LargeCost. |
63 | 63 |
typedef double LargeCost; |
64 | 64 |
|
65 | 65 |
/// The tolerance type used for internal computations |
66 | 66 |
typedef lemon::Tolerance<LargeCost> Tolerance; |
67 | 67 |
|
68 | 68 |
/// \brief The path type of the found cycles |
69 | 69 |
/// |
70 | 70 |
/// The path type of the found cycles. |
71 | 71 |
/// It must conform to the \ref lemon::concepts::Path "Path" concept |
72 | 72 |
/// and it must have an \c addFront() function. |
73 | 73 |
typedef lemon::Path<Digraph> Path; |
74 | 74 |
}; |
75 | 75 |
|
76 | 76 |
// Default traits class for integer cost types |
77 | 77 |
template <typename GR, typename CM> |
78 | 78 |
struct HartmannOrlinMmcDefaultTraits<GR, CM, true> |
79 | 79 |
{ |
80 | 80 |
typedef GR Digraph; |
81 | 81 |
typedef CM CostMap; |
82 | 82 |
typedef typename CostMap::Value Cost; |
83 | 83 |
#ifdef LEMON_HAVE_LONG_LONG |
84 | 84 |
typedef long long LargeCost; |
85 | 85 |
#else |
86 | 86 |
typedef long LargeCost; |
87 | 87 |
#endif |
88 | 88 |
typedef lemon::Tolerance<LargeCost> Tolerance; |
89 | 89 |
typedef lemon::Path<Digraph> Path; |
90 | 90 |
}; |
91 | 91 |
|
92 | 92 |
|
93 | 93 |
/// \addtogroup min_mean_cycle |
94 | 94 |
/// @{ |
95 | 95 |
|
96 | 96 |
/// \brief Implementation of the Hartmann-Orlin algorithm for finding |
97 | 97 |
/// a minimum mean cycle. |
98 | 98 |
/// |
99 | 99 |
/// This class implements the Hartmann-Orlin algorithm for finding |
100 | 100 |
/// a directed cycle of minimum mean cost in a digraph |
101 | 101 |
/// \ref amo93networkflows, \ref dasdan98minmeancycle. |
102 |
/// It is an improved version of \ref |
|
102 |
/// It is an improved version of \ref KarpMmc "Karp"'s original algorithm, |
|
103 | 103 |
/// it applies an efficient early termination scheme. |
104 | 104 |
/// It runs in time O(ne) and uses space O(n<sup>2</sup>+e). |
105 | 105 |
/// |
106 | 106 |
/// \tparam GR The type of the digraph the algorithm runs on. |
107 | 107 |
/// \tparam CM The type of the cost map. The default |
108 | 108 |
/// map type is \ref concepts::Digraph::ArcMap "GR::ArcMap<int>". |
109 | 109 |
/// \tparam TR The traits class that defines various types used by the |
110 | 110 |
/// algorithm. By default, it is \ref HartmannOrlinMmcDefaultTraits |
111 | 111 |
/// "HartmannOrlinMmcDefaultTraits<GR, CM>". |
112 | 112 |
/// In most cases, this parameter should not be set directly, |
113 | 113 |
/// consider to use the named template parameters instead. |
114 | 114 |
#ifdef DOXYGEN |
115 | 115 |
template <typename GR, typename CM, typename TR> |
116 | 116 |
#else |
117 | 117 |
template < typename GR, |
118 | 118 |
typename CM = typename GR::template ArcMap<int>, |
119 | 119 |
typename TR = HartmannOrlinMmcDefaultTraits<GR, CM> > |
120 | 120 |
#endif |
121 | 121 |
class HartmannOrlinMmc |
122 | 122 |
{ |
123 | 123 |
public: |
124 | 124 |
|
125 | 125 |
/// The type of the digraph |
126 | 126 |
typedef typename TR::Digraph Digraph; |
127 | 127 |
/// The type of the cost map |
128 | 128 |
typedef typename TR::CostMap CostMap; |
129 | 129 |
/// The type of the arc costs |
130 | 130 |
typedef typename TR::Cost Cost; |
131 | 131 |
|
132 | 132 |
/// \brief The large cost type |
133 | 133 |
/// |
134 | 134 |
/// The large cost type used for internal computations. |
135 | 135 |
/// By default, it is \c long \c long if the \c Cost type is integer, |
136 | 136 |
/// otherwise it is \c double. |
137 | 137 |
typedef typename TR::LargeCost LargeCost; |
138 | 138 |
|
139 | 139 |
/// The tolerance type |
140 | 140 |
typedef typename TR::Tolerance Tolerance; |
141 | 141 |
|
142 | 142 |
/// \brief The path type of the found cycles |
143 | 143 |
/// |
144 | 144 |
/// The path type of the found cycles. |
145 | 145 |
/// Using the \ref HartmannOrlinMmcDefaultTraits "default traits class", |
146 | 146 |
/// it is \ref lemon::Path "Path<Digraph>". |
147 | 147 |
typedef typename TR::Path Path; |
148 | 148 |
|
149 | 149 |
/// The \ref HartmannOrlinMmcDefaultTraits "traits class" of the algorithm |
150 | 150 |
typedef TR Traits; |
151 | 151 |
|
152 | 152 |
private: |
153 | 153 |
|
154 | 154 |
TEMPLATE_DIGRAPH_TYPEDEFS(Digraph); |
155 | 155 |
|
156 | 156 |
// Data sturcture for path data |
157 | 157 |
struct PathData |
158 | 158 |
{ |
159 | 159 |
LargeCost dist; |
160 | 160 |
Arc pred; |
161 | 161 |
PathData(LargeCost d, Arc p = INVALID) : |
162 | 162 |
dist(d), pred(p) {} |
163 | 163 |
}; |
164 | 164 |
|
165 | 165 |
typedef typename Digraph::template NodeMap<std::vector<PathData> > |
166 | 166 |
PathDataNodeMap; |
167 | 167 |
|
168 | 168 |
private: |
169 | 169 |
|
170 | 170 |
// The digraph the algorithm runs on |
171 | 171 |
const Digraph &_gr; |
172 | 172 |
// The cost of the arcs |
173 | 173 |
const CostMap &_cost; |
174 | 174 |
|
175 | 175 |
// Data for storing the strongly connected components |
176 | 176 |
int _comp_num; |
177 | 177 |
typename Digraph::template NodeMap<int> _comp; |
178 | 178 |
std::vector<std::vector<Node> > _comp_nodes; |
179 | 179 |
std::vector<Node>* _nodes; |
180 | 180 |
typename Digraph::template NodeMap<std::vector<Arc> > _out_arcs; |
181 | 181 |
|
182 | 182 |
// Data for the found cycles |
183 | 183 |
bool _curr_found, _best_found; |
184 | 184 |
LargeCost _curr_cost, _best_cost; |
185 | 185 |
int _curr_size, _best_size; |
186 | 186 |
Node _curr_node, _best_node; |
187 | 187 |
int _curr_level, _best_level; |
188 | 188 |
|
189 | 189 |
Path *_cycle_path; |
190 | 190 |
bool _local_path; |
191 | 191 |
|
192 | 192 |
// Node map for storing path data |
193 | 193 |
PathDataNodeMap _data; |
194 | 194 |
// The processed nodes in the last round |
195 | 195 |
std::vector<Node> _process; |
196 | 196 |
|
197 | 197 |
Tolerance _tolerance; |
198 | 198 |
|
199 | 199 |
// Infinite constant |
200 | 200 |
const LargeCost INF; |
201 | 201 |
|
202 | 202 |
public: |
203 | 203 |
|
204 | 204 |
/// \name Named Template Parameters |
205 | 205 |
/// @{ |
206 | 206 |
|
207 | 207 |
template <typename T> |
208 | 208 |
struct SetLargeCostTraits : public Traits { |
209 | 209 |
typedef T LargeCost; |
210 | 210 |
typedef lemon::Tolerance<T> Tolerance; |
211 | 211 |
}; |
212 | 212 |
|
213 | 213 |
/// \brief \ref named-templ-param "Named parameter" for setting |
214 | 214 |
/// \c LargeCost type. |
215 | 215 |
/// |
216 | 216 |
/// \ref named-templ-param "Named parameter" for setting \c LargeCost |
217 | 217 |
/// type. It is used for internal computations in the algorithm. |
218 | 218 |
template <typename T> |
219 | 219 |
struct SetLargeCost |
220 | 220 |
: public HartmannOrlinMmc<GR, CM, SetLargeCostTraits<T> > { |
221 | 221 |
typedef HartmannOrlinMmc<GR, CM, SetLargeCostTraits<T> > Create; |
222 | 222 |
}; |
223 | 223 |
|
224 | 224 |
template <typename T> |
225 | 225 |
struct SetPathTraits : public Traits { |
226 | 226 |
typedef T Path; |
227 | 227 |
}; |
228 | 228 |
|
229 | 229 |
/// \brief \ref named-templ-param "Named parameter" for setting |
230 | 230 |
/// \c %Path type. |
231 | 231 |
/// |
232 | 232 |
/// \ref named-templ-param "Named parameter" for setting the \c %Path |
233 | 233 |
/// type of the found cycles. |
234 | 234 |
/// It must conform to the \ref lemon::concepts::Path "Path" concept |
235 | 235 |
/// and it must have an \c addFront() function. |
236 | 236 |
template <typename T> |
237 | 237 |
struct SetPath |
238 | 238 |
: public HartmannOrlinMmc<GR, CM, SetPathTraits<T> > { |
239 | 239 |
typedef HartmannOrlinMmc<GR, CM, SetPathTraits<T> > Create; |
240 | 240 |
}; |
241 | 241 |
|
242 | 242 |
/// @} |
243 | 243 |
|
244 | 244 |
protected: |
245 | 245 |
|
246 | 246 |
HartmannOrlinMmc() {} |
247 | 247 |
|
248 | 248 |
public: |
249 | 249 |
|
250 | 250 |
/// \brief Constructor. |
251 | 251 |
/// |
252 | 252 |
/// The constructor of the class. |
253 | 253 |
/// |
254 | 254 |
/// \param digraph The digraph the algorithm runs on. |
255 | 255 |
/// \param cost The costs of the arcs. |
256 | 256 |
HartmannOrlinMmc( const Digraph &digraph, |
257 | 257 |
const CostMap &cost ) : |
258 | 258 |
_gr(digraph), _cost(cost), _comp(digraph), _out_arcs(digraph), |
259 | 259 |
_best_found(false), _best_cost(0), _best_size(1), |
260 | 260 |
_cycle_path(NULL), _local_path(false), _data(digraph), |
261 | 261 |
INF(std::numeric_limits<LargeCost>::has_infinity ? |
262 | 262 |
std::numeric_limits<LargeCost>::infinity() : |
263 | 263 |
std::numeric_limits<LargeCost>::max()) |
264 | 264 |
{} |
265 | 265 |
|
266 | 266 |
/// Destructor. |
267 | 267 |
~HartmannOrlinMmc() { |
268 | 268 |
if (_local_path) delete _cycle_path; |
269 | 269 |
} |
270 | 270 |
|
271 | 271 |
/// \brief Set the path structure for storing the found cycle. |
272 | 272 |
/// |
273 | 273 |
/// This function sets an external path structure for storing the |
274 | 274 |
/// found cycle. |
275 | 275 |
/// |
276 | 276 |
/// If you don't call this function before calling \ref run() or |
277 | 277 |
/// \ref findCycleMean(), it will allocate a local \ref Path "path" |
278 | 278 |
/// structure. The destuctor deallocates this automatically |
279 | 279 |
/// allocated object, of course. |
280 | 280 |
/// |
281 | 281 |
/// \note The algorithm calls only the \ref lemon::Path::addFront() |
282 | 282 |
/// "addFront()" function of the given path structure. |
283 | 283 |
/// |
284 | 284 |
/// \return <tt>(*this)</tt> |
285 | 285 |
HartmannOrlinMmc& cycle(Path &path) { |
286 | 286 |
if (_local_path) { |
287 | 287 |
delete _cycle_path; |
288 | 288 |
_local_path = false; |
289 | 289 |
} |
290 | 290 |
_cycle_path = &path; |
291 | 291 |
return *this; |
292 | 292 |
} |
293 | 293 |
|
294 | 294 |
/// \brief Set the tolerance used by the algorithm. |
295 | 295 |
/// |
296 | 296 |
/// This function sets the tolerance object used by the algorithm. |
297 | 297 |
/// |
298 | 298 |
/// \return <tt>(*this)</tt> |
299 | 299 |
HartmannOrlinMmc& tolerance(const Tolerance& tolerance) { |
300 | 300 |
_tolerance = tolerance; |
301 | 301 |
return *this; |
302 | 302 |
} |
303 | 303 |
|
304 | 304 |
/// \brief Return a const reference to the tolerance. |
305 | 305 |
/// |
306 | 306 |
/// This function returns a const reference to the tolerance object |
307 | 307 |
/// used by the algorithm. |
308 | 308 |
const Tolerance& tolerance() const { |
309 | 309 |
return _tolerance; |
310 | 310 |
} |
311 | 311 |
|
312 | 312 |
/// \name Execution control |
313 | 313 |
/// The simplest way to execute the algorithm is to call the \ref run() |
314 | 314 |
/// function.\n |
315 | 315 |
/// If you only need the minimum mean cost, you may call |
316 | 316 |
/// \ref findCycleMean(). |
317 | 317 |
|
318 | 318 |
/// @{ |
319 | 319 |
|
320 | 320 |
/// \brief Run the algorithm. |
321 | 321 |
/// |
322 | 322 |
/// This function runs the algorithm. |
323 | 323 |
/// It can be called more than once (e.g. if the underlying digraph |
324 | 324 |
/// and/or the arc costs have been modified). |
325 | 325 |
/// |
326 | 326 |
/// \return \c true if a directed cycle exists in the digraph. |
327 | 327 |
/// |
328 | 328 |
/// \note <tt>mmc.run()</tt> is just a shortcut of the following code. |
329 | 329 |
/// \code |
330 | 330 |
/// return mmc.findCycleMean() && mmc.findCycle(); |
331 | 331 |
/// \endcode |
332 | 332 |
bool run() { |
333 | 333 |
return findCycleMean() && findCycle(); |
334 | 334 |
} |
335 | 335 |
|
336 | 336 |
/// \brief Find the minimum cycle mean. |
337 | 337 |
/// |
338 | 338 |
/// This function finds the minimum mean cost of the directed |
339 | 339 |
/// cycles in the digraph. |
340 | 340 |
/// |
341 | 341 |
/// \return \c true if a directed cycle exists in the digraph. |
342 | 342 |
bool findCycleMean() { |
343 | 343 |
// Initialization and find strongly connected components |
344 | 344 |
init(); |
345 | 345 |
findComponents(); |
346 | 346 |
|
347 | 347 |
// Find the minimum cycle mean in the components |
348 | 348 |
for (int comp = 0; comp < _comp_num; ++comp) { |
349 | 349 |
if (!initComponent(comp)) continue; |
350 | 350 |
processRounds(); |
351 | 351 |
|
352 | 352 |
// Update the best cycle (global minimum mean cycle) |
353 | 353 |
if ( _curr_found && (!_best_found || |
354 | 354 |
_curr_cost * _best_size < _best_cost * _curr_size) ) { |
355 | 355 |
_best_found = true; |
356 | 356 |
_best_cost = _curr_cost; |
357 | 357 |
_best_size = _curr_size; |
358 | 358 |
_best_node = _curr_node; |
359 | 359 |
_best_level = _curr_level; |
360 | 360 |
} |
361 | 361 |
} |
362 | 362 |
return _best_found; |
363 | 363 |
} |
364 | 364 |
|
365 | 365 |
/// \brief Find a minimum mean directed cycle. |
366 | 366 |
/// |
367 | 367 |
/// This function finds a directed cycle of minimum mean cost |
368 | 368 |
/// in the digraph using the data computed by findCycleMean(). |
369 | 369 |
/// |
370 | 370 |
/// \return \c true if a directed cycle exists in the digraph. |
371 | 371 |
/// |
372 | 372 |
/// \pre \ref findCycleMean() must be called before using this function. |
373 | 373 |
bool findCycle() { |
374 | 374 |
if (!_best_found) return false; |
375 | 375 |
IntNodeMap reached(_gr, -1); |
376 | 376 |
int r = _best_level + 1; |
377 | 377 |
Node u = _best_node; |
378 | 378 |
while (reached[u] < 0) { |
379 | 379 |
reached[u] = --r; |
380 | 380 |
u = _gr.source(_data[u][r].pred); |
381 | 381 |
} |
382 | 382 |
r = reached[u]; |
383 | 383 |
Arc e = _data[u][r].pred; |
384 | 384 |
_cycle_path->addFront(e); |
385 | 385 |
_best_cost = _cost[e]; |
386 | 386 |
_best_size = 1; |
387 | 387 |
Node v; |
388 | 388 |
while ((v = _gr.source(e)) != u) { |
389 | 389 |
e = _data[v][--r].pred; |
390 | 390 |
_cycle_path->addFront(e); |
391 | 391 |
_best_cost += _cost[e]; |
392 | 392 |
++_best_size; |
393 | 393 |
} |
394 | 394 |
return true; |
395 | 395 |
} |
396 | 396 |
|
397 | 397 |
/// @} |
398 | 398 |
|
399 | 399 |
/// \name Query Functions |
400 | 400 |
/// The results of the algorithm can be obtained using these |
401 | 401 |
/// functions.\n |
402 | 402 |
/// The algorithm should be executed before using them. |
403 | 403 |
|
404 | 404 |
/// @{ |
405 | 405 |
|
406 | 406 |
/// \brief Return the total cost of the found cycle. |
407 | 407 |
/// |
408 | 408 |
/// This function returns the total cost of the found cycle. |
409 | 409 |
/// |
410 | 410 |
/// \pre \ref run() or \ref findCycleMean() must be called before |
411 | 411 |
/// using this function. |
412 | 412 |
Cost cycleCost() const { |
413 | 413 |
return static_cast<Cost>(_best_cost); |
414 | 414 |
} |
415 | 415 |
|
416 | 416 |
/// \brief Return the number of arcs on the found cycle. |
417 | 417 |
/// |
418 | 418 |
/// This function returns the number of arcs on the found cycle. |
419 | 419 |
/// |
420 | 420 |
/// \pre \ref run() or \ref findCycleMean() must be called before |
421 | 421 |
/// using this function. |
422 | 422 |
int cycleSize() const { |
423 | 423 |
return _best_size; |
424 | 424 |
} |
425 | 425 |
|
426 | 426 |
/// \brief Return the mean cost of the found cycle. |
427 | 427 |
/// |
428 | 428 |
/// This function returns the mean cost of the found cycle. |
429 | 429 |
/// |
430 | 430 |
/// \note <tt>alg.cycleMean()</tt> is just a shortcut of the |
431 | 431 |
/// following code. |
432 | 432 |
/// \code |
433 | 433 |
/// return static_cast<double>(alg.cycleCost()) / alg.cycleSize(); |
434 | 434 |
/// \endcode |
435 | 435 |
/// |
436 | 436 |
/// \pre \ref run() or \ref findCycleMean() must be called before |
437 | 437 |
/// using this function. |
438 | 438 |
double cycleMean() const { |
439 | 439 |
return static_cast<double>(_best_cost) / _best_size; |
440 | 440 |
} |
441 | 441 |
|
442 | 442 |
/// \brief Return the found cycle. |
443 | 443 |
/// |
444 | 444 |
/// This function returns a const reference to the path structure |
445 | 445 |
/// storing the found cycle. |
446 | 446 |
/// |
447 | 447 |
/// \pre \ref run() or \ref findCycle() must be called before using |
448 | 448 |
/// this function. |
449 | 449 |
const Path& cycle() const { |
450 | 450 |
return *_cycle_path; |
451 | 451 |
} |
452 | 452 |
|
453 | 453 |
///@} |
454 | 454 |
|
455 | 455 |
private: |
456 | 456 |
|
457 | 457 |
// Initialization |
458 | 458 |
void init() { |
459 | 459 |
if (!_cycle_path) { |
460 | 460 |
_local_path = true; |
461 | 461 |
_cycle_path = new Path; |
462 | 462 |
} |
463 | 463 |
_cycle_path->clear(); |
464 | 464 |
_best_found = false; |
465 | 465 |
_best_cost = 0; |
466 | 466 |
_best_size = 1; |
467 | 467 |
_cycle_path->clear(); |
468 | 468 |
for (NodeIt u(_gr); u != INVALID; ++u) |
469 | 469 |
_data[u].clear(); |
470 | 470 |
} |
471 | 471 |
|
472 | 472 |
// Find strongly connected components and initialize _comp_nodes |
473 | 473 |
// and _out_arcs |
474 | 474 |
void findComponents() { |
475 | 475 |
_comp_num = stronglyConnectedComponents(_gr, _comp); |
476 | 476 |
_comp_nodes.resize(_comp_num); |
477 | 477 |
if (_comp_num == 1) { |
478 | 478 |
_comp_nodes[0].clear(); |
479 | 479 |
for (NodeIt n(_gr); n != INVALID; ++n) { |
480 | 480 |
_comp_nodes[0].push_back(n); |
481 | 481 |
_out_arcs[n].clear(); |
482 | 482 |
for (OutArcIt a(_gr, n); a != INVALID; ++a) { |
483 | 483 |
_out_arcs[n].push_back(a); |
484 | 484 |
} |
485 | 485 |
} |
486 | 486 |
} else { |
0 comments (0 inline)