gravatar
kpeter (Peter Kovacs)
kpeter@inf.elte.hu
Small doc fixes and improvements (#359)
0 4 0
default
4 files changed with 22 insertions and 23 deletions:
↑ Collapse diff ↑
Show white space 192 line context
1 1
LEMON code without an explicit copyright notice is covered by the following
2 2
copyright/license.
3 3

	
4
Copyright (C) 2003-2009 Egervary Jeno Kombinatorikus Optimalizalasi
4
Copyright (C) 2003-2010 Egervary Jeno Kombinatorikus Optimalizalasi
5 5
Kutatocsoport (Egervary Combinatorial Optimization Research Group,
6 6
EGRES).
7 7

	
8 8
===========================================================================
9 9
Boost Software License, Version 1.0
10 10
===========================================================================
11 11

	
12 12
Permission is hereby granted, free of charge, to any person or organization
13 13
obtaining a copy of the software and accompanying documentation covered by
14 14
this license (the "Software") to use, reproduce, display, distribute,
15 15
execute, and transmit the Software, and to prepare derivative works of the
16 16
Software, and to permit third-parties to whom the Software is furnished to
17 17
do so, all subject to the following:
18 18

	
19 19
The copyright notices in the Software and this entire statement, including
20 20
the above license grant, this restriction and the following disclaimer,
21 21
must be included in all copies of the Software, in whole or in part, and
22 22
all derivative works of the Software, unless such copies or derivative
23 23
works are solely in the form of machine-executable object code generated by
24 24
a source language processor.
25 25

	
26 26
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
27 27
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
28 28
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
29 29
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
30 30
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
31 31
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
32 32
DEALINGS IN THE SOFTWARE.
Show white space 192 line context
... ...
@@ -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

	
Show white space 192 line context
1 1
/* -*- mode: C++; indent-tabs-mode: nil; -*-
2 2
 *
3 3
 * This file is a part of LEMON, a generic C++ optimization library.
4 4
 *
5 5
 * Copyright (C) 2003-2010
6 6
 * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
7 7
 * (Egervary Research Group on Combinatorial Optimization, EGRES).
8 8
 *
9 9
 * Permission to use, modify and distribute this software is granted
10 10
 * provided that this copyright notice appears in all copies. For
11 11
 * precise terms see the accompanying LICENSE file.
12 12
 *
13 13
 * This software is provided "AS IS" with no warranty of any kind,
14 14
 * express or implied, and with no claim as to its suitability for any
15 15
 * purpose.
16 16
 *
17 17
 */
18 18

	
19 19
#ifndef LEMON_ARG_PARSER_H
20 20
#define LEMON_ARG_PARSER_H
21 21

	
22 22
#include <vector>
23 23
#include <map>
24 24
#include <list>
25 25
#include <string>
26 26
#include <iostream>
27 27
#include <sstream>
28 28
#include <algorithm>
29 29
#include <lemon/assert.h>
30 30

	
31 31
///\ingroup misc
32 32
///\file
33 33
///\brief A tool to parse command line arguments.
34 34

	
35 35
namespace lemon {
36 36

	
37 37
  ///Exception used by ArgParser
38

	
39
  ///Exception used by ArgParser.
40
  ///
38 41
  class ArgParserException : public Exception {
39 42
  public:
43
    /// Reasons for failure
44

	
45
    /// Reasons for failure.
46
    ///
40 47
    enum Reason {
41
      HELP,         /// <tt>--help</tt> option was given
42
      UNKNOWN_OPT,  /// Unknown option was given
43
      INVALID_OPT   /// Invalid combination of options
48
      HELP,         ///< <tt>--help</tt> option was given.
49
      UNKNOWN_OPT,  ///< Unknown option was given.
50
      INVALID_OPT   ///< Invalid combination of options.
44 51
    };
45 52

	
46 53
  private:
47 54
    Reason _reason;
48 55

	
49 56
  public:
50 57
    ///Constructor
51 58
    ArgParserException(Reason r) throw() : _reason(r) {}
52 59
    ///Virtual destructor
53 60
    virtual ~ArgParserException() throw() {}
54 61
    ///A short description of the exception
55 62
    virtual const char* what() const throw() {
56 63
      switch(_reason)
57 64
        {
58 65
        case HELP:
59 66
          return "lemon::ArgParseException: ask for help";
60 67
          break;
61 68
        case UNKNOWN_OPT:
62 69
          return "lemon::ArgParseException: unknown option";
63 70
          break;
64 71
        case INVALID_OPT:
65 72
          return "lemon::ArgParseException: invalid combination of options";
66 73
          break;
67 74
        }
68 75
      return "";
69 76
    }
70 77
    ///Return the reason for the failure
71 78
    Reason reason() const {return _reason; }
72 79
  };
73 80

	
74 81

	
75 82
  ///Command line arguments parser
76 83

	
77 84
  ///\ingroup misc
78 85
  ///Command line arguments parser.
79 86
  ///
80 87
  ///For a complete example see the \ref arg_parser_demo.cc demo file.
81 88
  class ArgParser {
82 89

	
83 90
    static void _showHelp(void *p);
84 91
  protected:
85 92

	
86 93
    int _argc;
87 94
    const char * const *_argv;
88 95

	
89 96
    enum OptType { UNKNOWN=0, BOOL=1, STRING=2, DOUBLE=3, INTEGER=4, FUNC=5 };
90 97

	
91 98
    class ParData {
92 99
    public:
93 100
      union {
94 101
        bool *bool_p;
95 102
        int *int_p;
96 103
        double *double_p;
97 104
        std::string *string_p;
98 105
        struct {
99 106
          void (*p)(void *);
100 107
          void *data;
101 108
        } func_p;
102 109

	
103 110
      };
104 111
      std::string help;
105 112
      bool mandatory;
106 113
      OptType type;
107 114
      bool set;
108 115
      bool ingroup;
109 116
      bool has_syn;
110 117
      bool syn;
111 118
      bool self_delete;
112 119
      ParData() : mandatory(false), type(UNKNOWN), set(false), ingroup(false),
113 120
                  has_syn(false), syn(false), self_delete(false) {}
114 121
    };
115 122

	
116 123
    typedef std::map<std::string,ParData> Opts;
117 124
    Opts _opts;
118 125

	
119 126
    class GroupData
120 127
    {
121 128
    public:
122 129
      typedef std::list<std::string> Opts;
123 130
      Opts opts;
124 131
      bool only_one;
125 132
      bool mandatory;
126 133
      GroupData() :only_one(false), mandatory(false) {}
127 134
    };
128 135

	
129 136
    typedef std::map<std::string,GroupData> Groups;
130 137
    Groups _groups;
131 138

	
132 139
    struct OtherArg
133 140
    {
134 141
      std::string name;
135 142
      std::string help;
136 143
      OtherArg(std::string n, std::string h) :name(n), help(h) {}
137 144

	
138 145
    };
139 146

	
Show white space 192 line context
1 1
/* -*- mode: C++; indent-tabs-mode: nil; -*-
2 2
 *
3 3
 * This file is a part of LEMON, a generic C++ optimization library.
4 4
 *
5 5
 * Copyright (C) 2003-2010
6 6
 * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
7 7
 * (Egervary Research Group on Combinatorial Optimization, EGRES).
8 8
 *
9 9
 * Permission to use, modify and distribute this software is granted
10 10
 * provided that this copyright notice appears in all copies. For
11 11
 * precise terms see the accompanying LICENSE file.
12 12
 *
13 13
 * This software is provided "AS IS" with no warranty of any kind,
14 14
 * express or implied, and with no claim as to its suitability for any
15 15
 * purpose.
16 16
 *
17 17
 */
18 18

	
19 19
#ifndef LEMON_HARTMANN_ORLIN_MMC_H
20 20
#define LEMON_HARTMANN_ORLIN_MMC_H
21 21

	
22 22
/// \ingroup min_mean_cycle
23 23
///
24 24
/// \file
25 25
/// \brief Hartmann-Orlin's algorithm for finding a minimum mean cycle.
26 26

	
27 27
#include <vector>
28 28
#include <limits>
29 29
#include <lemon/core.h>
30 30
#include <lemon/path.h>
31 31
#include <lemon/tolerance.h>
32 32
#include <lemon/connectivity.h>
33 33

	
34 34
namespace lemon {
35 35

	
36 36
  /// \brief Default traits class of HartmannOrlinMmc class.
37 37
  ///
38 38
  /// Default traits class of HartmannOrlinMmc class.
39 39
  /// \tparam GR The type of the digraph.
40 40
  /// \tparam CM The type of the cost map.
41
  /// It must conform to the \ref concepts::Rea_data "Rea_data" concept.
41
  /// It must conform to the \ref concepts::ReadMap "ReadMap" concept.
42 42
#ifdef DOXYGEN
43 43
  template <typename GR, typename CM>
44 44
#else
45 45
  template <typename GR, typename CM,
46 46
    bool integer = std::numeric_limits<typename CM::Value>::is_integer>
47 47
#endif
48 48
  struct HartmannOrlinMmcDefaultTraits
49 49
  {
50 50
    /// The type of the digraph
51 51
    typedef GR Digraph;
52 52
    /// The type of the cost map
53 53
    typedef CM CostMap;
54 54
    /// The type of the arc costs
55 55
    typedef typename CostMap::Value Cost;
56 56

	
57 57
    /// \brief The large cost type used for internal computations
58 58
    ///
59 59
    /// The large cost type used for internal computations.
60 60
    /// It is \c long \c long if the \c Cost type is integer,
61 61
    /// otherwise it is \c double.
62 62
    /// \c Cost must be convertible to \c LargeCost.
63 63
    typedef double LargeCost;
64 64

	
65 65
    /// The tolerance type used for internal computations
66 66
    typedef lemon::Tolerance<LargeCost> Tolerance;
67 67

	
68 68
    /// \brief The path type of the found cycles
69 69
    ///
70 70
    /// The path type of the found cycles.
71 71
    /// It must conform to the \ref lemon::concepts::Path "Path" concept
72 72
    /// and it must have an \c addFront() function.
73 73
    typedef lemon::Path<Digraph> Path;
74 74
  };
75 75

	
76 76
  // Default traits class for integer cost types
77 77
  template <typename GR, typename CM>
78 78
  struct HartmannOrlinMmcDefaultTraits<GR, CM, true>
79 79
  {
80 80
    typedef GR Digraph;
81 81
    typedef CM CostMap;
82 82
    typedef typename CostMap::Value Cost;
83 83
#ifdef LEMON_HAVE_LONG_LONG
84 84
    typedef long long LargeCost;
85 85
#else
86 86
    typedef long LargeCost;
87 87
#endif
88 88
    typedef lemon::Tolerance<LargeCost> Tolerance;
89 89
    typedef lemon::Path<Digraph> Path;
90 90
  };
91 91

	
92 92

	
93 93
  /// \addtogroup min_mean_cycle
94 94
  /// @{
95 95

	
96 96
  /// \brief Implementation of the Hartmann-Orlin algorithm for finding
97 97
  /// a minimum mean cycle.
98 98
  ///
99 99
  /// This class implements the Hartmann-Orlin algorithm for finding
100 100
  /// a directed cycle of minimum mean cost in a digraph
101 101
  /// \ref amo93networkflows, \ref dasdan98minmeancycle.
102
  /// It is an improved version of \ref Karp "Karp"'s original algorithm,
102
  /// It is an improved version of \ref KarpMmc "Karp"'s original algorithm,
103 103
  /// it applies an efficient early termination scheme.
104 104
  /// It runs in time O(ne) and uses space O(n<sup>2</sup>+e).
105 105
  ///
106 106
  /// \tparam GR The type of the digraph the algorithm runs on.
107 107
  /// \tparam CM The type of the cost map. The default
108 108
  /// map type is \ref concepts::Digraph::ArcMap "GR::ArcMap<int>".
109 109
  /// \tparam TR The traits class that defines various types used by the
110 110
  /// algorithm. By default, it is \ref HartmannOrlinMmcDefaultTraits
111 111
  /// "HartmannOrlinMmcDefaultTraits<GR, CM>".
112 112
  /// In most cases, this parameter should not be set directly,
113 113
  /// consider to use the named template parameters instead.
114 114
#ifdef DOXYGEN
115 115
  template <typename GR, typename CM, typename TR>
116 116
#else
117 117
  template < typename GR,
118 118
             typename CM = typename GR::template ArcMap<int>,
119 119
             typename TR = HartmannOrlinMmcDefaultTraits<GR, CM> >
120 120
#endif
121 121
  class HartmannOrlinMmc
122 122
  {
123 123
  public:
124 124

	
125 125
    /// The type of the digraph
126 126
    typedef typename TR::Digraph Digraph;
127 127
    /// The type of the cost map
128 128
    typedef typename TR::CostMap CostMap;
129 129
    /// The type of the arc costs
130 130
    typedef typename TR::Cost Cost;
131 131

	
132 132
    /// \brief The large cost type
133 133
    ///
134 134
    /// The large cost type used for internal computations.
135 135
    /// By default, it is \c long \c long if the \c Cost type is integer,
136 136
    /// otherwise it is \c double.
137 137
    typedef typename TR::LargeCost LargeCost;
138 138

	
139 139
    /// The tolerance type
140 140
    typedef typename TR::Tolerance Tolerance;
141 141

	
142 142
    /// \brief The path type of the found cycles
143 143
    ///
144 144
    /// The path type of the found cycles.
145 145
    /// Using the \ref HartmannOrlinMmcDefaultTraits "default traits class",
146 146
    /// it is \ref lemon::Path "Path<Digraph>".
147 147
    typedef typename TR::Path Path;
148 148

	
149 149
    /// The \ref HartmannOrlinMmcDefaultTraits "traits class" of the algorithm
150 150
    typedef TR Traits;
151 151

	
152 152
  private:
153 153

	
154 154
    TEMPLATE_DIGRAPH_TYPEDEFS(Digraph);
155 155

	
156 156
    // Data sturcture for path data
157 157
    struct PathData
158 158
    {
159 159
      LargeCost dist;
160 160
      Arc pred;
161 161
      PathData(LargeCost d, Arc p = INVALID) :
162 162
        dist(d), pred(p) {}
163 163
    };
164 164

	
165 165
    typedef typename Digraph::template NodeMap<std::vector<PathData> >
166 166
      PathDataNodeMap;
167 167

	
168 168
  private:
169 169

	
170 170
    // The digraph the algorithm runs on
171 171
    const Digraph &_gr;
172 172
    // The cost of the arcs
173 173
    const CostMap &_cost;
174 174

	
175 175
    // Data for storing the strongly connected components
176 176
    int _comp_num;
177 177
    typename Digraph::template NodeMap<int> _comp;
178 178
    std::vector<std::vector<Node> > _comp_nodes;
179 179
    std::vector<Node>* _nodes;
180 180
    typename Digraph::template NodeMap<std::vector<Arc> > _out_arcs;
181 181

	
182 182
    // Data for the found cycles
183 183
    bool _curr_found, _best_found;
184 184
    LargeCost _curr_cost, _best_cost;
185 185
    int _curr_size, _best_size;
186 186
    Node _curr_node, _best_node;
187 187
    int _curr_level, _best_level;
188 188

	
189 189
    Path *_cycle_path;
190 190
    bool _local_path;
191 191

	
192 192
    // Node map for storing path data
193 193
    PathDataNodeMap _data;
194 194
    // The processed nodes in the last round
195 195
    std::vector<Node> _process;
196 196

	
197 197
    Tolerance _tolerance;
198 198

	
0 comments (0 inline)