songsenand
/
cgal
mirror of https://github.com/CGAL/cgal
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

No need for CGAL:: in user manuals

This commit is contained in:
Andreas Fabri 2012-10-31 20:11:16 +00:00
parent eefa062960
commit 7a6634b5a7
31 changed files with 254 additions and 256 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt
View File

@ -190,19 +190,19 @@ functions or just via implicit constructor calls.
This level of interoperability is reflected by the concept
`ImplicitInteroperable`. However, within template code the result type,
or so called coercion type, of a mixed arithmetic operation may be unclear.
Therefore, the package introduces `CGAL::Coercion_traits`
giving access to the coercion type via `CGAL::Coercion_traits<A,B>::Type`
Therefore, the package introduces `Coercion_traits`
giving access to the coercion type via `Coercion_traits<A,B>::Type`
for two interoperable types `A` and `B`.
Some trivial example are `int` and `double` with coercion type double
or `CGAL::Gmpz` and `CGAL::Gmpq` with coercion type `CGAL::Gmpq`.
or `Gmpz` and `Gmpq` with coercion type `Gmpq`.
However, the coercion type is not necessarily one of the input types,
e.g. the coercion type of a polynomial
with integer coefficients that is multiplied by a rational type
is supposed to be a polynomial with rational coefficients.
`CGAL::Coercion_traits` is also
required to provide a functor `CGAL::Coercion_traits<A,B>::Cast()`, that
`Coercion_traits` is also
required to provide a functor `Coercion_traits<A,B>::Cast()`, that
converts from an input type into the coercion type. This is in fact the core
of the more basic concept `ExplicitInteroperable`.
`ExplicitInteroperable` has been introduced to cover more complex cases
@ -242,11 +242,11 @@ denominator and a compound numerator with a simpler coefficient type
(e.g. integer instead of rational). Often operations can be performed faster on
these denominator-free multiples. In case a type is a `Fraction`
the relevant functionality as well as the numerator and denominator
type are provided by `CGAL::Fraction_traits`. In particular
`CGAL::Fraction_traits` provides a tag `Is_fraction` that can be
type are provided by `Fraction_traits`. In particular
`Fraction_traits` provides a tag `Is_fraction` that can be
used for dispatching.
A related class is `CGAL::Rational_traits` which has been kept for backward
A related class is `Rational_traits` which has been kept for backward
compatibility reasons. However, we recommend to use `Fraction_traits` since
it is more general and offers dispatching functionality.

32
Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt
View File

@ -103,7 +103,7 @@ First of all the type `AlgebraicKernel_d_1::Polynomial_1` is required
to be a model of the concept `Polynomial_1`, which is defined
in the Polynomial package (see chapter \ref Chapter_Polynomial).
This implies that all essential functionality is provided via
`CGAL::Polynomial_traits_d`. However, the algebraic kernel also
`Polynomial_traits_d`. However, the algebraic kernel also
provides several function objects to handle polynomials:
`AlgebraicKernel_d_1::Is_square_free_1` - determines whether a polynomial is square free,
@ -122,7 +122,7 @@ allows for instance internal caching by the kernel.
Also note that `AlgebraicKernel_d_1::Square_free_factorize_1` only computes the square free
factorization up to a constant factor. This is a slight modification with respect to its
counterpart in `CGAL::Polynomial_traits_d`. In this way it was possible that the concepts just require
counterpart in `Polynomial_traits_d`. In this way it was possible that the concepts just require
the coefficient type to be a model of `IntegralDomain`, instead of `Field` or `UniqueFactorizationDomain`.
For more details see also:
@ -239,13 +239,13 @@ additional functors that may allow a model to bypass this issue:
## Generic Algebraic Kernels ##
The package provides generic models of the univariate and bivariate algebraic
kernel, namely `CGAL::Algebraic_kernel_d_1<Coeff>` and `CGAL::Algebraic_kernel_d_2<Coeff>`,
kernel, namely `Algebraic_kernel_d_1<Coeff>` and `Algebraic_kernel_d_2<Coeff>`,
respectively. Both kernels support a large set of number types as their
template argument, which defines the supported coefficient type. The supported
types are, for instance, `CGAL::Gmpz` and `CGAL::Gmpq` as well as the corresponding types
types are, for instance, `Gmpz` and `Gmpq` as well as the corresponding types
of LEDA and CORE.
The `CGAL::Algebraic_kernel_d_1<Coeff>` represents an algebraic real root by a square
The `Algebraic_kernel_d_1<Coeff>` represents an algebraic real root by a square
free polynomial and an isolating interval that uniquely defines the root.
The current method to isolate roots is the Bitstream Descartes
method \cite eigenwillig-phd-08.
@ -253,7 +253,7 @@ The used method to refine the approximation of an algebraic real root is a
slightly modified (filtered) version of the one presented in \cite abbott-qir-06.
The method has quadratic convergence.
`CGAL::Algebraic_kernel_d_2<Coeff>` is based on an algorithm computing a
`Algebraic_kernel_d_2<Coeff>` is based on an algorithm computing a
geometric-topological analysis of a single curve \cite ekw-fast-07 and of a
pair of curves \cite ek-exact-08.
The main idea behind both analyses is to compute the critical
@ -286,19 +286,19 @@ time-consuming step, and should be avoided for efficiency reasons if possible.
## Algebraic Kernels Based on RS ##
The package offers two univariate algebraic kernels that are based on
the library RS \cite cgal:r-rs, namely `CGAL::Algebraic_kernel_rs_gmpz_d_1`
and `CGAL::Algebraic_kernel_rs_gmpq_d_1`. As the names indicate,
the library RS \cite cgal:r-rs, namely `Algebraic_kernel_rs_gmpz_d_1`
and `Algebraic_kernel_rs_gmpq_d_1`. As the names indicate,
the kernels are based on the library RS \cite cgal:r-rs and support univariate
polynomials over `CGAL::Gmpz` or `CGAL::Gmpq`, respectively.
polynomials over `Gmpz` or `Gmpq`, respectively.
In general we encourage to use `CGAL::Algebraic_kernel_rs_gmpz_d_1`
instead of `CGAL::Algebraic_kernel_rs_gmpq_d_1`. This is caused by
In general we encourage to use `Algebraic_kernel_rs_gmpz_d_1`
instead of `Algebraic_kernel_rs_gmpq_d_1`. This is caused by
the fact that the most efficient way to compute operations (such as gcd)
on polynomials with rational coefficients is to use the corresponding
implementation for polynomials with integer coefficients. That is,
the `CGAL::Algebraic_kernel_rs_gmpq_d_1` is slightly slower due to
the `Algebraic_kernel_rs_gmpq_d_1` is slightly slower due to
overhead caused by the necessary conversions. However, since this may
not always be a major issue, the `CGAL::Algebraic_kernel_rs_gmpq_d_1`
not always be a major issue, the `Algebraic_kernel_rs_gmpq_d_1`
is provided for convenience.
The core of both kernels is the implementation of the interval Descartes
@ -311,9 +311,9 @@ interfaces between layers. Specifically, working with
only one number type allows to optimize some polynomial operations
as well as memory handling. The implementation of these kernels
make heavy use of the <span class="textsc">Mpfr</span> \cite cgal:mt-mpfr and <span class="textsc">Mpfi</span> \cite cgal:r-mpfi
libraries, and of their \cgal interfaces, `CGAL::Gmpfr` and `CGAL::Gmpfi`.
libraries, and of their \cgal interfaces, `Gmpfr` and `Gmpfi`.
The algebraic numbers (roots of the polynomials) are represented
in the two RS kernels by a `CGAL::Gmpfi` interval and a pointer to
in the two RS kernels by a `Gmpfi` interval and a pointer to
the polynomial of which they are roots. See \cite cgal:lpt-wea-09
for more details on the implementation, tests of these kernels,
comparisons with other algebraic kernels and discussions about the
@ -371,7 +371,7 @@ initial contributions.
The two generic models where initially developed as part of the <span class="textsc">Exacus</span> \cite beh+-eeeafcs-05 project.
However, the models are now fully integrated into the \cgal library,
since also the relevant layers of <span class="textsc">Exacus</span> are now part of \cgal.
The main authors for `CGAL::Algebraic_kernel_d_1<Coeff>` and `CGAL::Algebraic_kernel_d_2<Coeff>` are
The main authors for `Algebraic_kernel_d_1<Coeff>` and `Algebraic_kernel_d_2<Coeff>` are
Michael Hemmer and Michael Kerber, respectively. Notwithstanding, the authors also want to emphasize the
contribution of all authors of the <span class="textsc">Exacus</span> project,
particularly the contribution of Arno Eigenwillig, Sebastian Limbach and Pavel Emeliyanenko.

20
Apollonius_graph_2/doc/Apollonius_graph_2/Apollonius_graph_2.txt
View File

