1.1 --- a/doc/gwrappers.dox	Wed Mar 23 15:43:18 2005 +0000
     1.2 +++ b/doc/gwrappers.dox	Wed Mar 23 16:59:13 2005 +0000
     1.3 @@ -5,50 +5,69 @@
     1.4     
     1.5     The main parts of LEMON are the different graph structures, 
     1.6     generic graph algorithms, graph concepts which couple these, and 
     1.7 -   graph wrappers. While the previous ones are more or less clear, the 
     1.8 -   latter notion needs further explanation.
     1.9 +   graph wrappers. While the previous notions are more or less clear, the 
    1.10 +   latter one needs further explanation. 
    1.11     Graph wrappers are graph classes which serve for considering graph 
    1.12 -   structures in different ways. A short example makes the notion much 
    1.13 +   structures in different ways. 
    1.14 +
    1.15 +   A short example makes this much 
    1.16     clearer. 
    1.17     Suppose that we have an instance \c g of a directed graph
    1.18 -   type say \c ListGraph and an algorithm 
    1.19 +   type say ListGraph and an algorithm 
    1.20     \code template<typename Graph> int algorithm(const Graph&); \endcode 
    1.21 -   is needed to run on the reversely oriented graph. 
    1.22 +   is needed to run on the reversed oriented graph. 
    1.23     It may be expensive (in time or in memory usage) to copy 
    1.24 -   \c g with the reverse orientation. 
    1.25 -   Thus, a wrapper class
    1.26 -   \code template<typename Graph> class RevGraphWrapper; \endcode is used. 
    1.27 -   The code looks as follows
    1.28 +   \c g with the reversed orientation. 
    1.29 +   In this case, a wrapper class is used, which 
    1.30 +   (according to LEMON graph concepts) works as a graph. 
    1.31 +   The wrapper uses 
    1.32 +   the original graph structure and graph operations when methods of the 
    1.33 +   reversed oriented graph are called. 
    1.34 +   This means that the wrapper have minor memory usage, 
    1.35 +   and do not perform sophisticated algorithmic actions. 
    1.36 +   The purpose of it is to give a tool for the cases when 
    1.37 +   a graph have to be used in a specific alteration. 
    1.38 +   If this alteration is obtained by a usual construction 
    1.39 +   like filtering the edge-set or considering a new orientation, then 
    1.40 +   a wrapper is worthwhile to use. 
    1.41 +   To come back to the reversed oriented graph, in this situation 
    1.42 +   \code template<typename Graph> class RevGraphWrapper; \endcode 
    1.43 +   template class can be used. 
    1.44 +   The code looks as follows 
    1.45     \code
    1.46     ListGraph g;
    1.47     RevGraphWrapper<ListGraph> rgw(g);
    1.48     int result=algorithm(rgw);
    1.49     \endcode
    1.50     After running the algorithm, the original graph \c g 
    1.51 -   remains untouched. Thus the graph wrapper used above is to consider the 
    1.52 -   original graph with reverse orientation. 
    1.53 +   is untouched. 
    1.54     This techniques gives rise to an elegant code, and 
    1.55     based on stable graph wrappers, complex algorithms can be 
    1.56     implemented easily. 
    1.57 +
    1.58     In flow, circulation and bipartite matching problems, the residual 
    1.59     graph is of particular importance. Combining a wrapper implementing 
    1.60     this, shortest path algorithms and minimum mean cycle algorithms, 
    1.61     a range of weighted and cardinality optimization algorithms can be 
    1.62 -   obtained. For lack of space, for other examples, 
    1.63 -   the interested user is referred to the detailed documentation of graph 
    1.64 -   wrappers. 
    1.65 +   obtained. 
    1.66 +   For other examples, 
    1.67 +   the interested user is referred to the detailed documentation of 
    1.68 +   particular wrappers. 
    1.69 +
    1.70     The behavior of graph wrappers can be very different. Some of them keep 
    1.71     capabilities of the original graph while in other cases this would be 
    1.72 -   meaningless. This means that the concepts that they are a model of depend 
    1.73 +   meaningless. This means that the concepts that they are models of depend 
    1.74     on the graph wrapper, and the wrapped graph(s). 
    1.75     If an edge of \c rgw is deleted, this is carried out by 
    1.76 -   deleting the corresponding edge of \c g. But for a residual 
    1.77 +   deleting the corresponding edge of \c g, thus the wrapper modifies the 
    1.78 +   original graph. 
    1.79 +   But for a residual 
    1.80     graph, this operation has no sense. 
    1.81 -   Let we stand one more example here to simplify your work. 
    1.82 -   wrapper class
    1.83 -   \code template<typename Graph> class RevGraphWrapper; \endcode 
    1.84 -   has constructor 
    1.85 -   <tt> RevGraphWrapper(Graph& _g)</tt>. 
    1.86 +   Let us stand one more example here to simplify your work. 
    1.87 +   RevGraphWrapper has constructor 
    1.88 +   \code 
    1.89 +   RevGraphWrapper(Graph& _g);
    1.90 +   \endcode
    1.91     This means that in a situation, 
    1.92     when a <tt> const ListGraph& </tt> reference to a graph is given, 
    1.93     then it have to be instantiated with <tt>Graph=const ListGraph</tt>.

     2.1 --- a/src/lemon/graph_wrapper.h	Wed Mar 23 15:43:18 2005 +0000
     2.2 +++ b/src/lemon/graph_wrapper.h	Wed Mar 23 16:59:13 2005 +0000
     2.3 @@ -434,11 +434,11 @@
     2.4    two nodes \c s and \c t. Shortest here means being shortest w.r.t. 
     2.5    non-negative edge-lengths. Note that 
     2.6    the comprehension of the presented solution 
     2.7 -  need's some knowledge from elementary combinatorial optimization. 
     2.8 +  need's some elementary knowledge from combinatorial optimization. 
     2.9  
    2.10    If a single shortest path is to be 
    2.11 -  searched between two nodes \c s and \c t, then this can be done easily by 
    2.12 -  applying the Dijkstra algorithm class. What happens, if a maximum number of 
    2.13 +  searched between \c s and \c t, then this can be done easily by 
    2.14 +  applying the Dijkstra algorithm. What happens, if a maximum number of 
    2.15    edge-disjoint shortest paths is to be computed. It can be proved that an 
    2.16    edge can be in a shortest path if and only if it is tight with respect to 
    2.17    the potential function computed by Dijkstra. Moreover, any path containing 
    2.18 @@ -923,7 +923,8 @@
    2.19    /// But BidirGraphWrapper is obtained from 
    2.20    /// SubBidirGraphWrapper by considering everywhere true 
    2.21    /// valued maps both for forward_filter and backward_filter. 
    2.22 -  /// Finally, one of the most important applications of SubBidirGraphWrapper 
    2.23 +  ///
    2.24 +  /// The most important application of SubBidirGraphWrapper 
    2.25    /// is ResGraphWrapper, which stands for the residual graph in directed 
    2.26    /// flow and circulation problems. 
    2.27    /// As wrappers usually, the SubBidirGraphWrapper implements the