doc/graph-adaptors.dox
author deba
Thu, 27 Dec 2007 13:40:16 +0000
changeset 2547 f393a8162688
parent 2084 59769591eb60
child 2553 bfced05fa852
permissions -rw-r--r--
Renaming state_enum to State
Removing "Type" suffix from typedefs
Moving implementation into the class definition
alpar@2391
     1
/* -*- C++ -*-
alpar@2391
     2
 *
alpar@2391
     3
 * This file is a part of LEMON, a generic C++ optimization library
alpar@2391
     4
 *
alpar@2391
     5
 * Copyright (C) 2003-2007
alpar@2391
     6
 * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
alpar@2391
     7
 * (Egervary Research Group on Combinatorial Optimization, EGRES).
alpar@2391
     8
 *
alpar@2391
     9
 * Permission to use, modify and distribute this software is granted
alpar@2391
    10
 * provided that this copyright notice appears in all copies. For
alpar@2391
    11
 * precise terms see the accompanying LICENSE file.
alpar@2391
    12
 *
alpar@2391
    13
 * This software is provided "AS IS" with no warranty of any kind,
alpar@2391
    14
 * express or implied, and with no claim as to its suitability for any
alpar@2391
    15
 * purpose.
alpar@2391
    16
 *
alpar@2391
    17
 */
alpar@2391
    18
marci@1172
    19
/**
alpar@1401
    20
   @defgroup graph_adaptors Adaptor Classes for Graphs
alpar@1949
    21
   @ingroup graphs
alpar@1401
    22
   \brief This group contains several adaptor classes for graphs
marci@556
    23
   
marci@1172
    24
   The main parts of LEMON are the different graph structures, 
marci@1172
    25
   generic graph algorithms, graph concepts which couple these, and 
alpar@1401
    26
   graph adaptors. While the previous notions are more or less clear, the 
marci@1252
    27
   latter one needs further explanation. 
alpar@1401
    28
   Graph adaptors are graph classes which serve for considering graph 
marci@1252
    29
   structures in different ways. 
marci@1252
    30
marci@1252
    31
   A short example makes this much 
marci@1172
    32
   clearer. 
marci@1172
    33
   Suppose that we have an instance \c g of a directed graph
marci@1252
    34
   type say ListGraph and an algorithm 
marci@1172
    35
   \code template<typename Graph> int algorithm(const Graph&); \endcode 
marci@1252
    36
   is needed to run on the reversed oriented graph. 
marci@1172
    37
   It may be expensive (in time or in memory usage) to copy 
marci@1252
    38
   \c g with the reversed orientation. 
alpar@1401
    39
   In this case, an adaptor class is used, which 
marci@1252
    40
   (according to LEMON graph concepts) works as a graph. 
alpar@1401
    41
   The adaptor uses 
marci@1252
    42
   the original graph structure and graph operations when methods of the 
marci@1252
    43
   reversed oriented graph are called. 
alpar@1401
    44
   This means that the adaptor have minor memory usage, 
marci@1252
    45
   and do not perform sophisticated algorithmic actions. 
marci@1252
    46
   The purpose of it is to give a tool for the cases when 
marci@1252
    47
   a graph have to be used in a specific alteration. 
marci@1252
    48
   If this alteration is obtained by a usual construction 
marci@1252
    49
   like filtering the edge-set or considering a new orientation, then 
alpar@1401
    50
   an adaptor is worthwhile to use. 
marci@1252
    51
   To come back to the reversed oriented graph, in this situation 
alpar@1401
    52
   \code template<typename Graph> class RevGraphAdaptor; \endcode 
marci@1252
    53
   template class can be used. 
marci@1252
    54
   The code looks as follows 
marci@1172
    55
   \code
marci@1172
    56
   ListGraph g;
deba@2084
    57
   RevGraphAdaptor<ListGraph> rga(g);
deba@2084
    58
   int result=algorithm(rga);
marci@1172
    59
   \endcode
marci@1172
    60
   After running the algorithm, the original graph \c g 
marci@1252
    61
   is untouched. 
marci@1172
    62
   This techniques gives rise to an elegant code, and 
alpar@1401
    63
   based on stable graph adaptors, complex algorithms can be 
marci@1172
    64
   implemented easily. 
marci@1252
    65
marci@1172
    66
   In flow, circulation and bipartite matching problems, the residual 
alpar@1401
    67
   graph is of particular importance. Combining an adaptor implementing 
marci@1172
    68
   this, shortest path algorithms and minimum mean cycle algorithms, 
marci@1172
    69
   a range of weighted and cardinality optimization algorithms can be 
marci@1252
    70
   obtained. 
marci@1252
    71
   For other examples, 
marci@1252
    72
   the interested user is referred to the detailed documentation of 
alpar@1401
    73
   particular adaptors. 
marci@1252
    74
alpar@1401
    75
   The behavior of graph adaptors can be very different. Some of them keep 
marci@1172
    76
   capabilities of the original graph while in other cases this would be 
marci@1252
    77
   meaningless. This means that the concepts that they are models of depend 
alpar@1401
    78
   on the graph adaptor, and the wrapped graph(s). 
deba@2084
    79
   If an edge of \c rga is deleted, this is carried out by 
alpar@1401
    80
   deleting the corresponding edge of \c g, thus the adaptor modifies the 
marci@1252
    81
   original graph. 
marci@1252
    82
   But for a residual 
marci@1172
    83
   graph, this operation has no sense. 
marci@1252
    84
   Let us stand one more example here to simplify your work. 
alpar@1401
    85
   RevGraphAdaptor has constructor 
marci@1252
    86
   \code 
alpar@1401
    87
   RevGraphAdaptor(Graph& _g);
marci@1252
    88
   \endcode
marci@1172
    89
   This means that in a situation, 
marci@1172
    90
   when a <tt> const ListGraph& </tt> reference to a graph is given, 
marci@1172
    91
   then it have to be instantiated with <tt>Graph=const ListGraph</tt>.
marci@1172
    92
   \code
marci@1172
    93
   int algorithm1(const ListGraph& g) {
deba@2084
    94
   RevGraphAdaptor<const ListGraph> rga(g);
deba@2084
    95
   return algorithm2(rga);
marci@1172
    96
   }
marci@1172
    97
   \endcode
marci@1172
    98
*/