@ -286,7 +286,7 @@ not.
\image html apollonius-vertex_conflict-false.gif
\image html apollonius-vertex_conflict-true.gif
<center><b>
The `Vertex_conflict_2` predicate. The left-most, bottom-most and top-most circles define the tritangent circle in the middle. We want to determine the sign of the distance of the left-most circle from the one in the middle. The almost horizontal curve is the bisector of the top-most and bottom-most circles. Left: the predicate returns `CGAL::NEGATIVE`. Right: the predicate returns `CGAL::POSITIVE`.
The `Vertex_conflict_2` predicate. The left-most, bottom-most and top-most circles define the tritangent circle in the middle. We want to determine the sign of the distance of the left-most circle from the one in the middle. The almost horizontal curve is the bisector of the top-most and bottom-most circles. Left: the predicate returns `NEGATIVE`. Right: the predicate returns `POSITIVE`.
</b></center>
What we essentially want to compute when we construct incrementally a
@ -370,31 +370,31 @@ concept. The second template parameter is a tag that indicates what
operations are allowed in the computations that take place within the
traits class.
The two possible values of the `Method_tag` parameter are
`CGAL::Ring_tag` and `CGAL::Sqrt_field_tag`. When
`CGAL::Ring_tag` is used, only ring operations are used during the
evaluation of the predicates, whereas if `CGAL::Sqrt_field_tag` is
`Ring_tag` and `Sqrt_field_tag`. When
`Ring_tag` is used, only ring operations are used during the
evaluation of the predicates, whereas if `Sqrt_field_tag` is
chosen, all four field operations, as well as square roots, are used
during the predicate evaluation.
The `Apollonius_graph_traits_2<K,Method_tag>` class provides exact
predicates if the number type in the kernel `K` is an exact number
type. This is to be associated with the type of operations allowed for
the predicate evaluation. For example `CGAL::MP_Float` as number
type, with `CGAL::Ring_tag` as tag will give exact predicates,
whereas `CGAL::MP_Float` with `CGAL::Sqrt_field_tag` will give
the predicate evaluation. For example `MP_Float` as number
type, with `Ring_tag` as tag will give exact predicates,
whereas `MP_Float` with `Sqrt_field_tag` will give
inexact predicates.
Since using an exact number type may be too slow, the
`Apollonius_graph_traits_2<K,Method_tag>` class is designed to
support the dynamic filtering of \cgal through the
`CGAL::Filtered_exact<CT,ET>` mechanism. In particular if `CT`
`Filtered_exact<CT,ET>` mechanism. In particular if `CT`
is an inexact number type that supports the operations denoted by the
tag `Method_tag` and `ET` is an exact number type for these
operations, then kernel with number type
`CGAL::Filtered_exact<CT,ET>` will yield exact predicates for the
`Filtered_exact<CT,ET>` will yield exact predicates for the
Apollonius graph traits. To give a concrete example,
`CGAL::Filtered_exact<double,CGAL::MP_Float>` with
`CGAL::Ring_tag` will produce exact predicates.
`Ring_tag` will produce exact predicates.
Another possibility for fast and exact predicate evaluation is to use
the

6
Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt
View File

@ -811,8 +811,8 @@ file `point_location_utils.h`, accepts a point-location object
(whose type can be any of the models to the
`ArrangementPointLocation_2` concept) and a query point, and
prints out the result of the point-location query for the given
point. Observe how we use the function `CGAL::assign()` is order
to cast the resulting `CGAL::Object` into a handle to an arrangement
point. Observe how we use the function `assign()` is order
to cast the resulting `Object` into a handle to an arrangement
feature. The point-location object `pl` is assumed to be already
associated with an arrangement:
@ -2600,7 +2600,7 @@ algebraic curves).
The template argument `Coefficient` determines
the type of the scalar coefficients of the polynomial.
Currently supported types are `leda_integer`, `CORE::BigInt`,
and any instance of `CGAL::Sqrt_extension<A,B>`
and any instance of `Sqrt_extension<A,B>`
instantiated with one of the integral types above.
The traits class defines a type `Curve_2` for algebraic curves.

18
Bounding_volumes/doc/Bounding_volumes/Bounding_volumes.txt
View File

@ -18,7 +18,7 @@ then we obtain the smallest enclosing sphere problem already mentioned
above.
In the following example a smallest enclosing circle
(`CGAL::Min_circle_2<Traits>`) is constructed from points
(`Min_circle_2<Traits>`) is constructed from points
on a line and written to standard output. The example
shows that it is advisable to switch on random shuffling
in order to deal with a <i>bad</i> order of the input points.
@ -26,16 +26,16 @@ in order to deal with a <i>bad</i> order of the input points.
\cgalexample{Min_circle_2/min_circle_2.cpp}
Other classes for which we provide solutions are ellipses
(`CGAL::Min_ellipse_2<Traits>`), rectangles
(`CGAL::min_rectangle_2`), parallelograms
(`CGAL::min_parallelogram_2`) and strips (`CGAL::min_strip_2`)
(`Min_ellipse_2<Traits>`), rectangles
(`min_rectangle_2()`), parallelograms
(`min_parallelogram_2()`) and strips (`min_strip_2()`)
in the plane, with appropriate optimality criteria. For arbitrary
dimensions we provide smallest enclosing spheres for points
(`CGAL::Min_sphere_d<Traits>`) and spheres for spheres
(`CGAL::Min_sphere_of_spheres_d<Traits>`), smallest enclosing
annuli (`CGAL::Min_annulus_d<Traits>`), and approximate
(`Min_sphere_d<Traits>`) and spheres for spheres
(`Min_sphere_of_spheres_d<Traits>`), smallest enclosing
annuli (`Min_annulus_d<Traits>`), and approximate
minimum-volume enclosing ellipsoid with user-specified
approximation ratio (`CGAL::Approximate_min_ellipsoid_d<Traits>`).
approximation ratio (`Approximate_min_ellipsoid_d<Traits>`).
\image html annulus.gif
@ -75,7 +75,7 @@ more advanced bounding volumes might give better results in some
cases. It can also make sense to consider several center points
instead of just one. For example, we provide algorithms to cover a
planar point set with between two and four minimal boxes
(`CGAL::rectangular_p_center_2`). Below is an example covering with
(`rectangular_p_center_2()`). Below is an example covering with
three boxes; the center points are shown in red.
\image html pcenter.gif

20
Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt
View File

