COIN-OR::LEMON - Graph Library

Changeset 2117:96efb4fa0736 in lemon-0.x for doc


Ignore:
Timestamp:
07/04/06 19:49:01 (13 years ago)
Author:
Alpar Juttner
Branch:
default
Phase:
public
Convert:
svn:c9d7d8f5-90d6-0310-b91f-818b3a526b0e/lemon/trunk@2827
Message:
  • Revised "Concepts" group documentation
  • Other minor doc improvements
File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/groups.dox

    r2084 r2117  
    2626Alteration of standard containers need a very limited number of
    2727operations, these together satisfy the everyday requirements.
    28 In the case of graph strutures, different operations are needed which do
     28In the case of graph structures, different operations are needed which do
    2929not alter the physical graph, but gives another view. If some nodes or
    3030edges have to be hidden or the reverse oriented graph have to be used, then
    31 this is the case. It also may happen that in a flow implemenation
     31this is the case. It also may happen that in a flow implementation
    3232the residual graph can be accessed by another algorithm, or a node-set
    3333is to be shrunk for another algorithm.
     
    4646\brief Graph types between real graphs and graph adaptors.
    4747
    48 Graph types between real graphs and graph adaptors. These classes
    49 wrap graphs to give new functionality as the adaptors do it. But the
    50 other way they are not light-weigth structures as the adaptors.
     48Graph types between real graphs and graph adaptors. These classes wrap
     49graphs to give new functionality as the adaptors do it. On the other
     50hand they are not light-weight structures as the adaptors.
    5151*/
    5252
     
    7878
    7979Most of them are \ref lemon::concept::ReadMap "ReadMap"s. They can
    80 make arithmetic oprerations between one or two maps (negation, scaling,
     80make arithmetic operations between one or two maps (negation, scaling,
    8181addition, multiplication etc.) or e.g. convert a map to another one
    8282of different Value type.
     
    186186@defgroup spantree Minimum Cost Spanning Tree Algorithms
    187187@ingroup algs
    188 \brief This group containes the algorithms for finding a minimum cost spanning
     188\brief This group contains the algorithms for finding a minimum cost spanning
    189189tree in a graph
    190190
    191 This group containes the algorithms for finding a minimum cost spanning
     191This group contains the algorithms for finding a minimum cost spanning
    192192tree in a graph
    193193*/
     
    233233Here you can find tools for importing and exporting graphs
    234234and graph related data. Now it supports the LEMON format, the
    235 dimacs format and the encapsulated postscript format.
     235\c DIMACS format and the encapsulated postscript format.
    236236*/
    237237
     
    269269@defgroup eps_io Postscript exporting
    270270@ingroup io_group
    271 \brief General EPS drawer and graph exporter
    272 
    273 This group contains general EPS drawing methods and special
     271\brief General \c EPS drawer and graph exporter
     272
     273This group contains general \c EPS drawing methods and special
    274274graph exporting tools.
    275275*/
     
    287287classes implemented in LEMON.
    288288
    289 One aim of these classes is to make it easier to check if a certain
    290 class or template function is correctly implemented.
    291 
    292 The other (sometimes even more important) aim is to document the concepts.
     289The purpose of the classes in this group is fourfold.
     290 
     291- These classes contain the documentations of the concepts. In order
     292  to avoid document multiplications, an implementation of a concept
     293  simply refers to the corresponding concept class.
     294
     295- These classes declare every functions, <tt>typedef<tt>s etc. an
     296  implementation of the concepts should provide, however completely
     297  without implementations and real data structures behind the
     298  interface. On the other hand they should provide nothing else. All
     299  the algorithms working on a data structure meeting a certain concept
     300  should compile with these classes. (Though it will not run properly,
     301  of course.) In this way it is easily to check if an algorithm
     302  doesn't use any extra feature of a certain implementation.
     303
     304- The concept descriptor classes also provide a <em>checker class<em>
     305  that makes it possible check whether a certain implementation of a
     306  concept indeed provides all the required features.
     307
     308- Finally, They can serve as a skeleton of a new implementation of a concept.
    293309
    294310*/
Note: See TracChangeset for help on using the changeset viewer.