mirror of https://github.com/CGAL/cgal
Global heading reduction. Rename some Parameter section to Template
Parameters. Fix dependencies.
This commit is contained in:
Philipp Möller
parent
5b93145c39
commit
0aa7cd1c3b
|
|
@ -4681,7 +4681,6 @@ Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triang
|
|||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_ds_vertex_base_3.h -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_hierarchy_3.h -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/CGAL/Periodic_3_triangulation_traits_3.h -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Classified.txt -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Concepts/Periodic_3DelaunayTriangulationTraits_3.h -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Concepts/Periodic_3Offset_3.h -text
|
||||
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Concepts/Periodic_3TriangulationDSCellBase_3.h -text
|
||||
|
|
|
|||
|
|
@ -7,13 +7,7 @@ Compares `AlgebraicKernel_d_1::Algebraic_real_1` values.
|
|||
|
||||
\refines ::AdaptableBinaryFunction
|
||||
|
||||
Operations
|
||||
--------------
|
||||
|
||||
The following operators and their symmetric counterparts are required:
|
||||
|
||||
*/
|
||||
|
||||
class AlgebraicKernel_d_1::Compare_1 {
|
||||
public:
|
||||
|
||||
|
|
@ -38,6 +32,8 @@ typedef AlgebraicKernel_d_1::Algebraic_real_1 second_argument_type;
|
|||
/// @}
|
||||
|
||||
/// \name Operations
|
||||
/// The following operators and their symmetric counterparts are
|
||||
/// required:
|
||||
/// @{
|
||||
|
||||
/*!
|
||||
|
|
|
|||
|
|
@ -8,18 +8,12 @@ The multiplicity stored in the output iterator is the multiplicity in the system
|
|||
|
||||
\refines ::Assignable
|
||||
\refines ::CopyConstructible
|
||||
|
||||
Operations
|
||||
--------------
|
||||
|
||||
A model of this type must provide:
|
||||
|
||||
*/
|
||||
|
||||
class AlgebraicKernel_d_2::Solve_2 {
|
||||
public:
|
||||
|
||||
/// \name Operations
|
||||
/// A model of this type must provide:
|
||||
/// @{
|
||||
|
||||
/*!
|
||||
|
|
|
|||
|
|
@ -979,8 +979,7 @@ namespace CGAL {
|
|||
into \f$ x\f$-monotone subcurves (and perhaps isolated points), which are
|
||||
inserted into the arrangement.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>If the curve is \f$ x\f$-monotone curve then The instantiated
|
||||
|
|
@ -1068,8 +1067,7 @@ void insert (Arrangement_2<Traits,Dcel>& arr,
|
|||
edges or vertices of the existing arrangement `arr`.
|
||||
\pre If provided, `pl` must be attached to the given arrangement `arr`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>If `c` is \f$ x\f$-monotone then the instantiated `GeomTraits`
|
||||
|
|
@ -1110,8 +1108,7 @@ bool do_intersect (
|
|||
|
||||
\pre If provided, `pl` must be attached to the given arrangement `arr`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated `Traits` class must model the restricted
|
||||
|
|
@ -1138,8 +1135,7 @@ insert_non_intersecting_curve (Arrangement_2<Traits,Dcel>& arr,
|
|||
disjoint in their interior and pairwise interior-disjoint from all existing
|
||||
arrangement vertices and edges.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated `Traits` class must model the
|
||||
|
|
@ -1170,8 +1166,7 @@ void insert_non_intersecting_curves(Arrangement_2<Traits,Dcel>& arr,
|
|||
|
||||
\pre If provided, `pl` must be attached to the given arrangement `arr`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated `Traits` class must model the
|
||||
|
|
@ -1206,8 +1201,7 @@ insert_point (Arrangement_2<Traits,Dcel>& arr,
|
|||
function may take a considerable amount of time; it is recommended to be
|
||||
used only for debugging purposes.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
The instantiated traits class must model the concept
|
||||
`ArranagmentXMonotoneTraits_2`.
|
||||
|
|
@ -1235,8 +1229,7 @@ bool is_valid (const Arrangement_2<Traits, Dcel>& arr);
|
|||
is returned. Otherwise, the face to which the edge was incident before the
|
||||
removal is returned.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated traits class must model the concept
|
||||
|
|
@ -1261,8 +1254,7 @@ remove_edge (Arrangement_2<Traits,Dcel>& arr,
|
|||
The function returns a boolean value that indicates whether it succeeded
|
||||
removing the vertex from the arrangement.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated `Traits` class must model the
|
||||
|
|
@ -1294,8 +1286,7 @@ bool remove_vertex (Arrangement_2<Traits,Dcel>& arr,
|
|||
arrangement `arr`.
|
||||
\pre If provided, `pl` must be attached to the given arrangement `arr`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>The instantiated `GeomTraits` class must model the
|
||||
|
|
|
|||
|
|
@ -11,8 +11,7 @@ index vertices for \sc{Bgl} algorithms.
|
|||
Note that the user is in charge to set the index correctly before
|
||||
running a graph algorithm.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Parameters ###
|
||||
|
||||
The first template argument is the geometric traits class
|
||||
`TriangulationTraits_2` which provides the `Point_2`.
|
||||
|
|
|
|||
|
|
@ -9,9 +9,6 @@ to the
|
|||
<A HREF="http://www.boost.org/libs/graph/doc/BidirectionalGraph.html">`BidirectionalGraph`</A> and
|
||||
<A HREF="http://www.boost.org/libs/graph/doc/EdgeAndVertexListGraph.html">`EdgeAndVertexListGraph`</A>.
|
||||
|
||||
Types
|
||||
--------------
|
||||
|
||||
The const specialization, `boost::graph_traits< CGAL::Polyhedron_3<Traits> const>`
|
||||
is also defined, using the constant handles in the polyhedron.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,8 +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
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
For each <I>directed edge</I> \f$ e=(v,w)\f$ its opposite edge \f$ e'=(w,v)\f$
|
||||
must be part of the graph.
|
||||
|
|
@ -32,8 +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
|
||||
--------------
|
||||
### Associated Types ###
|
||||
|
||||
Because (directed) edges must come in pairs, there is the
|
||||
additional notion of an <I>undirected edge</I>
|
||||
|
|
@ -56,8 +54,7 @@ typedef Hidden_type halfedge_graph_traits<HalfedgeGraph>::Point;
|
|||
typedef Hidden_type halfedge_graph_traits<HalfedgeGraph>::undirected_edge_iterator;
|
||||
\endcode
|
||||
|
||||
Valid Expressions
|
||||
--------------
|
||||
### Valid Expressions ###
|
||||
|
||||
Following the \sc{Bgl} design, the following graph operations are defined as free
|
||||
rather than member functions.
|
||||
|
|
|
|||
|
|
@ -103,30 +103,26 @@ requires a number type `ET` that provides <I>exact</I> arithmetic.
|
|||
`ApproximateMinEllipsoid_d_Traits_d`.)
|
||||
|
||||
|
||||
\tparam Traits must be a model for
|
||||
`ApproximateMinEllipsoid_d_Traits_d`.
|
||||
\tparam Traits must be a model for `ApproximateMinEllipsoid_d_Traits_d`.
|
||||
|
||||
We provide the model
|
||||
`CGAL::Approximate_min_ellipsoid_d_traits_d<K>` using the
|
||||
\f$ d\f$-dimensional \cgal kernel; the models
|
||||
`CGAL::Approximate_min_ellipsoid_d_traits_2<K>` and
|
||||
`CGAL::Approximate_min_ellipsoid_d_traits_3<K>` are for use with
|
||||
the \f$ 2\f$- and \f$ 3\f$-dimensional \cgal kernel, respectively.
|
||||
We provide the model `CGAL::Approximate_min_ellipsoid_d_traits_d<K>`
|
||||
using the \f$ d\f$-dimensional \cgal kernel; the models
|
||||
`CGAL::Approximate_min_ellipsoid_d_traits_2<K>` and
|
||||
`CGAL::Approximate_min_ellipsoid_d_traits_3<K>` are for use with the
|
||||
\f$ 2\f$- and \f$ 3\f$-dimensional \cgal kernel, respectively.
|
||||
|
||||
\sa `CGAL::Min_ellipse_2<Traits>`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
We implement Khachyian's algorithm for rounding
|
||||
polytopes \cite cgal:k-rprnm-96. Internally, we use
|
||||
`double`-arithmetic and (initially a single)
|
||||
Cholesky-decomposition. The algorithm's running time is \f$ {\cal
|
||||
O}(nd^2(\epsilon^{-1}+\ln d + \ln\ln(n)))\f$, where \f$ n=|P|\f$ and
|
||||
Cholesky-decomposition. The algorithm's running time is
|
||||
\f$ {\cal O}(nd^2(\epsilon^{-1}+\ln d + \ln\ln(n)))\f$, where \f$ n=|P|\f$ and
|
||||
\f$ 1+\epsilon\f$ is the desired approximation ratio.
|
||||
|
||||
Example
|
||||
--------------
|
||||
## Example ###
|
||||
|
||||
To illustrate the usage of `Approximate_min_ellipsoid_d` we give two examples in 2D. The
|
||||
first program generates a random set \f$ P\subset\E^2\f$ and outputs the
|
||||
|
|
|
|||
|
|
@ -50,8 +50,7 @@ two-dimensional \cgal kernel.
|
|||
\sa `CGAL::Min_circle_2_traits_2<K>`
|
||||
\sa `MinCircle2Traits`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
We implement the incremental algorithm of Welzl, with move-to-front
|
||||
heuristic \cite w-sedbe-91a. The whole implementation is described
|
||||
|
|
@ -64,8 +63,7 @@ take up to linear time, but substantially less than computing the new
|
|||
smallest enclosing circle from scratch. The clear operation and the check
|
||||
for validity each takes linear time.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
To illustrate the creation of `Min_circle_2` and to show that
|
||||
randomization can be useful in certain cases, we give an example.
|
||||
|
|
|
|||
|
|
@ -42,16 +42,14 @@ type from one the \cgal kernels. In this case, a default traits class
|
|||
\sa `MinQuadrilateralTraits_2`
|
||||
\sa `CGAL::Min_quadrilateral_default_traits_2<K>`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
We use a rotating caliper
|
||||
algorithm
|
||||
\cite stvwe-mepa-95, \cite v-fmep-90 with worst case running time linear
|
||||
in the number of input points.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following code generates a random convex polygon
|
||||
`P` with 20 vertices and computes the minimum enclosing
|
||||
|
|
@ -114,15 +112,13 @@ is `CGAL::Point_2<K>` for some kernel `K`.
|
|||
\sa `MinQuadrilateralTraits_2`
|
||||
\sa `CGAL::Min_quadrilateral_default_traits_2<K>`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
We use a rotating caliper
|
||||
algorithm \cite t-sgprc-83
|
||||
with worst case running time linear in the number of input points.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following code generates a random convex polygon
|
||||
`P` with 20 vertices and computes the minimum enclosing
|
||||
|
|
|
|||
|
|
@ -57,8 +57,7 @@ namespace CGAL {
|
|||
\sa `BoxIntersectionBox_d`
|
||||
\sa `BoxIntersectionTraits_d`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The algorithm is trivially testing all pairs and runs therefore in time
|
||||
\f$ O(nm)\f$ where \f$ n\f$ is the size of the first sequence and \f$ m\f$ is the
|
||||
|
|
@ -132,8 +131,7 @@ namespace CGAL {
|
|||
values `CGAL::Box_intersection_d::COMPLETE` and
|
||||
`CGAL::Box_intersection_d::BIPARTITE`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>`RandomAccessIterator1`, and \f$ \ldots\f$ `2`, must be
|
||||
|
|
@ -157,8 +155,7 @@ namespace CGAL {
|
|||
\sa `BoxIntersectionBox_d`
|
||||
\sa `BoxIntersectionTraits_d`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implemented algorithm is described in \cite cgal:ze-fsbi-02 as
|
||||
version two. Its performance depends on a `cutoff` parameter.
|
||||
|
|
@ -190,8 +187,7 @@ namespace CGAL {
|
|||
cutoff parameters are recommended. See also
|
||||
Section \ref secboxintersperformance .
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The box implementation provided with
|
||||
`CGAL::Box_intersection_d::Box_d<double,2>` has a special
|
||||
|
|
@ -338,8 +334,7 @@ namespace CGAL {
|
|||
concept and that the box handle, i.e., the iterators value type, is
|
||||
identical to the box type or a pointer to the box type.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>`ForwardIterator` must be a forward iterator. We call its
|
||||
|
|
@ -363,8 +358,7 @@ namespace CGAL {
|
|||
\sa `BoxIntersectionBox_d`
|
||||
\sa `BoxIntersectionTraits_d`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The algorithm is trivially testing all pairs and runs therefore in time
|
||||
\f$ O(n^2)\f$ where \f$ n\f$ is the size of the input sequence. This algorithm
|
||||
|
|
@ -463,8 +457,7 @@ namespace CGAL {
|
|||
concept and that the box handle, i.e., the iterators value type, is
|
||||
identical to the box type or a pointer to the box type.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
<UL>
|
||||
<LI>`RandomAccessIterator` must be a mutable random-access
|
||||
|
|
@ -487,14 +480,12 @@ namespace CGAL {
|
|||
\sa `BoxIntersectionBox_d`
|
||||
\sa `BoxIntersectionTraits_d`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
See the implementation section of the `CGAL::box_intersection_d`
|
||||
function on page \ref ccRef_CGALbox_intersection_d.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The box implementation provided with
|
||||
`CGAL::Box_intersection_d::Box_d<double,2>` has a special
|
||||
|
|
|
|||
|
|
@ -6,16 +6,8 @@ namespace CGAL {
|
|||
|
||||
\models ::SphericalKernel::LineArc_3
|
||||
|
||||
I/O
|
||||
--------------
|
||||
|
||||
The format for input/output is, for each line arc: a `Line_3`
|
||||
(the supporting line) and two `Circular_arc_point_3` (the two endpoints),
|
||||
under the condition that the endpoints are actually lying on the line.
|
||||
|
||||
\sa `CGAL::Circular_arc_point_3<SphericalKernel>`
|
||||
\sa `CGAL::Circular_arc_3<SphericalKernel>`
|
||||
|
||||
*/
|
||||
template< typename SphericalKernel >
|
||||
class Line_arc_3 {
|
||||
|
|
@ -100,12 +92,16 @@ Test for nonequality.
|
|||
bool operator!=(const Line_arc_3<SphericalKernel> &s1, const Line_arc_3<SphericalKernel> &s2);
|
||||
|
||||
/*!
|
||||
|
||||
The format for input/output is, for each line arc: a `Line_3`
|
||||
(the supporting line) and two `Circular_arc_point_3` (the two endpoints),
|
||||
under the condition that the endpoints are actually lying on the line.
|
||||
*/
|
||||
istream& operator>> (std::istream& is, Line_arc_3 & ca);
|
||||
|
||||
/*!
|
||||
|
||||
The format for input/output is, for each line arc: a `Line_3`
|
||||
(the supporting line) and two `Circular_arc_point_3` (the two endpoints),
|
||||
under the condition that the endpoints are actually lying on the line.
|
||||
*/
|
||||
ostream& operator<< (std::ostream& os, const Line_arc_3 & ca);
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@ namespace CGAL {
|
|||
|
||||
\models ::SphericalKernel
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Parameters ###
|
||||
|
||||
The first parameter of the spherical kernel must be instantiated with
|
||||
a model of the `Kernel` concept. The `Spherical_kernel_3`
|
||||
|
|
|
|||
|
|
@ -11,22 +11,11 @@ The plane equations of each face are not computed.
|
|||
|
||||
\pre `T.dimension()`==3.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
This function requires the following:
|
||||
<OL>
|
||||
<LI>`Triangulation_3` is a \cgal\ 3D triangulation.
|
||||
<LI>`Polyhedron_3` is an instantiation of `CGAL::Polyhedron_3<Traits>`.
|
||||
</OL>
|
||||
\requires `Triangulation_3` is a \cgal\ 3D triangulation.
|
||||
\requires `Polyhedron_3` is an instantiation of `CGAL::Polyhedron_3<Traits>`.
|
||||
|
||||
\sa `CGAL::convex_hull_3`
|
||||
|
||||
|
||||
|
||||
|
||||
*/
|
||||
|
||||
template <class Triangulation_3, class Polyhedron_3>
|
||||
void convex_hull_3_to_polyhedron_3(const Triangulation_3& T,Polyhedron_3& P);
|
||||
|
||||
|
|
|
|||
|
|
@ -1142,7 +1142,12 @@ namespace for the XML file to be processed properly. -->
|
|||
<string name="STRIP_FROM_PATH">../Point_set_processing_3/doc/Property_map</string>
|
||||
<string name="STRIP_FROM_INC_PATH">../Point_set_processing_3/doc/Property_map</string>
|
||||
<string name="GENERATE_TAGFILE">./tags/Property_map.tag</string>
|
||||
<string name="IMAGE_PATH">../Point_set_processing_3/doc/Property_map/fig</string>
|
||||
<string name="EXAMPLE_PATH">../Point_set_processing_3/examples</string>
|
||||
<list name="TAGFILES" append="true">
|
||||
<item>./tags/Point_set_processing_3.tag=../../CGAL.CGAL.Point-Set-Processing/html</item>
|
||||
<item>./tags/Surface_reconstruction_points_3.tag=../../CGAL.CGAL.Surface-Reconstruction-from-Point-Sets/html</item>
|
||||
</list>
|
||||
</doxygen>
|
||||
</project>
|
||||
|
||||
|
|
@ -1205,6 +1210,10 @@ namespace for the XML file to be processed properly. -->
|
|||
<item>../Nef_3/examples</item>
|
||||
<item>../Nef_3/demo</item>
|
||||
</list>
|
||||
<list name="TAGFILES" append="true">
|
||||
<item>./tags/Nef_S2.tag=../../CGAL.CGAL.2D-Boolean-Operations-on-Nef-Polygons-Embedded-on-the-Sphere/html</item>
|
||||
<item>./tags/Polyhedron.tag=../../CGAL.CGAL.3D-Polyhedral-Surface/html</item>
|
||||
</list>
|
||||
</doxygen>
|
||||
</project>
|
||||
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ namespace CGAL {
|
|||
from. The constructor starts Geomview either on the local either on
|
||||
a remote machine.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The constructor forks a process and establishes two pipes between the
|
||||
processes. The forked process is then overlaid with Geomview. The
|
||||
|
|
|
|||
|
|
@ -11,8 +11,7 @@ that do not contain any point of the point set.
|
|||
|
||||
The class `Largest_empty_iso_rectangle_2` expects a model of the concept `LargestEmptyIsoRectangleTraits_2` as its template argument.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The algorithm is an implementation of \cite o-naler-90. The runtime of an
|
||||
insertion or a removal is \f$ O(\log n)\f$. A query takes \f$ O(n^2)\f$ worst
|
||||
|
|
|
|||
|
|
@ -32,8 +32,7 @@ type.
|
|||
\sa `ExtremalPolygonTraits_2`
|
||||
\sa `CGAL::monotone_matrix_search`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implementation uses monotone matrix search
|
||||
\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k
|
||||
|
|
@ -95,16 +94,14 @@ where `K` is a model for `Kernel`.
|
|||
\sa `CGAL::extremal_polygon_2`
|
||||
\sa `CGAL::monotone_matrix_search`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implementation uses monotone matrix search
|
||||
\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k
|
||||
\cdot n + n \cdot \log n)\f$, where \f$ n\f$ is the number of vertices in
|
||||
\f$ P\f$.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following code generates a random convex polygon
|
||||
`p` with ten vertices and computes the maximum area inscribed
|
||||
|
|
@ -168,16 +165,14 @@ defined that computes the squareroot of a number.
|
|||
\sa `CGAL::extremal_polygon_2`
|
||||
\sa `CGAL::monotone_matrix_search`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implementation uses monotone matrix search
|
||||
\cite akmsw-gamsa-87 and has a worst case running time of \f$ O(k
|
||||
\cdot n + n \cdot \log n)\f$, where \f$ n\f$ is the number of vertices in
|
||||
\f$ P\f$.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following code generates a random convex polygon
|
||||
`p` with ten vertices and computes the maximum perimeter inscribed
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@
|
|||
It describes the linear algebra types and algorithms needed by the
|
||||
class `CGAL::Monge_via_jet_fitting`.
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
### Requirements ###
|
||||
|
||||
The scalar type, `SvdTraits::FT`, must be the same as that of
|
||||
the `LocalKernel` concept : `LocalKernel::FT`.
|
||||
|
|
|
|||
|
|
@ -12,8 +12,7 @@ must be non-zero. A point \f$ p\f$ with homogeneous coordinates \f$ (p[0],
|
|||
= \f$ Mp\f$, where `A` is an affine transformation created from `M`
|
||||
by the constructors below.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Affine Transformations are implemented by matrices of number type
|
||||
`RT` as a handle type. All operations like creation,
|
||||
|
|
|
|||
|
|
@ -13,14 +13,12 @@ which are of type `FT`. Two directions are equal if their
|
|||
Cartesian coordinates are positive multiples of each other. Directions
|
||||
are in one-to-one correspondence to points on the unit sphere.
|
||||
|
||||
Downward compatibility
|
||||
--------------
|
||||
### Downward compatibility ###
|
||||
|
||||
We provide the operations of the lower dimensional interface `dx()`,
|
||||
`dy()`, `dz()`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Directions are implemented by arrays of integers as an item type. All
|
||||
operations like creation, initialization, tests, inversion, input and
|
||||
|
|
|
|||
|
|
@ -22,8 +22,7 @@ coefficient vectors are positive multiples of each other and they are
|
|||
(weakly) equal if their coefficient vectors are multiples of each
|
||||
other.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Hyperplanes are implemented by arrays of integers as an item type.
|
||||
All operations like creation, initialization, tests, vector
|
||||
|
|
|
|||
|
|
@ -6,8 +6,7 @@ namespace CGAL {
|
|||
An instance of data type `Line_d` is an oriented line in
|
||||
\f$ d\f$-dimensional Euclidean space.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Lines are implemented by a pair of points as an item type. All
|
||||
operations like creation, initialization, tests, direction
|
||||
|
|
|
|||
|
|
@ -14,15 +14,13 @@ We call \f$ p_i\f$, \f$ 0 \leq i < d\f$ the \f$ i\f$-th Cartesian coordinate and
|
|||
\f$ h_i\f$, \f$ 0 \le i \le d\f$, the \f$ i\f$-th homogeneous coordinate. We call \f$ d\f$
|
||||
the dimension of the point.
|
||||
|
||||
Downward compatibility
|
||||
--------------
|
||||
### Downward compatibility ###
|
||||
|
||||
We provide operations of the lower
|
||||
dimensional interface `x()`, `y()`, `z()`, `hx()`,
|
||||
`hy()`, `hz()`, `hw()`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Points are implemented by arrays of `RT` items. All operations
|
||||
like creation, initialization, tests, point - vector arithmetic, input
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ An instance of data type `Ray_d` is a ray in \f$ d\f$-dimensional
|
|||
Euclidean space. It starts in a point called the source of `r` and
|
||||
it goes to infinity.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Rays are implemented by a pair of points as an item type. All
|
||||
operations like creation, initialization, tests, direction
|
||||
|
|
|
|||
|
|
@ -9,8 +9,7 @@ two points \f$ p\f$ and \f$ q\f$. \f$ p\f$ is called the source point and \f$ q\
|
|||
called the target point of \f$ s\f$, both points are called endpoints of
|
||||
\f$ s\f$. A segment whose endpoints are equal is called <I>degenerate</I>.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Segments are implemented by a pair of points as an item type. All
|
||||
operations like creation, initialization, tests, the calculation of
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@ sense and hence many operations on spheres require the set of defining
|
|||
points to be legal. The orientation of \f$ S\f$ is equal to the
|
||||
orientation of the defining points, i.e., `orientation(A)`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Spheres are implemented by a vector of points as a handle type. All
|
||||
operations like creation, initialization, tests, input and output of a
|
||||
|
|
|
|||
|
|
@ -16,15 +16,13 @@ main difference between position vectors and free vectors is their
|
|||
behavior under affine transformations, e.g., free vectors are
|
||||
invariant under translations.
|
||||
|
||||
Downward compatibility
|
||||
--------------
|
||||
### Downward compatibility ###
|
||||
|
||||
We provide all operations of the
|
||||
lower dimensional interface `x()`, `y()`, `z()`,
|
||||
`hx()`, `hy()`, `hz()`, `hw()`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
Vectors are implemented by arrays of variables of type `RT`. All
|
||||
operations like creation, initialization, tests, vector arithmetic,
|
||||
|
|
|
|||
|
|
@ -10,13 +10,9 @@ algebra for field number types `FT`.
|
|||
|
||||
\models ::LinearAlgebraTraits_d
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
\tparam FT must be a field number type.
|
||||
|
||||
`FT` must be a field number type.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
### Operations ###
|
||||
|
||||
Fits all operation requirements of the concept.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,14 +10,10 @@ algebra for Euclidean ring number types `RT`.
|
|||
|
||||
\models ::LinearAlgebraTraits_d
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
To make a ring number type `RT` work with this class it has to
|
||||
\requires To make a ring number type `RT` work with this class it has to
|
||||
provide a division `operator/` with remainder.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
### Operations ###
|
||||
|
||||
Fits all operation requirements of the concept.
|
||||
|
||||
|
|
|
|||
|
|
@ -118,8 +118,7 @@ the possible return values wrapped in `Object` are the following:
|
|||
</TABLE>
|
||||
</DIV>
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following example demonstrates the most common use of
|
||||
`intersection` routines.
|
||||
|
|
|
|||
|
|
@ -7,12 +7,6 @@ An instance of data type `Vector` is a vector of variables of
|
|||
number type `NT`. Together with the type `Matrix` it realizes
|
||||
the basic operations of linear algebra.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
|
||||
The same operations `begin()`, `end()` exist for
|
||||
`const_iterator`.
|
||||
|
||||
*/
|
||||
|
||||
class Vector {
|
||||
|
|
@ -104,6 +98,17 @@ iterator beyond the last component.
|
|||
*/
|
||||
iterator end() ;
|
||||
|
||||
/*!
|
||||
iterator to the first component.
|
||||
*/
|
||||
const_iterator begin() const;
|
||||
|
||||
/*!
|
||||
iterator beyond the last component.
|
||||
*/
|
||||
const_iterator end() const;
|
||||
|
||||
|
||||
/*!
|
||||
Addition.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@ is processed.
|
|||
\sa `Kinetic::ActiveObjectsTable`
|
||||
\sa `Kinetic::Active_objects_vector<MovingObject>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
\code{.cpp}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,7 @@ is processed.
|
|||
\sa `Kinetic::ActiveObjectsTable`
|
||||
\sa `Kinetic::Active_objects_vector<MovingObject>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
\code{.cpp}
|
||||
|
||||
|
|
|
|||
|
|
@ -21,8 +21,7 @@ vertex base.
|
|||
\sa `Kinetic::Delaunay_triangulation_3<Traits, Visitor, Triangulation>`
|
||||
\sa `Kinetic::RegularTriangulationVisitor_3`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
\cgalexample{Kinetic_regular_triangulation_3.cpp}
|
||||
|
||||
|
|
|
|||
|
|
@ -59,8 +59,7 @@ writing my own.
|
|||
|
||||
\sa `Multi_listener<Interface>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
Here is a simplier class that provides notifications:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@ the type to be reference counted as the template argument) and then
|
|||
access the object through `Handle` objects rather than bare C++
|
||||
pointers.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
### Operations ###
|
||||
|
||||
There are no methods which should be called by users of this class.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,8 +16,7 @@ time (if only a time value rather than an interval is passed).
|
|||
|
||||
\sa `Kinetic::KineticKernel`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
Here you see how to use both functions on an orientation predicate.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,8 +18,7 @@ namespace KineticConcepts {
|
|||
|
||||
\sa `Kinetic::RootEnumerator`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
We provide several models of the concept, which are not documented
|
||||
separately. The models of `Kinetic::SimulationTraits` all choose
|
||||
|
|
@ -110,8 +109,7 @@ public:
|
|||
\sa `FunctionKernel
|
||||
\sa `FunctionKernel::ConstructFunction`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
Several ways to create functions:
|
||||
|
||||
|
|
@ -230,8 +228,7 @@ public:
|
|||
|
||||
\sa `FunctionKernel`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
\code{.cpp}
|
||||
|
||||
|
|
|
|||
|
|
@ -99,8 +99,7 @@ public:
|
|||
|
||||
\sa `Kinetic::EventQueue`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
All of the kinetic data structures provided have models of
|
||||
`Event`. Here is the code implementing a swap event from the
|
||||
|
|
|
|||
|
|
@ -11,19 +11,13 @@ of a combinatorial map.
|
|||
|
||||
\models ::CellAttributeWithPoint
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
\tparam LCC must be an instantiation of `Linear_cell_complex` class,
|
||||
\tparam Info_ is the type of the information contained in the attribute, `void` for no information,
|
||||
|
||||
`LCC` must be an instantiation of `Linear_cell_complex` class,
|
||||
|
||||
`Info_` is the type of the information contained in the attribute, `void` for no information,
|
||||
|
||||
`Tag` is `Tag_true` to enable the storage of a
|
||||
`Dart_handle` of the associated cell, `Tag_false` otherwise,
|
||||
|
||||
`OnMerge` is a functor called when two attributes are merged,
|
||||
|
||||
`OnSplit` is a functor called when one attribute is split in two.
|
||||
\tparam Tag is `Tag_true` to enable the storage of a
|
||||
\tparam Dart_handle of the associated cell, `Tag_false` otherwise,
|
||||
\tparam OnMerge is a functor called when two attributes are merged,
|
||||
\tparam OnSplit is a functor called when one attribute is split in two.
|
||||
|
||||
By default, `OnMerge` and `OnSplit` are equal to
|
||||
`Null_functor`; `Tag` is equal to
|
||||
|
|
|
|||
|
|
@ -12,18 +12,12 @@ model of `CellAttributeWithPoint`.
|
|||
|
||||
\models ::CombinatorialMap
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
`d` an integer for the dimension of the combinatorial map,
|
||||
|
||||
`d2` an integer for the dimension of the ambient space,
|
||||
|
||||
`LCCTraits` must be a model of the `LinearCellComplexTraits` concept, satisfying `LCCTraits::ambiant_dimension==d2`,
|
||||
|
||||
`Items` must be a model of the `LinearCellComplexItems` concept,
|
||||
|
||||
`Alloc` has to match the standard allocator requirements.
|
||||
\tparam d an integer for the dimension of the combinatorial map,
|
||||
\tparam d2 an integer for the dimension of the ambient space,
|
||||
\tparam LCCTraits must be a model of the `LinearCellComplexTraits` concept,
|
||||
satisfying `LCCTraits::ambiant_dimension==d2`,
|
||||
\tparam Items must be a model of the `LinearCellComplexItems` concept,
|
||||
\tparam Alloc has to match the standard allocator requirements.
|
||||
|
||||
There are four default template arguments:
|
||||
`d2` is equal to `d`,
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ Objects are added in `lcc`, existing darts are not modified.
|
|||
Returns a dart created during the import.
|
||||
\pre `LCC::dimension`\f$ \geq\f$2 and `LCC::ambient_dimension`==2.
|
||||
|
||||
File format
|
||||
--------------
|
||||
### File format ###
|
||||
|
||||
The file format must be the following. First
|
||||
the number of vertices and the number of edges of the planar graph.
|
||||
|
|
|
|||
|
|
@ -11,13 +11,9 @@ this class, 0-attributes are enabled and associated with
|
|||
|
||||
\models ::LinearCellComplexItems
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
\tparam d the dimension of the combinatorial map.
|
||||
|
||||
`d` the dimension of the combinatorial map.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following example shows one implementation of the
|
||||
`Linear_cell_complex_min_items` class.
|
||||
|
|
|
|||
|
|
@ -11,12 +11,8 @@ types and functors corresponding to the given dimension.
|
|||
|
||||
\models ::LinearCellComplexTraits
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
`d` the dimension of the kernel,
|
||||
|
||||
`K` a model of the concept `Kernel` if `d==2` or
|
||||
\tparam d the dimension of the kernel,
|
||||
\tparam K a model of the concept `Kernel` if `d==2` or
|
||||
`d==3`; a model of the concept `Kernel_d` otherwise.
|
||||
|
||||
There is a default template arguments for `K` which is
|
||||
|
|
|
|||
|
|
@ -10,10 +10,7 @@ models of the `CellAttributeWithPoint` concept.
|
|||
|
||||
\refines ::CombinatorialMapItems
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
The first type in `Attributes` must be a model of the
|
||||
\requires The first type in `Attributes` must be a model of the
|
||||
`CellAttributeWithPoint` concept.
|
||||
|
||||
\hasModel `CGAL::Linear_cell_complex_min_items<d>`
|
||||
|
|
|
|||
|
|
@ -19,8 +19,7 @@ matrix search.
|
|||
\sa `MonotoneMatrixSearchTraits`
|
||||
\sa `BasicMatrix`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
All operations take constant time except for
|
||||
`extract_all_even_rows` which needs time linear in the number
|
||||
|
|
|
|||
|
|
@ -49,8 +49,7 @@ binary function: `Matrix::Value` \f$ \times\f$
|
|||
\sa `CGAL::maximum_perimeter_inscribed_k_gon_2`
|
||||
\sa `CGAL::extremal_polygon_2`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implementation uses an algorithm by Aggarwal
|
||||
et al.\cite akmsw-gamsa-87. The runtime is linear in the number
|
||||
|
|
|
|||
|
|
@ -48,8 +48,7 @@ true.
|
|||
\requires `Traits` is a model for `SortedMatrixSearchTraits`.
|
||||
\requires Value type of `RandomAccessIterator` is `Traits::Matrix`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The implementation uses an algorithm by
|
||||
Frederickson and Johnson\cite fj-fkppc-83, \cite fj-gsrsm-84 and runs in
|
||||
|
|
@ -57,8 +56,7 @@ Frederickson and Johnson\cite fj-fkppc-83, \cite fj-gsrsm-84 and runs in
|
|||
the number of input matrices, \f$ k\f$ denotes the maximal dimension of
|
||||
any input matrix and \f$ f\f$ the time needed for one feasibility test.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
In the following program we build a random vector \f$ a =
|
||||
(a_i)_{i = 1,\,\ldots,\,5}\f$ (elements drawn uniformly from \f$ \{
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@ The concept `MonotoneMatrixSearchTraits` is a refinement of
|
|||
compute the maxima for all rows of a totally monotone matrix using
|
||||
the function `monotone_matrix_search`.
|
||||
|
||||
Notes
|
||||
--------------
|
||||
### Notes ###
|
||||
|
||||
<UL>
|
||||
<LI>For the sake of efficiency (and in order to achieve the time
|
||||
|
|
|
|||
|
|
@ -24,17 +24,7 @@ namespace CGAL {
|
|||
for every item, and an incidence relation on them. Each edge and each facet
|
||||
is represented by two halfedges or two halffacets, respectively.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
\code
|
||||
template< class Nef_polyhedronTraits_3,
|
||||
class Nef_polyhedronItems_3 = CGAL::Default_items<Nef_polyhedronTraits_3>
|
||||
class Nef_polyhedronMarks = bool
|
||||
> class Nef_polyhedron_3;
|
||||
\endcode
|
||||
|
||||
</TABLE>
|
||||
### Template Parameters ###
|
||||
|
||||
The first parameter requires one of the following exact kernels:
|
||||
`Homogeneous`, `Simple_homogeneous`, `Extended_homogeneous`
|
||||
|
|
@ -59,8 +49,10 @@ namespace CGAL {
|
|||
\sa `CGAL::Polyhedron_3<Traits>`
|
||||
|
||||
*/
|
||||
template< typename Traits >
|
||||
class Nef_polyhedron_3 {
|
||||
template< class Nef_polyhedronTraits_3,
|
||||
class Nef_polyhedronItems_3 = CGAL::Default_items<Nef_polyhedronTraits_3>
|
||||
class Nef_polyhedronMarks = bool
|
||||
> class Nef_polyhedron_3 {
|
||||
public:
|
||||
|
||||
/// \name Types
|
||||
|
|
@ -90,8 +82,7 @@ public:
|
|||
`out_sedge` returns the first outgoing shalfedge, and `incident_sface`
|
||||
returns the incident sface.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `Halfedge` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed halfedges internally.
|
||||
|
|
@ -281,8 +272,7 @@ public:
|
|||
iterator range (`halffacet_cycles_begin()`/`halffacet_cycles_end()`)
|
||||
provides an entry element for each halffacet cycle of a halffacet.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `Halffacet` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed halffacets internally.
|
||||
|
|
@ -468,8 +458,7 @@ public:
|
|||
`SFace_cycle_const_iterator` and represent either a shalfedge, a shalfloop,
|
||||
or a svertex.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `SFace` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed sfaces internally.
|
||||
|
|
@ -587,8 +576,7 @@ public:
|
|||
A const circulators is provided for each of the three circular orders.
|
||||
The circulators are bidirectional and assignable to `SHalfedge_const_handle`.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `SHalfedge` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed shalfedges internally.
|
||||
|
|
@ -749,14 +737,13 @@ public:
|
|||
this shalfloop of opposite orientation.
|
||||
|
||||
\anchor figureNef3HalfloopIncidences
|
||||
\image html shalfloopB
|
||||
\image html shalfloopB.gif
|
||||
|
||||
A sphere map having a shalfloop models the neighborhood of a vertex which is
|
||||
isolated on a facet. That facet is returned by the member function
|
||||
`facet`.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `SHalfloop` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed shalfloops internally.
|
||||
|
|
@ -841,21 +828,15 @@ public:
|
|||
This is done by the member function `get_sphere_map` of
|
||||
the class `Nef_polyhedron_3`.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `Vertex` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed vertices internally.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
|
||||
`CGAL::Nef_polyhedron_3<Traits>`
|
||||
|
||||
`CGAL::Nef_polyhedron_S2<Traits>`
|
||||
\sa `CGAL::Nef_polyhedron_3<Traits>`
|
||||
\sa `CGAL::Nef_polyhedron_S2<Traits>`
|
||||
|
||||
*/
|
||||
|
||||
class Vertex {
|
||||
public:
|
||||
|
||||
|
|
@ -901,8 +882,7 @@ public:
|
|||
iterator range (`shells_begin()`/`shells_end()`). A
|
||||
`Shell_entry_iterator` is assignable to `SFace_handle`.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
### Creation ###
|
||||
|
||||
There is no need for a user to create a `Volume` explicitly. The
|
||||
class `Nef_polyhedron_3<Traits>` manages the needed volumes internally.
|
||||
|
|
|
|||
|
|
@ -164,7 +164,8 @@ forms a two-dimensional Nef polyhedron embedded in
|
|||
the sphere. We add the set-selection mark for the vertex and call the
|
||||
resulting structure the <I>sphere map</I> of the vertex.
|
||||
We use the prefix \f$ s\f$ to distinguish the elements of the sphere map
|
||||
from the three-dimensional elements. See Chapter \ref chapterNef_S2
|
||||
from the three-dimensional elements. See Chapter
|
||||
\ref Chapter_2D_Boolean_Operations_on_Nef_Polygons_Embedded_on_the_Sphere
|
||||
for further details.
|
||||
|
||||
\image html sphere_map.png
|
||||
|
|
|
|||
|
|
@ -17,4 +17,6 @@
|
|||
\example shell_exploration.cpp
|
||||
\example topological_operations.cpp
|
||||
\example transformation.cpp
|
||||
\example visualization_SM.cpp
|
||||
\example visualization_SNC.cpp
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ namespace CGAL {
|
|||
|
||||
\mainpage 2D Boolean Operations on Nef Polygons Embedded on the Sphere
|
||||
\anchor Chapter_2D_Boolean_Operations_on_Nef_Polygons_Embedded_on_the_Sphere
|
||||
\anchor chapterNefS2
|
||||
\autotoc
|
||||
|
||||
\authors Peter Hachenberger and Lutz Kettner
|
||||
|
|
|
|||
|
|
@ -20,13 +20,11 @@ type `InputIterator::value_type` is defined.
|
|||
\sa `CGAL::y_monotone_partition_2`
|
||||
\sa `CGAL::y_monotone_partition_is_valid_2`
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
This function requires \f$ O(n)\f$ time for a polygon with \f$ n\f$ vertices.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
The following program computes a \f$ y\f$-monotone partitioning
|
||||
of a polygon using the default
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ namespace CGAL {
|
|||
The class `Periodic_3_Delaunay_triangulation_3` represents a
|
||||
Delaunay triangulation in three-dimensional periodic space.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Template Parameters ###
|
||||
|
||||
The first template argument `PT` must be a model of the
|
||||
`Periodic_3DelaunayTriangulationTraits_3` concept.
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ namespace CGAL {
|
|||
The class `Periodic_triangulation_3` represents a 3-dimensional
|
||||
triangulation of a point set in \f$ \mathbb T_c^3\f$.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Template Parameters ###
|
||||
|
||||
The first template argument `PT` must be a model of the
|
||||
`Periodic_3DelaunayTriangulationTraits_3` concept.
|
||||
|
|
@ -19,14 +18,12 @@ functionality in cells and vertices.
|
|||
Its default value is
|
||||
`Triangulation_data_structure_3<Triangulation_vertex_base_3<PT,Periodic_3_triangulation_ds_vertex_base_3<>>,Triangulation_cell_base_3<PT,Periodic_3_triangulation_ds_cell_base_3<>>>`.
|
||||
|
||||
Traversal of the Triangulation
|
||||
--------------
|
||||
### Traversal of the Triangulation ###
|
||||
|
||||
The periodic triangulation class provides several iterators and circulators
|
||||
that allow one to traverse it.
|
||||
|
||||
\sa `Periodic_3_Delaunay_triangulation_3`
|
||||
|
||||
*/
|
||||
template< typename PT, typename TDS >
|
||||
class Periodic_3_triangulation_3 {
|
||||
|
|
|
|||
|
|
@ -8,8 +8,7 @@ The class `Periodic_3_triangulation_hierarchy_3` implements a
|
|||
triangulation augmented with a data structure which allows fast point
|
||||
location queries.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Template Parameters ###
|
||||
|
||||
It is templated by a parameter which must be instantiated by one of the \cgal periodic triangulation classes. <I>In the current
|
||||
implementation, only `Periodic_3_Delaunay_triangulation_3` is
|
||||
|
|
@ -34,8 +33,7 @@ hierarchy into a file will lose the hierarchic structure and reading
|
|||
it from the file will result in an ordinary triangulation whose
|
||||
efficiency will be the same as `PTr`.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
### Implementation ###
|
||||
|
||||
The data structure is a hierarchy of triangulations. The triangulation
|
||||
at the lowest level is the original triangulation where operations and
|
||||
|
|
|
|||
|
|
@ -1,43 +0,0 @@
|
|||
|
||||
\authors Manuel Caroli and Monique Teillaud
|
||||
|
||||
|
||||
# Classified Reference Pages #
|
||||
|
||||
## Concepts ##
|
||||
|
||||
`Periodic_3DelaunayTriangulationTraits_3`
|
||||
|
||||
`TriangulationDataStructure_3`
|
||||
|
||||
`Periodic_3TriangulationDSCellBase_3`
|
||||
|
||||
`Periodic_3TriangulationDSVertexBase_3`
|
||||
|
||||
`Periodic_3Offset_3`
|
||||
|
||||
## Classes ##
|
||||
|
||||
## Main Classes ##
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_3<PT,TDS>
|
||||
|
||||
\ref ::CGAL::Periodic_3_Delaunay_triangulation_3<PT,TDS>
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_hierarchy_3<PTr>
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_ds_cell_base_3<>
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_ds_vertex_base_3<>
|
||||
|
||||
\ref ::CGAL::Periodic_3_offset_3
|
||||
|
||||
## Traits Classes ##
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_traits_3<Traits,Periodic_3Offset_3>
|
||||
|
||||
## Enums ##
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_3::Iterator_type
|
||||
|
||||
\ref ::CGAL::Periodic_3_triangulation_3::Locate_type
|
||||
|
|
@ -7,18 +7,9 @@ namespace CGAL {
|
|||
Property map that converts a `T*` pointer (or in general an iterator
|
||||
over `T` elements) to the `T` object.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
\code
|
||||
template<typename T>
|
||||
struct Dereference_property_map;
|
||||
\endcode
|
||||
|
||||
\models `boost::LvaluePropertyMap`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
See \ref property_map.cpp example.
|
||||
|
||||
|
|
@ -81,11 +72,7 @@ public:
|
|||
|
||||
Access a property map element.
|
||||
|
||||
Template Parameters
|
||||
--------------
|
||||
|
||||
`Iter`: Type convertible to `key_type`.
|
||||
|
||||
\tparam Iter Type convertible to `key_type`.
|
||||
*/
|
||||
template<class Iter> reference operator[](Iter it) const;
|
||||
|
||||
|
|
@ -108,27 +95,13 @@ Dereference_property_map<typename value_type_traits<Iter>::type> make_dereferenc
|
|||
|
||||
Property map that accesses the first item of a `std::pair`.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
template\f$ <\f$typename Pair\f$ >\f$
|
||||
|
||||
struct `First_of_pair_property_map`;
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
`Pair`: Instance of `std::pair`.
|
||||
|
||||
Inherits From
|
||||
--------------
|
||||
\tparam Pair Instance of `std::pair`.
|
||||
|
||||
\models `boost::LvaluePropertyMap`
|
||||
|
||||
\sa `CGAL::Second_of_pair_property_map<Pair>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
See `property_map.cpp` example.
|
||||
|
||||
|
|
@ -191,10 +164,7 @@ public:
|
|||
|
||||
Access a property map element.
|
||||
|
||||
Template Parameters
|
||||
--------------
|
||||
|
||||
`Iter`: Type convertible to `key_type`.
|
||||
\tparam Iter Type convertible to `key_type`.
|
||||
|
||||
*/
|
||||
template<class Iter> reference operator[](Iter pair) const;
|
||||
|
|
@ -216,22 +186,12 @@ First_of_pair_property_map<typename value_type_traits<Iter>::type> make_first_of
|
|||
|
||||
Property map that accesses the Nth item of a `boost::tuple`.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
template\f$ <\f$int N, typename Tuple\f$ >\f$
|
||||
|
||||
struct `Nth_of_tuple_property_map`;
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
`N`: Index of the item to access. `Tuple`: Instance of `boost::tuple`.
|
||||
\tparam N Index of the item to access.
|
||||
\tparam Tuple Instance of `boost::tuple`.
|
||||
|
||||
\models `boost::LvaluePropertyMap`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
See `property_map.cpp` example.
|
||||
|
||||
|
|
@ -293,10 +253,7 @@ public:
|
|||
|
||||
Access a property map element.
|
||||
|
||||
Template Parameters
|
||||
--------------
|
||||
|
||||
`Iter`: Type convertible to `key_type`.
|
||||
\tparam Iter Type convertible to `key_type`.
|
||||
|
||||
*/
|
||||
template<class Iter> reference operator[](Iter tuple) const;
|
||||
|
|
@ -320,24 +277,13 @@ Nth_of_tuple_property_map<N, typename value_type_traits<Iter>::type> make_nth_of
|
|||
|
||||
Property map that accesses the second item of a `std::pair`.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
template\f$ <\f$typename Pair\f$ >\f$
|
||||
|
||||
struct `Second_of_pair_property_map`;
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
|
||||
`Pair`: Instance of `std::pair`.
|
||||
\tparam Pair Instance of `std::pair`.
|
||||
|
||||
\models `boost::LvaluePropertyMap`
|
||||
|
||||
\sa `CGAL::First_of_pair_property_map<Pair>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
See `property_map.cpp` example.
|
||||
|
||||
|
|
@ -399,10 +345,7 @@ public:
|
|||
/*!
|
||||
Access a property map element.
|
||||
|
||||
Template Parameters
|
||||
--------------
|
||||
|
||||
`Iter`: Type convertible to `key_type`.
|
||||
\tparam Iter Type convertible to `key_type`.
|
||||
|
||||
*/
|
||||
template<class Iter> reference operator[](Iter pair) const;
|
||||
|
|
|
|||
|
|
@ -2,4 +2,5 @@
|
|||
\example remove_outliers_example.cpp
|
||||
\example read_write_xyz_point_set_example.cpp
|
||||
\example average_spacing_example.cpp
|
||||
\example property_map.cpp
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -33,12 +33,9 @@ comes in <I>dense</I> representation which includes zero entries.
|
|||
\hasModel Quadratic_program_from_mps<NT>
|
||||
\hasModel Nonnegative_linear_program_from_iterators<A_it, B_it, R_it, FL_it, L_it, FU_it, U_it, D_it, C_it>
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
The value types of all iterator types (nested iterator types,
|
||||
respectively, for `A_iterator`) must be convertible to some common
|
||||
`IntegralDomain` `ET`.
|
||||
\requires The value types of all iterator types (nested iterator
|
||||
types, respectively, for `A_iterator`) must be convertible to some
|
||||
common `IntegralDomain` `ET`.
|
||||
|
||||
The models
|
||||
\hasModel `CGAL::Quadratic_program<NT>`
|
||||
|
|
|
|||
|
|
@ -37,12 +37,9 @@ comes in <I>dense</I> representation which includes zero entries.
|
|||
\hasModel `CGAL::Quadratic_program_from_mps<NT>`
|
||||
\hasModel `CGAL::Nonnegative_quadratic_program_from_iterators<A_it, B_it, R_it, FL_it, L_it, FU_it, U_it, D_it, C_it>`
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
The value types of all iterator types (nested iterator types,
|
||||
respectively, for `A_iterator` and `D_iterator`) must be
|
||||
convertible to some common `IntegralDomain` `ET`.
|
||||
\requires The value types of all iterator types (nested iterator
|
||||
types, respectively, for `A_iterator` and `D_iterator`) must be
|
||||
convertible to some common `IntegralDomain` `ET`.
|
||||
|
||||
|
||||
\sa `QuadraticProgram`
|
||||
|
|
|
|||
|
|
@ -37,19 +37,15 @@ comes in <I>dense</I> representation which includes zero entries.
|
|||
\hasModel `CGAL::Quadratic_program_from_mps<NT>`
|
||||
\hasModel `CGAL::Quadratic_program_from_iterators<A_it, B_it, R_it, FL_it, L_it, FU_it, U_it, D_it, C_it>`
|
||||
|
||||
Requirements
|
||||
--------------
|
||||
|
||||
The value types of all iterator types (nested iterator types,
|
||||
respectively, for `A_iterator` and `D_iterator`) must be
|
||||
convertible to some common `IntegralDomain` `ET`.
|
||||
\requires The value types of all iterator types (nested iterator
|
||||
types, respectively, for `A_iterator` and `D_iterator`) must be
|
||||
convertible to some common `IntegralDomain` `ET`.
|
||||
|
||||
\sa `NonnegativeQuadraticProgramInterface`
|
||||
\sa `LinearProgramInterface`
|
||||
\sa `NonnegativeLinearProgramInterface`
|
||||
|
||||
*/
|
||||
|
||||
class QuadraticProgram {
|
||||
public:
|
||||
|
||||
|
|
|
|||
|
|
@ -120,8 +120,7 @@ namespace CGAL {
|
|||
The class `Ridge_approximation` computes the approximation of
|
||||
ridges of a triangular polyhedral surface.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Template Parameters ###
|
||||
|
||||
The class `Ridge_approximation` has three template parameters.
|
||||
`TriangulatedSurfaceMesh` provides the surface.
|
||||
|
|
|
|||
|
|
@ -40,8 +40,7 @@ namespace CGAL {
|
|||
The class `Umbilic_approximation` computes the approximation of
|
||||
umbilics on a triangular polyhedral surface.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Template Parameters ###
|
||||
|
||||
The class `Umbilic_approximation` has three template parameters.
|
||||
`TriangulatedSurfaceMesh` provides the surface. Parameters
|
||||
|
|
@ -114,10 +113,9 @@ namespace CGAL {
|
|||
|
||||
The class `Umbilic` stores the description of an umbilic.
|
||||
|
||||
Operations
|
||||
--------------
|
||||
### Operations ###
|
||||
|
||||
The usual insert operator (\f$ <<\f$) is overloaded for `Umbilic`, it
|
||||
The usual insert operator (\f$<<\f$) is overloaded for `Umbilic`, it
|
||||
gives the location (3d coordinates of the vertex) and the type.
|
||||
|
||||
\sa `Umbilic_approximation`
|
||||
|
|
|
|||
|
|
@ -8,15 +8,12 @@ boundary) embedded in the 3 space. It is combinatorially based on a
|
|||
halfedge data structure with triangular faces, geometrically 3d points
|
||||
associated to the vertices define the embedding.
|
||||
|
||||
Creation
|
||||
--------------
|
||||
|
||||
Construction and destruction are undefined.
|
||||
|
||||
\hasModel `CGAL::Polyhedron_3` with the restriction that faces are triangular.
|
||||
|
||||
*/
|
||||
### Creation ###
|
||||
|
||||
Construction and destruction are undefined.
|
||||
*/
|
||||
class TriangulatedSurfaceMesh {
|
||||
public:
|
||||
|
||||
|
|
|
|||
|
|
@ -257,8 +257,7 @@ Let `os` be an output stream.
|
|||
\sa `CGAL::is_pretty`
|
||||
\sa `CGAL::operator>>`
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
|
||||
\code{.cpp}
|
||||
#include <CGAL/basic.h>
|
||||
|
|
@ -299,8 +298,7 @@ from the class `istream`. This allows to read from istreams
|
|||
as `cin`, as well as from strstreams and fstreams.
|
||||
The input operator is defined for all classes in the \cgal kernel.
|
||||
|
||||
Example
|
||||
--------------
|
||||
### Example ###
|
||||
\code{.cpp}
|
||||
#include <CGAL/basic.h>
|
||||
#include <iostream>
|
||||
|
|
|
|||
|
|
@ -10,8 +10,7 @@ approximating a surface.
|
|||
The library provides two overloaded version
|
||||
of this function:
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Parameters ###
|
||||
|
||||
The template parameter `SurfaceMeshC2T3`
|
||||
is required to be a model of the concept
|
||||
|
|
@ -144,8 +143,7 @@ approximating a surface.
|
|||
The library provides two overloaded version
|
||||
of this function:
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Parameters ###
|
||||
|
||||
The template parameter `SurfaceMeshC2T3`
|
||||
is required to be a model of the concept
|
||||
|
|
|
|||
|
|
@ -30,24 +30,18 @@ be instantiated by a model of the `Kernel` concept.
|
|||
`Triangulation_euclidean_traits_xy_3` uses types
|
||||
and predicates defined in `K`.
|
||||
|
||||
### Access to Predicate Objects ###
|
||||
\sa `TriangulationTraits_2`
|
||||
\sa `DelaunayTriangulationTraits_2`
|
||||
\sa `CGAL::Triangulation_2<Traits,Tds>`
|
||||
\sa `CGAL::Delaunay_triangulation_2<Traits,Tds>`
|
||||
|
||||
The following access functions are provided
|
||||
\cgal provides also predefined geometric traits class
|
||||
`Triangulation_euclidean_traits_yz_3<K>` and
|
||||
`Triangulation_euclidean_traits_xz_3<K>` to deal with projections on
|
||||
the `xz`- or the `yz`-plane, respectively.
|
||||
|
||||
`TriangulationTraits_2`
|
||||
|
||||
`DelaunayTriangulationTraits_2`
|
||||
|
||||
`CGAL::Triangulation_2<Traits,Tds>`
|
||||
|
||||
`CGAL::Delaunay_triangulation_2<Traits,Tds>`
|
||||
|
||||
\cgal provides also predefined geometric traits class
|
||||
`Triangulation_euclidean_traits_yz_3<K>` and
|
||||
`Triangulation_euclidean_traits_xz_3<K>` to
|
||||
deal with projections on the
|
||||
`xz`- or the `yz`-plane,
|
||||
respectively.
|
||||
\sa \ref CGAL/Triangulation_euclidean_traits_xz_3.h
|
||||
\sa \ref CGAL/Triangulation_euclidean_traits_yz_3.h
|
||||
|
||||
*/
|
||||
template< typename K >
|
||||
|
|
@ -224,6 +218,7 @@ Triangulation_euclidean_traits_xy_3 operator=
|
|||
/// @}
|
||||
|
||||
/// \name Access to predicate objects
|
||||
/// The following access functions are provided
|
||||
/// @{
|
||||
|
||||
/*!
|
||||
|
|
@ -275,9 +270,6 @@ Intersect_2 intersect_2_object();
|
|||
|
||||
/*!
|
||||
|
||||
See Also
|
||||
--------------
|
||||
|
||||
*/
|
||||
Compute_squared_distance_2 compute_squared_distance_2_object();
|
||||
|
||||
|
|
|
|||
|
|
@ -15,8 +15,7 @@ constraints.
|
|||
|
||||
\refines ::TriangulationFaceBase_2
|
||||
|
||||
Types
|
||||
--------------
|
||||
### Types ###
|
||||
|
||||
Defines the same types as the `TriangulationFaceBase_2` concept
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,7 @@ implemented using `CGAL::Compact_container`. The class may offer some
|
|||
flexibility for the choice of container in the future, in the form of
|
||||
additional template parameters.
|
||||
|
||||
Parameters
|
||||
--------------
|
||||
### Parameters ###
|
||||
|
||||
It is parameterized by base classes for vertices and cells which have to match
|
||||
the requirements for the concepts `TriangulationDSCellBase_3` and
|
||||
|
|
|
|||
Loading…
Reference in New Issue