@ -53,8 +53,8 @@ interpretation when comparing boxes, which is selected with the two
possible values for the `topology` parameter:
<UL>
<LI>`CGAL::Box_intersection_d::HALF_OPEN` and
<LI>`CGAL::Box_intersection_d::CLOSED`.
<LI>`Box_intersection_d::HALF_OPEN` and
<LI>`Box_intersection_d::CLOSED`.
</UL>
The number type of the interval boundaries must be one of the built-in
@ -132,8 +132,8 @@ to the box type (see the previous paragraph for the value versus
pointer nature of the box handle).
Two implementations of iso-oriented boxes are provided;
`CGAL::Box_intersection_d::Box_d` as a plain box, and
`CGAL::Box_intersection_d::Box_with_handle_d` as a box plus a
`Box_intersection_d::Box_d` as a plain box, and
`Box_intersection_d::Box_with_handle_d` as a box plus a
handle that can be used to point to the full geometry that is
approximated by the box. Both implementations have template parameters
for the number type used for the interval bounds, for the fixed
@ -170,8 +170,8 @@ void box_intersection_d(RandomAccessIterator1 begin1, RandomAccessIterator1 end1
\section secboxintersectminimal Minimal Example for Intersecting Boxes
The box implementation provided with
`CGAL::Box_intersection_d::Box_d<double,2>` has a dedicated
constructor for the \cgal bounding box type `CGAL::Bbox_2`
`Box_intersection_d::Box_d<double,2>` has a dedicated
constructor for the \cgal bounding box type `Bbox_2`
(similar for dimension 3). We use this in our minimal example to
create easily nine two-dimensional `boxes` in a grid layout of \f$ 3
\times 3\f$ boxes. Additionally we pick the center box and the box in
@ -204,7 +204,7 @@ triangles in a vector called `triangles`.
Next we create a vector for the bounding boxes of the triangles called
`boxes`. For the boxes we choose the type
`Box_with_handle_d<double,3,Iterator>` that works nicely together
with the \cgal bounding boxes of type `CGAL::Bbox_3`. In
with the \cgal bounding boxes of type `Bbox_3`. In
addition, each box stores the iterator to the corresponding triangle.
The default policy of this box type uses for the `id`-number the
@ -283,7 +283,7 @@ version above that copies the boxes becomes 300% faster.
Note that switching to the built-in type `float` is supported by
the box intersection algorithm, but the interfacing with the \cgal
bounding box `CGAL::Bbox_3` would not be that easy. In particular,
bounding box `Bbox_3` would not be that easy. In particular,
just converting from the `double` to the `float`
representation incurs rounding that needs to be controlled properly,
otherwise the box might shrink and one might miss intersections.
@ -299,8 +299,8 @@ closed or half-open boxes is selected with the `topology`
parameter and its two values:
<UL>
<LI>`CGAL::Box_intersection_d::HALF_OPEN` and
<LI>`CGAL::Box_intersection_d::CLOSED`.
<LI>`Box_intersection_d::HALF_OPEN` and
<LI>`Box_intersection_d::CLOSED`.
</UL>
The example program uses a two-dimensional box with `int`

10
CGAL_ipelets/doc/CGAL_ipelets/CGAL_ipelets.txt
View File

@ -24,13 +24,13 @@ of ipelets: alpha-shape, arrangements, Voronoi diagrams, convex hulls, Hilbert c
\section seccgal_ipelets CGAL Ipelets
The class `CGAL::Ipelet_base` derives from the class `Ipelets` from Ipe
The class `Ipelet_base` derives from the class `Ipelets` from Ipe
and has one template parameter indicating
which kernel must be used within the ipelet.
In practice, we recommend to use either `CGAL::Exact_predicates_exact_constructions_kernel`
or `CGAL::Exact_predicates_inexact_constructions_kernel`.
In practice, we recommend to use either `Exact_predicates_exact_constructions_kernel`
or `Exact_predicates_inexact_constructions_kernel`.
Two main methods are provided by the `CGAL::Ipelet_base` class.
Two main methods are provided by the `Ipelet_base` class.
The first one, `read_active_objects` retrieves all
primitives selected in Ipe when calling an ipelet, and converts them into equivalent \cgal objects.
The second method, `draw_in_ipe` draws \cgal objects in the Ipe
@ -42,7 +42,7 @@ must follow the definition of the ipelet class, in the same file source file.
# Example # {#CGAL_ipeletsExample}
The following example shows how the class `CGAL::Ipelet_base` can be used to easily
The following example shows how the class `Ipelet_base` can be used to easily
interface the \cgal 2D Delaunay triangulation with Ipe.
\cgalexample{CGAL_ipelets/simple_triangulation.cpp}

3
Circular_kernel_2/doc/Circular_kernel_2/Circular_kernel_2.txt
View File

@ -73,8 +73,7 @@ The following example shows how to use a functor of the kernel.
The first pieces of prototype code were comparisons of algebraic
numbers of degree 2, written by Olivier Devillers
\cite cgal:dfmt-amafe-00,cgal:dfmt-amafe-02, and that are still used
in the current implementation of `CGAL::Root_of_2`.
\cite cgal:dfmt-amafe-00,cgal:dfmt-amafe-02.
Some work was then done in the direction of a "kernel" for
\cgal.\footnote{Monique Teillaud, First Prototype of a \cgal Geometric Kernel with Circular Arcs, Technical Report ECG-TR-182203-01, 2002

14
Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt
View File

@ -1360,9 +1360,11 @@ the darts of the two triangles are all 2-free. In the 4D case, the
In this example, we also illustrate how to use the basic methods to
build "by hand" some specific configuration in a combinatorial map. In
fact, these functions are already present in the package: function
`make_triangle(cm)` is equivalent to
`CGAL::make_combinatorial_polygon(cm,3)` and `make_tetrahedron(cm)` is
equivalent to `CGAL::make_combinatorial_tetrahedron(cm)`. If we want
\link make_triangle() `make_triangle(cm)` \endlink is equivalent to
\link make_combinatorial_polygon() `make_combinatorial_polygon(cm,3)`\endlink
and \link make_tetrahedron() `make_tetrahedron(cm)` \endlink is
equivalent to \link make_combinatorial_tetrahedron() `make_combinatorial_tetrahedron(cm)`\endlink.
If we want
to create a 4D simplex, we must create five 3D simplexes, and sew them
correctly two by two by \f$ \beta_3\f$ (and so on if you want to
create higher dimensional combinatorial map).
@ -1378,8 +1380,8 @@ The output is:
In the following example, we illustrate how to specify the
2-attributes in a 3D combinatorial map. For that, we define our own
item class using `CGAL::Dart<3,CMap>` as type of dart, and
`CGAL::Cell_attribute<CMap,int,CGAL::Tag_true,Sum_functor,Divide_by_two_functor>`
item class using `Dart<3,CMap>` as type of dart, and
\link Cell_attribute `Cell_attribute<CMap,int,Tag_true,Sum_functor,Divide_by_two_functor>`\endlink
as attributes which contain an `int` and which are associated to
2-cells of the combinatorial map.
@ -1405,7 +1407,7 @@ cube with an attribute having 13 as value. During the `cm.sew<3>`, two
two associated 2-attributes, and the value of the new 2-cell is the
sum of the two previous one: 20.
Then we call `CGAL::insert_cell_0_in_cell_2` on a dart which belong to
Then we call `insert_cell_0_in_cell_2()` on a dart which belong to
this 2-cell. This method splits the existing 2-cell in <I>k</I>
2-cells, <I>k</I> being the number of 1-cells of the initial 2-cell (4
in this example). These splits are made consecutively, thus for the

6
Inscribed_areas/doc/Inscribed_areas/Inscribed_areas.txt
View File

@ -16,8 +16,8 @@ computing maximal inscribed \f$ k\f$-gons (triangles, quadrilaterals,
\f$ \dots\f$ ) of a planar point set \f$ P\f$. Maximal \f$ k\f$-gons are convex, and it
is known that their vertices can be chosen to be vertices of the
convex hull of \f$ P\f$. Hence, the functions
`CGAL::maximum_area_inscribed_k_gon_2` and
`CGAL::maximum_perimeter_inscribed_k_gon_2` operate on convex polygons
`maximum_area_inscribed_k_gon_2()` and
`maximum_perimeter_inscribed_k_gon_2()` operate on convex polygons
only. The example below shows that the largest area triangle (green)
and the largest perimeter triangle (orange, containing the top point)
of a point set are different in general.
@ -40,7 +40,7 @@ allows to increase it easily.
We further provide an algorithm for computing the maximal area
inscribed axis parallel rectangle for a point set.
Given a set of points in the plane, the class `CGAL::Largest_empty_iso_rectangle_2<T>`
Given a set of points in the plane, the class `Largest_empty_iso_rectangle_2<T>`
is a data structure that maintains an iso-rectangle with the largest area among
all iso-rectangles that are inside a given iso-rectangles, and
that do not contain any point of the point set.

10
Jet_fitting_3/doc/Jet_fitting_3/Jet_fitting_3.txt
View File

@ -226,7 +226,7 @@ In addition, the class `Monge_via_jet_fitting` stores
This concept provides the types for the input sample points, together
with \f$ 3d\f$ vectors and a number type. It is used as template for the
class `Monge_via_jet_fitting<DataKernel, LocalKernel, SvdTraits>`. Typically, one can use
`CGAL::Cartesian<double>`.
`Cartesian<double>`.
## Template parameter LocalKernel ##
@ -240,7 +240,7 @@ Input points of type
`LocalKernel::Point_3`. For output of the `Monge_via_jet_fitting::Monge_form` class,
these types are converted back to `DataKernel` ones. Typically,
one can use
`CGAL::Cartesian<double>` which is the default.
`Cartesian<double>` which is the default.
## Template parameter SvdTraits ##
@ -253,14 +253,14 @@ operations required by the fitting method in
To solve the fitting problem, the sample points are first converted
from the `DataKernel` to the `LocalKernel` (this is done using
the `CGAL::Cartesian_converter`). Then change of coordinate
the `Cartesian_converter`). Then change of coordinate
systems and linear algebra operations are performed with this
kernel. This implies that the number types `LocalKernel::FT` and
`SvdTraits::FT` must be identical.
Second the Monge basis and coefficients, computed with the
`LocalKernel`, are converted back to the `DataKernel`
(this is done using the `CGAL::Cartesian_converter` and the
`CGAL::NT_converter`).
(this is done using the `Cartesian_converter` and the
`NT_converter`).
# Examples # {#Jet_fitting_3Examples}

53
Linear_cell_complex/doc/Linear_cell_complex/Linear_cell_complex.txt
View File

@ -22,7 +22,7 @@ The combinatorial part of a linear cell complex is described by a
read \ref ChapterCombinatorialMap
for definitions). To add
the linear geometrical embedding, a point (a model of
`CGAL::Point_2` or `CGAL::Point_3` or `CGAL::Point_d`) is
`Point_2` or `Point_3` or `Point_d`) is
associated to each vertex of the combinatorial map.
\anchor figexempleintroductif
@ -47,7 +47,7 @@ each vertex of the map.
\image html first-example-lcc.png
<center><b>
Example of 3D linear cell complex describing the object given in Figure \ref figexempleintroductif (Right). <B>Left</B>: The 3D linear cell complex which contains 54 darts (18 for each 3-cell) where each vertex is associated with a point, here a `CGAL::Point_3`. Blue segments represent \f$ \beta_3\f$ relations. <B>Middle</B>: Zoom around the central edge which details the six darts belonging to the edge and the associations between darts and points. <B>Right</B>: Zoom around the facet between light gray and white 3-cells, which details the eight darts belonging to the facet and the associations between darts and points (given by red segments).
Example of 3D linear cell complex describing the object given in Figure \ref figexempleintroductif (Right). <B>Left</B>: The 3D linear cell complex which contains 54 darts (18 for each 3-cell) where each vertex is associated with a point, here a `Point_3`. Blue segments represent \f$ \beta_3\f$ relations. <B>Middle</B>: Zoom around the central edge which details the six darts belonging to the edge and the associations between darts and points. <B>Right</B>: Zoom around the facet between light gray and white 3-cells, which details the eight darts belonging to the facet and the associations between darts and points (given by red segments).
</b></center>
@ -64,19 +64,19 @@ on.
# Software Design # {#Linear_cell_complexSoftware}
The diagram in Figure \ref figdiagram_class_lcc shows the main
classes of the package. `CGAL::Linear_cell_complex` is the main
classes of the package. `Linear_cell_complex` is the main
class (see Section \ref sseclinearcellcomplex), which inherits from
the `CGAL::Combinatorial_map` class. Attributes can be associated
the `Combinatorial_map` class. Attributes can be associated
to some cells of the linear cell complex thanks to an items class (see
Section \ref sseclccitem), which defines the dart type and the
attributes types. These types may be different for different
dimensions of cells, and they may also be void. In the class
`CGAL::Linear_cell_complex`, it is required that
`Linear_cell_complex`, it is required that
specific attributes are associated to all vertices of the
combinatorial map. These attributes must contain a point (a model of
`CGAL::Point_2` or `CGAL::Point_3` or `CGAL::Point_d`),
`Point_2` or `Point_3` or `Point_d`),
and can be represented by instances of class
`CGAL::Cell_attribute_with_point` (see
`Cell_attribute_with_point` (see
Section \ref ssecattributewp).
\anchor figdiagram_class_lcc
@ -88,7 +88,7 @@ UML diagram of the main classes of the package. Gray elements come from the \ref
# Linear Cell Complex # {#sseclinearcellcomplex}
The `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>` class
The `Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>` class
is a model of the `CombinatorialMap` concept. It guarantees that
each vertex of the combinatorial map is associated with an attribute
containing a point. This class can be used in geometric algorithms (it
@ -109,21 +109,20 @@ where each dart is associated with an attribute containing a point
(i.e. an instance of a model of the `CellAttributeWithPoint`
concept). Note that there are no validity constraints on the geometry
(test on self intersection, planarity of 2-cells...).
We can see two examples of `CGAL::Linear_cell_complex` in
We can see two examples of `Linear_cell_complex` in
Figure \ref figcombi_map_with_point.
\anchor figcombi_map_with_point
\image html lcc-examples-2d-3d.png
<center><b>
Examples of `CGAL::Linear_cell_complex`. Gray disks show the attributes associated to vertices. Associations between darts and attributes are drawn by small lines between darts and disks. <B>Left:</B> Example of `CGAL::Linear_cell_complex<2,2>`. <B>Right:</B> Example of `CGAL::Linear_cell_complex<3,3>`.
Examples of `Linear_cell_complex`. Gray disks show the attributes associated to vertices. Associations between darts and attributes are drawn by small lines between darts and disks. <B>Left:</B> Example of `Linear_cell_complex<2,2>`. <B>Right:</B> Example of `Linear_cell_complex<3,3>`.
</b></center>
## Cell Attributes ##
\anchor ssecattributewp
The
`CGAL::Cell_attribute_with_point<LCC,Info_,Tag,OnMerge,OnSplit>`
The `Cell_attribute_with_point<LCC,Info_,Tag,OnMerge,OnSplit>`
class is a model of the `CellAttributeWithPoint` concept, which is
a refinement of the `CellAttribute` concept. It represents an
attribute associated with a cell, which can contain an information
@ -141,7 +140,7 @@ the required functors used for constructions and operations, as for
example `Construct_translated_point` or
`Construct_sum_of_vectors`.
The class `CGAL::Linear_cell_complex_traits<d,K>` is a model of
The class `Linear_cell_complex_traits<d,K>` is a model of
`LinearCellComplexTraits`. It defines the different types which
are obtained from `K` that, depending on `d`, is a model of
the concept `Kernel` if `d==2` or `d==3`, and a model of
@ -155,9 +154,9 @@ The `LinearCellComplexItems` concept refines the
0-attributes are enabled, and associated with a type of attribute
being a model of the `CellAttributeWithPoint` concept.
The class `CGAL::Linear_cell_complex_min_items<d>` is a
model of `LinearCellComplexItems`. It uses `CGAL::Dart<d>`,
and instances of `CGAL::Cell_attribute_with_point`
The class `Linear_cell_complex_min_items<d>` is a
model of `LinearCellComplexItems`. It uses `Dart<d>`,
and instances of `Cell_attribute_with_point`
(which contain no information) associated to each vertex. All other
attributes are void.
@ -246,19 +245,19 @@ that the dimension of the linear cell complex must be large enough:
darts must contain all the \f$ \beta\f$ used by the operation. All these
methods add new darts in the current linear cell complex, existing
darts are not modified. These functions
are `make_segment`, `make_triangle`,
`make_tetrahedron` and `make_hexahedron`.
are `make_segment()`, `make_triangle()`,
`make_tetrahedron()` and `make_hexahedron()`.
There are two functions allowing to build a linear cell complex
from two other \cgal data types:
<UL>
<LI>`import_from_triangulation_3(lcc,atr)`: adds in `lcc` all
the tetrahedra present in `atr`, a `CGAL::Triangulation_3`;
<LI>`import_from_polyhedron_3(lcc,ap)`: adds in `lcc` all
the cells present in `ap`, a `CGAL::Polyhedron_3`.
<LI>\link import_from_triangulation_3() `import_from_triangulation_3(lcc,atr)`\endlink: adds in `lcc` all
the tetrahedra present in `atr`, a `Triangulation_3`;
<LI>\link import_from_polyhedron_3() `import_from_polyhedron_3(lcc,ap)`\endlink: adds in `lcc` all
the cells present in `ap`, a `Polyhedron_3`.
</UL>
Lastly, the function `import_from_plane_graph(lcc,ais)` adds in
Lastly, the function \link\import_from_polyhedron_3() `import_from_plane_graph(lcc,ais)` \endlink adds in
`lcc` all the cells reconstructed from the planar graph read in
`ais`, a `std::istream` (see the reference manual for the file
format).
@ -383,17 +382,17 @@ The output is:
This example illustrates the way to use a 3D linear cell complex by
adding another information to vertices. For that, we need to define
our own items class. The difference with the
`CGAL::Linear_cell_complex_min_items` class is about the definition of
the vertex attribute where we use a `CGAL::Cell_attribute_with_point`
`Linear_cell_complex_min_items` class is about the definition of
the vertex attribute where we use a `Cell_attribute_with_point`
with a non void info. In this example, the "vextex color" is just
given by an `int` (the second template parameter of the
`CGAL::Cell_attribute_with_point`). Lastly, we define the
`Cell_attribute_with_point`). Lastly, we define the
`Average_functor` class in order to set the color of a vertex
resulting of the merging of two vertices to the average of the two
initial values. This functor is associated with the vertex attribute
by passing it as template parameter. Using this items class instead of
the default one is done during the instantiation of template
parameters of the `CGAL::Linear_cell_complex` class.
parameters of the `Linear_cell_complex` class.
Now we can use `LCC_3` in which each vertex is associated with an
attribute containing both a point and an information. In the following

2
Mesh_3/doc/Mesh_3/Mesh_3.txt
View File

@ -331,7 +331,7 @@ of the procedure.
The type `C3T3` is required to provide a nested type
`C3T3::Triangulation_3` for the 3D triangulation
embedding the mesh.
This triangulation is required to be a `CGAL::Regular_triangulation_3`.
This triangulation is required to be a `Regular_triangulation_3`.
with vertex and cell base classes that are respectively models of the
concepts `MeshVertexBase_3` and `MeshCellBase_3`.

4
Nef_3/doc/Nef_3/Nef_3.txt
View File

@ -297,8 +297,8 @@ The following example gives a first impression of how to instantiate
and use `Nef_polyhedron_3`. We use the `Cartesian`
kernel. All %Cartesian and homogeneous kernels of \cgal are suitable
if the number type parameter follows the usual requirements of being a
model of the `CGAL::FieldNumberType` concept for the %Cartesian
kernels, or the `CGAL::RingNumberType` concept for the homogeneous
model of the `FieldNumberType` concept for the %Cartesian
kernels, or the `RingNumberType` concept for the homogeneous
kernels, respectively. Note however, that in the current state, the
Nef polyhedron works only with \cgal kernels. The implementation
makes use of \cgal specific functions in kernel objects, and does not

2
Number_types/doc/Number_types/NumberTypeSupport.txt
View File

@ -93,7 +93,7 @@ The file <TT>CGAL/Gmpzf.h</TT> provides the class `Gmpzf`, an exact
arbitrary-precision floating-point type. Hence, It does not support
operators like <TT>/</TT> to guarantee exactness of the operations. The
arithmetic operations on this type are restricted to <TT>+</TT>, <TT>-</TT>,
<TT>*</TT> and `CGAL::integral_division()`.
<TT>*</TT> and `integral_division()`.
The file <TT>CGAL/Gmpfr.h</TT> provides the class `Gmpfr`,
a fixed-precision floating-point number type. Since the precision

2
Periodic_3_triangulation_3/doc/Periodic_3_triangulation_3/Periodic_3_triangulation_3.txt
View File

@ -286,7 +286,7 @@ If the user does not need to add a type in a vertex that depends on the
`TriangulationDataStructure_3` (e.g. a `Vertex_handle` or
`Cell_handle`), then he can use the
`Triangulation_vertex_base_with_info_3` class to add his own information
easily in the vertices. The example below shows how to add a `CGAL::Color`
easily in the vertices. The example below shows how to add a `Color`
this way.
\cgalexample{Periodic_3_triangulation_3/colored_vertices.cpp}

10
Point_set_2/doc/Point_set_2/Point_set_2.txt
View File

@ -50,16 +50,16 @@ Mehlhorn and N&auml;her in \cite mn-lpcgc-00.
In this section we present a generic variant of a two dimensional point set
data type supporting various geometric queries.
The `CGAL::Point_set_2` class in this section is inherited
The `Point_set_2` class in this section is inherited
from the two-dimensional \cgal <I>Delaunay Triangulation</I> data type.
The `CGAL::Point_set_2` class depends on two template parameters `T1` and `T2`.
They are used as template parameters for the `CGAL::Delaunay_triangulation_2`
class `CGAL::Point_set_2` is inherited from. `T1` is a model for the
The `Point_set_2` class depends on two template parameters `T1` and `T2`.
They are used as template parameters for the `Delaunay_triangulation_2`
class `Point_set_2` is inherited from. `T1` is a model for the
geometric traits and `T2` is a model for the triangulation data structure that the Delaunay triangulation
expects.
The `CGAL::Point_set_2` class supports the following kinds of queries:
The `Point_set_2` class supports the following kinds of queries:
<UL>
<LI>circular range search
<LI>triangular range search

36
Point_set_processing_3/doc/Point_set_processing_3/Point_set_processing_3.txt
View File

@ -58,9 +58,9 @@ The following classes described in Chapter \ref chapterProperty_map
provide property maps for the implementations of points with normals
listed above:
- `CGAL::Dereference_property_map<T>`
- `CGAL::First_of_pair_property_map<Pair>` and `CGAL::Second_of_pair_property_map<Pair>`
- `CGAL::Nth_of_tuple_property_map<N, Tuple>`
- `Dereference_property_map<T>`
- `First_of_pair_property_map<Pair>` and `Second_of_pair_property_map<Pair>`
- `Nth_of_tuple_property_map<N, Tuple>`
`Dereference_property_map<Point_3>` is the default value of the
position property map expected by all functions in this component.
@ -78,10 +78,10 @@ point coordinates `x y z` per line or three point coordinates and
three normal vector coordinates `x y z nx ny nz` per line), and OFF
(%Object File Format) \cite cgal:p-gmgv16-96.
- `CGAL::read_xyz_points`
- `CGAL::read_off_points`
- `CGAL::write_off_points`
- `CGAL::write_xyz_points`
- `read_xyz_points()`
- `read_off_points()`
- `write_off_points()`
- `write_xyz_points()`
## Example ##
@ -92,7 +92,7 @@ in pairs and accessed through property maps.
# Analysis #
Function `CGAL::compute_average_spacing()` computes the average
Function `compute_average_spacing()` computes the average
spacing of all input points to their `k` nearest neighbor points,
`k` being specified by the user. As it provides an order of a
point set density, this function is used downstream the surface
@ -117,7 +117,7 @@ found in other \cgal components:
# Outlier Removal #
Function `CGAL::remove_outliers()` deletes a user-specified fraction
Function `remove_outliers()` deletes a user-specified fraction
of outliers from an input point set. More specifically, it sorts the
input points in increasing order of average squared distances to their
`k` nearest neighbors and deletes the points with largest value.
@ -125,7 +125,7 @@ input points in increasing order of average squared distances to their
## Example ##
The following example reads a point set and removes 5% of the
points. It uses the `CGAL::Dereference_property_map<Point_3>` property
points. It uses the `Dereference_property_map<Point_3>` property
map (optional as it is the default position property map of all
functions in this component.)
\cgalexample{Point_set_processing_3/remove_outliers_example.cpp}
@ -136,15 +136,15 @@ functions in this component.)
Two simplification functions are devised to reduce an input point set,
either randomly or using a grid-based clustering approach.
Function `CGAL::random_simplify_point_set()` randomly deletes a
Function `random_simplify_point_set()` randomly deletes a
user-specified fraction of points from the input point set. This
algorithm is fast.
Function `CGAL::grid_simplify_point_set()` considers a regular grid
Function `grid_simplify_point_set()` considers a regular grid
covering the bounding box of the input point set, and clusters all
points sharing the same cell of the grid by picking as representant
one arbitrarily chosen point. This algorithm is slower than
`CGAL::random_simplify_point_set()`.
`random_simplify_point_set()`.
## Example ##
@ -157,7 +157,7 @@ The following example reads a point set and simplifies it by clustering.
# Smoothing #
Function `CGAL::jet_smooth_point_set` smooths the input point set by
Function `jet_smooth_point_set` smooths the input point set by
projecting each point onto a smooth parametric surface patch
(so-called jet surface) fitted over its `k` nearest neighbors.
@ -174,19 +174,19 @@ Assuming a point set sampled over an inferred surface \f$ S\f$, two
functions provide an estimate of the normal to \f$ S\f$ at each
point. The result is an unoriented normal vector for each input point.
Function `CGAL::jet_estimate_normals()` estimates the normal direction
Function `jet_estimate_normals()` estimates the normal direction
at each point from the input set by fitting a jet surface over its `k`
nearest neighbors. The default jet is a quadric surface. This
algorithm is well suited to point sets scattered over curved surfaces.
Function `CGAL::pca_estimate_normals()` estimates the normal direction
Function `pca_estimate_normals()` estimates the normal direction
at each point from the set by linear least squares fitting of a plane
over its `k` nearest neighbors. This algorithm is simpler and
faster than `CGAL::jet_estimate_normals()`.
faster than `jet_estimate_normals()`.
# Normal Orientation #
Function `CGAL::mst_orient_normals()` orients the normals of a set of
Function `mst_orient_normals()` orients the normals of a set of
points with unoriented normals using the method described by Hoppe et
al. in <I>Surface reconstruction from unorganized points</I> \cite cgal:hddms-srup-92.
More specifically, this method constructs a

