kpeter@28: /* -*- mode: C++; indent-tabs-mode: nil; -*- kpeter@28: * kpeter@28: * This file is a part of LEMON, a generic C++ optimization library. kpeter@28: * kpeter@32: * Copyright (C) 2003-2010 kpeter@28: * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport kpeter@28: * (Egervary Research Group on Combinatorial Optimization, EGRES). kpeter@28: * kpeter@28: * Permission to use, modify and distribute this software is granted kpeter@28: * provided that this copyright notice appears in all copies. For kpeter@28: * precise terms see the accompanying LICENSE file. kpeter@28: * kpeter@28: * This software is provided "AS IS" with no warranty of any kind, kpeter@28: * express or implied, and with no claim as to its suitability for any kpeter@28: * purpose. kpeter@28: * kpeter@28: */ kpeter@28: kpeter@28: namespace lemon { kpeter@28: /** kpeter@28: [PAGE]sec_graph_structures[PAGE] Graph Structures kpeter@28: kpeter@28: The implementation of combinatorial algorithms heavily relies on kpeter@28: efficient graph structures. Diverse applications require the kpeter@28: usage of different physical graph storages. kpeter@28: In \ref sec_basics, we have introduced a general digraph structure, kpeter@28: \ref ListDigraph. Apart from this class, LEMON provides several kpeter@28: other classes for handling directed and undirected graphs to meet the kpeter@28: diverging requirements of the possible users. In order to save on running kpeter@28: time or on memory usage, some structures may fail to support some graph kpeter@28: features like node or arc/edge deletion. kpeter@28: You are free to use the graph structure that fit your requirements the best, kpeter@28: since most graph algorithms and auxiliary data structures can be used kpeter@28: with any of them. kpeter@28: kpeter@28: kpeter@28: [SEC]sec_graph_concepts[SEC] Graph Concepts kpeter@28: kpeter@28: In LEMON, there are various graph types, which are rather different, but kpeter@28: they all conform to the corresponding \ref graph_concepts "graph concept", kpeter@32: which defines the common part of the graph interfaces. kpeter@28: The \ref concepts::Digraph "Digraph concept" describes the common interface kpeter@28: of directed graphs (without any sensible implementation), while kpeter@28: the \ref concepts::Graph "Graph concept" describes the undirected graphs. kpeter@28: Any generic graph algorithm should only exploit the features of the kpeter@28: corresponding graph concept. (It should compile with the kpeter@28: \ref concepts::Digraph "Digraph" or \ref concepts::Graph "Graph" type, kpeter@28: but it will not run properly, of course.) kpeter@28: kpeter@28: The graph %concepts define the member classes for the iterators and maps kpeter@28: along with some useful basic functions for obtaining the identifiers of kpeter@28: the items, the end nodes of the arcs (or edges) and their iterators, kpeter@32: etc. kpeter@28: An actual graph implementation may have various additional functionalities kpeter@28: according to its purpose. kpeter@28: kpeter@28: kpeter@28: [SEC]sec_digraph_types[SEC] Digraph Structures kpeter@28: kpeter@28: The already used \ref ListDigraph class is the most versatile directed kpeter@28: graph structure. Apart from the general digraph functionalities, it kpeter@28: provides operations for adding and removing nodes and arcs, changing kpeter@28: the source or target node of an arc, and contracting and splitting nodes kpeter@28: or arcs. kpeter@28: kpeter@28: \ref SmartDigraph is another general digraph implementation, which is kpeter@28: significantly more efficient (both in terms of space and time), but it kpeter@28: provides less functionality. For example, nodes and arcs cannot be kpeter@32: removed from it. kpeter@28: kpeter@28: \ref FullDigraph is an efficient implementation of a directed full graph. kpeter@28: This structure is completely static, so you can neither add nor delete kpeter@28: arcs or nodes, and the class needs constant space in memory. kpeter@28: kpeter@28: kpeter@28: [SEC]sec_undir_graphs[SEC] Undirected Graphs kpeter@28: kpeter@28: LEMON also provides undirected graph structures. For example, kpeter@28: \ref ListGraph and \ref SmartGraph are the undirected versions of kpeter@28: \ref ListDigraph and \ref SmartDigraph, respectively. kpeter@28: They provide similar features to the digraph structures. kpeter@28: kpeter@28: The \ref concepts::Graph "undirected graphs" also fulfill the concept of kpeter@32: \ref concepts::Digraph "directed graphs", in such a way that each kpeter@28: undirected \e edge of a graph can also be regarded as two oppositely kpeter@28: directed \e arcs. As a result, all directed graph algorithms automatically kpeter@28: run on undirected graphs, as well. kpeter@28: kpeter@28: Undirected graphs provide an \c Edge type for the \e undirected \e edges kpeter@28: and an \c Arc type for the \e directed \e arcs. The \c Arc type is kpeter@28: convertible to \c Edge (or inherited from it), thus the corresponding kpeter@28: edge can always be obtained from an arc. kpeter@28: kpeter@28: Only nodes and edges can be added to or removed from an undirected kpeter@28: graph and the corresponding arcs are added or removed automatically kpeter@28: (there are twice as many arcs as edges) kpeter@28: kpeter@28: For example, kpeter@28: \code kpeter@28: ListGraph g; kpeter@32: kpeter@28: ListGraph::Node a = g.addNode(); kpeter@28: ListGraph::Node b = g.addNode(); kpeter@28: ListGraph::Node c = g.addNode(); kpeter@28: kpeter@28: ListGraph::Edge e = g.addEdge(a,b); kpeter@28: g.addEdge(b,c); kpeter@28: g.addEdge(c,a); kpeter@28: \endcode kpeter@28: kpeter@28: Each edge has an inherent orientation, thus it can be defined whether an kpeter@28: arc is forward or backward oriented in an undirected graph with respect kpeter@28: to this default oriantation of the represented edge. kpeter@28: The direction of an arc can be obtained and set using the functions kpeter@28: \ref concepts::Graph::direction() "direction()" and kpeter@28: \ref concepts::Graph::direct() "direct()", respectively. kpeter@28: kpeter@28: For example, kpeter@28: \code kpeter@28: ListGraph::Arc a1 = g.direct(e, true); // a1 is the forward arc kpeter@28: ListGraph::Arc a2 = g.direct(e, false); // a2 is the backward arc kpeter@28: kpeter@28: if (a2 == g.oppositeArc(a1)) kpeter@28: std::cout << "a2 is the opposite of a1" << std::endl; kpeter@28: \endcode kpeter@28: kpeter@28: The end nodes of an edge can be obtained using the functions kpeter@28: \ref concepts::Graph::source() "u()" and kpeter@28: \ref concepts::Graph::target() "v()", while the kpeter@28: \ref concepts::Graph::source() "source()" and kpeter@28: \ref concepts::Graph::target() "target()" can be used for arcs. kpeter@28: kpeter@28: \code kpeter@28: std::cout << "Edge " << g.id(e) << " connects node " kpeter@28: << g.id(g.u(e)) << " and node " << g.id(g.v(e)) << std::endl; kpeter@32: kpeter@28: std::cout << "Arc " << g.id(a2) << " goes from node " kpeter@28: << g.id(g.source(a2)) << " to node " << g.id(g.target(a2)) << std::endl; kpeter@28: \endcode kpeter@28: kpeter@28: kpeter@28: Similarly to the digraphs, the undirected graphs also provide iterators kpeter@28: \ref concepts::Graph::NodeIt "NodeIt", \ref concepts::Graph::ArcIt "ArcIt", kpeter@28: \ref concepts::Graph::OutArcIt "OutArcIt" and \ref concepts::Graph::InArcIt kpeter@28: "InArcIt", which can be used the same way. kpeter@28: However, they also have iterator classes for edges. kpeter@28: \ref concepts::Graph::EdgeIt "EdgeIt" traverses all edges in the graph and kpeter@28: \ref concepts::Graph::IncEdgeIt "IncEdgeIt" lists the incident edges of a kpeter@28: certain node. kpeter@28: kpeter@28: For example, the degree of each node can be computed and stored in a node map kpeter@28: like this: kpeter@28: kpeter@28: \code kpeter@28: ListGraph::NodeMap deg(g, 0); kpeter@28: for (ListGraph::NodeIt n(g); n != INVALID; ++n) { kpeter@28: for (ListGraph::IncEdgeIt e(g, n); e != INVALID; ++e) { kpeter@28: deg[n]++; kpeter@28: } kpeter@28: } kpeter@28: \endcode kpeter@28: kpeter@28: In an undirected graph, both \ref concepts::Graph::OutArcIt "OutArcIt" kpeter@28: and \ref concepts::Graph::InArcIt "InArcIt" iterates on the same \e edges kpeter@28: but with opposite direction. They are convertible to both \c Arc and kpeter@28: \c Edge types. \ref concepts::Graph::IncEdgeIt "IncEdgeIt" also iterates kpeter@28: on these edges, but it is not convertible to \c Arc, only to \c Edge. kpeter@28: kpeter@28: Apart from the node and arc maps, an undirected graph also defines kpeter@28: a template member class for constructing edge maps. These maps can be kpeter@28: used in conjunction with both edges and arcs. kpeter@28: kpeter@28: For example, kpeter@28: \code kpeter@28: ListGraph::EdgeMap cost(g); kpeter@28: cost[e] = 10; kpeter@28: std::cout << cost[e] << std::endl; kpeter@28: std::cout << cost[a1] << ", " << cost[a2] << std::endl; kpeter@28: kpeter@28: ListGraph::ArcMap arc_cost(g); kpeter@28: arc_cost[a1] = cost[a1]; kpeter@28: arc_cost[a2] = 2 * cost[a2]; kpeter@28: // std::cout << arc_cost[e] << std::endl; // this is not valid kpeter@28: std::cout << arc_cost[a1] << ", " << arc_cost[a2] << std::endl; kpeter@28: \endcode kpeter@32: kpeter@28: [SEC]sec_special_graphs[SEC] Special Graph Structures kpeter@28: kpeter@28: In addition to the general undirected classes \ref ListGraph and kpeter@28: \ref SmartGraph, LEMON also provides special purpose graph types for kpeter@28: handling \ref FullGraph "full graphs", \ref GridGraph "grid graphs" and kpeter@28: \ref HypercubeGraph "hypercube graphs". kpeter@28: They all static structures, i.e. they do not allow distinct item additions kpeter@28: or deletions, the graph has to be built at once. kpeter@28: kpeter@28: [TRAILER] kpeter@28: */ kpeter@28: }