1.1 --- a/doc/Doxyfile	Wed Feb 23 10:53:17 2005 +0000
     1.2 +++ b/doc/Doxyfile	Wed Feb 23 22:00:05 2005 +0000
     1.3 @@ -458,6 +458,7 @@
     1.4                           developers_interface.dox \
     1.5                           graph_io.dox \
     1.6                           dirs.dox \
     1.7 +			 gwrappers.dox \
     1.8                           ../src/lemon \
     1.9                           ../src/lemon/concept \
    1.10                           ../src/test/test_tools.h

     2.1 --- a/doc/groups.dox	Wed Feb 23 10:53:17 2005 +0000
     2.2 +++ b/doc/groups.dox	Wed Feb 23 22:00:05 2005 +0000
     2.3 @@ -9,20 +9,34 @@
     2.4  @ingroup datas
     2.5  \brief Graph structures implemented in LEMON.
     2.6  
     2.7 -LEMON provides several data structures to meet the diverging requirements
     2.8 -of the possible users.
     2.9 -In order to save on running time or on memory usage, some structures may
    2.10 -fail to provide
    2.11 -some graph features like edge or node deletion.
    2.12 +The implementation of combinatorial algorithms heavily relies on 
    2.13 +efficient graph implementations. LEMON offers data structures which are 
    2.14 +planned to be easily used in an experimental phase of implementation studies, 
    2.15 +and thereafter the program code can be made efficient by small modifications. 
    2.16  
    2.17 -LEMON also offers special graphs that cannot be used alone but only
    2.18 -in conjunction with other graph representation. The examples for this are
    2.19 -\ref lemon::EdgeSet "EdgeSet", \ref lemon::NodeSet "NodeSet"
    2.20 -and the large variety of \ref gwrappers "graph wrappers".
    2.21 +The most efficient implementation of diverse applications require the usage of different physical graph implementations. These differences appear in the size of 
    2.22 +graph we require to handle, memory or time usage limitations or in 
    2.23 +the set of operations through which the graph can be accessed. 
    2.24 +LEMON provides several physical graph structures to meet the 
    2.25 +diverging requirements of the possible users. 
    2.26 +In order to save on running time or on memory usage, some structures may 
    2.27 +fail to provide some graph features like edge or node deletion.
    2.28 +
    2.29 +Alteration of standard containers need a very limited number of 
    2.30 +operations, these together satisfy the everyday requirements. 
    2.31 +In the case of graph strutures, different operations are needed which do 
    2.32 +not alter the physical graph, but gives an other view. If some nodes or 
    2.33 +edges have to be hidden or the reverse oriented graph have to be used, then 
    2.34 +this is the case. It also may happen that in a flow implemenation 
    2.35 +the residual graph can be accessed by an other algorithm, or a node-set 
    2.36 +is to be shrunk for an other algorithm. 
    2.37 +LEMON also provides a variety of graphs for these requirements called 
    2.38 +\ref gwrappers "graph wrappers". Wrappers cannot be used alone but only 
    2.39 +in conjunction with other graph representation. 
    2.40  
    2.41  You are free to use the graph structure that fit your requirements
    2.42  the best, most graph algorithms and auxiliary data structures can be used
    2.43 -with any graph structures.
    2.44 +with any graph structures. 
    2.45  */
    2.46  
    2.47  /**
    2.48 @@ -53,12 +67,6 @@
    2.49  */
    2.50  
    2.51  /**
    2.52 -@defgroup gwrappers Wrapper Classes for Graphs
    2.53 -\brief This group contains several wrapper classes for graphs
    2.54 -@ingroup graphs
    2.55 -*/
    2.56 -
    2.57 -/**
    2.58  @defgroup galgs Graph Algorithms
    2.59  \brief This group describes the several graph algorithms
    2.60  implemented in LEMON.

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/doc/gwrappers.dox	Wed Feb 23 22:00:05 2005 +0000
     3.3 @@ -0,0 +1,61 @@
     3.4 +/**
     3.5 +   @defgroup gwrappers Wrapper Classes for Graphs
     3.6 +   \brief This group contains several wrapper classes for graphs
     3.7 +   @ingroup graphs
     3.8 +   
     3.9 +   The main parts of LEMON are the different graph structures, 
    3.10 +   generic graph algorithms, graph concepts which couple these, and 
    3.11 +   graph wrappers. While the previous ones are more or less clear, the 
    3.12 +   latter notion needs further explanation.
    3.13 +   Graph wrappers are graph classes which serve for considering graph 
    3.14 +   structures in different ways. A short example makes the notion much 
    3.15 +   clearer. 
    3.16 +   Suppose that we have an instance \c g of a directed graph
    3.17 +   type say \c ListGraph and an algorithm 
    3.18 +   \code template<typename Graph> int algorithm(const Graph&); \endcode 
    3.19 +   is needed to run on the reversely oriented graph. 
    3.20 +   It may be expensive (in time or in memory usage) to copy 
    3.21 +   \c g with the reverse orientation. 
    3.22 +   Thus, a wrapper class
    3.23 +   \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
    3.24 +   The code looks as follows
    3.25 +   \code
    3.26 +   ListGraph g;
    3.27 +   RevGraphWrapper<ListGraph> rgw(g);
    3.28 +   int result=algorithm(rgw);
    3.29 +   \endcode
    3.30 +   After running the algorithm, the original graph \c g 
    3.31 +   remains untouched. Thus the graph wrapper used above is to consider the 
    3.32 +   original graph with reverse orientation. 
    3.33 +   This techniques gives rise to an elegant code, and 
    3.34 +   based on stable graph wrappers, complex algorithms can be 
    3.35 +   implemented easily. 
    3.36 +   In flow, circulation and bipartite matching problems, the residual 
    3.37 +   graph is of particular importance. Combining a wrapper implementing 
    3.38 +   this, shortest path algorithms and minimum mean cycle algorithms, 
    3.39 +   a range of weighted and cardinality optimization algorithms can be 
    3.40 +   obtained. For lack of space, for other examples, 
    3.41 +   the interested user is referred to the detailed documentation of graph 
    3.42 +   wrappers. 
    3.43 +   The behavior of graph wrappers can be very different. Some of them keep 
    3.44 +   capabilities of the original graph while in other cases this would be 
    3.45 +   meaningless. This means that the concepts that they are a model of depend 
    3.46 +   on the graph wrapper, and the wrapped graph(s). 
    3.47 +   If an edge of \c rgw is deleted, this is carried out by 
    3.48 +   deleting the corresponding edge of \c g. But for a residual 
    3.49 +   graph, this operation has no sense. 
    3.50 +   Let we stand one more example here to simplify your work. 
    3.51 +   wrapper class
    3.52 +   \code template<typename Graph> class RevGraphWrapper; \endcode 
    3.53 +   has constructor 
    3.54 +   <tt> RevGraphWrapper(Graph& _g)</tt>. 
    3.55 +   This means that in a situation, 
    3.56 +   when a <tt> const ListGraph& </tt> reference to a graph is given, 
    3.57 +   then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
    3.58 +   \code
    3.59 +   int algorithm1(const ListGraph& g) {
    3.60 +   RevGraphWrapper<const ListGraph> rgw(g);
    3.61 +   return algorithm2(rgw);
    3.62 +   }
    3.63 +   \endcode
    3.64 +*/

     4.1 --- a/src/lemon/graph_wrapper.h	Wed Feb 23 10:53:17 2005 +0000
     4.2 +++ b/src/lemon/graph_wrapper.h	Wed Feb 23 22:00:05 2005 +0000
     4.3 @@ -34,66 +34,12 @@
     4.4  
     4.5    // Graph wrappers
     4.6  
     4.7 -  /*! \addtogroup gwrappers
     4.8 -    The main parts of LEMON are the different graph structures, 
     4.9 -    generic graph algorithms, graph concepts which couple these, and 
    4.10 -    graph wrappers. While the previous ones are more or less clear, the 
    4.11 -    latter notion needs further explanation.
    4.12 -    Graph wrappers are graph classes which serve for considering graph 
    4.13 -    structures in different ways. A short example makes the notion much 
    4.14 -    clearer. 
    4.15 -    Suppose that we have an instance \c g of a directed graph
    4.16 -    type say \c ListGraph and an algorithm 
    4.17 -    \code template<typename Graph> int algorithm(const Graph&); \endcode 
    4.18 -    is needed to run on the reversely oriented graph. 
    4.19 -    It may be expensive (in time or in memory usage) to copy 
    4.20 -    \c g with the reverse orientation. 
    4.21 -    Thus, a wrapper class
    4.22 -    \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
    4.23 -    The code looks as follows
    4.24 -    \code
    4.25 -    ListGraph g;
    4.26 -    RevGraphWrapper<ListGraph> rgw(g);
    4.27 -    int result=algorithm(rgw);
    4.28 -    \endcode
    4.29 -    After running the algorithm, the original graph \c g 
    4.30 -    remains untouched. Thus the graph wrapper used above is to consider the 
    4.31 -    original graph with reverse orientation. 
    4.32 -    This techniques gives rise to an elegant code, and 
    4.33 -    based on stable graph wrappers, complex algorithms can be 
    4.34 -    implemented easily. 
    4.35 -    In flow, circulation and bipartite matching problems, the residual 
    4.36 -    graph is of particular importance. Combining a wrapper implementing 
    4.37 -    this, shortest path algorithms and minimum mean cycle algorithms, 
    4.38 -    a range of weighted and cardinality optimization algorithms can be 
    4.39 -    obtained. For lack of space, for other examples, 
    4.40 -    the interested user is referred to the detailed documentation of graph 
    4.41 -    wrappers. 
    4.42 -    The behavior of graph wrappers can be very different. Some of them keep 
    4.43 -    capabilities of the original graph while in other cases this would be 
    4.44 -    meaningless. This means that the concepts that they are a model of depend 
    4.45 -    on the graph wrapper, and the wrapped graph(s). 
    4.46 -    If an edge of \c rgw is deleted, this is carried out by 
    4.47 -    deleting the corresponding edge of \c g. But for a residual 
    4.48 -    graph, this operation has no sense. 
    4.49 -    Let we stand one more example here to simplify your work. 
    4.50 -    wrapper class
    4.51 -    \code template<typename Graph> class RevGraphWrapper; \endcode 
    4.52 -    has constructor 
    4.53 -    <tt> RevGraphWrapper(Graph& _g)</tt>. 
    4.54 -    This means that in a situation, 
    4.55 -    when a <tt> const ListGraph& </tt> reference to a graph is given, 
    4.56 -    then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
    4.57 -    \code
    4.58 -    int algorithm1(const ListGraph& g) {
    4.59 -    RevGraphWrapper<const ListGraph> rgw(g);
    4.60 -    return algorithm2(rgw);
    4.61 -    }
    4.62 -    \endcode
    4.63 -
    4.64 +  /*!
    4.65      \addtogroup gwrappers
    4.66      @{
    4.67 +   */
    4.68  
    4.69 +  /*! 
    4.70      Base type for the Graph Wrappers
    4.71  
    4.72      \warning Graph wrappers are in even more experimental state than the other

     5.1 --- a/src/lemon/maps.h	Wed Feb 23 10:53:17 2005 +0000
     5.2 +++ b/src/lemon/maps.h	Wed Feb 23 22:00:05 2005 +0000
     5.3 @@ -590,7 +590,7 @@
     5.4    ///that is it provides an <tt>operator()</tt> to read its values.
     5.5    ///
     5.6    ///For the sake of convenience it also works as a ususal map, i.e
     5.7 -  ///<tt>operator[]</tt> and the \c Key and \c Valu typedefs also exist.
     5.8 +  ///<tt>operator[]</tt> and the \c Key and \c Value typedefs also exist.
     5.9  
    5.10    template<class M> 
    5.11    class MapFunctor

     6.1 --- a/src/lemon/max_matching.h	Wed Feb 23 10:53:17 2005 +0000
     6.2 +++ b/src/lemon/max_matching.h	Wed Feb 23 22:00:05 2005 +0000
     6.3 @@ -161,7 +161,7 @@
     6.4      ///map[v] must be an \c UndirEdge incident to \c v. This map must
     6.5      ///have the property that if \c g.oppositeNode(u,map[u])==v then
     6.6      ///\c \c g.oppositeNode(v,map[v])==u holds, and now some edge
     6.7 -    ///joining \c u to \v will be an edge of the matching.
     6.8 +    ///joining \c u to \c v will be an edge of the matching.
     6.9      template<typename NMapE>
    6.10      void readNMapEdge(NMapE& map) {
    6.11       for(NodeIt v(g); v!=INVALID; ++v) {