5
Polytope_distance_d/doc/Polytope_distance_d/Polytope_distance_d.txt
View File

@ -10,9 +10,8 @@ namespace CGAL {
This chapter describes how to compute the distance between the convex
hulls of two given point sets in \f$ d\f$-dimensional Euclidean space
(`CGAL::Polytope_distance_d<Traits>`). Moreover, it is possible to
compute the width of a point set in three dimensions
(`CGAL::Width_3<Traits>`).
(`Polytope_distance_d<Traits>`). Moreover, it is possible to
compute the width of a point set in three dimensions (`Width_3<Traits>`).
\image html polydist.gif

64
QP_solver/doc/QP_solver/QP_solver.txt
View File

@ -767,14 +767,14 @@ fixed multiples of the numbers in the table below, and they might
vary with the random choices). The default choice of the pricing
strategy in that case is `QP_PARTIAL_FILTERED_DANTZIG`.
strategy | runtime in seconds
-------------------------- | ------------------
`CGAL::QP_CHOOSE_DEFAULT` | 0.32
`CGAL::QP_DANTZIG` | 10.7
`CGAL::QP_PARTIAL_DANTZIG` | 3.72
`CGAL::QP_BLAND` | 3.65
`CGAL::QP_FILTERED_DANTZIG` | 0.43
`CGAL::QP_PARTIAL_FILTERED_DANTZIG` | 0.32
Strategy | Runtime in seconds
-------------------------- | ------------------
`QP_CHOOSE_DEFAULT` | 0.32
`QP_DANTZIG` | 10.7
`QP_PARTIAL_DANTZIG` | 3.72
`QP_BLAND` | 3.65
`QP_FILTERED_DANTZIG` | 0.43
`QP_PARTIAL_FILTERED_DANTZIG` | 0.32
We clearly see the effect of filtering: we gain a factor of ten,
roughly, compared to the next best non-filtered variant.
@ -785,14 +785,14 @@ The filtering effect is amplified if the points/dimension ratio becomes
larger. This is what you might see in dimension three, with one million
points.
strategy | runtime in seconds
-------------------------- | ------------------
`CGAL::QP_CHOOSE_DEFAULT` | 1.34
`CGAL::QP_DANTZIG` | 47.6
`CGAL::QP_PARTIAL_DANTZIG` | 15.6
`CGAL::QP_BLAND` | 16.02
`CGAL::QP_FILTERED_DANTZIG` | 1.89
`CGAL::QP_PARTIAL_FILTERED_DANTZIG` | 1.34
Strategy | Runtime in seconds
-------------------------- | ------------------
`QP_CHOOSE_DEFAULT` | 1.34
`QP_DANTZIG` | 47.6
`QP_PARTIAL_DANTZIG` | 15.6
`QP_BLAND` | 16.02
`QP_FILTERED_DANTZIG` | 1.89
`QP_PARTIAL_FILTERED_DANTZIG` | 1.34
In general, if your problem has a high variable/constraint or
constraint/variable ratio, then filtering will typically pay off.
@ -805,14 +805,14 @@ see the issue discussed in Section \ref secQPcustomizationfiltering).
Conversely, the filtering effect deteriorates if the points/dimension ratio
becomes smaller.
strategy | runtime in seconds
-------------------------- | ------------------
`CGAL::QP_CHOOSE_DEFAULT` | 3.05
`CGAL::QP_DANTZIG` | 78.4
`CGAL::QP_PARTIAL_DANTZIG` | 45.9
`CGAL::QP_BLAND` | 33.2
`CGAL::QP_FILTERED_DANTZIG` | 3.36
`CGAL::QP_PARTIAL_FILTERED_DANTZIG` | 3.06
Strategy | Runtime in seconds
-------------------------- | ------------------
`QP_CHOOSE_DEFAULT` | 3.05
`QP_DANTZIG` | 78.4
`QP_PARTIAL_DANTZIG` | 45.9
`QP_BLAND` | 33.2
`QP_FILTERED_DANTZIG` | 3.36
`QP_PARTIAL_FILTERED_DANTZIG` | 3.06
## \f$ d=500\f$, \f$ n=1,000\f$ ##
@ -821,14 +821,14 @@ longer a clear winner. The reason is that in this case,
the necessary exact calculations with multiprecision numbers
dominate the overall runtime.
strategy | runtime in seconds
-------------------------- | ------------------
`CGAL::QP_CHOOSE_DEFAULT` | 2.65
`CGAL::QP_DANTZIG` | 5.55
`CGAL::QP_PARTIAL_DANTZIG` | 5.6
`CGAL::QP_BLAND` | 4.46
`CGAL::QP_FILTERED_DANTZIG` | 2.65
`CGAL::QP_PARTIAL_FILTERED_DANTZIG` | 2.61
Strategy | Runtime in seconds
-------------------------- | ------------------
`QP_CHOOSE_DEFAULT` | 2.65
`QP_DANTZIG` | 5.55
`QP_PARTIAL_DANTZIG` | 5.6
`QP_BLAND` | 4.46
`QP_FILTERED_DANTZIG` | 2.65
`QP_PARTIAL_FILTERED_DANTZIG` | 2.61
In general, if you have a program where the number of variables
and the number of constraints have the same order of magnitude, then

12
STL_Extension/doc/STL_Extension/STL_Extension.txt
View File

@ -145,7 +145,7 @@ and `Compact_location` are also provided.
In \cpp, it is possible to specify defaults at the end of a template parameter
list. Specifying that one wishes to use the default is simply done by omitting
it. This is however possible only at the end of the list. `CGAL::Default`
it. This is however possible only at the end of the list. `Default`
provides a simple mechanism that performs something equivalent anywhere in the
sequence.
@ -272,8 +272,8 @@ management. Thus, the categories do not apply for static assertions.
As stated above, if a postcondition, precondition or assertion is
violated, an exception is thrown, and if nothing is done to catch it,
the program will abort.
This behavior can be changed by means of the function `CGAL::set_error_behaviour()`
and the enum `CGAL::Failure_behaviour`.
This behavior can be changed by means of the function `set_error_behaviour()`
and the enum `Failure_behaviour`.
The `THROW_EXCEPTION` value is the default, which throws an exception.
@ -288,9 +288,9 @@ totally disabling them).
\advanced If the `EXIT_WITH_SUCCESS` value is set, the program will stop and
return a value corresponding to successful execution and not dump the core.
The value that is returned by `CGAL::set_error_behaviour` is the value that was in use before.
The value that is returned by `set_error_behaviour()` is the value that was in use before.
For warnings we provide `CGAL::set_warning_behaviour()` which works in the same way.
For warnings we provide `set_warning_behaviour()` which works in the same way.
The only difference is that for warnings the default value is
`CONTINUE`.
@ -314,7 +314,7 @@ The name of a particular module is documented with that module.
Normally, error messages are written to the standard error output.
It is possible to do something different with them.
To that end you can register your own handler using
`CGAL::set_error_handler(Failure_function handler)`
`set_error_handler(Failure_function handler)`
This function should be declared as follows.

8
SearchStructures/doc/SearchStructures/SearchStructures.txt
View File

@ -307,7 +307,7 @@ The following example program uses the predefined `Range_tree_2` data structure
class `Range_tree_map_traits_2` which has two template
arguments specifying the
type of the point data in each dimension
(`CGAL::Cartesian<double>`) and the value type of the
(`Cartesian<double>`) and the value type of the
2-dimensional point data (`char`). Therefore the `Range_tree_2` is defined on 2-dimensional point data each of which is
associated with a character.
Then, a few data items are created and put into a list. After
@ -440,7 +440,7 @@ the number of reported intervals.
One possible application of a two-dimensional segment tree is the
following. Given a set of convex polygons in two-dimensional
space (CGAL::Polygon_2), we want to determine all polygons
space (Polygon_2), we want to determine all polygons
that intersect a given rectangular query window. Therefore, we define a
two-dimensional segment tree, where the two-dimensional interval of
a data item corresponds to the bounding box of a polygon and the
@ -455,9 +455,9 @@ The following example program uses the predefined `Segment_tree_2` data structur
class `Segment_tree_map_traits_2` which has two template arguments
specifying the
type of the point data in each dimension
(`CGAL::Cartesian<double>`) and the value type of the
(`Cartesian<double>`) and the value type of the
2-dimensional point data (`char`). Therefore the `Segment_tree_2` is defined on 2-dimensional point data
(`CGAL::Point_2<Cartesian<double> >`) each of which is
(`Point_2<Cartesian<double> >`) each of which is
associated with a character.
Then, a few data items are created and put into a list. After
that the tree is constructed according to that list, a window

14
Segment_Delaunay_graph_2/doc/Segment_Delaunay_graph_2/Segment_Delaunay_graph_2.txt
View File

@ -415,7 +415,7 @@ filtering for the predicates involved in the computation of
segment Delaunay graphs:
<OL>
<LI>The user can define his/her kernel using as number type, a
number type of the form `CGAL::Filtered_exact<CT,ET>`. Then this
number type of the form `Filtered_exact<CT,ET>`. Then this
kernel can be entered as the first template parameter in the
`Segment_Delaunay_graph_2<K,MTag>` or
`Segment_Delaunay_graph_without_intersections_2<K,MTag>` class.
@ -442,13 +442,13 @@ Let's consider once more the classes
The template parameter `MTag` provides another degree of freedom
to the user, who can indicate the type of arithmetic operations to
be used in the evaluation of the predicates. More specifically, in
both classes, `MTag` can be `CGAL::Field_with_sqrt_tag`, in
both classes, `MTag` can be `Field_with_sqrt_tag`, in
which case the predicates will be evaluated using all four basic
arithmetic operations plus square roots; this requires, of course,
that the number type used in the kernel `K` supports these
operations exactly. The second choices are `CGAL::Field_tag` for
operations exactly. The second choices are `Field_tag` for
the `Segment_Delaunay_graph_2<K,MTag>` class, and
`CGAL::Euclidean_ring_tag` for the
`Euclidean_ring_tag` for the
`Segment_Delaunay_graph_without_intersections_2<K,MTag>`
class. In the first case we indicate that we want the predicates to be
computed using only the four basic arithmetic operations, whereas in
@ -467,10 +467,10 @@ calculations involving each of the corresponding kernels `CK`,
`FK` and `EK`. When the
`Segment_Delaunay_graph_filtered_traits_2<CK,CM,EK,EM,FK,FM>` is
used the possible values for `CM`, `FM` and `EM` are
`CGAL::Field_with_sqrt_tag` and `CGAL::Field_tag`, whereas if the
`Field_with_sqrt_tag` and `Field_tag`, whereas if the
`Segment_Delaunay_graph_filtered_traits_without_intersections_2<CK,CM,EK,EM,FK,FM>`
class is used, the possible values are `CGAL::Field_with_sqrt_tag` and
`CGAL::Euclidean_ring_tag`. The semantics are the same as in the case of the
class is used, the possible values are `Field_with_sqrt_tag` and
`Euclidean_ring_tag`. The semantics are the same as in the case of the
`Segment_Delaunay_graph_2<K,MTag>` and
`Segment_Delaunay_graph_without_intersections_2<K,MTag>` classes.

2
Stream_lines_2/doc/Stream_lines_2/Stream_lines_2.txt
View File

@ -156,7 +156,7 @@ Streamlines are represented as polylines, and are obtained by
iterative integration from the seed point. A polyline is represented as a range of points. The computation is
processed via a list of Delaunay triangulation vertices.
To implement the triangular grid, the class `CGAL::Delaunay_triangulation_2` is used. The priority queue used
To implement the triangular grid, the class `Delaunay_triangulation_2` is used. The priority queue used
to store candidate seed points is taken from the Standard Template
Library \cite cgal:sgcsi-stlpg-97.

2
Stream_support/doc/IOstream/IOstream.txt
View File

@ -219,7 +219,7 @@ public:
# Colors # {#IOstreamColors}
An object of the class `CGAL::Color` is a color available
An object of the class `Color` is a color available
for drawing operations in many \cgal output streams.
Each color is defined by a triple of integers `(r,g,b)` with

94
Surface_mesh_parameterization/doc/Surface_mesh_parameterization/Surface_mesh_parameterization.txt
View File

