alpar@209: /* -*- mode: C++; indent-tabs-mode: nil; -*-
alpar@40:  *
alpar@209:  * This file is a part of LEMON, a generic C++ optimization library.
alpar@40:  *
alpar@40:  * Copyright (C) 2003-2008
alpar@40:  * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
alpar@40:  * (Egervary Research Group on Combinatorial Optimization, EGRES).
alpar@40:  *
alpar@40:  * Permission to use, modify and distribute this software is granted
alpar@40:  * provided that this copyright notice appears in all copies. For
alpar@40:  * precise terms see the accompanying LICENSE file.
alpar@40:  *
alpar@40:  * This software is provided "AS IS" with no warranty of any kind,
alpar@40:  * express or implied, and with no claim as to its suitability for any
alpar@40:  * purpose.
alpar@40:  *
alpar@40:  */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup datas Data Structures
kpeter@50: This group describes the several data structures implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup graphs Graph Structures
alpar@40: @ingroup datas
alpar@40: \brief Graph structures implemented in LEMON.
alpar@40: 
alpar@209: The implementation of combinatorial algorithms heavily relies on
alpar@209: efficient graph implementations. LEMON offers data structures which are
alpar@209: planned to be easily used in an experimental phase of implementation studies,
alpar@209: and thereafter the program code can be made efficient by small modifications.
alpar@40: 
alpar@40: The most efficient implementation of diverse applications require the
alpar@40: usage of different physical graph implementations. These differences
alpar@40: appear in the size of graph we require to handle, memory or time usage
alpar@40: limitations or in the set of operations through which the graph can be
alpar@40: accessed.  LEMON provides several physical graph structures to meet
alpar@40: the diverging requirements of the possible users.  In order to save on
alpar@40: running time or on memory usage, some structures may fail to provide
kpeter@83: some graph features like arc/edge or node deletion.
alpar@40: 
alpar@209: Alteration of standard containers need a very limited number of
alpar@209: operations, these together satisfy the everyday requirements.
alpar@209: In the case of graph structures, different operations are needed which do
alpar@209: not alter the physical graph, but gives another view. If some nodes or
kpeter@83: arcs have to be hidden or the reverse oriented graph have to be used, then
alpar@209: this is the case. It also may happen that in a flow implementation
alpar@209: the residual graph can be accessed by another algorithm, or a node-set
alpar@209: is to be shrunk for another algorithm.
alpar@209: LEMON also provides a variety of graphs for these requirements called
alpar@209: \ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only
alpar@209: in conjunction with other graph representations.
alpar@40: 
alpar@40: You are free to use the graph structure that fit your requirements
alpar@40: the best, most graph algorithms and auxiliary data structures can be used
kpeter@314: with any graph structure.
kpeter@314: 
kpeter@314: <b>See also:</b> \ref graph_concepts "Graph Structure Concepts".
alpar@40: */
alpar@40: 
alpar@40: /**
deba@416: @defgroup graph_adaptors Adaptor Classes for graphs
deba@416: @ingroup graphs
deba@416: \brief This group contains several adaptor classes for digraphs and graphs
deba@416: 
deba@416: The main parts of LEMON are the different graph structures, generic
deba@416: graph algorithms, graph concepts which couple these, and graph
deba@416: adaptors. While the previous notions are more or less clear, the
deba@416: latter one needs further explanation. Graph adaptors are graph classes
deba@416: which serve for considering graph structures in different ways.
deba@416: 
deba@416: A short example makes this much clearer.  Suppose that we have an
deba@416: instance \c g of a directed graph type say ListDigraph and an algorithm
deba@416: \code
deba@416: template <typename Digraph>
deba@416: int algorithm(const Digraph&);
deba@416: \endcode
deba@416: is needed to run on the reverse oriented graph.  It may be expensive
deba@416: (in time or in memory usage) to copy \c g with the reversed
deba@416: arcs.  In this case, an adaptor class is used, which (according
deba@416: to LEMON digraph concepts) works as a digraph.  The adaptor uses the
deba@416: original digraph structure and digraph operations when methods of the
deba@416: reversed oriented graph are called.  This means that the adaptor have
deba@416: minor memory usage, and do not perform sophisticated algorithmic
deba@416: actions.  The purpose of it is to give a tool for the cases when a
deba@416: graph have to be used in a specific alteration.  If this alteration is
deba@416: obtained by a usual construction like filtering the arc-set or
deba@416: considering a new orientation, then an adaptor is worthwhile to use.
deba@416: To come back to the reverse oriented graph, in this situation
deba@416: \code
deba@416: template<typename Digraph> class ReverseDigraph;
deba@416: \endcode
deba@416: template class can be used. The code looks as follows
deba@416: \code
deba@416: ListDigraph g;
deba@416: ReverseDigraph<ListGraph> rg(g);
deba@416: int result = algorithm(rg);
deba@416: \endcode
deba@416: After running the algorithm, the original graph \c g is untouched.
deba@416: This techniques gives rise to an elegant code, and based on stable
deba@416: graph adaptors, complex algorithms can be implemented easily.
deba@416: 
deba@416: In flow, circulation and bipartite matching problems, the residual
deba@416: graph is of particular importance. Combining an adaptor implementing
deba@416: this, shortest path algorithms and minimum mean cycle algorithms,
deba@416: a range of weighted and cardinality optimization algorithms can be
deba@416: obtained. For other examples, the interested user is referred to the
deba@416: detailed documentation of particular adaptors.
deba@416: 
deba@416: The behavior of graph adaptors can be very different. Some of them keep
deba@416: capabilities of the original graph while in other cases this would be
deba@416: meaningless. This means that the concepts that they are models of depend
deba@416: on the graph adaptor, and the wrapped graph(s).
deba@416: If an arc of \c rg is deleted, this is carried out by deleting the
deba@416: corresponding arc of \c g, thus the adaptor modifies the original graph.
deba@416: 
deba@416: But for a residual graph, this operation has no sense.
deba@416: Let us stand one more example here to simplify your work.
deba@416: RevGraphAdaptor has constructor
deba@416: \code
deba@416: ReverseDigraph(Digraph& digraph);
deba@416: \endcode
deba@416: This means that in a situation, when a <tt>const ListDigraph&</tt>
deba@416: reference to a graph is given, then it have to be instantiated with
deba@416: <tt>Digraph=const ListDigraph</tt>.
deba@416: \code
deba@416: int algorithm1(const ListDigraph& g) {
deba@416:   RevGraphAdaptor<const ListDigraph> rg(g);
deba@416:   return algorithm2(rg);
deba@416: }
deba@416: \endcode
deba@416: */
deba@416: 
deba@416: /**
kpeter@50: @defgroup semi_adaptors Semi-Adaptor Classes for Graphs
alpar@40: @ingroup graphs
alpar@40: \brief Graph types between real graphs and graph adaptors.
alpar@40: 
kpeter@50: This group describes some graph types between real graphs and graph adaptors.
alpar@209: These classes wrap graphs to give new functionality as the adaptors do it.
kpeter@50: On the other hand they are not light-weight structures as the adaptors.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@209: @defgroup maps Maps
alpar@40: @ingroup datas
kpeter@50: \brief Map structures implemented in LEMON.
alpar@40: 
kpeter@50: This group describes the map structures implemented in LEMON.
kpeter@50: 
kpeter@314: LEMON provides several special purpose maps and map adaptors that e.g. combine
alpar@40: new maps from existing ones.
kpeter@314: 
kpeter@314: <b>See also:</b> \ref map_concepts "Map Concepts".
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@209: @defgroup graph_maps Graph Maps
alpar@40: @ingroup maps
kpeter@83: \brief Special graph-related maps.
alpar@40: 
kpeter@50: This group describes maps that are specifically designed to assign
kpeter@83: values to the nodes and arcs of graphs.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: \defgroup map_adaptors Map Adaptors
alpar@40: \ingroup maps
alpar@40: \brief Tools to create new maps from existing ones
alpar@40: 
kpeter@50: This group describes map adaptors that are used to create "implicit"
kpeter@50: maps from other maps.
alpar@40: 
kpeter@83: Most of them are \ref lemon::concepts::ReadMap "read-only maps".
kpeter@83: They can make arithmetic and logical operations between one or two maps
kpeter@83: (negation, shifting, addition, multiplication, logical 'and', 'or',
kpeter@83: 'not' etc.) or e.g. convert a map to another one of different Value type.
alpar@40: 
kpeter@50: The typical usage of this classes is passing implicit maps to
alpar@40: algorithms.  If a function type algorithm is called then the function
alpar@40: type map adaptors can be used comfortable. For example let's see the
kpeter@314: usage of map adaptors with the \c graphToEps() function.
alpar@40: \code
alpar@40:   Color nodeColor(int deg) {
alpar@40:     if (deg >= 2) {
alpar@40:       return Color(0.5, 0.0, 0.5);
alpar@40:     } else if (deg == 1) {
alpar@40:       return Color(1.0, 0.5, 1.0);
alpar@40:     } else {
alpar@40:       return Color(0.0, 0.0, 0.0);
alpar@40:     }
alpar@40:   }
alpar@209: 
kpeter@83:   Digraph::NodeMap<int> degree_map(graph);
alpar@209: 
kpeter@314:   graphToEps(graph, "graph.eps")
alpar@40:     .coords(coords).scaleToA4().undirected()
kpeter@83:     .nodeColors(composeMap(functorToMap(nodeColor), degree_map))
alpar@40:     .run();
alpar@209: \endcode
kpeter@83: The \c functorToMap() function makes an \c int to \c Color map from the
kpeter@314: \c nodeColor() function. The \c composeMap() compose the \c degree_map
kpeter@83: and the previously created map. The composed map is a proper function to
kpeter@83: get the color of each node.
alpar@40: 
alpar@40: The usage with class type algorithms is little bit harder. In this
alpar@40: case the function type map adaptors can not be used, because the
kpeter@50: function map adaptors give back temporary objects.
alpar@40: \code
kpeter@83:   Digraph graph;
kpeter@83: 
kpeter@83:   typedef Digraph::ArcMap<double> DoubleArcMap;
kpeter@83:   DoubleArcMap length(graph);
kpeter@83:   DoubleArcMap speed(graph);
kpeter@83: 
kpeter@83:   typedef DivMap<DoubleArcMap, DoubleArcMap> TimeMap;
alpar@40:   TimeMap time(length, speed);
alpar@209: 
kpeter@83:   Dijkstra<Digraph, TimeMap> dijkstra(graph, time);
alpar@40:   dijkstra.run(source, target);
alpar@40: \endcode
kpeter@83: We have a length map and a maximum speed map on the arcs of a digraph.
kpeter@83: The minimum time to pass the arc can be calculated as the division of
kpeter@83: the two maps which can be done implicitly with the \c DivMap template
alpar@40: class. We use the implicit minimum time map as the length map of the
alpar@40: \c Dijkstra algorithm.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@209: @defgroup matrices Matrices
alpar@40: @ingroup datas
kpeter@50: \brief Two dimensional data storages implemented in LEMON.
alpar@40: 
kpeter@50: This group describes two dimensional data storages implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup paths Path Structures
alpar@40: @ingroup datas
kpeter@318: \brief %Path structures implemented in LEMON.
alpar@40: 
kpeter@50: This group describes the path structures implemented in LEMON.
alpar@40: 
kpeter@50: LEMON provides flexible data structures to work with paths.
kpeter@50: All of them have similar interfaces and they can be copied easily with
kpeter@50: assignment operators and copy constructors. This makes it easy and
alpar@40: efficient to have e.g. the Dijkstra algorithm to store its result in
alpar@40: any kind of path structure.
alpar@40: 
alpar@40: \sa lemon::concepts::Path
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup auxdat Auxiliary Data Structures
alpar@40: @ingroup datas
kpeter@50: \brief Auxiliary data structures implemented in LEMON.
alpar@40: 
kpeter@50: This group describes some data structures implemented in LEMON in
alpar@40: order to make it easier to implement combinatorial algorithms.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup algs Algorithms
alpar@40: \brief This group describes the several algorithms
alpar@40: implemented in LEMON.
alpar@40: 
alpar@40: This group describes the several algorithms
alpar@40: implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup search Graph Search
alpar@40: @ingroup algs
kpeter@50: \brief Common graph search algorithms.
alpar@40: 
alpar@209: This group describes the common graph search algorithms like
kpeter@314: Breadth-First Search (BFS) and Depth-First Search (DFS).
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup shortest_path Shortest Path Algorithms
alpar@40: @ingroup algs
kpeter@50: \brief Algorithms for finding shortest paths.
alpar@40: 
kpeter@50: This group describes the algorithms for finding shortest paths in graphs.
alpar@40: */
alpar@40: 
alpar@209: /**
kpeter@314: @defgroup max_flow Maximum Flow Algorithms
alpar@209: @ingroup algs
kpeter@50: \brief Algorithms for finding maximum flows.
alpar@40: 
alpar@40: This group describes the algorithms for finding maximum flows and
alpar@40: feasible circulations.
alpar@40: 
kpeter@50: The maximum flow problem is to find a flow between a single source and
kpeter@50: a single target that is maximum. Formally, there is a \f$G=(V,A)\f$
alpar@40: directed graph, an \f$c_a:A\rightarrow\mathbf{R}^+_0\f$ capacity
alpar@40: function and given \f$s, t \in V\f$ source and target node. The
kpeter@50: maximum flow is the \f$f_a\f$ solution of the next optimization problem:
alpar@40: 
alpar@40: \f[ 0 \le f_a \le c_a \f]
alpar@210: \f[ \sum_{v\in\delta^{-}(u)}f_{vu}=\sum_{v\in\delta^{+}(u)}f_{uv}
alpar@210: \qquad \forall u \in V \setminus \{s,t\}\f]
alpar@40: \f[ \max \sum_{v\in\delta^{+}(s)}f_{uv} - \sum_{v\in\delta^{-}(s)}f_{vu}\f]
alpar@40: 
kpeter@50: LEMON contains several algorithms for solving maximum flow problems:
alpar@209: - \ref lemon::EdmondsKarp "Edmonds-Karp"
alpar@40: - \ref lemon::Preflow "Goldberg's Preflow algorithm"
kpeter@50: - \ref lemon::DinitzSleatorTarjan "Dinitz's blocking flow algorithm with dynamic trees"
alpar@40: - \ref lemon::GoldbergTarjan "Preflow algorithm with dynamic trees"
alpar@40: 
kpeter@50: In most cases the \ref lemon::Preflow "Preflow" algorithm provides the
alpar@40: fastest method to compute the maximum flow. All impelementations
kpeter@50: provides functions to query the minimum cut, which is the dual linear
kpeter@50: programming problem of the maximum flow.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup min_cost_flow Minimum Cost Flow Algorithms
alpar@40: @ingroup algs
alpar@40: 
kpeter@50: \brief Algorithms for finding minimum cost flows and circulations.
alpar@40: 
alpar@40: This group describes the algorithms for finding minimum cost flows and
alpar@209: circulations.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup min_cut Minimum Cut Algorithms
alpar@209: @ingroup algs
alpar@40: 
kpeter@50: \brief Algorithms for finding minimum cut in graphs.
alpar@40: 
alpar@40: This group describes the algorithms for finding minimum cut in graphs.
alpar@40: 
alpar@40: The minimum cut problem is to find a non-empty and non-complete
alpar@40: \f$X\f$ subset of the vertices with minimum overall capacity on
alpar@40: outgoing arcs. Formally, there is \f$G=(V,A)\f$ directed graph, an
alpar@40: \f$c_a:A\rightarrow\mathbf{R}^+_0\f$ capacity function. The minimum
kpeter@50: cut is the \f$X\f$ solution of the next optimization problem:
alpar@40: 
alpar@210: \f[ \min_{X \subset V, X\not\in \{\emptyset, V\}}
alpar@210: \sum_{uv\in A, u\in X, v\not\in X}c_{uv}\f]
alpar@40: 
kpeter@50: LEMON contains several algorithms related to minimum cut problems:
alpar@40: 
kpeter@50: - \ref lemon::HaoOrlin "Hao-Orlin algorithm" to calculate minimum cut
alpar@209:   in directed graphs
kpeter@50: - \ref lemon::NagamochiIbaraki "Nagamochi-Ibaraki algorithm" to
alpar@40:   calculate minimum cut in undirected graphs
kpeter@50: - \ref lemon::GomoryHuTree "Gomory-Hu tree computation" to calculate all
alpar@40:   pairs minimum cut in undirected graphs
alpar@40: 
alpar@40: If you want to find minimum cut just between two distinict nodes,
alpar@40: please see the \ref max_flow "Maximum Flow page".
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup graph_prop Connectivity and Other Graph Properties
alpar@40: @ingroup algs
kpeter@50: \brief Algorithms for discovering the graph properties
alpar@40: 
kpeter@50: This group describes the algorithms for discovering the graph properties
kpeter@50: like connectivity, bipartiteness, euler property, simplicity etc.
alpar@40: 
alpar@40: \image html edge_biconnected_components.png
alpar@40: \image latex edge_biconnected_components.eps "bi-edge-connected components" width=\textwidth
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup planar Planarity Embedding and Drawing
alpar@40: @ingroup algs
kpeter@50: \brief Algorithms for planarity checking, embedding and drawing
alpar@40: 
alpar@210: This group describes the algorithms for planarity checking,
alpar@210: embedding and drawing.
alpar@40: 
alpar@40: \image html planar.png
alpar@40: \image latex planar.eps "Plane graph" width=\textwidth
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup matching Matching Algorithms
alpar@40: @ingroup algs
kpeter@50: \brief Algorithms for finding matchings in graphs and bipartite graphs.
alpar@40: 
kpeter@50: This group contains algorithm objects and functions to calculate
alpar@40: matchings in graphs and bipartite graphs. The general matching problem is
kpeter@83: finding a subset of the arcs which does not shares common endpoints.
alpar@209: 
alpar@40: There are several different algorithms for calculate matchings in
alpar@40: graphs.  The matching problems in bipartite graphs are generally
alpar@40: easier than in general graphs. The goal of the matching optimization
alpar@40: can be the finding maximum cardinality, maximum weight or minimum cost
alpar@40: matching. The search can be constrained to find perfect or
alpar@40: maximum cardinality matching.
alpar@40: 
ladanyi@236: LEMON contains the next algorithms:
alpar@209: - \ref lemon::MaxBipartiteMatching "MaxBipartiteMatching" Hopcroft-Karp
alpar@209:   augmenting path algorithm for calculate maximum cardinality matching in
alpar@40:   bipartite graphs
alpar@209: - \ref lemon::PrBipartiteMatching "PrBipartiteMatching" Push-Relabel
alpar@209:   algorithm for calculate maximum cardinality matching in bipartite graphs
alpar@209: - \ref lemon::MaxWeightedBipartiteMatching "MaxWeightedBipartiteMatching"
alpar@209:   Successive shortest path algorithm for calculate maximum weighted matching
alpar@40:   and maximum weighted bipartite matching in bipartite graph
alpar@209: - \ref lemon::MinCostMaxBipartiteMatching "MinCostMaxBipartiteMatching"
alpar@209:   Successive shortest path algorithm for calculate minimum cost maximum
alpar@40:   matching in bipartite graph
alpar@40: - \ref lemon::MaxMatching "MaxMatching" Edmond's blossom shrinking algorithm
alpar@40:   for calculate maximum cardinality matching in general graph
alpar@40: - \ref lemon::MaxWeightedMatching "MaxWeightedMatching" Edmond's blossom
alpar@40:   shrinking algorithm for calculate maximum weighted matching in general
alpar@40:   graph
alpar@40: - \ref lemon::MaxWeightedPerfectMatching "MaxWeightedPerfectMatching"
alpar@40:   Edmond's blossom shrinking algorithm for calculate maximum weighted
alpar@40:   perfect matching in general graph
alpar@40: 
alpar@40: \image html bipartite_matching.png
alpar@40: \image latex bipartite_matching.eps "Bipartite Matching" width=\textwidth
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup spantree Minimum Spanning Tree Algorithms
alpar@40: @ingroup algs
kpeter@50: \brief Algorithms for finding a minimum cost spanning tree in a graph.
alpar@40: 
kpeter@50: This group describes the algorithms for finding a minimum cost spanning
alpar@40: tree in a graph
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup auxalg Auxiliary Algorithms
alpar@40: @ingroup algs
kpeter@50: \brief Auxiliary algorithms implemented in LEMON.
alpar@40: 
kpeter@50: This group describes some algorithms implemented in LEMON
kpeter@50: in order to make it easier to implement complex algorithms.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup approx Approximation Algorithms
kpeter@314: @ingroup algs
kpeter@50: \brief Approximation algorithms.
alpar@40: 
kpeter@50: This group describes the approximation and heuristic algorithms
kpeter@50: implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup gen_opt_group General Optimization Tools
alpar@40: \brief This group describes some general optimization frameworks
alpar@40: implemented in LEMON.
alpar@40: 
alpar@40: This group describes some general optimization frameworks
alpar@40: implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup lp_group Lp and Mip Solvers
alpar@40: @ingroup gen_opt_group
alpar@40: \brief Lp and Mip solver interfaces for LEMON.
alpar@40: 
alpar@40: This group describes Lp and Mip solver interfaces for LEMON. The
alpar@40: various LP solvers could be used in the same manner with this
alpar@40: interface.
alpar@40: */
alpar@40: 
alpar@209: /**
kpeter@314: @defgroup lp_utils Tools for Lp and Mip Solvers
alpar@40: @ingroup lp_group
kpeter@50: \brief Helper tools to the Lp and Mip solvers.
alpar@40: 
alpar@40: This group adds some helper tools to general optimization framework
alpar@40: implemented in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup metah Metaheuristics
alpar@40: @ingroup gen_opt_group
alpar@40: \brief Metaheuristics for LEMON library.
alpar@40: 
kpeter@50: This group describes some metaheuristic optimization tools.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@209: @defgroup utils Tools and Utilities
kpeter@50: \brief Tools and utilities for programming in LEMON
alpar@40: 
kpeter@50: Tools and utilities for programming in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup gutils Basic Graph Utilities
alpar@40: @ingroup utils
kpeter@50: \brief Simple basic graph utilities.
alpar@40: 
alpar@40: This group describes some simple basic graph utilities.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup misc Miscellaneous Tools
alpar@40: @ingroup utils
kpeter@50: \brief Tools for development, debugging and testing.
kpeter@50: 
kpeter@50: This group describes several useful tools for development,
alpar@40: debugging and testing.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup timecount Time Measuring and Counting
alpar@40: @ingroup misc
kpeter@50: \brief Simple tools for measuring the performance of algorithms.
kpeter@50: 
kpeter@50: This group describes simple tools for measuring the performance
alpar@40: of algorithms.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup exceptions Exceptions
alpar@40: @ingroup utils
kpeter@50: \brief Exceptions defined in LEMON.
kpeter@50: 
kpeter@50: This group describes the exceptions defined in LEMON.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup io_group Input-Output
kpeter@50: \brief Graph Input-Output methods
alpar@40: 
alpar@209: This group describes the tools for importing and exporting graphs
kpeter@314: and graph related data. Now it supports the \ref lgf-format
kpeter@314: "LEMON Graph Format", the \c DIMACS format and the encapsulated
kpeter@314: postscript (EPS) format.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@351: @defgroup lemon_io LEMON Graph Format
alpar@40: @ingroup io_group
kpeter@314: \brief Reading and writing LEMON Graph Format.
alpar@40: 
alpar@210: This group describes methods for reading and writing
ladanyi@236: \ref lgf-format "LEMON Graph Format".
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@314: @defgroup eps_io Postscript Exporting
alpar@40: @ingroup io_group
alpar@40: \brief General \c EPS drawer and graph exporter
alpar@40: 
kpeter@50: This group describes general \c EPS drawing methods and special
alpar@209: graph exporting tools.
alpar@40: */
alpar@40: 
alpar@40: /**
kpeter@388: @defgroup dimacs_group DIMACS format
kpeter@388: @ingroup io_group
kpeter@388: \brief Read and write files in DIMACS format
kpeter@388: 
kpeter@388: Tools to read a digraph from or write it to a file in DIMACS format data.
kpeter@388: */
kpeter@388: 
kpeter@388: /**
kpeter@351: @defgroup nauty_group NAUTY Format
kpeter@351: @ingroup io_group
kpeter@351: \brief Read \e Nauty format
kpeter@388: 
kpeter@351: Tool to read graphs from \e Nauty format data.
kpeter@351: */
kpeter@351: 
kpeter@351: /**
alpar@40: @defgroup concept Concepts
alpar@40: \brief Skeleton classes and concept checking classes
alpar@40: 
alpar@40: This group describes the data/algorithm skeletons and concept checking
alpar@40: classes implemented in LEMON.
alpar@40: 
alpar@40: The purpose of the classes in this group is fourfold.
alpar@209: 
kpeter@318: - These classes contain the documentations of the %concepts. In order
alpar@40:   to avoid document multiplications, an implementation of a concept
alpar@40:   simply refers to the corresponding concept class.
alpar@40: 
alpar@40: - These classes declare every functions, <tt>typedef</tt>s etc. an
kpeter@318:   implementation of the %concepts should provide, however completely
alpar@40:   without implementations and real data structures behind the
alpar@40:   interface. On the other hand they should provide nothing else. All
alpar@40:   the algorithms working on a data structure meeting a certain concept
alpar@40:   should compile with these classes. (Though it will not run properly,
alpar@40:   of course.) In this way it is easily to check if an algorithm
alpar@40:   doesn't use any extra feature of a certain implementation.
alpar@40: 
alpar@40: - The concept descriptor classes also provide a <em>checker class</em>
kpeter@50:   that makes it possible to check whether a certain implementation of a
alpar@40:   concept indeed provides all the required features.
alpar@40: 
alpar@40: - Finally, They can serve as a skeleton of a new implementation of a concept.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup graph_concepts Graph Structure Concepts
alpar@40: @ingroup concept
alpar@40: \brief Skeleton and concept checking classes for graph structures
alpar@40: 
kpeter@50: This group describes the skeletons and concept checking classes of LEMON's
alpar@40: graph structures and helper classes used to implement these.
alpar@40: */
alpar@40: 
kpeter@314: /**
kpeter@314: @defgroup map_concepts Map Concepts
kpeter@314: @ingroup concept
kpeter@314: \brief Skeleton and concept checking classes for maps
kpeter@314: 
kpeter@314: This group describes the skeletons and concept checking classes of maps.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: \anchor demoprograms
alpar@40: 
alpar@40: @defgroup demos Demo programs
alpar@40: 
alpar@40: Some demo programs are listed here. Their full source codes can be found in
alpar@40: the \c demo subdirectory of the source tree.
alpar@40: 
alpar@41: It order to compile them, use <tt>--enable-demo</tt> configure option when
alpar@41: build the library.
alpar@40: */
alpar@40: 
alpar@40: /**
alpar@40: @defgroup tools Standalone utility applications
alpar@40: 
alpar@209: Some utility applications are listed here.
alpar@40: 
alpar@40: The standard compilation procedure (<tt>./configure;make</tt>) will compile
alpar@209: them, as well.
alpar@40: */
alpar@40: