0
8
0
| ... | ... |
@@ -98,10 +98,10 @@ |
| 98 | 98 |
|
| 99 | 99 |
\subsection pri-loc-var Private member variables |
| 100 | 100 |
|
| 101 |
Private member variables should start with underscore |
|
| 101 |
Private member variables should start with underscore. |
|
| 102 | 102 |
|
| 103 | 103 |
\code |
| 104 |
|
|
| 104 |
_start_with_underscore |
|
| 105 | 105 |
\endcode |
| 106 | 106 |
|
| 107 | 107 |
\subsection cs-excep Exceptions |
| ... | ... |
@@ -406,10 +406,10 @@ |
| 406 | 406 |
- \ref CycleCanceling Cycle-Canceling algorithms, two of which are |
| 407 | 407 |
strongly polynomial \ref klein67primal, \ref goldberg89cyclecanceling. |
| 408 | 408 |
|
| 409 |
In general NetworkSimplex is the most efficient implementation, |
|
| 410 |
but in special cases other algorithms could be faster. |
|
| 409 |
In general, \ref NetworkSimplex and \ref CostScaling are the most efficient |
|
| 410 |
implementations, but the other two algorithms could be faster in special cases. |
|
| 411 | 411 |
For example, if the total supply and/or capacities are rather small, |
| 412 |
CapacityScaling is usually the fastest algorithm (without effective scaling). |
|
| 412 |
\ref CapacityScaling is usually the fastest algorithm (without effective scaling). |
|
| 413 | 413 |
*/ |
| 414 | 414 |
|
| 415 | 415 |
/** |
| ... | ... |
@@ -471,7 +471,7 @@ |
| 471 | 471 |
- \ref HowardMmc Howard's policy iteration algorithm |
| 472 | 472 |
\ref dasdan98minmeancycle. |
| 473 | 473 |
|
| 474 |
In practice, the \ref HowardMmc "Howard" algorithm |
|
| 474 |
In practice, the \ref HowardMmc "Howard" algorithm turned out to be by far the |
|
| 475 | 475 |
most efficient one, though the best known theoretical bound on its running |
| 476 | 476 |
time is exponential. |
| 477 | 477 |
Both \ref KarpMmc "Karp" and \ref HartmannOrlinMmc "Hartmann-Orlin" algorithms |
| ... | ... |
@@ -539,7 +539,7 @@ |
| 539 | 539 |
*/ |
| 540 | 540 |
|
| 541 | 541 |
/** |
| 542 |
@defgroup planar |
|
| 542 |
@defgroup planar Planar Embedding and Drawing |
|
| 543 | 543 |
@ingroup algs |
| 544 | 544 |
\brief Algorithms for planarity checking, embedding and drawing |
| 545 | 545 |
| ... | ... |
@@ -88,8 +88,8 @@ |
| 88 | 88 |
/// |
| 89 | 89 |
/// \warning Both number types must be signed and all input data must |
| 90 | 90 |
/// be integer. |
| 91 |
/// \warning This algorithm does not support negative costs for such |
|
| 92 |
/// arcs that have infinite upper bound. |
|
| 91 |
/// \warning This algorithm does not support negative costs for |
|
| 92 |
/// arcs having infinite upper bound. |
|
| 93 | 93 |
#ifdef DOXYGEN |
| 94 | 94 |
template <typename GR, typename V, typename C, typename TR> |
| 95 | 95 |
#else |
| ... | ... |
@@ -422,7 +422,7 @@ |
| 422 | 422 |
/// calling \ref run(), the supply of each node will be set to zero. |
| 423 | 423 |
/// |
| 424 | 424 |
/// Using this function has the same effect as using \ref supplyMap() |
| 425 |
/// with |
|
| 425 |
/// with a map in which \c k is assigned to \c s, \c -k is |
|
| 426 | 426 |
/// assigned to \c t and all other nodes have zero supply value. |
| 427 | 427 |
/// |
| 428 | 428 |
/// \param s The source node. |
| ... | ... |
@@ -97,6 +97,9 @@ |
| 97 | 97 |
/// can be viewed as the generalization of the \ref Preflow |
| 98 | 98 |
/// "preflow push-relabel" algorithm for the maximum flow problem. |
| 99 | 99 |
/// |
| 100 |
/// In general, \ref NetworkSimplex and \ref CostScaling are the fastest |
|
| 101 |
/// implementations available in LEMON for this problem. |
|
| 102 |
/// |
|
| 100 | 103 |
/// Most of the parameters of the problem (except for the digraph) |
| 101 | 104 |
/// can be given using separate functions, and the algorithm can be |
| 102 | 105 |
/// executed using the \ref run() function. If some parameters are not |
| ... | ... |
@@ -115,8 +118,8 @@ |
| 115 | 118 |
/// |
| 116 | 119 |
/// \warning Both number types must be signed and all input data must |
| 117 | 120 |
/// be integer. |
| 118 |
/// \warning This algorithm does not support negative costs for such |
|
| 119 |
/// arcs that have infinite upper bound. |
|
| 121 |
/// \warning This algorithm does not support negative costs for |
|
| 122 |
/// arcs having infinite upper bound. |
|
| 120 | 123 |
/// |
| 121 | 124 |
/// \note %CostScaling provides three different internal methods, |
| 122 | 125 |
/// from which the most efficient one is used by default. |
| ... | ... |
@@ -178,7 +181,7 @@ |
| 178 | 181 |
/// in their base operations, which are used in conjunction with the |
| 179 | 182 |
/// relabel operation. |
| 180 | 183 |
/// By default, the so called \ref PARTIAL_AUGMENT |
| 181 |
/// "Partial Augment-Relabel" method is used, which |
|
| 184 |
/// "Partial Augment-Relabel" method is used, which turned out to be |
|
| 182 | 185 |
/// the most efficient and the most robust on various test inputs. |
| 183 | 186 |
/// However, the other methods can be selected using the \ref run() |
| 184 | 187 |
/// function with the proper parameter. |
| ... | ... |
@@ -447,7 +450,7 @@ |
| 447 | 450 |
/// calling \ref run(), the supply of each node will be set to zero. |
| 448 | 451 |
/// |
| 449 | 452 |
/// Using this function has the same effect as using \ref supplyMap() |
| 450 |
/// with |
|
| 453 |
/// with a map in which \c k is assigned to \c s, \c -k is |
|
| 451 | 454 |
/// assigned to \c t and all other nodes have zero supply value. |
| 452 | 455 |
/// |
| 453 | 456 |
/// \param s The source node. |
| ... | ... |
@@ -67,8 +67,8 @@ |
| 67 | 67 |
/// |
| 68 | 68 |
/// \warning Both number types must be signed and all input data must |
| 69 | 69 |
/// be integer. |
| 70 |
/// \warning This algorithm does not support negative costs for such |
|
| 71 |
/// arcs that have infinite upper bound. |
|
| 70 |
/// \warning This algorithm does not support negative costs for |
|
| 71 |
/// arcs having infinite upper bound. |
|
| 72 | 72 |
/// |
| 73 | 73 |
/// \note For more information about the three available methods, |
| 74 | 74 |
/// see \ref Method. |
| ... | ... |
@@ -116,8 +116,7 @@ |
| 116 | 116 |
/// |
| 117 | 117 |
/// \ref CycleCanceling provides three different cycle-canceling |
| 118 | 118 |
/// methods. By default, \ref CANCEL_AND_TIGHTEN "Cancel and Tighten" |
| 119 |
/// is used, which proved to be the most efficient and the most robust |
|
| 120 |
/// on various test inputs. |
|
| 119 |
/// is used, which is by far the most efficient and the most robust. |
|
| 121 | 120 |
/// However, the other methods can be selected using the \ref run() |
| 122 | 121 |
/// function with the proper parameter. |
| 123 | 122 |
enum Method {
|
| ... | ... |
@@ -349,7 +348,7 @@ |
| 349 | 348 |
/// calling \ref run(), the supply of each node will be set to zero. |
| 350 | 349 |
/// |
| 351 | 350 |
/// Using this function has the same effect as using \ref supplyMap() |
| 352 |
/// with |
|
| 351 |
/// with a map in which \c k is assigned to \c s, \c -k is |
|
| 353 | 352 |
/// assigned to \c t and all other nodes have zero supply value. |
| 354 | 353 |
/// |
| 355 | 354 |
/// \param s The source node. |
| ... | ... |
@@ -36,7 +36,7 @@ |
| 36 | 36 |
|
| 37 | 37 |
///Euler tour iterator for digraphs. |
| 38 | 38 |
|
| 39 |
/// \ingroup |
|
| 39 |
/// \ingroup graph_properties |
|
| 40 | 40 |
///This iterator provides an Euler tour (Eulerian circuit) of a \e directed |
| 41 | 41 |
///graph (if there exists) and it converts to the \c Arc type of the digraph. |
| 42 | 42 |
/// |
| ... | ... |
@@ -47,10 +47,10 @@ |
| 47 | 47 |
/// linear programming simplex method directly for the minimum cost |
| 48 | 48 |
/// flow problem. |
| 49 | 49 |
/// |
| 50 |
/// In general, %NetworkSimplex is the fastest implementation available |
|
| 51 |
/// in LEMON for this problem. |
|
| 52 |
/// Moreover, it supports both directions of the supply/demand inequality |
|
| 53 |
/// constraints. For more information, see \ref SupplyType. |
|
| 50 |
/// In general, \ref NetworkSimplex and \ref CostScaling are the fastest |
|
| 51 |
/// implementations available in LEMON for this problem. |
|
| 52 |
/// Furthermore, this class supports both directions of the supply/demand |
|
| 53 |
/// inequality constraints. For more information, see \ref SupplyType. |
|
| 54 | 54 |
/// |
| 55 | 55 |
/// Most of the parameters of the problem (except for the digraph) |
| 56 | 56 |
/// can be given using separate functions, and the algorithm can be |
| ... | ... |
@@ -125,7 +125,7 @@ |
| 125 | 125 |
/// implementations that significantly affect the running time |
| 126 | 126 |
/// of the algorithm. |
| 127 | 127 |
/// By default, \ref BLOCK_SEARCH "Block Search" is used, which |
| 128 |
/// |
|
| 128 |
/// turend out to be the most efficient and the most robust on various |
|
| 129 | 129 |
/// test inputs. |
| 130 | 130 |
/// However, another pivot rule can be selected using the \ref run() |
| 131 | 131 |
/// function with the proper parameter. |
| ... | ... |
@@ -167,7 +167,7 @@ |
| 167 | 167 |
typedef std::vector<Value> ValueVector; |
| 168 | 168 |
typedef std::vector<Cost> CostVector; |
| 169 | 169 |
typedef std::vector<signed char> CharVector; |
| 170 |
// Note: vector<signed char> is used instead of vector<ArcState> and |
|
| 170 |
// Note: vector<signed char> is used instead of vector<ArcState> and |
|
| 171 | 171 |
// vector<ArcDirection> for efficiency reasons |
| 172 | 172 |
|
| 173 | 173 |
// State constants for arcs |
| ... | ... |
@@ -734,6 +734,8 @@ |
| 734 | 734 |
/// of the algorithm. |
| 735 | 735 |
/// |
| 736 | 736 |
/// \return <tt>(*this)</tt> |
| 737 |
/// |
|
| 738 |
/// \sa supplyType() |
|
| 737 | 739 |
template<typename SupplyMap> |
| 738 | 740 |
NetworkSimplex& supplyMap(const SupplyMap& map) {
|
| 739 | 741 |
for (NodeIt n(_graph); n != INVALID; ++n) {
|
| ... | ... |
@@ -750,7 +752,7 @@ |
| 750 | 752 |
/// calling \ref run(), the supply of each node will be set to zero. |
| 751 | 753 |
/// |
| 752 | 754 |
/// Using this function has the same effect as using \ref supplyMap() |
| 753 |
/// with |
|
| 755 |
/// with a map in which \c k is assigned to \c s, \c -k is |
|
| 754 | 756 |
/// assigned to \c t and all other nodes have zero supply value. |
| 755 | 757 |
/// |
| 756 | 758 |
/// \param s The source node. |
0 comments (0 inline)