| ... |
... |
@@ -170,200 +170,192 @@
|
| 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]
|
| ... |
... |
@@ -379,205 +371,205 @@
|
| 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 Karp "Karp"'s original algorithm \ref amo93networkflows,
|
|
467 |
- \ref KarpMmc Karp's original algorithm \ref amo93networkflows,
|
| 476 |
468 |
\ref dasdan98minmeancycle.
|
| 477 |
|
- \ref HartmannOrlin "Hartmann-Orlin"'s algorithm, which is an improved
|
|
469 |
- \ref HartmannOrlinMmc Hartmann-Orlin's algorithm, which is an improved
|
| 478 |
470 |
version of Karp's algorithm \ref dasdan98minmeancycle.
|
| 479 |
|
- \ref Howard "Howard"'s policy iteration algorithm
|
|
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 |
|