@ -35,7 +35,7 @@ minimize (angles vs. areas), by the constrained border onto the
planar domain (convex polygon vs. free border) and by the guarantees
provided in terms of bijective mapping.
The package proposes currently an interface with the `CGAL::Polyhedron_3`
The package proposes currently an interface with the `Polyhedron_3`
data structure.
Since parameterizing meshes require efficient representation of sparse
@ -69,17 +69,17 @@ is the following function:
Parameterizer_traits_3<ParameterizationMesh_3>::Error_code parameterize (ParameterizationMesh_3 & mesh);
\endcode
The function `CGAL::parameterize()` applies a default surface parameterization
The function `parameterize()` applies a default surface parameterization
method, namely Floater Mean Value Coordinates \cite cgal:f-mvc-03, with an
arc-length circular border parameterization, and using OpenNL sparse
linear solver \cite cgal:l-nmdgp-05. The `ParameterizationMesh_3` concept defines the input meshes handled by `CGAL::parameterize()`. See Section \ref secInputMeshforparameterize. The result is stored into the `(u,v)` fields of the mesh halfedges.
linear solver \cite cgal:l-nmdgp-05. The `ParameterizationMesh_3` concept defines the input meshes handled by `parameterize()`. See Section \ref secInputMeshforparameterize. The result is stored into the `(u,v)` fields of the mesh halfedges.
The mesh must be a triangle mesh surface with one connected component.
Note: `CGAL::Parameterizer_traits_3<ParameterizationMesh_3>` is the (pure virtual) superclass of all surface parameterizations and defines the error codes.
Note: `Parameterizer_traits_3<ParameterizationMesh_3>` is the (pure virtual) superclass of all surface parameterizations and defines the error codes.
\subsection secInputMeshforparameterize Input Mesh for parameterize()
The input meshes handled <I>directly</I> by `CGAL::parameterize()` must be models of `ParameterizationMesh_3`, triangulated, 2-manifold, oriented, and homeomorphic to discs (possibly with holes).
The input meshes handled <I>directly</I> by `parameterize()` must be models of `ParameterizationMesh_3`, triangulated, 2-manifold, oriented, and homeomorphic to discs (possibly with holes).
Note: `ParameterizationMesh_3` is a general concept to access a
polyhedral mesh. It is optimized for the `Surface_mesh_parameterization` package
@ -91,24 +91,24 @@ The extra constraints needed by the surface parameterization methods (triangulat
are checked at runtime.
This package provides a model of the `ParameterizationMesh_3` concept
to access `CGAL::Polyhedron_3<Traits>`:
to access `Polyhedron_3<Traits>`:
`CGAL::Parameterization_polyhedron_adaptor_3<Polyhedron_3_>`
`Parameterization_polyhedron_adaptor_3<Polyhedron_3_>`
We will see later that `CGAL::parameterize()` can support <I>indirectly</I>
We will see later that `parameterize()` can support <I>indirectly</I>
meshes that are not topological disks.
## %Default Parameterization Example ##
In the following example, we apply the default parameterization to a
`CGAL::Polyhedron_3<Traits>` mesh (must be a topological disk).
`Polyhedron_3<Traits>` mesh (must be a topological disk).
Eventually, it extracts the result from halfedges and prints it.
\cgalexample{Surface_mesh_parameterization/Simple_parameterization.cpp}
## Enhanced %parameterize() Function ##
This package provides a second `CGAL::parameterize()` entry point
This package provides a second `parameterize()` entry point
where the user can specify a parameterization method:
\code{.cpp}
@ -161,20 +161,20 @@ of `SparseLinearAlgebraTraits_d`. See Section \ref secSparseLinearAlgebra.
## The %ParameterizationMesh_3 and %ParameterizationPatchableMesh_3 Concepts ##
As described in Section \ref secInputMeshforparameterize
the input meshes handled by `CGAL::parameterize()`
the input meshes handled by `parameterize()`
must be models of the `ParameterizationMesh_3` concept. The surface parameterization methods provided by this package only support
surfaces which are homeomorphic to disks, possibly with holes. Nevertheless meshed with arbitrary topology and number of connected components can be parameterized, provided that the user specifies a <I>cut graph</I> (an oriented list of
vertices) which is the border of a topological disc. If no cut graph is
specified as input, the longest border of the input mesh is taken by default, the others being considered as holes.
For this purpose, the
`CGAL::Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`
`Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`
class is responsible for <I>virtually</I> cutting
a patch into a `ParameterizationPatchableMesh_3` mesh.
The resulting patch is a topological
disk (if the input cutting path is correct)
and provides a `ParameterizationMesh_3` interface. It can be used as
parameter for the function `CGAL::parameterize()`.
parameter for the function `parameterize()`.
`ParameterizationPatchableMesh_3` inherits from `ParameterizationMesh_3`,
thus is a concept for a 3D surface mesh.
@ -200,7 +200,7 @@ Such border parameterizations are described in Section
## Tutte Barycentric Mapping ##
`CGAL::Barycentric_mapping_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`Barycentric_mapping_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
The Barycentric Mapping parameterization method has been introduced by
Tutte \cite t-hdg-63. In parameter space, each vertex is
@ -220,7 +220,7 @@ this method does not minimize angles nor areas distortion.
## Discrete Conformal Map ##
`CGAL::Discrete_conformal_map_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`Discrete_conformal_map_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
Discrete conformal map parameterization has been introduced by Eck et
al. to the graphics community \cite cgal:eddhls-maam-95. It attempts to
@ -241,7 +241,7 @@ thus can be efficiently solved using dedicated linear solvers.
## Floater Mean Value Coordinates ##
`CGAL::Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
The mean value coordinates parameterization method has been introduced
by Floater \cite cgal:f-mvc-03. Each vertex in parameter space is
@ -258,7 +258,7 @@ same for both systems) is asymmetric.
## Discrete Authalic Parameterization ##
`CGAL::Discrete_authalic_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`Discrete_authalic_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
The discrete authalic parameterization method has been introduced by
Desbrun et al. \cite cgal:dma-ipsm-02. It corresponds to
@ -304,13 +304,13 @@ parameterization is commonly used for texture mapping.
</UL>
`CGAL::Circular_border_arc_length_parameterizer_3<ParameterizationMesh_3>`
`Circular_border_arc_length_parameterizer_3<ParameterizationMesh_3>`
`CGAL::Circular_border_uniform_parameterizer_3<ParameterizationMesh_3>`
`Circular_border_uniform_parameterizer_3<ParameterizationMesh_3>`
`CGAL::Square_border_arc_length_parameterizer_3<ParameterizationMesh_3>`
`Square_border_arc_length_parameterizer_3<ParameterizationMesh_3>`
`CGAL::Square_border_uniform_parameterizer_3<ParameterizationMesh_3>`
`Square_border_uniform_parameterizer_3<ParameterizationMesh_3>`
\anchor Surface_mesh_parameterizationfigcircular_border
\image html border.png "Left: Julius Cesar mask parameterization with Authalic/circular border. Right: Julius Cesar mask's image with Floater/square border."
@ -319,7 +319,7 @@ parameterization is commonly used for texture mapping.
## Least Squares Conformal Maps ##
`CGAL::LSCM_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`LSCM_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
The Least Squares Conformal Maps (LSCM) parameterization method has
been introduced by L&eacute;vy et al. \cite cgal:lprm-lscm-02.
@ -343,11 +343,11 @@ parameterization methods define only two constraints: the pinned vertices.
<UL>
<LI>`CGAL::Two_vertices_parameterizer_3<ParameterizationMesh_3>`
<LI>`Two_vertices_parameterizer_3<ParameterizationMesh_3>`
<I>Usage:</I>
`CGAL::Two_vertices_parameterizer_3<ParameterizationMesh_3>` is the default
`Two_vertices_parameterizer_3<ParameterizationMesh_3>` is the default
free border parameterization, and is the only one available
in the current version of this package.
@ -356,8 +356,8 @@ in the current version of this package.
## Discrete Authalic Parameterization Example ##
In the following example, we compute a Discrete Authalic parameterization
over a `CGAL::Polyhedron_3<Traits>` mesh. Specifying a specific surface parameterization
instead of the default one means using the second parameter of `CGAL::parameterize()`. The
over a `Polyhedron_3<Traits>` mesh. Specifying a specific surface parameterization
instead of the default one means using the second parameter of `parameterize()`. The
differences with the first example \ref Surface_mesh_parameterization/Simple_parameterization.cpp "Simple_parameterization.cpp" are:
\code{.cpp}
@ -385,7 +385,7 @@ In the following example, we compute a Floater mean value coordinates
parameterization with a square border arc length parameterization.
Specifying a specific border parameterization
instead of the default one means using the second parameter of
`CGAL::Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`.
`Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`.
The differences with the first example \ref Surface_mesh_parameterization/Simple_parameterization.cpp "Simple_parameterization.cpp" are:
\code{.cpp}
@ -432,7 +432,7 @@ of the `SparseLinearAlgebraTraits_d` concept:
supports exact number types.
- An interface to all sparse solvers from the \ref thirdpartyEigen "Eigen" library is provided through the class
`CGAL::Eigen_solver_traits<T>`. This solver traits class can be used for an iterative or a direct,
`Eigen_solver_traits<T>`. This solver traits class can be used for an iterative or a direct,
symmetric or general sparse solvers. The \ref thirdpartyEigen "Eigen" solver to be used must be given as template parameter.
## Eigen Solver Example ##
@ -441,7 +441,7 @@ The example \ref Surface_mesh_parameterization/Eigen_parameterization.cpp "Eigen
default parameterization method (Floater mean value coordinates with a circular border),
but specifically instantiates an \ref thirdpartyEigen "Eigen" solver. Specifying a specific solver
instead of the default one (OpenNL) means using the third parameter of
`CGAL::Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`. The differences with the first
`Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`. The differences with the first
example \ref Surface_mesh_parameterization/Simple_parameterization.cpp "Simple_parameterization.cpp" are:
\code{.cpp}
@ -500,13 +500,13 @@ surfaces which are homeomorphic to disks (models of
`ParameterizationMesh_3`). This software design simplifies the
implementation of all new parameterization methods.
The `CGAL::Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`
The `Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`
class is responsible for <I>virtually</I> cutting
a patch in a `ParameterizationPatchableMesh_3` mesh.
The resulting patch is a topological
disk (if the cut graph is correct)
and provides a `ParameterizationMesh_3` interface. It can be used as
parameter of `CGAL::parameterize()`.
parameter of `parameterize()`.
`ParameterizationPatchableMesh_3` inherits from concept `ParameterizationMesh_3`,
thus is a concept for a 3D surface mesh.
@ -517,7 +517,7 @@ virtual seams. <I>Patches</I> are a subset of a 3D mesh.
The `ParameterizationMesh_3` interface with the Polyhedron is both a model of
`ParameterizationMesh_3` and `ParameterizationPatchableMesh_3`:
`CGAL::Parameterization_polyhedron_adaptor_3<Polyhedron_3_>`
`Parameterization_polyhedron_adaptor_3<Polyhedron_3_>`
Note that this class is a decorator which adds <I>on the fly</I>
the necessary fields to unmodified \cgal data structures (using STL
@ -528,7 +528,7 @@ class in \ref Surface_mesh_parameterization/polyhedron_ex_parameterization.cpp "
## Cutting a Mesh Example ##
In the following example, we <I>virtually</I> cut a
`CGAL::Polyhedron_3<Traits>` mesh
`Polyhedron_3<Traits>` mesh
to make it a topological disk, then applies the default parameterization:
\cgalexample{Surface_mesh_parameterization/Mesh_cutting_parameterization.cpp}
@ -537,22 +537,22 @@ to make it a topological disk, then applies the default parameterization:
Parameterization methods compute \f$ (u,v)\f$ fields for each vertex
of the input mesh, with the seam vertices being virtually duplicated (thanks
to `CGAL::Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`).
to `Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`).
To support this duplication,
`CGAL::Parameterization_polyhedron_adaptor_3<Polyhedron_3_>` stores
`Parameterization_polyhedron_adaptor_3<Polyhedron_3_>` stores
the result in the \f$ (u,v)\f$ fields of the input mesh halfedges.
A \f$ (u,v)\f$ pair is computed for
each inner vertex (i.e. its halfedges share the same \f$ (u,v)\f$ pair),
while a \f$ (u,v)\f$ pair is computed for each border halfedge.
The user has to iterate over the mesh halfedges to get the result.
Note that \f$ (u,v)\f$ fields do not exist in `CGAL::Polyhedron_3<Traits>`,
Note that \f$ (u,v)\f$ fields do not exist in `Polyhedron_3<Traits>`,
thus the output traversal is specific to the way the (u,v) fields are implemented by the adaptor.
## EPS Output Example ##
The follwing example is a complete parameterization
example which outputs the resulting parameterization to a EPS file. It gets the \f$ (u,v)\f$ fields computed by a parameterization method over a `CGAL::Polyhedron_3<Traits>` mesh with a
`CGAL::Parameterization_polyhedron_adaptor_3<Polyhedron_3_>` adaptor:
example which outputs the resulting parameterization to a EPS file. It gets the \f$ (u,v)\f$ fields computed by a parameterization method over a `Polyhedron_3<Traits>` mesh with a
`Parameterization_polyhedron_adaptor_3<Polyhedron_3_>` adaptor:
\cgalexample{Surface_mesh_parameterization/Complete_parameterization_example.cpp}
@ -695,21 +695,21 @@ parameterize() method of a `ParameterizerTraits_3` object.
The purpose of these global functions is:
<UL>
<LI>to be consistent with other \cgal algorithms that are also provided as
global functions, e.g. `CGAL::convex_hull_2()`,
global functions, e.g. `convex_hull_2()`,
<LI>to provide a default parameterization method (Floater Mean Value Coordinates),
which wouldn't be possible with a direct call to an object's method.
</UL>
You may also wonder why there is not just one `CGAL::parameterize()` function
You may also wonder why there is not just one `parameterize()` function
with a default `ParameterizerTraits_3` argument equal to
`CGAL::Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3>`.
`Mean_value_coordinates_parameterizer_3<ParameterizationMesh_3>`.
The reason is simply that this is not allowed by the C++ standard (see
\cite cgal:ansi-is14882-98, paragraph 14.1/9).
## No Common Parameterization Algorithm ##
`ParameterizerTraits_3` models modify the behavior of the global function
`CGAL::parameterize()` - hence the <I>Traits</I> in the name.
`parameterize()` - hence the <I>Traits</I> in the name.
On the other hand, `ParameterizerTraits_3` models do not modify the behavior
of a common parameterization algorithm - as you might expect.
@ -754,7 +754,7 @@ with default values adapted to the method.
\anchor Surface_mesh_parameterizationfigparameterizers_class_hierarchy
\image html parameterizers_class_hierarchy.png "Surface parameterizer classes hierarchy"
\note `CGAL::Parameterizer_traits_3<ParameterizationMesh_3>` is the (pure virtual)
\note `Parameterizer_traits_3<ParameterizationMesh_3>` is the (pure virtual)
superclass of all surface parameterization classes.
## %Fixed_border_parameterizer_3 Class ##
@ -763,7 +763,7 @@ Linear fixed border parameterization algorithms are very close. They mainly
differ by the energy that they try to minimize, i.e. by the value of the \f$ w_{ij}\f$
coefficient of the \f$ A\f$ matrix, for \f$ v_i\f$ and \f$ v_j\f$ neighbor vertices of the mesh
\cite cgal:fh-survey-05. One consequence is that most of the code of the fixed border methods is factorized in the
`CGAL::Fixed_border_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>` class.
`Fixed_border_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>` class.
Subclasses:
<UL>
@ -774,7 +774,7 @@ of matrix \f$ A\f$ for \f$ v_j\f$ neighbor vertex of \f$ v_i\f$,
<LI>may implement an optimized version of `is_one_to_one_mapping`().
</UL>
See `CGAL::Barycentric_mapping_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
See `Barycentric_mapping_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
class as an example.
## Border Parameterizations ##
@ -812,7 +812,7 @@ The current design of this package uses the second option, which is simpler.
Of course, we may decide at some point to switch to the first one to reach a deeper integration
of \cgal with Boost.
Point 3) is solved by class `CGAL::Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`,
Point 3) is solved by class `Parameterization_mesh_patch_3<ParameterizationPatchableMesh_3>`,
which takes care of <I>virtually</I> cutting
a patch in a `ParameterizationPatchableMesh_3` mesh, to make it appear as a topological disk
with a `ParameterizationMesh_3` interface.
@ -869,7 +869,7 @@ for \ref thirdpartyEigen "Eigen" and OpenNL are independent of the rest of the
Implementing a new fixed border linear parameterization is easy. Most
of the code of the fixed border methods is factorized in the
`CGAL::Fixed_border_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
`Fixed_border_parameterizer_3<ParameterizationMesh_3, BorderParameterizer_3, SparseLinearAlgebraTraits_d>`
class. Subclasses must mainly
implement a `compute_w_ij`() method which computes each
\f$ w_{ij}\f$ = \f$ (i, j)\f$ coefficient of the matrix \f$ A\f$ for \f$ v_j\f$ neighboring

6
Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt
View File

@ -203,17 +203,17 @@ are needed because the placement (and cost) changes.
## API Overview ##
Since the algorithm is free from robustness issues there is no need for exact predicates nor constructions and `Simple_cartesian<double>` can be used safely.
\footnote{In the current version, 3.3, the LindstromTurk policies are not implemented for homogeneous coordinates, so a cartesian kernel must be used.}
\footnote{In the current version, 3.3, the LindstromTurk policies are not implemented for homogeneous coordinates, so a %Cartesian kernel must be used.}
The simplification algorithm is implemented as the free template function
`CGAL::Surface_mesh_simplification::edge_collapse`. The function has two mandatory and several optional parameters.
`Surface_mesh_simplification::edge_collapse()`. The function has two mandatory and several optional parameters.
## Mandatory Parameters ##
There are two main parameters to the algorithm: the surface to be simplified (in-place) and the stop predicate.
The surface to simplify must be a model of the `EdgeCollapsableMesh` concept.
Many concrete surface types, such as `CGAL::Polyhedron_3` with only triangular faces,
Many concrete surface types, such as `Polyhedron_3` with only triangular faces,
become models of that concept via a technique known as
<I>external adaptation</I>, which is described in \cite cgal:sll-bgl-02
and this <span class="textsc">Bgl</span> web page: <A HREF="http://www.boost.org/libs/graph/doc/leda_conversion.html"><TT>http://www.boost.org/libs/graph/doc/leda_conversion.html</TT></A>

3
Triangulation_2/doc/TDS_2/TDS_2.txt
View File

@ -144,8 +144,7 @@ see Figure \ref TDS_2D_Fig_insertion,
\section TDS_2D_default The Default Triangulation Data Structure
\cgal provides the class
`CGAL::Triangulation_data_structure_2<Vb,Fb>`
\cgal provides the class `Triangulation_data_structure_2<Vb,Fb>`
as a default triangulation data structure.
## Flexibility ##

10
Triangulation_2/doc/Triangulation_2/Triangulation_2.txt
View File

@ -916,7 +916,7 @@ handle intersecting input constraints. One of them
is designed to be designed to be robust
when used in conjunction with a geometric traits
providing exact predicates and approximate constructions
(such as a `CGAL::Filtered_kernel` or any kernel providing
(such as a `Filtered_kernel` or any kernel providing
filtered exact predicates). The third version is designed to be used
with an exact arithmetic number type.
@ -929,9 +929,9 @@ As in the case of constraints triangulation, the third parameter
`Itag` is the intersection tag
and serves to choose how intersecting constraints
are dealt with. It can be instantiated with one of the following
classes: `CGAL::No_intersection_tag`,
`CGAL::Exact_predicates_tag`,
`CGAL::Exact_intersections_tag`
classes: `No_intersection_tag`,
`Exact_predicates_tag`,
`Exact_intersections_tag`
(see Section \ref Section_2D_Triangulations_Constrained).
A constrained Delaunay triangulation is not a Delaunay
@ -1019,7 +1019,7 @@ constrained edge, the set of input constraints that overlap it.
The class `Constrained_triangulation_plus_2<Tr>`
is especially useful when the base constrained triangulation class
handles intersections of constraints and uses an exact number type,
i.e. when its intersection tag is `CGAL::Exact_intersections_tag`.
i.e. when its intersection tag is `Exact_intersections_tag`.
Indeed in this case, the `Constrained_triangulation_plus_2<Tr>`
is specially designed to avoid cascading in the computations of
intersection points.

2
Triangulation_3/doc/Triangulation_3/Triangulation_3.txt
View File

@ -417,7 +417,7 @@ When the user doesn't need to add a type in a vertex which depends on the
`TriangulationDataStructure_3` (e.g. a `Vertex_handle` or
`Cell_handle`), then he can use the
`Triangulation_vertex_base_with_info_3` class to add his own information
easily in the vertices. The example below shows how to add a `CGAL::Color`
easily in the vertices. The example below shows how to add a `Color`
this way.
\cgalexample{Triangulation_3/color.cpp}

24
Voronoi_diagram_2/doc/Voronoi_diagram_2/Voronoi_diagram_2.txt
View File

@ -292,8 +292,8 @@ specifically it defines an `Edge_rejector` and a
`Face_rejector` functor that answer the question: "Should this
edge (face) of the Voronoi diagram be rejected?". In addition to the
edge and face rejectors the adaptation policy defines a tag, the
`Has_inserter` tag. This tag is either set to `CGAL::Tag_true`
or to `CGAL::Tag_false`. Semantically it determines if the adaptor
`Has_inserter` tag. This tag is either set to \tag_true
or to \tag_false. Semantically it determines if the adaptor
is allowed to insert sites in an on-line fashion (on-line removals are
not yet supported). In the former case, i.e., when on-line site
insertions are allowed, an additional functor is required, the
@ -312,7 +312,7 @@ Delaunay graph. The Voronoi diagram provided by the adaptor is the
true dual (from the graph-theoretical point of view) of the
triangulated Delaunay graph adapted. This policy assumes that the
Delaunay graph adapted allows for on-line insertions, and the
`Has_inserter` tag is set to `CGAL::Tag_true`. A default site
`Has_inserter` tag is set to `Tag_true`. A default site
inserter functor is also provided.
The second type of policy we provide is called
@ -381,9 +381,9 @@ modifications.
The way we indicate if we allow on-line insertions of sites is via the
`Has_inserter` tag (as mentioned, on-line removals are currently not
supported). The `Has_inserter` tag has two possible values,
namely, `CGAL::Tag_true` and `CGAL::Tag_false`. The value
`CGAL::Tag_true` indicates that the Delaunay graph allows for
on-line insertions, whereas the value `CGAL::Tag_false` indicates
namely, `Tag_true` and `Tag_false`. The value
`Tag_true` indicates that the Delaunay graph allows for
on-line insertions, whereas the value `Tag_false` indicates
the opposite. Note that these values <I>do not</I> indicate if the
Delaunay graph supports on-line insertions, but rather whether the
Voronoi diagram adaptor should be able to perform on-line insertions
@ -394,14 +394,14 @@ non-mutable, the Voronoi diagram adaptor cannot perform on-line
insertions of sites. In this case not only degeneracy removal
policies, but rather every single adaptation policy for
adapting the Delaunay graph in question should have the
`Has_inserter` tag set to `CGAL::Tag_false`.
`Has_inserter` tag set to `Tag_false`.
If the Delaunay graph is mutable, i.e., on-line site insertions as are
allowed, we can choose between two types of adaptation policies, those
that allow these on-line insertions and those that do not. In the
former case the `Has_inserter` tag should be set to
`CGAL::Tag_true`, whereas in the latter to
`CGAL::Tag_false`. In other words, even if the Delaunay graph is
`Tag_true`, whereas in the latter to
`Tag_false`. In other words, even if the Delaunay graph is
mutable, we can choose (by properly determining the value of the
`Has_inserter` tag) if the adaptor should be mutable as well. At a
first glance it may seem excessive to restrict existing
@ -418,9 +418,9 @@ results, and ideally we would like to do this in an efficient manner.
The inherent dilemma in the above discussion is whether the Voronoi
diagram adaptor should be able to perform on-line insertions of
sites. The answer to this question in this framework is given by the
`Has_inserter` tag. If the tag is set to `CGAL::Tag_false` the
`Has_inserter` tag. If the tag is set to `Tag_false` the
adaptor cannot insert sites on-line, whereas if the tag is set to
`CGAL::Tag_true` the adaptor can add sites on-line. In other
`Tag_true` the adaptor can add sites on-line. In other
words, the `Has_inserter` tag determines how the Voronoi diagram
adaptor should behave, and this is enough from the adaptor's point of
view.
@ -430,7 +430,7 @@ there: "Should the policy allow for on-line insertions or not?" The
answer really depends on what are the consequences of such a
choice. For a policy that has no state, such as our degeneracy removal
policies, it is natural to set the `Has_inserter` tag to
`CGAL::Tag_true`. For our caching degeneracy removal policies, our
`Tag_true`. For our caching degeneracy removal policies, our
choice was made on the grounds of whether we can update the cached
results efficiently when insertions are performed. For \cgal's
Apollonius graphs, Delaunay triangulation and regular triangulations