0
6
0
34
21
15
9
31
60
... | ... |
@@ -127,589 +127,602 @@ |
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 | 266 |
@defgroup matrices Matrices |
267 | 267 |
@ingroup datas |
268 | 268 |
\brief Two dimensional data storages implemented in LEMON. |
269 | 269 |
|
270 | 270 |
This group contains two dimensional data storages implemented in LEMON. |
271 | 271 |
*/ |
272 | 272 |
|
273 | 273 |
/** |
274 | 274 |
@defgroup auxdat Auxiliary Data Structures |
275 | 275 |
@ingroup datas |
276 | 276 |
\brief Auxiliary data structures implemented in LEMON. |
277 | 277 |
|
278 | 278 |
This group contains some data structures implemented in LEMON in |
279 | 279 |
order to make it easier to implement combinatorial algorithms. |
280 | 280 |
*/ |
281 | 281 |
|
282 | 282 |
/** |
283 | 283 |
@defgroup geomdat Geometric Data Structures |
284 | 284 |
@ingroup auxdat |
285 | 285 |
\brief Geometric data structures implemented in LEMON. |
286 | 286 |
|
287 | 287 |
This group contains geometric data structures implemented in LEMON. |
288 | 288 |
|
289 | 289 |
- \ref lemon::dim2::Point "dim2::Point" implements a two dimensional |
290 | 290 |
vector with the usual operations. |
291 | 291 |
- \ref lemon::dim2::Box "dim2::Box" can be used to determine the |
292 | 292 |
rectangular bounding box of a set of \ref lemon::dim2::Point |
293 | 293 |
"dim2::Point"'s. |
294 | 294 |
*/ |
295 | 295 |
|
296 | 296 |
/** |
297 | 297 |
@defgroup matrices Matrices |
298 | 298 |
@ingroup auxdat |
299 | 299 |
\brief Two dimensional data storages implemented in LEMON. |
300 | 300 |
|
301 | 301 |
This group contains two dimensional data storages implemented in LEMON. |
302 | 302 |
*/ |
303 | 303 |
|
304 | 304 |
/** |
305 | 305 |
@defgroup algs Algorithms |
306 | 306 |
\brief This group contains the several algorithms |
307 | 307 |
implemented in LEMON. |
308 | 308 |
|
309 | 309 |
This group contains the several algorithms |
310 | 310 |
implemented in LEMON. |
311 | 311 |
*/ |
312 | 312 |
|
313 | 313 |
/** |
314 | 314 |
@defgroup search Graph Search |
315 | 315 |
@ingroup algs |
316 | 316 |
\brief Common graph search algorithms. |
317 | 317 |
|
318 | 318 |
This group contains the common graph search algorithms, namely |
319 |
\e breadth-first \e search (BFS) and \e depth-first \e search (DFS) |
|
319 |
\e breadth-first \e search (BFS) and \e depth-first \e search (DFS) |
|
320 |
\ref clrs01algorithms. |
|
320 | 321 |
*/ |
321 | 322 |
|
322 | 323 |
/** |
323 | 324 |
@defgroup shortest_path Shortest Path Algorithms |
324 | 325 |
@ingroup algs |
325 | 326 |
\brief Algorithms for finding shortest paths. |
326 | 327 |
|
327 |
This group contains the algorithms for finding shortest paths in digraphs |
|
328 |
This group contains the algorithms for finding shortest paths in digraphs |
|
329 |
\ref clrs01algorithms. |
|
328 | 330 |
|
329 | 331 |
- \ref Dijkstra algorithm for finding shortest paths from a source node |
330 | 332 |
when all arc lengths are non-negative. |
331 | 333 |
- \ref BellmanFord "Bellman-Ford" algorithm for finding shortest paths |
332 | 334 |
from a source node when arc lenghts can be either positive or negative, |
333 | 335 |
but the digraph should not contain directed cycles with negative total |
334 | 336 |
length. |
335 | 337 |
- \ref FloydWarshall "Floyd-Warshall" and \ref Johnson "Johnson" algorithms |
336 | 338 |
for solving the \e all-pairs \e shortest \e paths \e problem when arc |
337 | 339 |
lenghts can be either positive or negative, but the digraph should |
338 | 340 |
not contain directed cycles with negative total length. |
339 | 341 |
- \ref Suurballe A successive shortest path algorithm for finding |
340 | 342 |
arc-disjoint paths between two nodes having minimum total length. |
341 | 343 |
*/ |
342 | 344 |
|
343 | 345 |
/** |
344 | 346 |
@defgroup spantree Minimum Spanning Tree Algorithms |
345 | 347 |
@ingroup algs |
346 | 348 |
\brief Algorithms for finding minimum cost spanning trees and arborescences. |
347 | 349 |
|
348 | 350 |
This group contains the algorithms for finding minimum cost spanning |
349 |
trees and arborescences. |
|
351 |
trees and arborescences \ref clrs01algorithms. |
|
350 | 352 |
*/ |
351 | 353 |
|
352 | 354 |
/** |
353 | 355 |
@defgroup max_flow Maximum Flow Algorithms |
354 | 356 |
@ingroup algs |
355 | 357 |
\brief Algorithms for finding maximum flows. |
356 | 358 |
|
357 | 359 |
This group contains the algorithms for finding maximum flows and |
358 |
feasible circulations. |
|
360 |
feasible circulations \ref clrs01algorithms, \ref amo93networkflows. |
|
359 | 361 |
|
360 | 362 |
The \e maximum \e flow \e problem is to find a flow of maximum value between |
361 | 363 |
a single source and a single target. Formally, there is a \f$G=(V,A)\f$ |
362 | 364 |
digraph, a \f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function and |
363 | 365 |
\f$s, t \in V\f$ source and target nodes. |
364 | 366 |
A maximum flow is an \f$f: A\rightarrow\mathbf{R}^+_0\f$ solution of the |
365 | 367 |
following optimization problem. |
366 | 368 |
|
367 | 369 |
\f[ \max\sum_{sv\in A} f(sv) - \sum_{vs\in A} f(vs) \f] |
368 | 370 |
\f[ \sum_{uv\in A} f(uv) = \sum_{vu\in A} f(vu) |
369 | 371 |
\quad \forall u\in V\setminus\{s,t\} \f] |
370 | 372 |
\f[ 0 \leq f(uv) \leq cap(uv) \quad \forall uv\in A \f] |
371 | 373 |
|
372 | 374 |
LEMON contains several algorithms for solving maximum flow problems: |
373 |
- \ref EdmondsKarp Edmonds-Karp algorithm. |
|
374 |
- \ref Preflow Goldberg-Tarjan's preflow push-relabel algorithm. |
|
375 |
- \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees. |
|
376 |
- \ref GoldbergTarjan Preflow push-relabel algorithm with dynamic trees. |
|
375 |
- \ref EdmondsKarp Edmonds-Karp algorithm |
|
376 |
\ref edmondskarp72theoretical. |
|
377 |
- \ref Preflow Goldberg-Tarjan's preflow push-relabel algorithm |
|
378 |
\ref goldberg88newapproach. |
|
379 |
- \ref DinitzSleatorTarjan Dinitz's blocking flow algorithm with dynamic trees |
|
380 |
\ref dinic70algorithm, \ref sleator83dynamic. |
|
381 |
- \ref GoldbergTarjan !Preflow push-relabel algorithm with dynamic trees |
|
382 |
\ref goldberg88newapproach, \ref sleator83dynamic. |
|
377 | 383 |
|
378 |
In most cases the \ref Preflow |
|
384 |
In most cases the \ref Preflow algorithm provides the |
|
379 | 385 |
fastest method for computing a maximum flow. All implementations |
380 | 386 |
also provide functions to query the minimum cut, which is the dual |
381 | 387 |
problem of maximum flow. |
382 | 388 |
|
383 | 389 |
\ref Circulation is a preflow push-relabel algorithm implemented directly |
384 | 390 |
for finding feasible circulations, which is a somewhat different problem, |
385 | 391 |
but it is strongly related to maximum flow. |
386 | 392 |
For more information, see \ref Circulation. |
387 | 393 |
*/ |
388 | 394 |
|
389 | 395 |
/** |
390 | 396 |
@defgroup min_cost_flow_algs Minimum Cost Flow Algorithms |
391 | 397 |
@ingroup algs |
392 | 398 |
|
393 | 399 |
\brief Algorithms for finding minimum cost flows and circulations. |
394 | 400 |
|
395 | 401 |
This group contains the algorithms for finding minimum cost flows and |
396 |
circulations. For more information about this problem and its dual |
|
397 |
solution see \ref min_cost_flow "Minimum Cost Flow Problem". |
|
402 |
circulations \ref amo93networkflows. For more information about this |
|
403 |
problem and its dual solution, see \ref min_cost_flow |
|
404 |
"Minimum Cost Flow Problem". |
|
398 | 405 |
|
399 | 406 |
LEMON contains several algorithms for this problem. |
400 | 407 |
- \ref NetworkSimplex Primal Network Simplex algorithm with various |
401 |
pivot strategies. |
|
408 |
pivot strategies \ref dantzig63linearprog, \ref kellyoneill91netsimplex. |
|
402 | 409 |
- \ref CostScaling Push-Relabel and Augment-Relabel algorithms based on |
403 |
cost scaling |
|
410 |
cost scaling \ref goldberg90approximation, \ref goldberg97efficient, |
|
411 |
\ref bunnagel98efficient. |
|
404 | 412 |
- \ref CapacityScaling Successive Shortest %Path algorithm with optional |
405 |
capacity scaling. |
|
406 |
- \ref CancelAndTighten The Cancel and Tighten algorithm. |
|
407 |
|
|
413 |
capacity scaling \ref edmondskarp72theoretical. |
|
414 |
- \ref CancelAndTighten The Cancel and Tighten algorithm |
|
415 |
\ref goldberg89cyclecanceling. |
|
416 |
- \ref CycleCanceling Cycle-Canceling algorithms |
|
417 |
\ref klein67primal, \ref goldberg89cyclecanceling. |
|
408 | 418 |
|
409 | 419 |
In general NetworkSimplex is the most efficient implementation, |
410 | 420 |
but in special cases other algorithms could be faster. |
411 | 421 |
For example, if the total supply and/or capacities are rather small, |
412 | 422 |
CapacityScaling is usually the fastest algorithm (without effective scaling). |
413 | 423 |
*/ |
414 | 424 |
|
415 | 425 |
/** |
416 | 426 |
@defgroup min_cut Minimum Cut Algorithms |
417 | 427 |
@ingroup algs |
418 | 428 |
|
419 | 429 |
\brief Algorithms for finding minimum cut in graphs. |
420 | 430 |
|
421 | 431 |
This group contains the algorithms for finding minimum cut in graphs. |
422 | 432 |
|
423 | 433 |
The \e minimum \e cut \e problem is to find a non-empty and non-complete |
424 | 434 |
\f$X\f$ subset of the nodes with minimum overall capacity on |
425 | 435 |
outgoing arcs. Formally, there is a \f$G=(V,A)\f$ digraph, a |
426 | 436 |
\f$cap: A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum |
427 | 437 |
cut is the \f$X\f$ solution of the next optimization problem: |
428 | 438 |
|
429 | 439 |
\f[ \min_{X \subset V, X\not\in \{\emptyset, V\}} |
430 | 440 |
\sum_{uv\in A: u\in X, v\not\in X}cap(uv) \f] |
431 | 441 |
|
432 | 442 |
LEMON contains several algorithms related to minimum cut problems: |
433 | 443 |
|
434 | 444 |
- \ref HaoOrlin "Hao-Orlin algorithm" for calculating minimum cut |
435 | 445 |
in directed graphs. |
436 | 446 |
- \ref NagamochiIbaraki "Nagamochi-Ibaraki algorithm" for |
437 | 447 |
calculating minimum cut in undirected graphs. |
438 | 448 |
- \ref GomoryHu "Gomory-Hu tree computation" for calculating |
439 | 449 |
all-pairs minimum cut in undirected graphs. |
440 | 450 |
|
441 | 451 |
If you want to find minimum cut just between two distinict nodes, |
442 | 452 |
see the \ref max_flow "maximum flow problem". |
443 | 453 |
*/ |
444 | 454 |
|
445 | 455 |
/** |
446 | 456 |
@defgroup matching Matching Algorithms |
447 | 457 |
@ingroup algs |
448 | 458 |
\brief Algorithms for finding matchings in graphs and bipartite graphs. |
449 | 459 |
|
450 | 460 |
This group contains the algorithms for calculating |
451 | 461 |
matchings in graphs and bipartite graphs. The general matching problem is |
452 | 462 |
finding a subset of the edges for which each node has at most one incident |
453 | 463 |
edge. |
454 | 464 |
|
455 | 465 |
There are several different algorithms for calculate matchings in |
456 | 466 |
graphs. The matching problems in bipartite graphs are generally |
457 | 467 |
easier than in general graphs. The goal of the matching optimization |
458 | 468 |
can be finding maximum cardinality, maximum weight or minimum cost |
459 | 469 |
matching. The search can be constrained to find perfect or |
460 | 470 |
maximum cardinality matching. |
461 | 471 |
|
462 | 472 |
The matching algorithms implemented in LEMON: |
463 | 473 |
- \ref MaxBipartiteMatching Hopcroft-Karp augmenting path algorithm |
464 | 474 |
for calculating maximum cardinality matching in bipartite graphs. |
465 | 475 |
- \ref PrBipartiteMatching Push-relabel algorithm |
466 | 476 |
for calculating maximum cardinality matching in bipartite graphs. |
467 | 477 |
- \ref MaxWeightedBipartiteMatching |
468 | 478 |
Successive shortest path algorithm for calculating maximum weighted |
469 | 479 |
matching and maximum weighted bipartite matching in bipartite graphs. |
470 | 480 |
- \ref MinCostMaxBipartiteMatching |
471 | 481 |
Successive shortest path algorithm for calculating minimum cost maximum |
472 | 482 |
matching in bipartite graphs. |
473 | 483 |
- \ref MaxMatching Edmond's blossom shrinking algorithm for calculating |
474 | 484 |
maximum cardinality matching in general graphs. |
475 | 485 |
- \ref MaxWeightedMatching Edmond's blossom shrinking algorithm for calculating |
476 | 486 |
maximum weighted matching in general graphs. |
477 | 487 |
- \ref MaxWeightedPerfectMatching |
478 | 488 |
Edmond's blossom shrinking algorithm for calculating maximum weighted |
479 | 489 |
perfect matching in general graphs. |
480 | 490 |
|
481 | 491 |
\image html bipartite_matching.png |
482 | 492 |
\image latex bipartite_matching.eps "Bipartite Matching" width=\textwidth |
483 | 493 |
*/ |
484 | 494 |
|
485 | 495 |
/** |
486 | 496 |
@defgroup graph_properties Connectivity and Other Graph Properties |
487 | 497 |
@ingroup algs |
488 | 498 |
\brief Algorithms for discovering the graph properties |
489 | 499 |
|
490 | 500 |
This group contains the algorithms for discovering the graph properties |
491 | 501 |
like connectivity, bipartiteness, euler property, simplicity etc. |
492 | 502 |
|
493 | 503 |
\image html connected_components.png |
494 | 504 |
\image latex connected_components.eps "Connected components" width=\textwidth |
495 | 505 |
*/ |
496 | 506 |
|
497 | 507 |
/** |
498 | 508 |
@defgroup planar Planarity Embedding and Drawing |
499 | 509 |
@ingroup algs |
500 | 510 |
\brief Algorithms for planarity checking, embedding and drawing |
501 | 511 |
|
502 | 512 |
This group contains the algorithms for planarity checking, |
503 | 513 |
embedding and drawing. |
504 | 514 |
|
505 | 515 |
\image html planar.png |
506 | 516 |
\image latex planar.eps "Plane graph" width=\textwidth |
507 | 517 |
*/ |
508 | 518 |
|
509 | 519 |
/** |
510 | 520 |
@defgroup approx Approximation Algorithms |
511 | 521 |
@ingroup algs |
512 | 522 |
\brief Approximation algorithms. |
513 | 523 |
|
514 | 524 |
This group contains the approximation and heuristic algorithms |
515 | 525 |
implemented in LEMON. |
516 | 526 |
*/ |
517 | 527 |
|
518 | 528 |
/** |
519 | 529 |
@defgroup auxalg Auxiliary Algorithms |
520 | 530 |
@ingroup algs |
521 | 531 |
\brief Auxiliary algorithms implemented in LEMON. |
522 | 532 |
|
523 | 533 |
This group contains some algorithms implemented in LEMON |
524 | 534 |
in order to make it easier to implement complex algorithms. |
525 | 535 |
*/ |
526 | 536 |
|
527 | 537 |
/** |
528 | 538 |
@defgroup gen_opt_group General Optimization Tools |
529 | 539 |
\brief This group contains some general optimization frameworks |
530 | 540 |
implemented in LEMON. |
531 | 541 |
|
532 | 542 |
This group contains some general optimization frameworks |
533 | 543 |
implemented in LEMON. |
534 | 544 |
*/ |
535 | 545 |
|
536 | 546 |
/** |
537 |
@defgroup lp_group |
|
547 |
@defgroup lp_group LP and MIP Solvers |
|
538 | 548 |
@ingroup gen_opt_group |
539 |
\brief |
|
549 |
\brief LP and MIP solver interfaces for LEMON. |
|
540 | 550 |
|
541 |
This group contains Lp and Mip solver interfaces for LEMON. The |
|
542 |
various LP solvers could be used in the same manner with this |
|
543 |
|
|
551 |
This group contains LP and MIP solver interfaces for LEMON. |
|
552 |
Various LP solvers could be used in the same manner with this |
|
553 |
high-level interface. |
|
554 |
|
|
555 |
The currently supported solvers are \ref glpk, \ref clp, \ref cbc, |
|
556 |
\ref cplex, \ref soplex. |
|
544 | 557 |
*/ |
545 | 558 |
|
546 | 559 |
/** |
547 | 560 |
@defgroup lp_utils Tools for Lp and Mip Solvers |
548 | 561 |
@ingroup lp_group |
549 | 562 |
\brief Helper tools to the Lp and Mip solvers. |
550 | 563 |
|
551 | 564 |
This group adds some helper tools to general optimization framework |
552 | 565 |
implemented in LEMON. |
553 | 566 |
*/ |
554 | 567 |
|
555 | 568 |
/** |
556 | 569 |
@defgroup metah Metaheuristics |
557 | 570 |
@ingroup gen_opt_group |
558 | 571 |
\brief Metaheuristics for LEMON library. |
559 | 572 |
|
560 | 573 |
This group contains some metaheuristic optimization tools. |
561 | 574 |
*/ |
562 | 575 |
|
563 | 576 |
/** |
564 | 577 |
@defgroup utils Tools and Utilities |
565 | 578 |
\brief Tools and utilities for programming in LEMON |
566 | 579 |
|
567 | 580 |
Tools and utilities for programming in LEMON. |
568 | 581 |
*/ |
569 | 582 |
|
570 | 583 |
/** |
571 | 584 |
@defgroup gutils Basic Graph Utilities |
572 | 585 |
@ingroup utils |
573 | 586 |
\brief Simple basic graph utilities. |
574 | 587 |
|
575 | 588 |
This group contains some simple basic graph utilities. |
576 | 589 |
*/ |
577 | 590 |
|
578 | 591 |
/** |
579 | 592 |
@defgroup misc Miscellaneous Tools |
580 | 593 |
@ingroup utils |
581 | 594 |
\brief Tools for development, debugging and testing. |
582 | 595 |
|
583 | 596 |
This group contains several useful tools for development, |
584 | 597 |
debugging and testing. |
585 | 598 |
*/ |
586 | 599 |
|
587 | 600 |
/** |
588 | 601 |
@defgroup timecount Time Measuring and Counting |
589 | 602 |
@ingroup misc |
590 | 603 |
\brief Simple tools for measuring the performance of algorithms. |
591 | 604 |
|
592 | 605 |
This group contains simple tools for measuring the performance |
593 | 606 |
of algorithms. |
594 | 607 |
*/ |
595 | 608 |
|
596 | 609 |
/** |
597 | 610 |
@defgroup exceptions Exceptions |
598 | 611 |
@ingroup utils |
599 | 612 |
\brief Exceptions defined in LEMON. |
600 | 613 |
|
601 | 614 |
This group contains the exceptions defined in LEMON. |
602 | 615 |
*/ |
603 | 616 |
|
604 | 617 |
/** |
605 | 618 |
@defgroup io_group Input-Output |
606 | 619 |
\brief Graph Input-Output methods |
607 | 620 |
|
608 | 621 |
This group contains the tools for importing and exporting graphs |
609 | 622 |
and graph related data. Now it supports the \ref lgf-format |
610 | 623 |
"LEMON Graph Format", the \c DIMACS format and the encapsulated |
611 | 624 |
postscript (EPS) format. |
612 | 625 |
*/ |
613 | 626 |
|
614 | 627 |
/** |
615 | 628 |
@defgroup lemon_io LEMON Graph Format |
616 | 629 |
@ingroup io_group |
617 | 630 |
\brief Reading and writing LEMON Graph Format. |
618 | 631 |
|
619 | 632 |
This group contains methods for reading and writing |
620 | 633 |
\ref lgf-format "LEMON Graph Format". |
621 | 634 |
*/ |
622 | 635 |
|
623 | 636 |
/** |
624 | 637 |
@defgroup eps_io Postscript Exporting |
625 | 638 |
@ingroup io_group |
626 | 639 |
\brief General \c EPS drawer and graph exporter |
627 | 640 |
|
628 | 641 |
This group contains general \c EPS drawing methods and special |
629 | 642 |
graph exporting tools. |
630 | 643 |
*/ |
631 | 644 |
|
632 | 645 |
/** |
633 | 646 |
@defgroup dimacs_group DIMACS Format |
634 | 647 |
@ingroup io_group |
635 | 648 |
\brief Read and write files in DIMACS format |
636 | 649 |
|
637 | 650 |
Tools to read a digraph from or write it to a file in DIMACS format data. |
638 | 651 |
*/ |
639 | 652 |
|
640 | 653 |
/** |
641 | 654 |
@defgroup nauty_group NAUTY Format |
642 | 655 |
@ingroup io_group |
643 | 656 |
\brief Read \e Nauty format |
644 | 657 |
|
645 | 658 |
Tool to read graphs from \e Nauty format data. |
646 | 659 |
*/ |
647 | 660 |
|
648 | 661 |
/** |
649 | 662 |
@defgroup concept Concepts |
650 | 663 |
\brief Skeleton classes and concept checking classes |
651 | 664 |
|
652 | 665 |
This group contains the data/algorithm skeletons and concept checking |
653 | 666 |
classes implemented in LEMON. |
654 | 667 |
|
655 | 668 |
The purpose of the classes in this group is fourfold. |
656 | 669 |
|
657 | 670 |
- These classes contain the documentations of the %concepts. In order |
658 | 671 |
to avoid document multiplications, an implementation of a concept |
659 | 672 |
simply refers to the corresponding concept class. |
660 | 673 |
|
661 | 674 |
- These classes declare every functions, <tt>typedef</tt>s etc. an |
662 | 675 |
implementation of the %concepts should provide, however completely |
663 | 676 |
without implementations and real data structures behind the |
664 | 677 |
interface. On the other hand they should provide nothing else. All |
665 | 678 |
the algorithms working on a data structure meeting a certain concept |
666 | 679 |
should compile with these classes. (Though it will not run properly, |
667 | 680 |
of course.) In this way it is easily to check if an algorithm |
668 | 681 |
doesn't use any extra feature of a certain implementation. |
669 | 682 |
|
670 | 683 |
- The concept descriptor classes also provide a <em>checker class</em> |
671 | 684 |
that makes it possible to check whether a certain implementation of a |
672 | 685 |
concept indeed provides all the required features. |
673 | 686 |
|
674 | 687 |
- Finally, They can serve as a skeleton of a new implementation of a concept. |
675 | 688 |
*/ |
676 | 689 |
|
677 | 690 |
/** |
678 | 691 |
@defgroup graph_concepts Graph Structure Concepts |
679 | 692 |
@ingroup concept |
680 | 693 |
\brief Skeleton and concept checking classes for graph structures |
681 | 694 |
|
682 | 695 |
This group contains the skeletons and concept checking classes of |
683 | 696 |
graph structures. |
684 | 697 |
*/ |
685 | 698 |
|
686 | 699 |
/** |
687 | 700 |
@defgroup map_concepts Map Concepts |
688 | 701 |
@ingroup concept |
689 | 702 |
\brief Skeleton and concept checking classes for maps |
690 | 703 |
|
691 | 704 |
This group contains the skeletons and concept checking classes of maps. |
692 | 705 |
*/ |
693 | 706 |
|
694 | 707 |
/** |
695 | 708 |
@defgroup tools Standalone Utility Applications |
696 | 709 |
|
697 | 710 |
Some utility applications are listed here. |
698 | 711 |
|
699 | 712 |
The standard compilation procedure (<tt>./configure;make</tt>) will compile |
700 | 713 |
them, as well. |
701 | 714 |
*/ |
702 | 715 |
|
703 | 716 |
/** |
704 | 717 |
\anchor demoprograms |
705 | 718 |
|
706 | 719 |
@defgroup demos Demo Programs |
707 | 720 |
|
708 | 721 |
Some demo programs are listed here. Their full source codes can be found in |
709 | 722 |
the \c demo subdirectory of the source tree. |
710 | 723 |
|
711 | 724 |
In order to compile them, use the <tt>make demo</tt> or the |
712 | 725 |
<tt>make check</tt> commands. |
713 | 726 |
*/ |
714 | 727 |
|
715 | 728 |
} |
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-2009 |
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 |
/** |
20 | 20 |
\mainpage LEMON Documentation |
21 | 21 |
|
22 | 22 |
\section intro Introduction |
23 | 23 |
|
24 |
\subsection whatis What is LEMON |
|
25 |
|
|
26 |
LEMON stands for <b>L</b>ibrary for <b>E</b>fficient <b>M</b>odeling |
|
27 |
and <b>O</b>ptimization in <b>N</b>etworks. |
|
28 |
It is a C++ template |
|
29 |
library aimed at combinatorial optimization tasks which |
|
30 |
often involve in working |
|
31 |
with graphs. |
|
24 |
<b>LEMON</b> stands for <i><b>L</b>ibrary for <b>E</b>fficient <b>M</b>odeling |
|
25 |
and <b>O</b>ptimization in <b>N</b>etworks</i>. |
|
26 |
It is a C++ template library providing efficient implementation of common |
|
27 |
data structures and algorithms with focus on combinatorial optimization |
|
28 |
problems in graphs and networks. |
|
32 | 29 |
|
33 | 30 |
<b> |
34 | 31 |
LEMON is an <a class="el" href="http://opensource.org/">open source</a> |
35 | 32 |
project. |
36 | 33 |
You are free to use it in your commercial or |
37 | 34 |
non-commercial applications under very permissive |
38 | 35 |
\ref license "license terms". |
39 | 36 |
</b> |
40 | 37 |
|
41 |
|
|
38 |
The project is maintained by the |
|
39 |
<a href="http://www.cs.elte.hu/egres/">Egerváry Research Group on |
|
40 |
Combinatorial Optimization</a> \ref egres |
|
41 |
at the Operations Research Department of the |
|
42 |
<a href="http://www.elte.hu/">Eötvös Loránd University, |
|
43 |
Budapest</a>, Hungary. |
|
44 |
LEMON is also a member of the <a href="http://www.coin-or.org/">COIN-OR</a> |
|
45 |
initiative \ref coinor. |
|
46 |
|
|
47 |
\section howtoread How to Read the Documentation |
|
42 | 48 |
|
43 | 49 |
If you would like to get to know the library, see |
44 | 50 |
<a class="el" href="http://lemon.cs.elte.hu/pub/tutorial/">LEMON Tutorial</a>. |
45 | 51 |
|
46 | 52 |
If you know what you are looking for, then try to find it under the |
47 | 53 |
<a class="el" href="modules.html">Modules</a> section. |
48 | 54 |
|
49 | 55 |
If you are a user of the old (0.x) series of LEMON, please check out the |
50 | 56 |
\ref migration "Migration Guide" for the backward incompatibilities. |
51 | 57 |
*/ |
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-2009 |
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 |
\page min_cost_flow Minimum Cost Flow Problem |
23 | 23 |
|
24 | 24 |
\section mcf_def Definition (GEQ form) |
25 | 25 |
|
26 | 26 |
The \e minimum \e cost \e flow \e problem is to find a feasible flow of |
27 | 27 |
minimum total cost from a set of supply nodes to a set of demand nodes |
28 | 28 |
in a network with capacity constraints (lower and upper bounds) |
29 |
and arc costs. |
|
29 |
and arc costs \ref amo93networkflows. |
|
30 | 30 |
|
31 | 31 |
Formally, let \f$G=(V,A)\f$ be a digraph, \f$lower: A\rightarrow\mathbf{R}\f$, |
32 | 32 |
\f$upper: A\rightarrow\mathbf{R}\cup\{+\infty\}\f$ denote the lower and |
33 | 33 |
upper bounds for the flow values on the arcs, for which |
34 | 34 |
\f$lower(uv) \leq upper(uv)\f$ must hold for all \f$uv\in A\f$, |
35 | 35 |
\f$cost: A\rightarrow\mathbf{R}\f$ denotes the cost per unit flow |
36 | 36 |
on the arcs and \f$sup: V\rightarrow\mathbf{R}\f$ denotes the |
37 | 37 |
signed supply values of the nodes. |
38 | 38 |
If \f$sup(u)>0\f$, then \f$u\f$ is a supply node with \f$sup(u)\f$ |
39 | 39 |
supply, if \f$sup(u)<0\f$, then \f$u\f$ is a demand node with |
40 | 40 |
\f$-sup(u)\f$ demand. |
41 | 41 |
A minimum cost flow is an \f$f: A\rightarrow\mathbf{R}\f$ solution |
42 | 42 |
of the following optimization problem. |
43 | 43 |
|
44 | 44 |
\f[ \min\sum_{uv\in A} f(uv) \cdot cost(uv) \f] |
45 | 45 |
\f[ \sum_{uv\in A} f(uv) - \sum_{vu\in A} f(vu) \geq |
46 | 46 |
sup(u) \quad \forall u\in V \f] |
47 | 47 |
\f[ lower(uv) \leq f(uv) \leq upper(uv) \quad \forall uv\in A \f] |
48 | 48 |
|
49 | 49 |
The sum of the supply values, i.e. \f$\sum_{u\in V} sup(u)\f$ must be |
50 | 50 |
zero or negative in order to have a feasible solution (since the sum |
51 | 51 |
of the expressions on the left-hand side of the inequalities is zero). |
52 | 52 |
It means that the total demand must be greater or equal to the total |
53 | 53 |
supply and all the supplies have to be carried out from the supply nodes, |
54 | 54 |
but there could be demands that are not satisfied. |
55 | 55 |
If \f$\sum_{u\in V} sup(u)\f$ is zero, then all the supply/demand |
56 | 56 |
constraints have to be satisfied with equality, i.e. all demands |
57 | 57 |
have to be satisfied and all supplies have to be used. |
58 | 58 |
|
59 | 59 |
|
60 | 60 |
\section mcf_algs Algorithms |
61 | 61 |
|
62 | 62 |
LEMON contains several algorithms for solving this problem, for more |
63 | 63 |
information see \ref min_cost_flow_algs "Minimum Cost Flow Algorithms". |
64 | 64 |
|
65 | 65 |
A feasible solution for this problem can be found using \ref Circulation. |
66 | 66 |
|
67 | 67 |
|
68 | 68 |
\section mcf_dual Dual Solution |
69 | 69 |
|
70 | 70 |
The dual solution of the minimum cost flow problem is represented by |
71 | 71 |
node potentials \f$\pi: V\rightarrow\mathbf{R}\f$. |
72 | 72 |
An \f$f: A\rightarrow\mathbf{R}\f$ primal feasible solution is optimal |
73 | 73 |
if and only if for some \f$\pi: V\rightarrow\mathbf{R}\f$ node potentials |
74 | 74 |
the following \e complementary \e slackness optimality conditions hold. |
75 | 75 |
|
76 | 76 |
- For all \f$uv\in A\f$ arcs: |
77 | 77 |
- if \f$cost^\pi(uv)>0\f$, then \f$f(uv)=lower(uv)\f$; |
78 | 78 |
- if \f$lower(uv)<f(uv)<upper(uv)\f$, then \f$cost^\pi(uv)=0\f$; |
79 | 79 |
- if \f$cost^\pi(uv)<0\f$, then \f$f(uv)=upper(uv)\f$. |
80 | 80 |
- For all \f$u\in V\f$ nodes: |
81 | 81 |
- \f$\pi(u)<=0\f$; |
82 | 82 |
- if \f$\sum_{uv\in A} f(uv) - \sum_{vu\in A} f(vu) \neq sup(u)\f$, |
83 | 83 |
then \f$\pi(u)=0\f$. |
84 | 84 |
|
85 | 85 |
Here \f$cost^\pi(uv)\f$ denotes the \e reduced \e cost of the arc |
86 | 86 |
\f$uv\in A\f$ with respect to the potential function \f$\pi\f$, i.e. |
87 | 87 |
\f[ cost^\pi(uv) = cost(uv) + \pi(u) - \pi(v).\f] |
88 | 88 |
|
89 | 89 |
All algorithms provide dual solution (node potentials), as well, |
90 | 90 |
if an optimal flow is found. |
91 | 91 |
|
92 | 92 |
|
93 | 93 |
\section mcf_eq Equality Form |
94 | 94 |
|
95 | 95 |
The above \ref mcf_def "definition" is actually more general than the |
96 | 96 |
usual formulation of the minimum cost flow problem, in which strict |
97 | 97 |
equalities are required in the supply/demand contraints. |
98 | 98 |
|
99 | 99 |
\f[ \min\sum_{uv\in A} f(uv) \cdot cost(uv) \f] |
100 | 100 |
\f[ \sum_{uv\in A} f(uv) - \sum_{vu\in A} f(vu) = |
101 | 101 |
sup(u) \quad \forall u\in V \f] |
102 | 102 |
\f[ lower(uv) \leq f(uv) \leq upper(uv) \quad \forall uv\in A \f] |
103 | 103 |
|
104 | 104 |
However if the sum of the supply values is zero, then these two problems |
105 | 105 |
are equivalent. |
106 | 106 |
The \ref min_cost_flow_algs "algorithms" in LEMON support the general |
107 | 107 |
form, so if you need the equality form, you have to ensure this additional |
108 | 108 |
contraint manually. |
109 | 109 |
|
110 | 110 |
|
111 | 111 |
\section mcf_leq Opposite Inequalites (LEQ Form) |
112 | 112 |
|
113 | 113 |
Another possible definition of the minimum cost flow problem is |
114 | 114 |
when there are <em>"less or equal"</em> (LEQ) supply/demand constraints, |
115 | 115 |
instead of the <em>"greater or equal"</em> (GEQ) constraints. |
116 | 116 |
|
117 | 117 |
\f[ \min\sum_{uv\in A} f(uv) \cdot cost(uv) \f] |
118 | 118 |
\f[ \sum_{uv\in A} f(uv) - \sum_{vu\in A} f(vu) \leq |
119 | 119 |
sup(u) \quad \forall u\in V \f] |
120 | 120 |
\f[ lower(uv) \leq f(uv) \leq upper(uv) \quad \forall uv\in A \f] |
121 | 121 |
|
122 | 122 |
It means that the total demand must be less or equal to the |
123 | 123 |
total supply (i.e. \f$\sum_{u\in V} sup(u)\f$ must be zero or |
124 | 124 |
positive) and all the demands have to be satisfied, but there |
125 | 125 |
could be supplies that are not carried out from the supply |
126 | 126 |
nodes. |
127 | 127 |
The equality form is also a special case of this form, of course. |
128 | 128 |
|
129 | 129 |
You could easily transform this case to the \ref mcf_def "GEQ form" |
130 | 130 |
of the problem by reversing the direction of the arcs and taking the |
131 | 131 |
negative of the supply values (e.g. using \ref ReverseDigraph and |
132 | 132 |
\ref NegMap adaptors). |
133 | 133 |
However \ref NetworkSimplex algorithm also supports this form directly |
134 | 134 |
for the sake of convenience. |
135 | 135 |
|
136 | 136 |
Note that the optimality conditions for this supply constraint type are |
137 | 137 |
slightly differ from the conditions that are discussed for the GEQ form, |
138 | 138 |
namely the potentials have to be non-negative instead of non-positive. |
139 | 139 |
An \f$f: A\rightarrow\mathbf{R}\f$ feasible solution of this problem |
140 | 140 |
is optimal if and only if for some \f$\pi: V\rightarrow\mathbf{R}\f$ |
141 | 141 |
node potentials the following conditions hold. |
142 | 142 |
|
143 | 143 |
- For all \f$uv\in A\f$ arcs: |
144 | 144 |
- if \f$cost^\pi(uv)>0\f$, then \f$f(uv)=lower(uv)\f$; |
145 | 145 |
- if \f$lower(uv)<f(uv)<upper(uv)\f$, then \f$cost^\pi(uv)=0\f$; |
146 | 146 |
- if \f$cost^\pi(uv)<0\f$, then \f$f(uv)=upper(uv)\f$. |
147 | 147 |
- For all \f$u\in V\f$ nodes: |
148 | 148 |
- \f$\pi(u)>=0\f$; |
149 | 149 |
- if \f$\sum_{uv\in A} f(uv) - \sum_{vu\in A} f(vu) \neq sup(u)\f$, |
150 | 150 |
then \f$\pi(u)=0\f$. |
151 | 151 |
|
152 | 152 |
*/ |
153 | 153 |
} |
1 | 1 |
%%%%% Defining LEMON %%%%% |
2 | 2 |
|
3 | 3 |
@misc{lemon, |
4 | 4 |
key = {LEMON}, |
5 | 5 |
title = {{LEMON} -- {L}ibrary for {E}fficient {M}odeling and |
6 | 6 |
{O}ptimization in {N}etworks}, |
7 | 7 |
howpublished = {\url{http://lemon.cs.elte.hu/}}, |
8 | 8 |
year = 2009 |
9 | 9 |
} |
10 | 10 |
|
11 | 11 |
@misc{egres, |
12 | 12 |
key = {EGRES}, |
13 | 13 |
title = {{EGRES} -- {E}gerv{\'a}ry {R}esearch {G}roup on |
14 | 14 |
{C}ombinatorial {O}ptimization}, |
15 | 15 |
url = {http://www.cs.elte.hu/egres/} |
16 | 16 |
} |
17 | 17 |
|
18 | 18 |
@misc{coinor, |
19 | 19 |
key = {COIN-OR}, |
20 | 20 |
title = {{COIN-OR} -- {C}omputational {I}nfrastructure for |
21 | 21 |
{O}perations {R}esearch}, |
22 | 22 |
url = {http://www.coin-or.org/} |
23 | 23 |
} |
24 | 24 |
|
25 | 25 |
|
26 | 26 |
%%%%% Other libraries %%%%%% |
27 | 27 |
|
28 | 28 |
@misc{boost, |
29 | 29 |
key = {Boost}, |
30 | 30 |
title = {{B}oost {C++} {L}ibraries}, |
31 | 31 |
url = {http://www.boost.org/} |
32 | 32 |
} |
33 | 33 |
|
34 | 34 |
@book{bglbook, |
35 | 35 |
author = {Jeremy G. Siek and Lee-Quan Lee and Andrew |
36 | 36 |
Lumsdaine}, |
37 | 37 |
title = {The Boost Graph Library: User Guide and Reference |
38 | 38 |
Manual}, |
39 | 39 |
publisher = {Addison-Wesley}, |
40 | 40 |
year = 2002 |
41 | 41 |
} |
42 | 42 |
|
43 | 43 |
@misc{leda, |
44 | 44 |
key = {LEDA}, |
45 | 45 |
title = {{LEDA} -- {L}ibrary of {E}fficient {D}ata {T}ypes and |
46 | 46 |
{A}lgorithms}, |
47 | 47 |
url = {http://www.algorithmic-solutions.com/} |
48 | 48 |
} |
49 | 49 |
|
50 | 50 |
@book{ledabook, |
51 | 51 |
author = {Kurt Mehlhorn and Stefan N{\"a}her}, |
52 | 52 |
title = {{LEDA}: {A} platform for combinatorial and geometric |
53 | 53 |
computing}, |
54 | 54 |
isbn = {0-521-56329-1}, |
55 | 55 |
publisher = {Cambridge University Press}, |
56 | 56 |
address = {New York, NY, USA}, |
57 | 57 |
year = 1999 |
58 | 58 |
} |
59 | 59 |
|
60 | 60 |
|
61 | 61 |
%%%%% Tools that LEMON depends on %%%%% |
62 | 62 |
|
63 | 63 |
@misc{cmake, |
64 | 64 |
key = {CMake}, |
65 | 65 |
title = {{CMake} -- {C}ross {P}latform {M}ake}, |
66 | 66 |
url = {http://www.cmake.org/} |
67 | 67 |
} |
68 | 68 |
|
69 | 69 |
@misc{doxygen, |
70 | 70 |
key = {Doxygen}, |
71 | 71 |
title = {{Doxygen} -- {S}ource code documentation generator |
72 | 72 |
tool}, |
73 | 73 |
url = {http://www.doxygen.org/} |
74 | 74 |
} |
75 | 75 |
|
76 | 76 |
|
77 | 77 |
%%%%% LP/MIP libraries %%%%% |
78 | 78 |
|
79 | 79 |
@misc{glpk, |
80 | 80 |
key = {GLPK}, |
81 | 81 |
title = {{GLPK} -- {GNU} {L}inear {P}rogramming {K}it}, |
82 | 82 |
url = {http://www.gnu.org/software/glpk/} |
83 | 83 |
} |
84 | 84 |
|
85 | 85 |
@misc{clp, |
86 | 86 |
key = {Clp}, |
87 | 87 |
title = {{Clp} -- {Coin-Or} {L}inear {P}rogramming}, |
88 | 88 |
url = {http://projects.coin-or.org/Clp/} |
89 | 89 |
} |
90 | 90 |
|
91 | 91 |
@misc{cbc, |
92 | 92 |
key = {Cbc}, |
93 | 93 |
title = {{Cbc} -- {Coin-Or} {B}ranch and {C}ut}, |
94 | 94 |
url = {http://projects.coin-or.org/Cbc/} |
95 | 95 |
} |
96 | 96 |
|
97 | 97 |
@misc{cplex, |
98 | 98 |
key = {CPLEX}, |
99 | 99 |
title = {{ILOG} {CPLEX}}, |
100 | 100 |
url = {http://www.ilog.com/} |
101 | 101 |
} |
102 | 102 |
|
103 | 103 |
@misc{soplex, |
104 | 104 |
key = {SoPlex}, |
105 | 105 |
title = {{SoPlex} -- {T}he {S}equential {O}bject-{O}riented |
106 | 106 |
{S}implex}, |
107 | 107 |
url = {http://soplex.zib.de/} |
108 | 108 |
} |
109 | 109 |
|
110 | 110 |
|
111 | 111 |
%%%%% General books %%%%% |
112 | 112 |
|
113 | 113 |
@book{amo93networkflows, |
114 | 114 |
author = {Ravindra K. Ahuja and Thomas L. Magnanti and James |
115 | 115 |
B. Orlin}, |
116 | 116 |
title = {Network Flows: Theory, Algorithms, and Applications}, |
117 | 117 |
publisher = {Prentice-Hall, Inc.}, |
118 | 118 |
year = 1993, |
119 | 119 |
month = feb, |
120 | 120 |
isbn = {978-0136175490} |
121 | 121 |
} |
122 | 122 |
|
123 | 123 |
@book{schrijver03combinatorial, |
124 | 124 |
author = {Alexander Schrijver}, |
125 | 125 |
title = {Combinatorial Optimization: Polyhedra and Efficiency}, |
126 | 126 |
publisher = {Springer-Verlag}, |
127 | 127 |
year = 2003, |
128 | 128 |
isbn = {978-3540443896} |
129 | 129 |
} |
130 | 130 |
|
131 | 131 |
@book{clrs01algorithms, |
132 | 132 |
author = {Thomas H. Cormen and Charles E. Leiserson and Ronald |
133 | 133 |
L. Rivest and Clifford Stein}, |
134 | 134 |
title = {Introduction to Algorithms}, |
135 | 135 |
publisher = {The MIT Press}, |
136 | 136 |
year = 2001, |
137 | 137 |
edition = {2nd} |
138 | 138 |
} |
139 | 139 |
|
140 | 140 |
@book{stroustrup00cpp, |
141 | 141 |
author = {Bjarne Stroustrup}, |
142 | 142 |
title = {The C++ Programming Language}, |
143 | 143 |
edition = {3rd}, |
144 | 144 |
publisher = {Addison-Wesley Professional}, |
145 | 145 |
isbn = 0201700735, |
146 | 146 |
month = {February}, |
147 | 147 |
year = 2000 |
148 | 148 |
} |
149 | 149 |
|
150 | 150 |
|
151 | 151 |
%%%%% Maximum flow algorithms %%%%% |
152 | 152 |
|
153 |
@ |
|
153 |
@article{edmondskarp72theoretical, |
|
154 |
author = {Jack Edmonds and Richard M. Karp}, |
|
155 |
title = {Theoretical improvements in algorithmic efficiency |
|
156 |
for network flow problems}, |
|
157 |
journal = {Journal of the ACM}, |
|
158 |
year = 1972, |
|
159 |
volume = 19, |
|
160 |
number = 2, |
|
161 |
pages = {248-264} |
|
162 |
} |
|
163 |
|
|
164 |
@article{goldberg88newapproach, |
|
154 | 165 |
author = {Andrew V. Goldberg and Robert E. Tarjan}, |
155 | 166 |
title = {A new approach to the maximum flow problem}, |
156 |
booktitle = {STOC '86: Proceedings of the Eighteenth Annual ACM |
|
157 |
Symposium on Theory of Computing}, |
|
158 |
year = 1986, |
|
159 |
publisher = {ACM Press}, |
|
160 |
address = {New York, NY}, |
|
161 |
pages = {136-146} |
|
167 |
journal = {Journal of the ACM}, |
|
168 |
year = 1988, |
|
169 |
volume = 35, |
|
170 |
number = 4, |
|
171 |
pages = {921-940} |
|
162 | 172 |
} |
163 | 173 |
|
164 | 174 |
@article{dinic70algorithm, |
165 | 175 |
author = {E. A. Dinic}, |
166 | 176 |
title = {Algorithm for solution of a problem of maximum flow |
167 | 177 |
in a network with power estimation}, |
168 | 178 |
journal = {Soviet Math. Doklady}, |
169 | 179 |
year = 1970, |
170 | 180 |
volume = 11, |
171 | 181 |
pages = {1277-1280} |
172 | 182 |
} |
173 | 183 |
|
174 | 184 |
@article{goldberg08partial, |
175 | 185 |
author = {Andrew V. Goldberg}, |
176 | 186 |
title = {The Partial Augment-Relabel Algorithm for the |
177 | 187 |
Maximum Flow Problem}, |
178 | 188 |
journal = {16th Annual European Symposium on Algorithms}, |
179 | 189 |
year = 2008, |
180 | 190 |
pages = {466-477} |
181 | 191 |
} |
182 | 192 |
|
183 | 193 |
@article{sleator83dynamic, |
184 | 194 |
author = {Daniel D. Sleator and Robert E. Tarjan}, |
185 | 195 |
title = {A data structure for dynamic trees}, |
186 | 196 |
journal = {Journal of Computer and System Sciences}, |
187 | 197 |
year = 1983, |
188 | 198 |
volume = 26, |
189 | 199 |
number = 3, |
190 | 200 |
pages = {362-391} |
191 | 201 |
} |
192 | 202 |
|
193 | 203 |
|
194 | 204 |
%%%%% Minimum mean cycle algorithms %%%%% |
195 | 205 |
|
196 | 206 |
@article{karp78characterization, |
197 | 207 |
author = {Richard M. Karp}, |
198 | 208 |
title = {A characterization of the minimum cycle mean in a |
199 | 209 |
digraph}, |
200 | 210 |
journal = {Discrete Math.}, |
201 | 211 |
year = 1978, |
202 | 212 |
volume = 23, |
203 | 213 |
pages = {309-311} |
204 | 214 |
} |
205 | 215 |
|
206 | 216 |
@article{dasdan98minmeancycle, |
207 | 217 |
author = {Ali Dasdan and Rajesh K. Gupta}, |
208 | 218 |
title = {Faster Maximum and Minimum Mean Cycle Alogrithms for |
209 | 219 |
System Performance Analysis}, |
210 | 220 |
journal = {IEEE Transactions on Computer-Aided Design of |
211 | 221 |
Integrated Circuits and Systems}, |
212 | 222 |
year = 1998, |
213 | 223 |
volume = 17, |
214 | 224 |
number = 10, |
215 | 225 |
pages = {889-899} |
216 | 226 |
} |
217 | 227 |
|
218 | 228 |
|
219 | 229 |
%%%%% Minimum cost flow algorithms %%%%% |
220 | 230 |
|
221 | 231 |
@article{klein67primal, |
222 | 232 |
author = {Morton Klein}, |
223 | 233 |
title = {A primal method for minimal cost flows with |
224 | 234 |
applications to the assignment and transportation |
225 | 235 |
problems}, |
226 | 236 |
journal = {Management Science}, |
227 | 237 |
year = 1967, |
228 | 238 |
volume = 14, |
229 | 239 |
pages = {205-220} |
230 | 240 |
} |
231 | 241 |
|
232 |
@ |
|
242 |
@article{goldberg89cyclecanceling, |
|
233 | 243 |
author = {Andrew V. Goldberg and Robert E. Tarjan}, |
234 | 244 |
title = {Finding minimum-cost circulations by canceling |
235 | 245 |
negative cycles}, |
236 |
booktitle = {STOC '88: Proceedings of the Twentieth Annual ACM |
|
237 |
Symposium on Theory of Computing}, |
|
238 |
year = 1988, |
|
239 |
publisher = {ACM Press}, |
|
240 |
address = {New York, NY}, |
|
241 |
pages = {388-397} |
|
246 |
journal = {Journal of the ACM}, |
|
247 |
year = 1989, |
|
248 |
volume = 36, |
|
249 |
number = 4, |
|
250 |
pages = {873-886} |
|
242 | 251 |
} |
243 | 252 |
|
244 |
@article{edmondskarp72theoretical, |
|
245 |
author = {Jack Edmonds and Richard M. Karp}, |
|
246 |
title = {Theoretical improvements in algorithmic efficiency |
|
247 |
for network flow problems}, |
|
248 |
journal = {Journal of the ACM}, |
|
249 |
year = 1972, |
|
250 |
volume = 19, |
|
251 |
number = 2, |
|
252 |
pages = {248-264} |
|
253 |
} |
|
254 |
|
|
255 |
@inproceedings{goldberg87approximation, |
|
256 |
author = {Andrew V. Goldberg and Robert E. Tarjan}, |
|
257 |
title = {Solving minimum-cost flow problems by successive |
|
258 |
approximation}, |
|
259 |
booktitle = {STOC '87: Proceedings of the Nineteenth Annual ACM |
|
260 |
Symposium on Theory of Computing}, |
|
261 |
year = 1987, |
|
262 |
publisher = {ACM Press}, |
|
263 |
address = {New York, NY}, |
|
264 |
pages = {7-18} |
|
265 |
} |
|
266 |
|
|
267 |
@article{goldberg90finding, |
|
253 |
@article{goldberg90approximation, |
|
268 | 254 |
author = {Andrew V. Goldberg and Robert E. Tarjan}, |
269 | 255 |
title = {Finding Minimum-Cost Circulations by Successive |
270 | 256 |
Approximation}, |
271 | 257 |
journal = {Mathematics of Operations Research}, |
272 | 258 |
year = 1990, |
273 | 259 |
volume = 15, |
274 | 260 |
number = 3, |
275 | 261 |
pages = {430-466} |
276 | 262 |
} |
277 | 263 |
|
278 | 264 |
@article{goldberg97efficient, |
279 | 265 |
author = {Andrew V. Goldberg}, |
280 | 266 |
title = {An Efficient Implementation of a Scaling |
281 | 267 |
Minimum-Cost Flow Algorithm}, |
282 | 268 |
journal = {Journal of Algorithms}, |
283 | 269 |
year = 1997, |
284 | 270 |
volume = 22, |
285 | 271 |
number = 1, |
286 | 272 |
pages = {1-29} |
287 | 273 |
} |
288 | 274 |
|
289 | 275 |
@article{bunnagel98efficient, |
290 | 276 |
author = {Ursula B{\"u}nnagel and Bernhard Korte and Jens |
291 | 277 |
Vygen}, |
292 | 278 |
title = {Efficient implementation of the {G}oldberg-{T}arjan |
293 | 279 |
minimum-cost flow algorithm}, |
294 | 280 |
journal = {Optimization Methods and Software}, |
295 | 281 |
year = 1998, |
296 | 282 |
volume = 10, |
297 | 283 |
pages = {157-174} |
298 | 284 |
} |
299 | 285 |
|
286 |
@book{dantzig63linearprog, |
|
287 |
author = {George B. Dantzig}, |
|
288 |
title = {Linear Programming and Extensions}, |
|
289 |
publisher = {Princeton University Press}, |
|
290 |
year = 1963 |
|
291 |
} |
|
292 |
|
|
300 | 293 |
@mastersthesis{kellyoneill91netsimplex, |
301 | 294 |
author = {Damian J. Kelly and Garrett M. O'Neill}, |
302 | 295 |
title = {The Minimum Cost Flow Problem and The Network |
303 | 296 |
Simplex Method}, |
304 | 297 |
school = {University College}, |
305 | 298 |
address = {Dublin, Ireland}, |
306 | 299 |
year = 1991, |
307 | 300 |
month = sep, |
308 | 301 |
} |
309 |
|
|
310 |
@techreport{lobel96networksimplex, |
|
311 |
author = {Andreas L{\"o}bel}, |
|
312 |
title = {Solving large-scale real-world minimum-cost flow |
|
313 |
problems by a network simplex method}, |
|
314 |
institution = {Konrad-Zuse-Zentrum fur Informationstechnik Berlin |
|
315 |
({ZIB})}, |
|
316 |
address = {Berlin, Germany}, |
|
317 |
year = 1996, |
|
318 |
number = {SC 96-7} |
|
319 |
} |
|
320 |
|
|
321 |
@article{frangioni06computational, |
|
322 |
author = {Antonio Frangioni and Antonio Manca}, |
|
323 |
title = {A Computational Study of Cost Reoptimization for |
|
324 |
Min-Cost Flow Problems}, |
|
325 |
journal = {INFORMS Journal On Computing}, |
|
326 |
year = 2006, |
|
327 |
volume = 18, |
|
328 |
number = 1, |
|
329 |
pages = {61-70} |
|
330 |
} |
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-2009 |
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_NETWORK_SIMPLEX_H |
20 | 20 |
#define LEMON_NETWORK_SIMPLEX_H |
21 | 21 |
|
22 | 22 |
/// \ingroup min_cost_flow_algs |
23 | 23 |
/// |
24 | 24 |
/// \file |
25 | 25 |
/// \brief Network Simplex algorithm for finding a minimum cost flow. |
26 | 26 |
|
27 | 27 |
#include <vector> |
28 | 28 |
#include <limits> |
29 | 29 |
#include <algorithm> |
30 | 30 |
|
31 | 31 |
#include <lemon/core.h> |
32 | 32 |
#include <lemon/math.h> |
33 | 33 |
|
34 | 34 |
namespace lemon { |
35 | 35 |
|
36 | 36 |
/// \addtogroup min_cost_flow_algs |
37 | 37 |
/// @{ |
38 | 38 |
|
39 | 39 |
/// \brief Implementation of the primal Network Simplex algorithm |
40 | 40 |
/// for finding a \ref min_cost_flow "minimum cost flow". |
41 | 41 |
/// |
42 | 42 |
/// \ref NetworkSimplex implements the primal Network Simplex algorithm |
43 |
/// for finding a \ref min_cost_flow "minimum cost flow" |
|
43 |
/// for finding a \ref min_cost_flow "minimum cost flow" |
|
44 |
/// \ref amo93networkflows, \ref dantzig63linearprog, |
|
45 |
/// \ref kellyoneill91netsimplex. |
|
44 | 46 |
/// This algorithm is a specialized version of the linear programming |
45 | 47 |
/// simplex method directly for the minimum cost flow problem. |
46 | 48 |
/// It is one of the most efficient solution methods. |
47 | 49 |
/// |
48 | 50 |
/// In general this class is the fastest implementation available |
49 | 51 |
/// in LEMON for the minimum cost flow problem. |
50 | 52 |
/// Moreover it supports both directions of the supply/demand inequality |
51 | 53 |
/// constraints. For more information see \ref SupplyType. |
52 | 54 |
/// |
53 | 55 |
/// Most of the parameters of the problem (except for the digraph) |
54 | 56 |
/// can be given using separate functions, and the algorithm can be |
55 | 57 |
/// executed using the \ref run() function. If some parameters are not |
56 | 58 |
/// specified, then default values will be used. |
57 | 59 |
/// |
58 | 60 |
/// \tparam GR The digraph type the algorithm runs on. |
59 | 61 |
/// \tparam V The value type used for flow amounts, capacity bounds |
60 | 62 |
/// and supply values in the algorithm. By default it is \c int. |
61 | 63 |
/// \tparam C The value type used for costs and potentials in the |
62 | 64 |
/// algorithm. By default it is the same as \c V. |
63 | 65 |
/// |
64 | 66 |
/// \warning Both value types must be signed and all input data must |
65 | 67 |
/// be integer. |
66 | 68 |
/// |
67 | 69 |
/// \note %NetworkSimplex provides five different pivot rule |
68 | 70 |
/// implementations, from which the most efficient one is used |
69 | 71 |
/// by default. For more information see \ref PivotRule. |
70 | 72 |
template <typename GR, typename V = int, typename C = V> |
71 | 73 |
class NetworkSimplex |
72 | 74 |
{ |
73 | 75 |
public: |
74 | 76 |
|
75 | 77 |
/// The type of the flow amounts, capacity bounds and supply values |
76 | 78 |
typedef V Value; |
77 | 79 |
/// The type of the arc costs |
78 | 80 |
typedef C Cost; |
79 | 81 |
|
80 | 82 |
public: |
81 | 83 |
|
82 | 84 |
/// \brief Problem type constants for the \c run() function. |
83 | 85 |
/// |
84 | 86 |
/// Enum type containing the problem type constants that can be |
85 | 87 |
/// returned by the \ref run() function of the algorithm. |
86 | 88 |
enum ProblemType { |
87 | 89 |
/// The problem has no feasible solution (flow). |
88 | 90 |
INFEASIBLE, |
89 | 91 |
/// The problem has optimal solution (i.e. it is feasible and |
90 | 92 |
/// bounded), and the algorithm has found optimal flow and node |
91 | 93 |
/// potentials (primal and dual solutions). |
92 | 94 |
OPTIMAL, |
93 | 95 |
/// The objective function of the problem is unbounded, i.e. |
94 | 96 |
/// there is a directed cycle having negative total cost and |
95 | 97 |
/// infinite upper bound. |
96 | 98 |
UNBOUNDED |
97 | 99 |
}; |
98 | 100 |
|
99 | 101 |
/// \brief Constants for selecting the type of the supply constraints. |
100 | 102 |
/// |
101 | 103 |
/// Enum type containing constants for selecting the supply type, |
102 | 104 |
/// i.e. the direction of the inequalities in the supply/demand |
103 | 105 |
/// constraints of the \ref min_cost_flow "minimum cost flow problem". |
104 | 106 |
/// |
105 | 107 |
/// The default supply type is \c GEQ, the \c LEQ type can be |
106 | 108 |
/// selected using \ref supplyType(). |
107 | 109 |
/// The equality form is a special case of both supply types. |
108 | 110 |
enum SupplyType { |
109 | 111 |
/// This option means that there are <em>"greater or equal"</em> |
110 | 112 |
/// supply/demand constraints in the definition of the problem. |
111 | 113 |
GEQ, |
112 | 114 |
/// This option means that there are <em>"less or equal"</em> |
113 | 115 |
/// supply/demand constraints in the definition of the problem. |
114 | 116 |
LEQ |
115 | 117 |
}; |
116 | 118 |
|
117 | 119 |
/// \brief Constants for selecting the pivot rule. |
118 | 120 |
/// |
119 | 121 |
/// Enum type containing constants for selecting the pivot rule for |
120 | 122 |
/// the \ref run() function. |
121 | 123 |
/// |
122 | 124 |
/// \ref NetworkSimplex provides five different pivot rule |
123 | 125 |
/// implementations that significantly affect the running time |
124 | 126 |
/// of the algorithm. |
125 | 127 |
/// By default \ref BLOCK_SEARCH "Block Search" is used, which |
126 | 128 |
/// proved to be the most efficient and the most robust on various |
127 | 129 |
/// test inputs according to our benchmark tests. |
128 | 130 |
/// However another pivot rule can be selected using the \ref run() |
129 | 131 |
/// function with the proper parameter. |
130 | 132 |
enum PivotRule { |
131 | 133 |
|
132 | 134 |
/// The First Eligible pivot rule. |
133 | 135 |
/// The next eligible arc is selected in a wraparound fashion |
134 | 136 |
/// in every iteration. |
135 | 137 |
FIRST_ELIGIBLE, |
136 | 138 |
|
137 | 139 |
/// The Best Eligible pivot rule. |
138 | 140 |
/// The best eligible arc is selected in every iteration. |
139 | 141 |
BEST_ELIGIBLE, |
140 | 142 |
|
141 | 143 |
/// The Block Search pivot rule. |
142 | 144 |
/// A specified number of arcs are examined in every iteration |
143 | 145 |
/// in a wraparound fashion and the best eligible arc is selected |
144 | 146 |
/// from this block. |
145 | 147 |
BLOCK_SEARCH, |
146 | 148 |
|
147 | 149 |
/// The Candidate List pivot rule. |
148 | 150 |
/// In a major iteration a candidate list is built from eligible arcs |
149 | 151 |
/// in a wraparound fashion and in the following minor iterations |
150 | 152 |
/// the best eligible arc is selected from this list. |
151 | 153 |
CANDIDATE_LIST, |
152 | 154 |
|
153 | 155 |
/// The Altering Candidate List pivot rule. |
154 | 156 |
/// It is a modified version of the Candidate List method. |
155 | 157 |
/// It keeps only the several best eligible arcs from the former |
156 | 158 |
/// candidate list and extends this list in every iteration. |
157 | 159 |
ALTERING_LIST |
158 | 160 |
}; |
159 | 161 |
|
160 | 162 |
private: |
161 | 163 |
|
162 | 164 |
TEMPLATE_DIGRAPH_TYPEDEFS(GR); |
163 | 165 |
|
164 | 166 |
typedef std::vector<int> IntVector; |
165 | 167 |
typedef std::vector<bool> BoolVector; |
166 | 168 |
typedef std::vector<Value> ValueVector; |
167 | 169 |
typedef std::vector<Cost> CostVector; |
168 | 170 |
|
169 | 171 |
// State constants for arcs |
170 | 172 |
enum ArcStateEnum { |
171 | 173 |
STATE_UPPER = -1, |
172 | 174 |
STATE_TREE = 0, |
173 | 175 |
STATE_LOWER = 1 |
174 | 176 |
}; |
175 | 177 |
|
176 | 178 |
private: |
177 | 179 |
|
178 | 180 |
// Data related to the underlying digraph |
179 | 181 |
const GR &_graph; |
180 | 182 |
int _node_num; |
181 | 183 |
int _arc_num; |
182 | 184 |
int _all_arc_num; |
183 | 185 |
int _search_arc_num; |
184 | 186 |
|
185 | 187 |
// Parameters of the problem |
186 | 188 |
bool _have_lower; |
187 | 189 |
SupplyType _stype; |
188 | 190 |
Value _sum_supply; |
189 | 191 |
|
190 | 192 |
// Data structures for storing the digraph |
191 | 193 |
IntNodeMap _node_id; |
192 | 194 |
IntArcMap _arc_id; |
193 | 195 |
IntVector _source; |
194 | 196 |
IntVector _target; |
195 | 197 |
|
196 | 198 |
// Node and arc data |
197 | 199 |
ValueVector _lower; |
198 | 200 |
ValueVector _upper; |
199 | 201 |
ValueVector _cap; |
200 | 202 |
CostVector _cost; |
201 | 203 |
ValueVector _supply; |
202 | 204 |
ValueVector _flow; |
203 | 205 |
CostVector _pi; |
204 | 206 |
|
205 | 207 |
// Data for storing the spanning tree structure |
206 | 208 |
IntVector _parent; |
207 | 209 |
IntVector _pred; |
208 | 210 |
IntVector _thread; |
209 | 211 |
IntVector _rev_thread; |
210 | 212 |
IntVector _succ_num; |
211 | 213 |
IntVector _last_succ; |
212 | 214 |
IntVector _dirty_revs; |
213 | 215 |
BoolVector _forward; |
214 | 216 |
IntVector _state; |
215 | 217 |
int _root; |
216 | 218 |
|
217 | 219 |
// Temporary data used in the current pivot iteration |
218 | 220 |
int in_arc, join, u_in, v_in, u_out, v_out; |
219 | 221 |
int first, second, right, last; |
220 | 222 |
int stem, par_stem, new_stem; |
221 | 223 |
Value delta; |
222 | 224 |
|
223 | 225 |
public: |
224 | 226 |
|
225 | 227 |
/// \brief Constant for infinite upper bounds (capacities). |
226 | 228 |
/// |
227 | 229 |
/// Constant for infinite upper bounds (capacities). |
228 | 230 |
/// It is \c std::numeric_limits<Value>::infinity() if available, |
229 | 231 |
/// \c std::numeric_limits<Value>::max() otherwise. |
230 | 232 |
const Value INF; |
231 | 233 |
|
232 | 234 |
private: |
233 | 235 |
|
234 | 236 |
// Implementation of the First Eligible pivot rule |
235 | 237 |
class FirstEligiblePivotRule |
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-2009 |
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_PREFLOW_H |
20 | 20 |
#define LEMON_PREFLOW_H |
21 | 21 |
|
22 | 22 |
#include <lemon/tolerance.h> |
23 | 23 |
#include <lemon/elevator.h> |
24 | 24 |
|
25 | 25 |
/// \file |
26 | 26 |
/// \ingroup max_flow |
27 | 27 |
/// \brief Implementation of the preflow algorithm. |
28 | 28 |
|
29 | 29 |
namespace lemon { |
30 | 30 |
|
31 | 31 |
/// \brief Default traits class of Preflow class. |
32 | 32 |
/// |
33 | 33 |
/// Default traits class of Preflow class. |
34 | 34 |
/// \tparam GR Digraph type. |
35 | 35 |
/// \tparam CAP Capacity map type. |
36 | 36 |
template <typename GR, typename CAP> |
37 | 37 |
struct PreflowDefaultTraits { |
38 | 38 |
|
39 | 39 |
/// \brief The type of the digraph the algorithm runs on. |
40 | 40 |
typedef GR Digraph; |
41 | 41 |
|
42 | 42 |
/// \brief The type of the map that stores the arc capacities. |
43 | 43 |
/// |
44 | 44 |
/// The type of the map that stores the arc capacities. |
45 | 45 |
/// It must meet the \ref concepts::ReadMap "ReadMap" concept. |
46 | 46 |
typedef CAP CapacityMap; |
47 | 47 |
|
48 | 48 |
/// \brief The type of the flow values. |
49 | 49 |
typedef typename CapacityMap::Value Value; |
50 | 50 |
|
51 | 51 |
/// \brief The type of the map that stores the flow values. |
52 | 52 |
/// |
53 | 53 |
/// The type of the map that stores the flow values. |
54 | 54 |
/// It must meet the \ref concepts::ReadWriteMap "ReadWriteMap" concept. |
55 | 55 |
#ifdef DOXYGEN |
56 | 56 |
typedef GR::ArcMap<Value> FlowMap; |
57 | 57 |
#else |
58 | 58 |
typedef typename Digraph::template ArcMap<Value> FlowMap; |
59 | 59 |
#endif |
60 | 60 |
|
61 | 61 |
/// \brief Instantiates a FlowMap. |
62 | 62 |
/// |
63 | 63 |
/// This function instantiates a \ref FlowMap. |
64 | 64 |
/// \param digraph The digraph for which we would like to define |
65 | 65 |
/// the flow map. |
66 | 66 |
static FlowMap* createFlowMap(const Digraph& digraph) { |
67 | 67 |
return new FlowMap(digraph); |
68 | 68 |
} |
69 | 69 |
|
70 | 70 |
/// \brief The elevator type used by Preflow algorithm. |
71 | 71 |
/// |
72 | 72 |
/// The elevator type used by Preflow algorithm. |
73 | 73 |
/// |
74 | 74 |
/// \sa Elevator, LinkedElevator |
75 | 75 |
#ifdef DOXYGEN |
76 | 76 |
typedef lemon::Elevator<GR, GR::Node> Elevator; |
77 | 77 |
#else |
78 | 78 |
typedef lemon::Elevator<Digraph, typename Digraph::Node> Elevator; |
79 | 79 |
#endif |
80 | 80 |
|
81 | 81 |
/// \brief Instantiates an Elevator. |
82 | 82 |
/// |
83 | 83 |
/// This function instantiates an \ref Elevator. |
84 | 84 |
/// \param digraph The digraph for which we would like to define |
85 | 85 |
/// the elevator. |
86 | 86 |
/// \param max_level The maximum level of the elevator. |
87 | 87 |
static Elevator* createElevator(const Digraph& digraph, int max_level) { |
88 | 88 |
return new Elevator(digraph, max_level); |
89 | 89 |
} |
90 | 90 |
|
91 | 91 |
/// \brief The tolerance used by the algorithm |
92 | 92 |
/// |
93 | 93 |
/// The tolerance used by the algorithm to handle inexact computation. |
94 | 94 |
typedef lemon::Tolerance<Value> Tolerance; |
95 | 95 |
|
96 | 96 |
}; |
97 | 97 |
|
98 | 98 |
|
99 | 99 |
/// \ingroup max_flow |
100 | 100 |
/// |
101 | 101 |
/// \brief %Preflow algorithm class. |
102 | 102 |
/// |
103 | 103 |
/// This class provides an implementation of Goldberg-Tarjan's \e preflow |
104 | 104 |
/// \e push-relabel algorithm producing a \ref max_flow |
105 |
/// "flow of maximum value" in a digraph |
|
105 |
/// "flow of maximum value" in a digraph \ref clrs01algorithms, |
|
106 |
/// \ref amo93networkflows, \ref goldberg88newapproach. |
|
106 | 107 |
/// The preflow algorithms are the fastest known maximum |
107 | 108 |
/// flow algorithms. The current implementation uses a mixture of the |
108 | 109 |
/// \e "highest label" and the \e "bound decrease" heuristics. |
109 | 110 |
/// The worst case time complexity of the algorithm is \f$O(n^2\sqrt{e})\f$. |
110 | 111 |
/// |
111 | 112 |
/// The algorithm consists of two phases. After the first phase |
112 | 113 |
/// the maximum flow value and the minimum cut is obtained. The |
113 | 114 |
/// second phase constructs a feasible maximum flow on each arc. |
114 | 115 |
/// |
115 | 116 |
/// \tparam GR The type of the digraph the algorithm runs on. |
116 | 117 |
/// \tparam CAP The type of the capacity map. The default map |
117 | 118 |
/// type is \ref concepts::Digraph::ArcMap "GR::ArcMap<int>". |
118 | 119 |
#ifdef DOXYGEN |
119 | 120 |
template <typename GR, typename CAP, typename TR> |
120 | 121 |
#else |
121 | 122 |
template <typename GR, |
122 | 123 |
typename CAP = typename GR::template ArcMap<int>, |
123 | 124 |
typename TR = PreflowDefaultTraits<GR, CAP> > |
124 | 125 |
#endif |
125 | 126 |
class Preflow { |
126 | 127 |
public: |
127 | 128 |
|
128 | 129 |
///The \ref PreflowDefaultTraits "traits class" of the algorithm. |
129 | 130 |
typedef TR Traits; |
130 | 131 |
///The type of the digraph the algorithm runs on. |
131 | 132 |
typedef typename Traits::Digraph Digraph; |
132 | 133 |
///The type of the capacity map. |
133 | 134 |
typedef typename Traits::CapacityMap CapacityMap; |
134 | 135 |
///The type of the flow values. |
135 | 136 |
typedef typename Traits::Value Value; |
136 | 137 |
|
137 | 138 |
///The type of the flow map. |
138 | 139 |
typedef typename Traits::FlowMap FlowMap; |
139 | 140 |
///The type of the elevator. |
140 | 141 |
typedef typename Traits::Elevator Elevator; |
141 | 142 |
///The type of the tolerance. |
142 | 143 |
typedef typename Traits::Tolerance Tolerance; |
143 | 144 |
|
144 | 145 |
private: |
145 | 146 |
|
146 | 147 |
TEMPLATE_DIGRAPH_TYPEDEFS(Digraph); |
147 | 148 |
|
148 | 149 |
const Digraph& _graph; |
149 | 150 |
const CapacityMap* _capacity; |
150 | 151 |
|
151 | 152 |
int _node_num; |
152 | 153 |
|
153 | 154 |
Node _source, _target; |
154 | 155 |
|
155 | 156 |
FlowMap* _flow; |
156 | 157 |
bool _local_flow; |
157 | 158 |
|
158 | 159 |
Elevator* _level; |
159 | 160 |
bool _local_level; |
160 | 161 |
|
161 | 162 |
typedef typename Digraph::template NodeMap<Value> ExcessMap; |
162 | 163 |
ExcessMap* _excess; |
163 | 164 |
|
164 | 165 |
Tolerance _tolerance; |
165 | 166 |
|
166 | 167 |
bool _phase; |
167 | 168 |
|
168 | 169 |
|
169 | 170 |
void createStructures() { |
170 | 171 |
_node_num = countNodes(_graph); |
171 | 172 |
|
172 | 173 |
if (!_flow) { |
173 | 174 |
_flow = Traits::createFlowMap(_graph); |
174 | 175 |
_local_flow = true; |
175 | 176 |
} |
176 | 177 |
if (!_level) { |
177 | 178 |
_level = Traits::createElevator(_graph, _node_num); |
178 | 179 |
_local_level = true; |
179 | 180 |
} |
180 | 181 |
if (!_excess) { |
181 | 182 |
_excess = new ExcessMap(_graph); |
182 | 183 |
} |
183 | 184 |
} |
184 | 185 |
|
185 | 186 |
void destroyStructures() { |
186 | 187 |
if (_local_flow) { |
187 | 188 |
delete _flow; |
188 | 189 |
} |
189 | 190 |
if (_local_level) { |
190 | 191 |
delete _level; |
191 | 192 |
} |
192 | 193 |
if (_excess) { |
193 | 194 |
delete _excess; |
194 | 195 |
} |
195 | 196 |
} |
196 | 197 |
|
197 | 198 |
public: |
198 | 199 |
|
199 | 200 |
typedef Preflow Create; |
200 | 201 |
|
201 | 202 |
///\name Named Template Parameters |
202 | 203 |
|
203 | 204 |
///@{ |
204 | 205 |
|
205 | 206 |
template <typename T> |
206 | 207 |
struct SetFlowMapTraits : public Traits { |
207 | 208 |
typedef T FlowMap; |
208 | 209 |
static FlowMap *createFlowMap(const Digraph&) { |
209 | 210 |
LEMON_ASSERT(false, "FlowMap is not initialized"); |
210 | 211 |
return 0; // ignore warnings |
211 | 212 |
} |
212 | 213 |
}; |
213 | 214 |
|
214 | 215 |
/// \brief \ref named-templ-param "Named parameter" for setting |
215 | 216 |
/// FlowMap type |
216 | 217 |
/// |
217 | 218 |
/// \ref named-templ-param "Named parameter" for setting FlowMap |
218 | 219 |
/// type. |
219 | 220 |
template <typename T> |
220 | 221 |
struct SetFlowMap |
221 | 222 |
: public Preflow<Digraph, CapacityMap, SetFlowMapTraits<T> > { |
222 | 223 |
typedef Preflow<Digraph, CapacityMap, |
223 | 224 |
SetFlowMapTraits<T> > Create; |
224 | 225 |
}; |
225 | 226 |
|
226 | 227 |
template <typename T> |
227 | 228 |
struct SetElevatorTraits : public Traits { |
228 | 229 |
typedef T Elevator; |
229 | 230 |
static Elevator *createElevator(const Digraph&, int) { |
230 | 231 |
LEMON_ASSERT(false, "Elevator is not initialized"); |
231 | 232 |
return 0; // ignore warnings |
232 | 233 |
} |
233 | 234 |
}; |
234 | 235 |
|
235 | 236 |
/// \brief \ref named-templ-param "Named parameter" for setting |
236 | 237 |
/// Elevator type |
237 | 238 |
/// |
238 | 239 |
/// \ref named-templ-param "Named parameter" for setting Elevator |
239 | 240 |
/// type. If this named parameter is used, then an external |
240 | 241 |
/// elevator object must be passed to the algorithm using the |
241 | 242 |
/// \ref elevator(Elevator&) "elevator()" function before calling |
242 | 243 |
/// \ref run() or \ref init(). |
243 | 244 |
/// \sa SetStandardElevator |
244 | 245 |
template <typename T> |
245 | 246 |
struct SetElevator |
246 | 247 |
: public Preflow<Digraph, CapacityMap, SetElevatorTraits<T> > { |
247 | 248 |
typedef Preflow<Digraph, CapacityMap, |
248 | 249 |
SetElevatorTraits<T> > Create; |
249 | 250 |
}; |
250 | 251 |
|
251 | 252 |
template <typename T> |
252 | 253 |
struct SetStandardElevatorTraits : public Traits { |
253 | 254 |
typedef T Elevator; |
254 | 255 |
static Elevator *createElevator(const Digraph& digraph, int max_level) { |
255 | 256 |
return new Elevator(digraph, max_level); |
256 | 257 |
} |
257 | 258 |
}; |
258 | 259 |
|
259 | 260 |
/// \brief \ref named-templ-param "Named parameter" for setting |
260 | 261 |
/// Elevator type with automatic allocation |
261 | 262 |
/// |
262 | 263 |
/// \ref named-templ-param "Named parameter" for setting Elevator |
263 | 264 |
/// type with automatic allocation. |
264 | 265 |
/// The Elevator should have standard constructor interface to be |
265 | 266 |
/// able to automatically created by the algorithm (i.e. the |
266 | 267 |
/// digraph and the maximum level should be passed to it). |
267 | 268 |
/// However an external elevator object could also be passed to the |
268 | 269 |
/// algorithm with the \ref elevator(Elevator&) "elevator()" function |
269 | 270 |
/// before calling \ref run() or \ref init(). |
270 | 271 |
/// \sa SetElevator |
271 | 272 |
template <typename T> |
272 | 273 |
struct SetStandardElevator |
273 | 274 |
: public Preflow<Digraph, CapacityMap, |
274 | 275 |
SetStandardElevatorTraits<T> > { |
275 | 276 |
typedef Preflow<Digraph, CapacityMap, |
276 | 277 |
SetStandardElevatorTraits<T> > Create; |
277 | 278 |
}; |
278 | 279 |
|
279 | 280 |
/// @} |
280 | 281 |
|
281 | 282 |
protected: |
282 | 283 |
|
283 | 284 |
Preflow() {} |
284 | 285 |
|
285 | 286 |
public: |
286 | 287 |
|
287 | 288 |
|
288 | 289 |
/// \brief The constructor of the class. |
289 | 290 |
/// |
290 | 291 |
/// The constructor of the class. |
291 | 292 |
/// \param digraph The digraph the algorithm runs on. |
292 | 293 |
/// \param capacity The capacity of the arcs. |
293 | 294 |
/// \param source The source node. |
294 | 295 |
/// \param target The target node. |
295 | 296 |
Preflow(const Digraph& digraph, const CapacityMap& capacity, |
296 | 297 |
Node source, Node target) |
297 | 298 |
: _graph(digraph), _capacity(&capacity), |
0 comments (0 inline)