... | ... |
@@ -255,79 +255,78 @@ |
255 | 255 |
/// a graph. |
256 | 256 |
/// |
257 | 257 |
/// This function runs Kruskal's algorithm to find a minimum cost |
258 | 258 |
/// spanning tree. |
259 | 259 |
/// Due to some C++ hacking, it accepts various input and output types. |
260 | 260 |
/// |
261 | 261 |
/// \param g The graph the algorithm runs on. |
262 | 262 |
/// It can be either \ref concepts::Digraph "directed" or |
263 | 263 |
/// \ref concepts::Graph "undirected". |
264 | 264 |
/// If the graph is directed, the algorithm consider it to be |
265 | 265 |
/// undirected by disregarding the direction of the arcs. |
266 | 266 |
/// |
267 | 267 |
/// \param in This object is used to describe the arc/edge costs. |
268 | 268 |
/// It can be one of the following choices. |
269 | 269 |
/// - An STL compatible 'Forward Container' with |
270 | 270 |
/// <tt>std::pair<GR::Arc,X></tt> or |
271 | 271 |
/// <tt>std::pair<GR::Edge,X></tt> as its <tt>value_type</tt>, where |
272 | 272 |
/// \c X is the type of the costs. The pairs indicates the arcs/edges |
273 | 273 |
/// along with the assigned cost. <em>They must be in a |
274 | 274 |
/// cost-ascending order.</em> |
275 | 275 |
/// - Any readable arc/edge map. The values of the map indicate the |
276 | 276 |
/// arc/edge costs. |
277 | 277 |
/// |
278 | 278 |
/// \retval out Here we also have a choice. |
279 | 279 |
/// - It can be a writable \c bool arc/edge map. After running the |
280 | 280 |
/// algorithm it will contain the found minimum cost spanning |
281 | 281 |
/// tree: the value of an arc/edge will be set to \c true if it belongs |
282 | 282 |
/// to the tree, otherwise it will be set to \c false. The value of |
283 | 283 |
/// each arc/edge will be set exactly once. |
284 | 284 |
/// - It can also be an iteraror of an STL Container with |
285 | 285 |
/// <tt>GR::Arc</tt> or <tt>GR::Edge</tt> as its |
286 | 286 |
/// <tt>value_type</tt>. The algorithm copies the elements of the |
287 | 287 |
/// found tree into this sequence. For example, if we know that the |
288 | 288 |
/// spanning tree of the graph \c g has say 53 arcs, then we can |
289 | 289 |
/// put its arcs into an STL vector \c tree with a code like this. |
290 | 290 |
///\code |
291 | 291 |
/// std::vector<Arc> tree(53); |
292 | 292 |
/// kruskal(g,cost,tree.begin()); |
293 | 293 |
///\endcode |
294 | 294 |
/// Or if we don't know in advance the size of the tree, we can |
295 | 295 |
/// write this. |
296 | 296 |
///\code |
297 | 297 |
/// std::vector<Arc> tree; |
298 | 298 |
/// kruskal(g,cost,std::back_inserter(tree)); |
299 | 299 |
///\endcode |
300 | 300 |
/// |
301 | 301 |
/// \return The total cost of the found spanning tree. |
302 | 302 |
/// |
303 |
/// \warning If Kruskal runs on an be consistent of using the same |
|
304 |
/// Arc type for input and output. |
|
305 |
/// |
|
303 |
/// \note If the input graph is not (weakly) connected, a spanning |
|
304 |
/// forest is calculated instead of a spanning tree. |
|
306 | 305 |
|
307 | 306 |
#ifdef DOXYGEN |
308 | 307 |
template <class Graph, class In, class Out> |
309 | 308 |
Value kruskal(GR const& g, const In& in, Out& out) |
310 | 309 |
#else |
311 | 310 |
template <class Graph, class In, class Out> |
312 | 311 |
inline typename _kruskal_bits::KruskalValueSelector<In>::Value |
313 | 312 |
kruskal(const Graph& graph, const In& in, Out& out) |
314 | 313 |
#endif |
315 | 314 |
{ |
316 | 315 |
return _kruskal_bits::KruskalInputSelector<Graph, In, Out>:: |
317 | 316 |
kruskal(graph, in, out); |
318 | 317 |
} |
319 | 318 |
|
320 | 319 |
|
321 | 320 |
|
322 | 321 |
|
323 | 322 |
template <class Graph, class In, class Out> |
324 | 323 |
inline typename _kruskal_bits::KruskalValueSelector<In>::Value |
325 | 324 |
kruskal(const Graph& graph, const In& in, const Out& out) |
326 | 325 |
{ |
327 | 326 |
return _kruskal_bits::KruskalInputSelector<Graph, In, const Out>:: |
328 | 327 |
kruskal(graph, in, out); |
329 | 328 |
} |
330 | 329 |
|
331 | 330 |
} //namespace lemon |
332 | 331 |
|
333 | 332 |
#endif //LEMON_KRUSKAL_H |
0 comments (0 inline)