mirror of https://github.com/CGAL/cgal
using cgalHeading instead of h3
This commit is contained in:
Sébastien Loriot
parent
09ea904efa
commit
9c2f35ed1a
|
|
@ -8,7 +8,7 @@ The concept `AABBPrimitive` describes the requirements for the primitives stored
|
|||
\sa `CGAL::AABB_tree<AABBTraits>`
|
||||
\sa `AABBPrimitiveWithSharedData`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
The `Primitive` type can be, e.g., a wrapper around a `Handle`. Assume for instance that the input objects are the triangle faces of a mesh stored as a `CGAL::Polyhedron_3`. The `Datum` would be a `Triangle_3` and the `Id` would be a polyhedron `Face_handle`. Method `datum()` can return either a `Triangle_3` constructed on the fly from the face handle or a `Triangle_3` stored internally. This provides a way for the user to trade memory for efficiency.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ of the primitives are required to access the datum and the reference point.
|
|||
\sa `CGAL::AABB_tree<AABBTraits>`
|
||||
\sa `AABBPrimitive`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
The `Primitive` type can be a wrapper around an integer that refers to the position
|
||||
of an object in a vector. Assume for instance that the input objects are some triangles.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,9 @@ Moreover, `CGAL::Algebraic_structure_traits< EuclideanRing >` is a model of
|
|||
- \link AlgebraicStructureTraits::Div `CGAL::Algebraic_structure_traits< EuclideanRing >::Div` \endlink which is a model of `AlgebraicStructureTraits_::Div`
|
||||
- \link AlgebraicStructureTraits::Div_mod `CGAL::Algebraic_structure_traits< EuclideanRing >::Div_mod` \endlink which is a model of `AlgebraicStructureTraits_::DivMod`
|
||||
|
||||
### Remarks ###
|
||||
<p></p> <!-- Work around for a doxygen bug -->
|
||||
|
||||
\cgalHeading{Remarks}
|
||||
|
||||
The most prominent example of a Euclidean ring are the integers.
|
||||
Whenever both \f$ x\f$ and \f$ y\f$ are positive, then it is conventional to choose
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ next and previous level graphs.
|
|||
|
||||
\cgalRefines `ApolloniusGraphVertexBase_2`
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
`ApolloniusGraphHierarchyVertexBase_2` does not introduce any
|
||||
types in addition to those of `ApolloniusGraphVertexBase_2`.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ a vertex. Each vertex has a geometric position in space. As in a
|
|||
halfedge data structure we define the face adjacent to a halfedge to be
|
||||
to the <I>left</I> of the halfedge.
|
||||
|
||||
### Requirements ###
|
||||
\cgalHeading{Requirements}
|
||||
|
||||
For each <I>directed edge</I> `e=(v,w)` its opposite edge `e2=(w,v)`
|
||||
must be part of the graph.
|
||||
|
|
@ -31,7 +31,7 @@ A model of `HalfedgeGraph` must have the <I>interior properties</I>
|
|||
`edge_is_border` attached to its edges, and it must have
|
||||
`vertex_is_border` and `vertex_point` attached to its vertices.
|
||||
|
||||
### Associated Types ###
|
||||
\cgalHeading{Associated Types}
|
||||
|
||||
Because (directed) edges must come in pairs, there is the
|
||||
additional notion of an <I>undirected edge</I>
|
||||
|
|
@ -52,7 +52,7 @@ halfedge_graph_traits<HalfedgeGraph>::undirected_edge_iterator; | An iterator th
|
|||
|
||||
|
||||
|
||||
### Valid Expressions ###
|
||||
\cgalHeading{Valid Expressions}
|
||||
|
||||
Following the \sc{Bgl} design, the following graph operations are defined as free
|
||||
rather than member functions.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ stores handles to the darts linked with itself by \f$ \beta_i\f$, \f$ \forall\f$
|
|||
0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>. Moreover, it stores also handles to each
|
||||
non void attribute associated with itself.
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
A dart `d0` is never constructed directly, but always created
|
||||
within a combinatorial map `cm` by using the method
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ class used by the function `random_polygon_2()`.
|
|||
|
||||
\cgalHasModel \cgal kernels.
|
||||
|
||||
### Operations ###
|
||||
\cgalHeading{Operations}
|
||||
|
||||
The following two member functions returning instances of the above predicate
|
||||
object types are required.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ dangling handles), it must be called explicitly in advance for a
|
|||
Classes built on top of a `HalfedgeDS` are advised to call the
|
||||
`reserve()` member function before creating new items.
|
||||
|
||||
### Parameters ###
|
||||
\cgalHeading{Parameters}
|
||||
|
||||
A `HalfedgeDS` is a class template and will be used as argument for
|
||||
other class templates, for example `CGAL::Polyhedron_3`. The
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ types are described on the manual pages of the concepts `HalfedgeDSVertex`,
|
|||
\sa `CGAL::HalfedgeDS_halfedge_base<Refs>`
|
||||
\sa `CGAL::HalfedgeDS_face_base<Refs>`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
The following example shows the canonical implementation of the
|
||||
`CGAL::HalfedgeDS_min_items` class. It uses the base classes for the
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ fulfilled by any class used to instantiate first template parameter of
|
|||
the class
|
||||
`CGAL::Monge_via_jet_fitting<DataKernel,LocalKernel,SvdTraits>`.
|
||||
|
||||
### Operations ###
|
||||
\cgalHeading{Operations}
|
||||
|
||||
Only constructors (from 3 scalars and copy constructors) and access
|
||||
methods to coordinates `x()`, `y()`, `z()` are needed.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ This concept provides the geometric primitives used for the
|
|||
computations in the class
|
||||
`CGAL::Monge_via_jet_fitting`.
|
||||
|
||||
### Requirements ###
|
||||
\cgalHeading{Requirements}
|
||||
|
||||
In the class `CGAL::Monge_via_jet_fitting` the scalar type,
|
||||
`LocalKernel::FT`, must be the same as that of the `SvdTraits`
|
||||
|
|
@ -20,7 +20,7 @@ concept : `SvdTraits::FT`.
|
|||
|
||||
The type `LocalKernel::FT` is a model of the FieldWithSqrt concept.
|
||||
|
||||
### Operations ###
|
||||
\cgalHeading{Operations}
|
||||
|
||||
The scalar type `LocalKernel::FT` must be a field type with a
|
||||
square root.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
It describes the linear algebra types and algorithms needed by the
|
||||
class `CGAL::Monge_via_jet_fitting`.
|
||||
|
||||
### Requirements ###
|
||||
\cgalHeading{Requirements}
|
||||
|
||||
The scalar type, `SvdTraits::FT`, must be the same as that of
|
||||
the `LocalKernel` concept : `LocalKernel::FT`.
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ bool do_intersect(Type1<Kernel> obj1, Type2<Kernel> obj2);
|
|||
\details Depending on which \cgal kernel is used, different overloads of this global
|
||||
function are available.
|
||||
|
||||
### Notes on Backward Compatibility ###
|
||||
\cgalHeading{Notes on Backward Compatibility}
|
||||
|
||||
The \ref intersection_grp function used to return an `Object`, but starting with
|
||||
\cgal 4.2 the
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ time (if only a time value rather than an interval is passed).
|
|||
|
||||
\sa `Kinetic::KineticKernel`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
Here you see how to use both functions on an orientation predicate.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ namespace Kinetic {
|
|||
|
||||
\sa `Kinetic::RootEnumerator`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
We provide several models of the concept, which are not documented
|
||||
separately. The models of `Kinetic::SimulationTraits` all choose
|
||||
|
|
@ -109,7 +109,7 @@ public:
|
|||
\sa `FunctionKernel`
|
||||
\sa `FunctionKernel::ConstructFunction`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
Several ways to create functions:
|
||||
|
||||
|
|
@ -228,7 +228,7 @@ public:
|
|||
|
||||
\sa `FunctionKernel`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
\code{.cpp}
|
||||
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ public:
|
|||
|
||||
\sa `Kinetic::EventQueue`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
All of the kinetic data structures provided have models of
|
||||
`Event`. Here is the code implementing a swap event from the
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The concept `MonotoneMatrixSearchTraits` is a refinement of
|
|||
compute the maxima for all rows of a totally monotone matrix using
|
||||
the function `CGAL::monotone_matrix_search`.
|
||||
|
||||
### Notes ###
|
||||
\cgalHeading{Notes}
|
||||
|
||||
<UL>
|
||||
<LI>For the sake of efficiency (and in order to achieve the time
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ namespace CGAL {
|
|||
/// can be any class that fulfills the requirements for an STL
|
||||
/// container. It defaults to the std::vector class.
|
||||
///
|
||||
/// ### Implementation ###
|
||||
/// \cgalHeading{Implementation}
|
||||
///
|
||||
/// The methods `is_simple()`, `is_convex()`, `orientation()`,
|
||||
/// `oriented_side()`, `bounded_side()`, `bbox()`, `area()`, `left_vertex()`,
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ polyhedral surface renames faces to facets.
|
|||
\sa `CGAL::HalfedgeDS_halfedge_base<Refs>`
|
||||
\sa `CGAL::HalfedgeDS_face_base<Refs>`
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
We define our own items class based on the available
|
||||
`CGAL::HalfedgeDS_face_base` base class for faces. We derive the
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ iterator range, where begin refers the value for the innermost variable.
|
|||
\cgalRefines CopyConstructible
|
||||
\cgalRefines DefaultConstructible
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
Note that the `result_type` is the coercion type of the value type of the
|
||||
given iterator range and `PolynomialTraits_d::Innermost_coefficient_type`.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ polynomial \f$ p(x_0,x_1,w) = x_0^2x_1^3+x_1^4w^1\f$.
|
|||
\cgalRefines CopyConstructible
|
||||
\cgalRefines DefaultConstructible
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
Note that the `result_type` is the coercion type of the value type of the
|
||||
given iterator range and `PolynomialTraits_d::Innermost_coefficient_type`.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ convex polygon using the function `all_furthest_neighbors_2`.
|
|||
|
||||
\sa `CGAL::all_furthest_neighbors_2()`
|
||||
|
||||
### Notes ###
|
||||
\cgalHeading{Notes}
|
||||
|
||||
<UL>
|
||||
<LI>`AllFurthestNeighborsTraits_2::Less_xy_2` and
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
This concept defines the requirements for traits classes of
|
||||
`Width_3<Traits>`.
|
||||
|
||||
### Operations ###
|
||||
\cgalHeading{Operations}
|
||||
|
||||
Whatever the coordinates of the points are, it is required for the
|
||||
width-algorithm to have access to the homogeneous representation of
|
||||
|
|
|
|||
|
|
@ -58,14 +58,14 @@ x1 x1 8
|
|||
|
||||
Here comes a semiformal description of the format in general.
|
||||
|
||||
<h3> NAME Section </h3>
|
||||
\cgalHeading{NAME Section}
|
||||
|
||||
This (mandatory) section consists of a single line
|
||||
starting with <TT>NAME</TT>. Everything starting from the
|
||||
first non-whitespace after that until the end of the line
|
||||
constitutes the name of the problem.
|
||||
|
||||
<h3>ROWS Section </h3>
|
||||
\cgalHeading{ROWS Section}
|
||||
|
||||
In the (mandatory) <TT>ROW</TT> section, you find one line for every
|
||||
constraint, where the letter <TT>L</TT> indicates relation \f$ \leq\f$,
|
||||
|
|
@ -77,7 +77,7 @@ constraints (here: <TT>c0, c1</TT>) and the objective function (here:
|
|||
functions by using several rows starting with <TT>N</TT>, but we ignore
|
||||
all but the first.
|
||||
|
||||
<h3>COLUMNS Section</h3>
|
||||
\cgalHeading{COLUMNS Section}
|
||||
|
||||
The (mandatory) <TT>COLUMNS</TT> section encodes the constraint matrix
|
||||
\f$ A\f$ and the linear objective function vector \f$ c\f$. Every line consists
|
||||
|
|
@ -89,7 +89,7 @@ linear objective function). Values for pairs \f$ (i,j)\f$ that are not
|
|||
specified in this section default to \f$ 0\f$. Otherwise, for every pair
|
||||
\f$ (i,j)\f$, the <I>last</I> specified value determines \f$ A_{ij}\f$ or \f$ c_j\f$.
|
||||
|
||||
<h3> RHS Section </h3>
|
||||
\cgalHeading{RHS Section}
|
||||
|
||||
This (mandatory) section encodes the right-hand side vector \f$ b\f$ and
|
||||
the constant term \f$ c_0\f$ in the objective function. The first token in
|
||||
|
|
@ -106,7 +106,7 @@ function). Values that are not specified in this section default to \f$ 0\f$.
|
|||
Otherwise, for every \f$ i\f$, the <I>last</I> specified value determines
|
||||
\f$ b_{i}\f$ or \f$ -c_0\f$.
|
||||
|
||||
<h3>BOUNDS Section</h3>
|
||||
\cgalHeading{BOUNDS Section}
|
||||
|
||||
This (optional) section encodes the lower and upper bound vectors \f$ l\f$
|
||||
and \f$ u\f$ for the variables. The default bounds for any variable \f$ x_j\f$ are
|
||||
|
|
@ -137,7 +137,7 @@ FR | \f$-\infty \leq x_j\leq\infty\f$ (previous bounds are discarded)
|
|||
MI | \f$x_j\geq -\infty\f$ (upper bound remains unchanged)
|
||||
PL | \f$x_j\leq \infty\f$ (lower bound remains unchanged)
|
||||
|
||||
<h3> QMATRIX / QUADOBJ / DMATRIX Section</h3>
|
||||
\cgalHeading{QMATRIX / QUADOBJ / DMATRIX Section}
|
||||
|
||||
This (optional) section encodes the quadratic objective
|
||||
function matrix \f$ D\f$. Every line is a sequence \f$ i j val\f$ of
|
||||
|
|
@ -156,7 +156,7 @@ nonzero values for an unordered pair \f$ \{i,j\}\f$.
|
|||
If this section is missing or does not contain nonzero values, the
|
||||
program is a model of the concept `LinearProgram`.
|
||||
|
||||
<h3>Miscellaneous </h3>
|
||||
\cgalHeading{Miscellaneous}
|
||||
|
||||
Our MPS format also supports an (optional) <TT>RANGES</TT> section,
|
||||
but we don't explain this here.
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
\cgalHasModel `CGAL::Polyhedron_3` with the restriction that faces are triangular.
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
Construction and destruction are undefined.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ type information of the keys and intervals. Further more, they define function o
|
|||
the keys and intervals, and provide comparison functions that
|
||||
are needed for window queries.
|
||||
|
||||
### Example ###
|
||||
\cgalHeading{Example}
|
||||
|
||||
The following piece of code gives an example of how a traits class
|
||||
might look like, if you have keys that are of the type `int`
|
||||
|
|
|
|||
|
|
@ -14,13 +14,13 @@ next and previous level graphs.
|
|||
|
||||
\cgalRefines `SegmentDelaunayGraphVertexBase_2`
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
`SegmentDelaunayGraphHierarchyVertexBase_2` does not introduce
|
||||
any types in addition to those of
|
||||
`SegmentDelaunayGraphVertexBase_2`.
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
The `SegmentDelaunayGraphHierarchyVertexBase_2` concept does not
|
||||
introduce any constructors in addition to those of the
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
\ingroup PkgStraightSkeleton2Concepts
|
||||
\cgalConcept
|
||||
|
||||
### Introduction ###
|
||||
\cgalHeading{Introduction}
|
||||
|
||||
A model for the `VertexContainer_2` concept defines the requirements for a resizable container of 2D points. It is used to output the offset polygons generated by the `Polygon_offset_builder_2<Ssds,Gt,Container>` class.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ It can have any number of connected components, boundaries
|
|||
|
||||
\cgalRefines `HalfedgeGraph`
|
||||
|
||||
### Valid Expressions ###
|
||||
\cgalHeading{Valid Expressions}
|
||||
|
||||
The mesh simplification algorithm requires the free function `collapse_triangulation_edge()`.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Insertion of a new vertex in a given face, or in a given edge,
|
|||
suppression of a vertex of degree three, flip of two edges
|
||||
are examples of combinatorial operations.
|
||||
|
||||
### I/O ###
|
||||
\cgalHeading{I/O}
|
||||
|
||||
The information output in the `iostream` is:
|
||||
the dimension, the number of (finite) vertices,
|
||||
|
|
@ -713,7 +713,7 @@ when using the triangulation data structure class alone.
|
|||
They became required when the triangulation data structure is plugged
|
||||
into a triangulation.
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
In order to obtain new vertices or destruct unused vertices, the user must
|
||||
call the `create_vertex()` and `delete_vertex()` methods of the
|
||||
|
|
@ -826,13 +826,13 @@ of maximal dimension of the complex, i.e., a vertex in dimension `0`, an edge in
|
|||
Only vertices and neighbors with index `0` are set in the first case,
|
||||
only vertices and neighbors with index `0` or `1` are set in the second case.
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
The class `TriangulationDataStructure_2::Face` defines the same types as
|
||||
the triangulation data structure
|
||||
except the iterators and the circulators.
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
The methods `create_face()` and
|
||||
`delete_face()`
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ constraints.
|
|||
|
||||
\cgalRefines `TriangulationFaceBase_2`
|
||||
|
||||
### Types ###
|
||||
\cgalHeading{Types}
|
||||
|
||||
Defines the same types as the `TriangulationFaceBase_2` concept
|
||||
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ this use as a template parameter of `CGAL::Triangulation_3`.
|
|||
A class that satisfies the requirements for a triangulation data structure
|
||||
class must provide the following types and operations.
|
||||
|
||||
### I/O ###
|
||||
\cgalHeading{I/O}
|
||||
|
||||
The information stored in the `iostream` is:
|
||||
the dimension, the number of vertices, the number of cells,
|
||||
|
|
@ -1035,7 +1035,7 @@ when using the triangulation data structure class alone. They become
|
|||
compulsory when the triangulation data structure is used as a layer
|
||||
for the geometric triangulation class. (See Section \ref TDS3secdesign.)
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
In order to obtain new vertices or destruct unused vertices, the user must
|
||||
call the `create_vertex()` and `delete_vertex()` methods of the
|
||||
|
|
@ -1141,7 +1141,7 @@ facet of index 3, and 3 edges \f$ (0,1)\f$, \f$ (1,2)\f$ and \f$ (2,0)\f$; in
|
|||
dimension 1, each cell represents one edge \f$ (0,1)\f$. (See also
|
||||
Section \ref TDS3secintro.)
|
||||
|
||||
### Creation ###
|
||||
\cgalHeading{Creation}
|
||||
|
||||
In order to obtain new cells or destruct unused cells, the user must call the
|
||||
`create_cell()` and `delete_cell()` methods of the triangulation data
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ that the Voronoi diagram adaptor can adapt it.
|
|||
|
||||
\cgalRefines `DefaultConstructible,` \cgalRefines `CopyConstructible,` \cgalRefines `Assignable`
|
||||
|
||||
### Traversal of the Delaunay graph ###
|
||||
\cgalHeading{Traversal of the Delaunay graph}
|
||||
|
||||
A model of the `DelaunayGraph_2` concept must provide several
|
||||
iterators and circulators that allow to traverse it (completely or
|
||||
|
|
|
|||
Loading…
Reference in New Issue