From a76bd6081e822eaf8c82e02806e6e8eece2eed7b Mon Sep 17 00:00:00 2001 From: Maxime Gimeno Date: Fri, 21 May 2021 15:28:54 +0200 Subject: [PATCH] Replace more sc text --- .../Algebraic_foundations.txt | 2 +- .../Algebraic_kernel_d/Algebraic_kernel_d.txt | 8 ++-- .../Arrangement_on_surface_2.txt | 39 +++++++++---------- .../CGAL/Arr_Bezier_curve_traits_2.h | 2 +- .../CGAL/Arr_conic_traits_2.h | 2 +- .../CGAL/Arr_dcel_base.h | 10 ++--- .../CGAL/Arr_default_dcel.h | 4 +- .../CGAL/Arr_default_overlay_traits.h | 10 ++--- .../CGAL/Arr_extended_dcel.h | 14 +++---- .../CGAL/Arr_overlay_2.h | 8 ++-- .../CGAL/Arrangement_2.h | 8 ++-- .../CGAL/Arrangement_with_history_2.h | 6 +-- .../CGAL/IO/Arr_iostream.h | 2 +- .../CGAL/IO/Arr_text_formatter.h | 6 +-- .../CGAL/IO/Arr_with_history_iostream.h | 2 +- .../Concepts/ArrangementDcel.h | 6 +-- .../Concepts/ArrangementDcelFace.h | 6 +-- .../Concepts/ArrangementDcelHalfedge.h | 8 ++-- .../Concepts/ArrangementDcelHole.h | 4 +- .../Concepts/ArrangementDcelIsolatedVertex.h | 4 +- .../Concepts/ArrangementDcelVertex.h | 8 ++-- .../Concepts/ArrangementDcelWithRebind.h | 2 +- .../ArrangementOpenBoundaryTraits_2.h | 2 +- .../Concepts/OverlayTraits.h | 6 +-- .../Boolean_set_operations_2.txt | 12 +++--- .../Gps_default_dcel.h | 12 +++--- .../CGAL/General_polygon_set_2.h | 4 +- .../CGAL/Polygon_set_2.h | 2 +- .../doc/Convex_hull_3/Convex_hull_3.txt | 2 +- .../Developer_manual/Chapter_portability.txt | 6 +-- .../doc/resources/1.8.13/BaseDoxyfile.in | 4 ++ .../doc/resources/1.8.14/BaseDoxyfile.in | 4 ++ .../doc/resources/1.8.20/BaseDoxyfile.in | 4 ++ .../doc/resources/1.8.4/BaseDoxyfile.in | 4 ++ .../doc/Geomview/CGAL/IO/Geomview_stream.h | 2 +- Geomview/doc/Geomview/Geomview.txt | 2 +- .../doc/Minkowski_sum_2/Minkowski_sum_2.txt | 2 +- .../Modular_arithmetic/Modular_arithmetic.txt | 2 +- .../doc/Number_types/CGAL/CORE_BigFloat.h | 2 +- .../doc/Number_types/CGAL/CORE_BigInt.h | 2 +- .../doc/Number_types/CGAL/CORE_BigRat.h | 2 +- .../doc/Number_types/CGAL/CORE_Expr.h | 2 +- Number_types/doc/Number_types/CGAL/Gmpfi.h | 7 ++-- Number_types/doc/Number_types/CGAL/Gmpfr.h | 16 ++++---- Number_types/doc/Number_types/CGAL/Gmpq.h | 2 +- Number_types/doc/Number_types/CGAL/Gmpz.h | 4 +- Number_types/doc/Number_types/CGAL/Gmpzf.h | 2 +- Number_types/doc/Number_types/CGAL/Mpzf.h | 7 ++-- Number_types/doc/Number_types/CGAL/gmpxx.h | 8 ++-- .../doc/Number_types/CGAL/leda_integer.h | 2 +- .../doc/Number_types/CGAL/leda_rational.h | 2 +- .../doc/Number_types/NumberTypeSupport.txt | 20 +++++----- Polynomial/doc/Polynomial/Polynomial.txt | 4 +- .../Policies/Edge_collapse/Edge_profile.h | 6 +-- .../Surface_mesh_simplification.txt | 2 +- .../doc/Triangulation_3/Triangulation_3.txt | 2 +- 56 files changed, 168 insertions(+), 155 deletions(-) diff --git a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt index de0ca3695a4..890716d2c09 100644 --- a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt +++ b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt @@ -267,7 +267,7 @@ compute the least common multiple of the denominators. The package is part of \cgal since release 3.3. Of course the package is based on the former Number type support of CGAL. This goes back to Stefan Schirra and Andreas Fabri. But on the other hand the package is to a large extend influenced -by the experience with the number type support in Exacus \cgalCite{beh-eeeafcs-05}, +by the experience with the number type support in \exacus \cgalCite{beh-eeeafcs-05}, which in the main goes back to Lutz Kettner, Susan Hert, Arno Eigenwillig and Michael Hemmer. However, the package abstracts from the pure support for diff --git a/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt b/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt index a14af4da5c6..f7090c76a10 100644 --- a/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt +++ b/Algebraic_kernel_d/doc/Algebraic_kernel_d/Algebraic_kernel_d.txt @@ -310,7 +310,7 @@ that does not follow the generic programming paradigm, by avoiding 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 Mpfr \cgalCite{cgal:mt-mpfr} and Mpfi \cgalCite{cgal:r-mpfi} +make heavy use of the \mpfr \cgalCite{cgal:mt-mpfr} and \mpfi \cgalCite{cgal:r-mpfi} 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 `Gmpfi` interval and a pointer to @@ -368,12 +368,12 @@ ideas that was brought to them throughout the last years. In particular, they want to thank Menelaos Karavelas and Elias Tsigaridas for their initial contributions. -The two generic models where initially developed as part of the Exacus \cgalCite{beh-eeeafcs-05} project. +The two generic models where initially developed as part of the \exacus \cgalCite{beh-eeeafcs-05} project. However, the models are now fully integrated into the \cgal library, -since also the relevant layers of Exacus are now part of \cgal. +since also the relevant layers of \exacus are now part of \cgal. The main authors for `Algebraic_kernel_d_1` and `Algebraic_kernel_d_2` are Michael Hemmer and Michael Kerber, respectively. Notwithstanding, the authors also want to emphasize the -contribution of all authors of the Exacus project, +contribution of all authors of the \exacus project, particularly the contribution of Arno Eigenwillig, Sebastian Limbach and Pavel Emeliyanenko. The two univariate kernels that interface the library RS \cgalCite{cgal:r-rs} were diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt index b45bc3ab794..93cf048521b 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt @@ -662,9 +662,9 @@ functions can be used. The program works in three steps, as demonstrated in \cgalFigureRef{arr_figex_3}. Note that here we still stick to integer coordinates, but as we work on a larger scale we use an unbounded integer number-type (in this -case, the `Gmpz` type taken from the Gmp library) +case, the `Gmpz` type taken from the \gmp library) instead of the built-in `int` type.\cgalFootnote{As a rule of thumb, one can use a bounded integer type for representing line segments whose coordinates are bounded by \f$ \lfloor\sqrt[3]{M}\rfloor\f$, where \f$ M\f$ is the maximal representable integer value. This guarantees that no overflows occur in the computations carried out by the traits class, hence all traits-class predicates always return correct results.} -In case the Gmp library is not installed (as indicated by +In case the \gmp library is not installed (as indicated by the `CGAL_USE_GMP` flag defined in `CGAL/basic.h`), we use `MP_Float`, a number-type included in \cgal's support library that is capable of storing floating-point numbers with @@ -2064,8 +2064,7 @@ rational numbers, and this ensures the robustness and correctness of any computation.\cgalFootnote{Many of the example programs in the rest of the chapter include a header file named `arr_rational_nt.h`, which defines a type named `Number_type` as either `Gmpq` or -`Quotient`, depending on whether Gmp is installed or not.} +`Quotient`, depending on whether \gmp is installed or not.} An instance of the `Arr_segment_traits_2` class template can be very efficient for constructing arrangements induced @@ -2480,7 +2479,7 @@ and extracting the real roots of a polynomial with integer coefficients. It is highly recommended to use the `CORE_algebraic_number_traits` class, which is included in the arrangement package. It relies on the exact number types -implemented in the Core library and performs exact +implemented in the \core library and performs exact computations on the number types it defines. @@ -3588,15 +3587,15 @@ and defines a simple textual input/output format. \section arr_secbgl Adapting to Boost Graphs -Boost\cgalFootnote{See also Boost's homepage at: www.boost.org.} -is a collection of portable \cpp libraries that extend the Standard Template Library (Stl). The Boost Graph Library (bgl), which one of the libraries in the collection, offers an +\boost\cgalFootnote{See also \boost's homepage at: www.boost.org.} +is a collection of portable \cpp libraries that extend the Standard Template Library (\stl). The \boost Graph Library (\bgl), which one of the libraries in the collection, offers an extensive set of generic graph algorithms parameterized through templates. As our arrangements are embedded as planar graphs, it is only natural to extend the underlying data structure with the interface that the -bgl expects, and gain the ability to perform the operations that the bgl supports, such as shortest-path computation. This section describes how apply -the graph algorithms implemented in the bgl to `Arrangement_2` instances. +\bgl expects, and gain the ability to perform the operations that the \bgl supports, such as shortest-path computation. This section describes how apply +the graph algorithms implemented in the \bgl to `Arrangement_2` instances. -An instance of `Arrangement_2` is adapted to a Boost graph through the +An instance of `Arrangement_2` is adapted to a \boost graph through the provision of a set of free functions that operate on the arrangement features and conform with the relevant BGL concepts. Besides the straightforward adaptation, which associates a vertex with each \dcel vertex and an edge @@ -3607,7 +3606,7 @@ faces. \subsection arr_ssecbgl_primal The Primal Arrangement Representation -Arrangement instances are adapted to Boost graphs by specializing the +Arrangement instances are adapted to \boost graphs by specializing the \link BGLArgtGT `boost:graph_traits` \endlink template for `Arrangement_2` instances. The graph-traits states the graph concepts that the arrangement class models (see below) and defines the types required by these concepts. @@ -3620,11 +3619,11 @@ graph-edge type. As halfedges are directed, we consider the graph to be directed as well. Moreover, as several interior-disjoint \f$ x\f$-monotone curves (say circular arcs) may share two common endpoints, inducing an arrangement with two vertices that are connected with several edges, we allow parallel -edges in our Boost graph. +edges in our \boost graph. Given an `Arrangement_2` instance, we can efficiently traverse its vertices and halfedges. Thus, the arrangement graph is a model of the concepts -`VertexListGraph` and `EdgeListGraph` introduced by the bgl. +`VertexListGraph` and `EdgeListGraph` introduced by the \bgl. At the same time, we use an iterator adapter of the circulator over the halfedges incident to a vertex (`Halfedge_around_vertex_circulator` - see Section \ref arr_sssectr_vertex), so it is possible to go over the ingoing @@ -3634,17 +3633,17 @@ is a model of the concept `BidirectionalGraph` (this concept refines It is important to notice that the vertex descriptors we use are `Vertex_handle` objects and not vertex indices. However, in order -to gain more efficiency in most bgl algorithm, it is better to have them +to gain more efficiency in most \bgl algorithm, it is better to have them indexed \f$ 0, 1, \ldots, (n-1)\f$, where \f$ n\f$ is the number of vertices. We therefore introduce the `Arr_vertex_index_map` class-template, which maintains a mapping of vertex handles to indices, as required by the -bgl. An instance of this class must be attached to a valid arrangement +\bgl. An instance of this class must be attached to a valid arrangement vertex when it is created. It uses the notification mechanism (see Section \ref arr_secnotif) to automatically maintain the mapping of vertices to indices, even when new vertices are inserted into the arrangement or existing vertices are removed. -In most algorithm provided by the bgl, the output is given by +In most algorithm provided by the \bgl, the output is given by property maps, such that each map entry corresponds to a vertex. For example, when we compute the shortest paths from a given source vertex \f$ s\f$ to all other vertices we can obtain a map of distances and a map of @@ -3659,7 +3658,7 @@ allows for an efficient mapping of `Vertex_handle` objects to properties of type `Type`. Note however that unlike the `Arr_vertex_index_map` class, the vertex property-map class is not kept synchronized with the number of vertices in the arrangement, so it -should not be reused in calls to bgl functions in case the arrangement +should not be reused in calls to \bgl functions in case the arrangement is modified in between these calls. \cgalFigureBegin{arr_figex_bgl,ex_bgl.png} @@ -3668,7 +3667,7 @@ An arrangement of 7 line segments, as constructed by `bgl_primal_adapter.cpp` an In the following example we construct an arrangement of 7 line segments, as shown in \cgalFigureRef{arr_figex_bgl}, -then use Dijkstra's shortest-paths algorithm from the bgl to compute +then use Dijkstra's shortest-paths algorithm from the \bgl to compute the graph distance of all vertices from the leftmost vertex in the arrangement \f$ v_0\f$. Note the usage of the `boost::vector_property_map` and the `Arr_vertex_property_map` classes. The latter one, instantiated by @@ -3692,7 +3691,7 @@ graph-edge type. We treat the graph edges as directed, such that a halfedge `e` is directed from \f$ f_1\f$, which is its incident face, to \f$ f_2\f$, which is the incident face of its twin halfedge. As two arrangement faces may share more than a single edge on their boundary, we allow parallel -edges in our Boost graph. As is the case in the primal graph, the dual +edges in our \boost graph. As is the case in the primal graph, the dual arrangement graph is also a model of the concepts `VertexListGraph`, `EdgeListGraph` and `BidirectionalGraph` (thus also of `IncidenceGraph`). @@ -3740,7 +3739,7 @@ exhibits slightly better performance than the default one (`Arr_segment_traits_2` even when the segments intersect each other, due to the small overhead of the latter (optimized) traits class. (For example, when the so -called Leda rational kernel is used). +called \leda rational kernel is used).
  • Prior knowledge of the combinatorial structure of the arrangement can be used to accelerate operations that insert \f$ x\f$-monotone curves, diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h index 138274e1305..b013c2be1ad 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_Bezier_curve_traits_2.h @@ -43,7 +43,7 @@ geometric kernels templated with the `NtTraits::Rational` and instantiate the `CORE_algebraic_number_traits` class as the `NtTraits` parameter, with `Cartesian` and `Cartesian` instantiating the two kernel types, -respectively. The number types in this case are provided by the Core +respectively. The number types in this case are provided by the \core library, with its ability to exactly represent simple algebraic numbers. While `Arr_Bezier_curve_traits_2` models the concept diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h index 36af11a5e52..74c0bd8d1e0 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_conic_traits_2.h @@ -61,7 +61,7 @@ It is recommended to instantiate the `CORE_algebraic_number_traits` class as the `NtTraits` parameter, with `Cartesian` and `Cartesian` instantiating the two kernel types, respectively. -The number types in this case are provided by the Core library, with its +The number types in this case are provided by the \core library, with its ability to exactly represent simple algebraic numbers. The traits class inherits its point type from `AlgKernel::Point_2`, diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h index 4697a9c2bc3..8f9202a3a13 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_dcel_base.h @@ -7,11 +7,11 @@ namespace CGAL { \anchor arr_refarr_dcel_base The `Arr_dcel_base` class is an important ingredient in the -definition of Dcel data structures. It serves as a basis class for +definition of \dcel data structures. It serves as a basis class for any instance of the `Dcel` template parameter of the `Arrangement_2` template. In particular it is the basis class of the default `Dcel` template parameter, and the basis class of any -extended Dcel. The template parameters `V`, `H`, and `F` +extended \dcel. The template parameters `V`, `H`, and `F` must be instantiated with models of the concepts `ArrangementDcelVertex`, `ArrangementDcelHalfedge`, and `ArrangementDcelFace` respectively. @@ -26,7 +26,7 @@ public: /*! -The basic Dcel face type. Serves as a basis class for an extended +The basic \dcel face type. Serves as a basis class for an extended face record with auxiliary data fields. \cgalModels `ArrangementDcelFace` @@ -39,7 +39,7 @@ class Arr_face_base { /*! -The basic Dcel halfedge type. Serves as a basis class for an +The basic \dcel halfedge type. Serves as a basis class for an extended halfedge record with auxiliary data fields. The `Curve` parameter is the type of \f$ x\f$-monotone curves associated with the vertices. @@ -54,7 +54,7 @@ class Arr_halfedge_base { /*! -The basic Dcel vertex type. Serves as a basis class for an extended +The basic \dcel vertex type. Serves as a basis class for an extended vertex record with auxiliary data fields. The `Point` parameter is the type of points associated with the vertices. diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h index bb8ce9bed4a..8da592fa207 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_dcel.h @@ -4,12 +4,12 @@ namespace CGAL { /*! \ingroup PkgArrangementOnSurface2DCEL -The default Dcel class used by the `Arrangement_2` class-template +The default \dcel class used by the `Arrangement_2` class-template is parameterized by a traits class, which is a model of the `ArrangementBasicTraits_2` concept. It simply uses the nested `Traits::Point_2` and `Traits::X_monotone_curve_2` to instantiate the base vertex and halfedge types, respectively. Thus, the default -Dcel records store no other information, except for the topological +\dcel records store no other information, except for the topological incidence relations and the geometric data attached to vertices and edges. \cgalModels `ArrangementDcelWithRebind` diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h index 072d4b24fc1..6419b1af7ae 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_default_overlay_traits.h @@ -6,8 +6,8 @@ namespace CGAL { \ingroup PkgArrangementOnSurface2Overlay An instance of `Arr_default_overlay_traits` should be used for overlaying two arrangements -of type `Arrangement` that store no auxiliary data with their Dcel records, where the resulting overlaid arrangement stores no auxiliary -Dcel data as well. This class simply gives empty implementation for all +of type `Arrangement` that store no auxiliary data with their \dcel records, where the resulting overlaid arrangement stores no auxiliary +\dcel data as well. This class simply gives empty implementation for all traits-class functions. \cgalModels `OverlayTraits` @@ -30,10 +30,10 @@ namespace CGAL { An instance of `Arr_face_overlay_traits` should be used for overlaying two arrangements of types `Arr_A` and `Arr_B`, which are instantiated using the same -geometric traits-class and with the Dcel classes `Dcel_A` and +geometric traits-class and with the \dcel classes `Dcel_A` and `Dcel_B` respectively, in order to store their overlay in an arrangement -of type `Arr_R`, which is instantiated using a third Dcel class -`Dcel_R`. All three Dcel classes are assumed to be instantiations of the +of type `Arr_R`, which is instantiated using a third \dcel class +`Dcel_R`. All three \dcel classes are assumed to be instantiations of the `Arr_face_extended_dcel` template with types `FaceData_A`, `FaceData_B` and `FaceData_R`, respectively. diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h index fce858fb241..b06910d1e14 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_extended_dcel.h @@ -4,11 +4,11 @@ namespace CGAL { /*! \ingroup PkgArrangementOnSurface2DCEL -The `Arr_extended_dcel` class-template extends the topological-features of the Dcel +The `Arr_extended_dcel` class-template extends the topological-features of the \dcel namely the vertex, halfedge, and face types. While it is possible to maintain extra (non-geometric) data with the curves or points of the arrangement by extending their types respectively, it is also possible to extend the vertex, -halfedge, or face types of the Dcel through inheritance. As the technique to +halfedge, or face types of the \dcel through inheritance. As the technique to extend these types is somewhat cumbersome and difficult for inexperienced users, the `Arr_extended_dcel` class-template provides a convenient way to do that. Each one of the three features is extended with a corresponding data type @@ -54,7 +54,7 @@ namespace CGAL { \ingroup PkgArrangementOnSurface2DCEL The `Arr_extended_face` class-template extends the face topological-features of the -Dcel. It is parameterized by a face base-type `FaceBase` and a data type +\dcel. It is parameterized by a face base-type `FaceBase` and a data type `FData` used to extend the face base-type. \cgalModels `ArrangementDcelFace` @@ -106,7 +106,7 @@ namespace CGAL { \ingroup PkgArrangementOnSurface2DCEL The `Arr_extended_halfedge` class-template extends the halfedge topological-features of -the Dcel. It is parameterized by a halfedge base-type `HalfedgeBase` +the \dcel. It is parameterized by a halfedge base-type `HalfedgeBase` and a data type `HData` used to extend the halfedge base-type. \cgalModels `ArrangementDcelHalfedge` @@ -158,7 +158,7 @@ namespace CGAL { \ingroup PkgArrangementOnSurface2DCEL The `Arr_extended_vertex` class-template extends the vertex -topological-features of the Dcel. It is parameterized by a +topological-features of the \dcel. It is parameterized by a vertex base-type `VertexBase` and a data type `VData` used to extend the vertex base-type. @@ -210,12 +210,12 @@ namespace CGAL { /*! \ingroup PkgArrangementOnSurface2DCEL -The `Arr_face_extended_dcel` class-template extends the Dcel face-records, making it +The `Arr_face_extended_dcel` class-template extends the \dcel face-records, making it possible to store extra (non-geometric) data with the arrangement faces. The class should be instantiated by an `FData` type which represents the extra data stored with each face. -Note that all types of Dcel features (namely vertex, halfedge and face) +Note that all types of \dcel features (namely vertex, halfedge and face) are provided as template parameters. However, by default they are defined as follows: diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h index 80c4a062c1c..bd1e4534d0f 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_overlay_2.h @@ -9,13 +9,13 @@ the output arrangement `res` to represent the overlaid arrangement. Computes the overlay of two input arrangement objects, and returns the overlaid arrangement. All three arrangements can be instantiated with different geometric traits classes and different -Dcel classes (encapsulated in the various topology-traits classes). +\dcel classes (encapsulated in the various topology-traits classes). The geometry traits of the resulting arrangement is used to construct the resulting arrangement. This means that all the types (e.g., `Traits::Point_2`, `Traits::Curve_2`, and `Traits::Point_2`) of both input arrangements have to be convertible to the types in the resulting arrangement. A given overlay-traits object is used to properly -construct the overlaid Dcel that represents the resulting arrangement. +construct the overlaid \dcel that represents the resulting arrangement. \pre `res` does not refer to either `arr1` or `arr2` (that is, "self overlay" is not supported). @@ -45,13 +45,13 @@ consolidated set of curves that induce `res`. Computes the overlay of two input arrangement objects, and returns the overlaid arrangement. All three arrangements can be instantiated with different geometric traits classes and different -Dcel classes (encapsulated in the various topology-traits classes). +\dcel classes (encapsulated in the various topology-traits classes). The geometry traits of the resulting arrangement is used to construct the resulting arrangement. This means that all the types (e.g., `Traits::Point_2`, `Traits::Curve_2`, and `Traits::Point_2`) of both input arrangements have to be convertible to the types in the resulting arrangement. A given overlay-traits object is used to properly -construct the overlaid Dcel that represents the resulting arrangement. +construct the overlaid \dcel that represents the resulting arrangement. \pre `res` does not refer to either `arr1` or `arr2` (that is, "self overlay" is not supported). diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h index 88921e98901..e6cc8b14cc1 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_2.h @@ -8,11 +8,11 @@ namespace CGAL { An object `arr` of the class `Arrangement_2` represents the planar subdivision induced by a set of \f$ x\f$-monotone curves and isolated points into maximally connected cells. The arrangement is represented as - a doubly-connected edge-list (Dcel) such that each Dcel vertex + a doubly-connected edge-list (\dcel) such that each \dcel vertex is associated with a point of the plane and each edge is associated with an \f$ x\f$-monotone curve whose interior is disjoint from all other edges and vertices. Recall that an arrangement - edge is always comprised of a pair of twin Dcel halfedges. + edge is always comprised of a pair of twin \dcel halfedges. The `Arrangement_2` template has two parameters:
      @@ -26,7 +26,7 @@ namespace CGAL { value of this parameter is by default `Arr_default_dcel`.
    - The available traits classes and Dcel classes are described below. + The available traits classes and \dcel classes are described below. \sa `ArrangementDcel` \sa `Arr_default_dcel` @@ -71,7 +71,7 @@ public: typedef Traits Traits_2; /*! - the Dcel representation of the arrangement. + the \dcel representation of the arrangement. */ typedef unspecified_type Dcel; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_with_history_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_with_history_2.h index 46ca16249c6..6541dd91374 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_with_history_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arrangement_with_history_2.h @@ -8,8 +8,8 @@ namespace CGAL { An object `arr` of the class `Arrangement_with_history_2` represents the planar subdivision induced by a set of input curves \f$ \cal C\f$. -The arrangement is represented as a doubly-connected edge-list (Dcel). -As is the case for the `Arrangement_2`, each Dcel +The arrangement is represented as a doubly-connected edge-list (\dcel). +As is the case for the `Arrangement_2`, each \dcel vertex is associated with a point and each edge is associated with an \f$ x\f$-monotone curve whose interior is disjoint from all other edges and vertices. Each such \f$ x\f$-monotone curve is a subcurve of some @@ -66,7 +66,7 @@ the traits class in use. typedef unspecified_type Traits_2; /*! -the Dcel representation of the arrangement. +the \dcel representation of the arrangement. */ typedef unspecified_type Dcel; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_iostream.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_iostream.h index 4b18dcd6656..7aa284b171a 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_iostream.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_iostream.h @@ -80,7 +80,7 @@ Inserts the arrangement object `arr` into the output stream `os` using the output format defined by the `Arr_text_formatter` class. Only the basic geometric and topological features of the arrangement are inserted. Auxiliary data -that may be attached to the Dcel features is ignored. +that may be attached to the \dcel features is ignored. */ template std::ostream& operator<< (std::ostream& os, diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_text_formatter.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_text_formatter.h index aa00f86e82d..fa5d3ff9698 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_text_formatter.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_text_formatter.h @@ -7,7 +7,7 @@ namespace CGAL { `Arr_extended_dcel_text_formatter` defines the format of an arrangement in an input or output stream (typically a file stream), thus enabling reading and writing an `Arrangement` instance using a simple text format. The `Arrangement` class should be -instantiated with a Dcel class which in turn instantiates the +instantiated with a \dcel class which in turn instantiates the `Arr_extended_dcel` template with the `VertexData`, `HalfedgeData` and `FaceData` types. The formatter supports reading and writing the data objects attached to the @@ -41,7 +41,7 @@ namespace CGAL { `Arr_face_extended_text_formatter` defines the format of an arrangement in an input or output stream (typically a file stream), thus enabling reading and writing an `Arrangement` instance using a simple text format. The `Arrangement` class should be -instantiated with a Dcel class which in turn instantiates the +instantiated with a \dcel class which in turn instantiates the `Arr_face_extended_dcel` template with a `FaceData` type. The formatter supports reading and writing the data objects attached to the arrangement faces as well. @@ -73,7 +73,7 @@ namespace CGAL { `Arr_text_formatter` defines the format of an arrangement in an input or output stream (typically a file stream), thus enabling reading and writing an `Arrangement` instance using a simple text format. The arrangement is assumed to store no auxiliary -data with its Dcel records (and if there are such records they will not be written +data with its \dcel records (and if there are such records they will not be written or read by the formatter). The `Arr_text_formatter` class assumes that the nested `Point_2` and the `Curve_2` types diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_with_history_iostream.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_with_history_iostream.h index 084ec73f6bd..968bda50939 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_with_history_iostream.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/IO/Arr_with_history_iostream.h @@ -36,7 +36,7 @@ Inserts the arrangement-with-history object `arr` into the output stream `os` using the output format defined by the `Arr_with_history_text_formatter` class. Only the basic geometric and topological features of the arrangement are inserted. Auxiliary -data that may be attached to the Dcel features is ignored. +data that may be attached to the \dcel features is ignored. */ template std::ostream& operator<< (std::ostream& os, diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcel.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcel.h index 16ee1ffbc1a..b9f1414102f 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcel.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcel.h @@ -3,7 +3,7 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -A doubly-connected edge-list (Dcel for short) data-structure. It consists +A doubly-connected edge-list (\dcel for short) data-structure. It consists of three containers of records: vertices \f$ V\f$, halfedges \f$ E\f$, and faces \f$ F\f$. It maintains the incidence relation among them. The halfedges are ordered in pairs sometimes referred to as twins, such that each halfedge pair @@ -112,12 +112,12 @@ typedef unspecified_type Face_const_iterator; /// @{ /*! -constructs an empty Dcel with one unbounded face. +constructs an empty \dcel with one unbounded face. */ Arr_dcel(); /*! -assigns the contents of the `other` Dcel whose unbounded face +assigns the contents of the `other` \dcel whose unbounded face is given by `uf`, to `dcel`. The function returns a pointer to the unbounded face of `dcel` after the assignment. */ diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelFace.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelFace.h index b13dcc720c0..e6a788c82da 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelFace.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelFace.h @@ -3,7 +3,7 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -A face record in a Dcel data structure. A face may either be unbounded, +A face record in a \dcel data structure. A face may either be unbounded, otherwise it has an incident halfedge along the chain defining its outer boundary. A face may also contain holes and isolated vertices in its interior. @@ -22,12 +22,12 @@ public: /// @{ /*! -the corresponding Dcel vertex type. +the corresponding \dcel vertex type. */ typedef unspecified_type Vertex; /*! -the corresponding Dcel halfedge type. +the corresponding \dcel halfedge type. */ typedef unspecified_type Halfedge; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHalfedge.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHalfedge.h index 83083ef5499..980309cca44 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHalfedge.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHalfedge.h @@ -3,7 +3,7 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -A halfedge record in a Dcel data structure. Two halfedges with opposite +A halfedge record in a \dcel data structure. Two halfedges with opposite directions always form an edge (a halfedge pair). The halfedges form together chains, defining the boundaries of connected components, such that all halfedges along a chain have the same incident face. Note that the chain the @@ -29,17 +29,17 @@ public: /// @{ /*! -the corresponding Dcel vertex type. +the corresponding \dcel vertex type. */ typedef unspecified_type Vertex; /*! -the corresponding Dcel face type. +the corresponding \dcel face type. */ typedef unspecified_type Face; /*! -the corresponding Dcel hole type. +the corresponding \dcel hole type. */ typedef unspecified_type Hole; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHole.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHole.h index 9b2b7563a29..f739d1eee8a 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHole.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelHole.h @@ -3,7 +3,7 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -A hole record in a Dcel data structure, which stores the face that contains +A hole record in a \dcel data structure, which stores the face that contains the hole in its interior, along with an iterator for the hole in the holes' container of this face. @@ -19,7 +19,7 @@ public: /// @{ /*! -the corresponding Dcel face type. +the corresponding \dcel face type. */ typedef unspecified_type Face; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelIsolatedVertex.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelIsolatedVertex.h index c0665b13bc4..633747e65fd 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelIsolatedVertex.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelIsolatedVertex.h @@ -3,7 +3,7 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -An isolated vertex-information record in a Dcel data structure, which stores +An isolated vertex-information record in a \dcel data structure, which stores the face that contains the isolated vertex in its interior, along with an iterator for the isolated vertex in the isolated vertices' container of this face. @@ -20,7 +20,7 @@ public: /// @{ /*! -the corresponding Dcel face type. +the corresponding \dcel face type. */ typedef unspecified_type Face; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelVertex.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelVertex.h index f837d8ee00f..d4eb01ee7c3 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelVertex.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelVertex.h @@ -3,13 +3,13 @@ \ingroup PkgArrangementOnSurface2ConceptsDCEL \cgalConcept -A vertex record in a Dcel data structure. A vertex is always associated +A vertex record in a \dcel data structure. A vertex is always associated with a point. However, the vertex record only stores a pointer to the associated point, and the actual `Point` object is stored elsewhere. A vertex usually has several halfedges incident to it, such that it is possible to access one of these halfedges directly and to traverse all -incident halfedges around the vertex. However, the Dcel may also contain +incident halfedges around the vertex. However, the \dcel may also contain isolated vertices that have no incident halfedges. In this case, the vertex stores an isolated vertex-information record, indicating the face that contains this vertex in its interior. @@ -27,12 +27,12 @@ public: /// @{ /*! -the corresponding Dcel halfedge type. +the corresponding \dcel halfedge type. */ typedef unspecified_type Halfedge; /*! -the corresponding Dcel isolated +the corresponding \dcel isolated vertex-information type. */ typedef unspecified_type Isolated_vertex; diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelWithRebind.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelWithRebind.h index da1306eba60..2f6b152e345 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelWithRebind.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementDcelWithRebind.h @@ -39,7 +39,7 @@ typedef unspecified_type template rebind; /// @{ /*! -constructs an empty Dcel with one unbouned face. +constructs an empty \dcel with one unbouned face. */ Arr_dcel(); diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementOpenBoundaryTraits_2.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementOpenBoundaryTraits_2.h index 3a2977d46bb..3f4bb7e7188 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementOpenBoundaryTraits_2.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/ArrangementOpenBoundaryTraits_2.h @@ -31,7 +31,7 @@ concept are expected to be open on the right, open at the bottom, or open at the top, the corresponding nested type must be convertible to `CGAL::Arr_open_side_tag`. A model of the concept `ArrangementOpenBoundaryTraits_2` must have all the four categories convertible to -`CGAL::Arr_open_side_tag`.\cgalFootnote{We intend to introduce more concepts that require only a subset of the categories to be convertible to `Arr_open_side_tag`.} In this case the Dcel of the arrangement +`CGAL::Arr_open_side_tag`.\cgalFootnote{We intend to introduce more concepts that require only a subset of the categories to be convertible to `Arr_open_side_tag`.} In this case the \dcel of the arrangement instantiated with the model is initialized with an implicit bounding rectangle. When the parameter space is bounded, it is the exact geometric embedding of the implicit bounding rectangle. diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/OverlayTraits.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/OverlayTraits.h index 4647f40b180..9221705a709 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/OverlayTraits.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Concepts/OverlayTraits.h @@ -4,11 +4,11 @@ \cgalConcept A model for the `OverlayTraits` should be able to operate on records (namely, -vertices, halfedges and faces) of two input Dcel classes, named -`Dcel_A` and `Dcel_B`, and construct the records of an output Dcel class, referred to as `Dcel_R`. +vertices, halfedges and faces) of two input \dcel classes, named +`Dcel_A` and `Dcel_B`, and construct the records of an output \dcel class, referred to as `Dcel_R`. Models for the concept are used by the global `overlay()` function to -maintain the auxiliary data stored with the Dcel records of the resulting +maintain the auxiliary data stored with the \dcel records of the resulting overlaid arrangement, based on the contents of the input records. \cgalHasModel `CGAL::Arr_default_overlay_traits` diff --git a/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt b/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt index 9529d732022..0b8bf34ad22 100644 --- a/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt +++ b/Boolean_set_operations_2/doc/Boolean_set_operations_2/Boolean_set_operations_2.txt @@ -185,9 +185,9 @@ two input polygons. The example listed below tests whether the two triangles depicted on the right intersect. It uses, as do the other example programs in this chapter, the auxiliary header file `bso_rational_nt.h`, which defines the type `Number_type` as -Gmp's rational number-type (`Gmpq`), or as the +\gmp's rational number-type (`Gmpq`), or as the number type `Quotient` that is included in the support -library of \cgal, based on whether the Gmp library is installed +library of \cgal, based on whether the \gmp library is installed or not. It also uses the function `print_polygon.h` listed above, which is located in the header file `print_utils.h`. @@ -371,7 +371,7 @@ to represent this point set in the plane as a planar arrangement; see Chapter \ref chapterArrangement_on_surface_2 "2D Arrangements". The instantiated `Dcel` type is used to represent the underlying internal arrangement. It must model the concept `GeneralPolygonSetDcel`, and defaults to `Gps_default_dcel`. -You can override this default, with a different Dcel class, typically +You can override this default, with a different \dcel class, typically an extension of the default. Overriding the default is necessary only if you intend to obtain the underlying internal arrangement and process it further. @@ -572,15 +572,15 @@ The central class-template `General_polygon_set_2` is used to represent point sets that are comprised of a finite number of pairwise disjoint general polygons with holes, and provides various Boolean set-operations on such sets. It is parameterized by a traits -class and a Dcel class. The former defines the type of points used +class and a \dcel class. The former defines the type of points used to represent polygon vertices and the type of \f$ x\f$-monotone curves that represent the polygon edges. The traits class also provides primitive geometric operations that operate on objects of these types. -The Dcel class is used to represent the underlying internal +The \dcel class is used to represent the underlying internal `Arrangement_2` data structure. The instantiated `Dcel` type is used to represent the underlying internal arrangement. It must model the concept `GeneralPolygonSetDcel`, and defaults to `Gps_default_dcel`. -You can override this default, with a different Dcel class, typically +You can override this default, with a different \dcel class, typically an extension of the default. Overriding the default is necessary only if you intend to obtain the underlying internal arrangement and process it further. diff --git a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Boolean_set_operations_2/Gps_default_dcel.h b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Boolean_set_operations_2/Gps_default_dcel.h index a70de3fc84d..5880c9a1cb4 100644 --- a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Boolean_set_operations_2/Gps_default_dcel.h +++ b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Boolean_set_operations_2/Gps_default_dcel.h @@ -4,7 +4,7 @@ namespace CGAL { \ingroup PkgBooleanSetOperations2Ref An instance of this template serves as a basis type for any face record -of the Dcel class used by instances of the +of the \dcel class used by instances of the `General_polygon_set_2` and `General_polygon_with_holes_2` class templates. The `Point_2` and the `X_monotone_curve_2` template parameters are the types of @@ -25,7 +25,7 @@ class Gps_face_base : public Arr_face_base {}; \ingroup PkgBooleanSetOperations2Ref An instance of this teplate serves as a basis type for any halfedge record -of the Dcel class used by instances of the +of the \dcel class used by instances of the General_polygon_set_2` and `General_polygon_with_holes_2` class templates. The `X_monotone_curve_2` template parameter is the type of @@ -46,20 +46,20 @@ class Gps_halfedge_base : public Arr_halfedge_base /*! \ingroup PkgBooleanSetOperations2Ref -The default Dcel class template used by the +The default \dcel class template used by the `General_polygon_set_2` and `General_polygon_with_holes_2` class templates. This template is parameterized by a traits class, which is a model of the `GeneralPolygonSetTraits_2` concept. It uses the types `Traits::Point_2` and `Traits::X_monotone_curve_2` nested in the traits class to instantiate the base vertex, halfedge, and face types, respectively. Recall, that the -Dcel stores the incidence relations between +\dcel stores the incidence relations between the arrangement calls and the geometric data attached to vertices and edges. -This Dcel also stores data used to determine +This \dcel also stores data used to determine whether a face is interior and exterior of the general polygon set, and additional data used for optimizations. You need to override this default and use a different -Dcel only if you intend to obtain the underlying +\dcel only if you intend to obtain the underlying arrangement of the general polygon set and process it further. \cgalModels `GeneralPolygonSetDcel` diff --git a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/General_polygon_set_2.h b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/General_polygon_set_2.h index c5446377ab7..153a27dbd72 100644 --- a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/General_polygon_set_2.h +++ b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/General_polygon_set_2.h @@ -9,7 +9,7 @@ lie on the boundary or on the positive side of the curves. This class template provides methods to apply regularized Boolean set-operations and few other utility methods. An `Arrangement_2` data structure is internally used to represent the point set. The arrangement is -represented as a doubly-connected edge-list (Dcel). +represented as a doubly-connected edge-list (\dcel). The `Traits` template-parameter should be instantiated with a model of the concept `GeneralPolygonSetTraits_2`. The traits class @@ -29,7 +29,7 @@ the term polygon instead of general polygon for simplicity hereafter. The template parameter `Dcel` should be instantiated with a model of the concept `GeneralPolygonSetDcel`. It is instantiated by default with the type `Gps_default_dcel`. You can override -this default, with a different Dcel class, typically an extension +this default, with a different \dcel class, typically an extension of the `Gps_default_dcel` class template. Overriding the default is necessary only if you intend to obtain the underlying internal arrangement and process it further. diff --git a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Polygon_set_2.h b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Polygon_set_2.h index d426ebb55a3..952a75587de 100644 --- a/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Polygon_set_2.h +++ b/Boolean_set_operations_2/doc/Boolean_set_operations_2/CGAL/Polygon_set_2.h @@ -13,7 +13,7 @@ and the boundaries of all holes of every set member. The third template parameter `Dcel` must be instantiated with a model of the concept `GeneralPolygonSetDcel`. It is instantiated by default with the type `Gps_default_dcel`. You can override -this default, with a different Dcel class, typically an extension +this default, with a different \dcel class, typically an extension of the `Gps_default_dcel` class template. Overriding the default is necessary only if you intend to obtain the underlying internal arrangement and process it further. diff --git a/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt b/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt index 8f29c432a0c..0722e7456fb 100644 --- a/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt +++ b/Convex_hull_3/doc/Convex_hull_3/Convex_hull_3.txt @@ -166,7 +166,7 @@ the dynamic approach needed 9.50s. To compute the convex hull of the model of \cgalFigureRef{figchbimba} featuring 192135 points, the static approach needed 0.18s, while the dynamic approach needed 1.90s. -The measurements have been performed using \cgal 3.9, using the Gnu \cpp compiler version 4.3.5, under Linux (Debian distribution), +The measurements have been performed using \cgal 3.9, using the \gnu \cpp compiler version 4.3.5, under Linux (Debian distribution), with the compilation options -O3 -DCGAL_NDEBUG. The computer used was equipped with a 64bit Intel Xeon 2.27GHz processor and 12GB of RAM. */ diff --git a/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt b/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt index c05737d8e93..3012abe3afb 100644 --- a/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt +++ b/Documentation/doc/Documentation/Developer_manual/Chapter_portability.txt @@ -9,7 +9,7 @@ This chapter gives an overview of issues related to the configuration of \cgal that allow you to answer such questions as:
      -
    • Is \em LEDA / Gmp there? (Section \ref secleda_gmp_support) +
    • Is \em LEDA / \gmp there? (Section \ref secleda_gmp_support)
    • Which compiler is this? (Section \ref secwhich_compiler )
    • Does the compiler support feature X? (Section \ref secworkaround_flags )
    @@ -290,8 +290,8 @@ up-to-date version of this list.
    CGAL_CFG_NO_LONG_LONG
    The `long long` built-in integral type is not part of the - Iso C++ standard, but many compilers support it - nevertheless, since it is part of the Iso C standard. This + \iso C++ standard, but many compilers support it + nevertheless, since it is part of the \iso C standard. This flag is set if it is supported.
    CGAL_CFG_NO_TMPL_IN_TMPL_PARAM
    diff --git a/Documentation/doc/resources/1.8.13/BaseDoxyfile.in b/Documentation/doc/resources/1.8.13/BaseDoxyfile.in index 4cfe65108d1..90cb15aabb7 100644 --- a/Documentation/doc/resources/1.8.13/BaseDoxyfile.in +++ b/Documentation/doc/resources/1.8.13/BaseDoxyfile.in @@ -234,6 +234,10 @@ ALIASES = "cgal=%CGAL" \ "stl=STL" \ "gmp=GMP" \ "gmpxx=GMPXX" \ + "iso=ISO" \ + "lisp=Lisp" \ + "ieee=IEEE" \ + "exacus=Exacus" \ "mpir=MPIR" \ "mpfr=MPFR" \ "leda=LEDA" \ diff --git a/Documentation/doc/resources/1.8.14/BaseDoxyfile.in b/Documentation/doc/resources/1.8.14/BaseDoxyfile.in index be20eb8b86f..96fd516d1ca 100644 --- a/Documentation/doc/resources/1.8.14/BaseDoxyfile.in +++ b/Documentation/doc/resources/1.8.14/BaseDoxyfile.in @@ -235,6 +235,10 @@ ALIASES = "cgal=%CGAL" \ "stl=STL" \ "gmp=GMP" \ "gmpxx=GMPXX" \ + "exacus=Exacus" \ + "iso=ISO" \ + "lisp=Lisp" \ + "ieee=IEEE" \ "mpir=MPIR" \ "mpfr=MPFR" \ "leda=LEDA" \ diff --git a/Documentation/doc/resources/1.8.20/BaseDoxyfile.in b/Documentation/doc/resources/1.8.20/BaseDoxyfile.in index f93cab94f41..afb52c9c5af 100644 --- a/Documentation/doc/resources/1.8.20/BaseDoxyfile.in +++ b/Documentation/doc/resources/1.8.20/BaseDoxyfile.in @@ -257,6 +257,10 @@ ALIASES = "cgal=%CGAL" \ "stl=STL" \ "gmp=GMP" \ "gmpxx=GMPXX" \ + "exacus=Exacus" \ + "iso=ISO" \ + "lisp=Lisp" \ + "ieee=IEEE" \ "mpir=MPIR" \ "mpfr=MPFR" \ "leda=LEDA" \ diff --git a/Documentation/doc/resources/1.8.4/BaseDoxyfile.in b/Documentation/doc/resources/1.8.4/BaseDoxyfile.in index bcbe2efb684..9124909bf7c 100644 --- a/Documentation/doc/resources/1.8.4/BaseDoxyfile.in +++ b/Documentation/doc/resources/1.8.4/BaseDoxyfile.in @@ -205,6 +205,10 @@ ALIASES += "gmp=GMP" ALIASES += "gmpxx=GMPXX" ALIASES += "mpir=MPIR" ALIASES += "mpfr=MPFR" +ALIASES += "exacus=Exacus" +ALIASES += "iso=ISO" +ALIASES += "lisp=Lisp" +ALIASES += "ieee=IEEE" ALIASES += "leda=LEDA" ALIASES += "gcc=GCC" ALIASES += "dcel=DCEL" diff --git a/Geomview/doc/Geomview/CGAL/IO/Geomview_stream.h b/Geomview/doc/Geomview/CGAL/IO/Geomview_stream.h index a0160596d12..8420d438d25 100644 --- a/Geomview/doc/Geomview/CGAL/IO/Geomview_stream.h +++ b/Geomview/doc/Geomview/CGAL/IO/Geomview_stream.h @@ -16,7 +16,7 @@ namespace CGAL { on the two pipes. All insert operators construct expressions in `gcl`, the Geomview - command language, which is a subset of Lisp. These expressions + command language, which is a subset of \lisp. These expressions are sent to Geomview via the pipe. The extract operators notify `interest` for a certain kind of events. When such an event happens Geomview sends a description of the event in `gcl` and the extract operator has diff --git a/Geomview/doc/Geomview/Geomview.txt b/Geomview/doc/Geomview/Geomview.txt index 490974c6582..bc5c19d97f5 100644 --- a/Geomview/doc/Geomview/Geomview.txt +++ b/Geomview/doc/Geomview/Geomview.txt @@ -35,7 +35,7 @@ file descriptors `stdin` and `stdout` of Geomview are hooked on the two pipes. All insert operators construct expressions in `gcl`, the Geomview -command language, which is a subset of Lisp. These expressions +command language, which is a subset of \lisp. These expressions are sent to Geomview via the pipe. The extract operators notify `interest` for a certain kind of events. When such an event happens Geomview sends a description of the event in `gcl` and the extract operator has diff --git a/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt b/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt index 22388d7d7b6..910660556bb 100644 --- a/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt +++ b/Minkowski_sum_2/doc/Minkowski_sum_2/Minkowski_sum_2.txt @@ -565,7 +565,7 @@ vertices (representing a line segment). The `traits` argument must model the concept `ArrangementTraits_2` and it should be capable of handling conic arcs in an exact manner---using an instance of the `Arr_conic_traits_2` class template with the number -types provided by the Core library is the +types provided by the \core library is the preferred option; see \ref arr_ssectr_conic "A Traits Class for Conic Arcs" for more details. The function template returns an object of the nested type `Gps_traits_2::Polygons_with_holes_2` diff --git a/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt b/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt index 0ee83145d51..ac6c1425a1f 100644 --- a/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt +++ b/Modular_arithmetic/doc/Modular_arithmetic/Modular_arithmetic.txt @@ -80,7 +80,7 @@ The class `Residue` is based on the C-code of Sylvain Pion et. al. as it was presented in \cgalCite{bepp-sdrns-99}. The remaining part of the package is the result of the integration process -of the NumeriX library of Exacus \cgalCite{beh-eeeafcs-05} into \cgal. +of the NumeriX library of \exacus \cgalCite{beh-eeeafcs-05} into \cgal. */ } /* namespace CGAL */ diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h b/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h index 2438818c8a9..754985917d9 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigFloat.h @@ -9,7 +9,7 @@ Rounding mode and precision (i.e.\ mantissa length) of `CORE::BigFloat` can be set. Since it also carries the error of a computed value. -This number type is provided by the Core library \cgalCite{klpy-clp-99}. +This number type is provided by the \core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigInt.h b/Number_types/doc/Number_types/CGAL/CORE_BigInt.h index 3ecc5b2edfe..c5fd69d35a9 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigInt.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigInt.h @@ -7,7 +7,7 @@ namespace CORE { The class `CORE::BigInt` provides exact computation in \f$ \Z\f$. Operations and comparisons between objects of this type are guaranteed to be exact. -This number type is provided by the Core library \cgalCite{klpy-clp-99}. +This number type is provided by the \core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_BigRat.h b/Number_types/doc/Number_types/CGAL/CORE_BigRat.h index 1942e0f9549..ac2fae1b1d8 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_BigRat.h +++ b/Number_types/doc/Number_types/CGAL/CORE_BigRat.h @@ -5,7 +5,7 @@ namespace CORE { The class `CORE::BigRat` provides exact computation in \f$ \Q\f$. Operations and comparisons between objects of this type are guaranteed to be exact. -This number type is provided by the Core library \cgalCite{klpy-clp-99}. +This number type is provided by the \core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/CORE_Expr.h b/Number_types/doc/Number_types/CGAL/CORE_Expr.h index 23261d640e8..ac6805b8914 100644 --- a/Number_types/doc/Number_types/CGAL/CORE_Expr.h +++ b/Number_types/doc/Number_types/CGAL/CORE_Expr.h @@ -8,7 +8,7 @@ numbers that contains integers, and which is closed by the operations \f$ +,-,\times,/,\sqrt{}\f$ and \f$\sqrt[k]{}\f$. Operations and comparisons between objects of this type are guaranteed to be exact. This number type is provided by the -Core library \cgalCite{klpy-clp-99}. +\core library \cgalCite{klpy-clp-99}. \cgal defines the necessary functions so that this class complies to the requirements on number types. diff --git a/Number_types/doc/Number_types/CGAL/Gmpfi.h b/Number_types/doc/Number_types/CGAL/Gmpfi.h index 7815f11addb..3b54efc175f 100644 --- a/Number_types/doc/Number_types/CGAL/Gmpfi.h +++ b/Number_types/doc/Number_types/CGAL/Gmpfi.h @@ -23,13 +23,12 @@ and long double. \cgalHeading{Implementation} -All interval operations are performed by the Mpfi library. The class `Gmpfi` is not reference +All interval operations are performed by the \mpfi library. The class `Gmpfi` is not reference counted, but its members are. The default precision of `Gmpfi` is local to each thread and independent of -the default precision of `Gmpfr` (in contrast to the behaviour of the Mpfi and Mpfr libraries, +the default precision of `Gmpfr` (in contrast to the behaviour of the \mpfi +and \mpfr libraries, which share a default precision). \sa `CGAL::Gmpfr` diff --git a/Number_types/doc/Number_types/CGAL/Gmpfr.h b/Number_types/doc/Number_types/CGAL/Gmpfr.h index ae7ce118966..c664a209f0f 100644 --- a/Number_types/doc/Number_types/CGAL/Gmpfr.h +++ b/Number_types/doc/Number_types/CGAL/Gmpfr.h @@ -5,7 +5,7 @@ namespace CGAL { \ingroup nt_gmp An object of the class `Gmpfr` is a fixed precision floating-point -number, based on the Mpfr library. This type is inexact, due to the fact +number, based on the \mpfr library. This type is inexact, due to the fact that the mantissa of each number is represented by a fixed amount of bits (this amount is called precision). If an operation needs more bits than the precision of the result number, the results are rounded following @@ -38,7 +38,7 @@ the compared numbers is `NaN`, the `erange` flag is set. \cgalHeading{Implementation} -Since the Mpfr library can be compiled to be thread-safe, this interface +Since the \mpfr library can be compiled to be thread-safe, this interface is designed to keep the thread-safety. `Gmpfr`s are reference counted. This behavior may be changed, by @@ -144,7 +144,7 @@ creation by default. static Precision_type get_default_precision(); /*! -This function sets the default Mpfr precision to p, and returns +This function sets the default \mpfr precision to p, and returns the old one. */ static Precision_type set_default_precision(Precision_type p); @@ -154,8 +154,8 @@ static Precision_type set_default_precision(Precision_type p); /*! \name Controlling the Precision Each Gmpfr object has a precision associated to it. The precision is -the amount of bits needed to represent the mantissa. Mpfr has a default precision value, which can be +the amount of bits needed to represent the mantissa. +\mpfr has a default precision value, which can be controlled by static functions of the Gmpfr class (in practice, this default value is a variable local to each execution thread). There are also functions to get and set the precision of each Gmpfr object. @@ -175,12 +175,12 @@ in the direction `r`. Gmpfr round(Precision_type p, std::float_round_style r)const; /*! -This function returns the current rounding mode used by Mpfr. +This function returns the current rounding mode used by \mpfr. */ static std::float_round_style get_default_rndmode(); /*! -This function sets the Mpfr rounding mode to `r` and returns +This function sets the \mpfr rounding mode to `r` and returns the old one. */ static std::float_round_style set_default_rndmode(std::float_round_style r); @@ -200,7 +200,7 @@ flags are: /// @{ /*! -Clears all the flags set by Mpfr(they are not cleared +Clears all the flags set by \mpfr(they are not cleared automatically). */ static void clear_flags(); diff --git a/Number_types/doc/Number_types/CGAL/Gmpq.h b/Number_types/doc/Number_types/CGAL/Gmpq.h index 883479df7cd..c399e69e83d 100644 --- a/Number_types/doc/Number_types/CGAL/Gmpq.h +++ b/Number_types/doc/Number_types/CGAL/Gmpq.h @@ -5,7 +5,7 @@ namespace CGAL { \ingroup nt_gmp An object of the class `Gmpq` is an arbitrary precision rational -number based on the Gmp library. +number based on the \gmp library. \cgalModels `Field` \cgalModels `RealEmbeddable` diff --git a/Number_types/doc/Number_types/CGAL/Gmpz.h b/Number_types/doc/Number_types/CGAL/Gmpz.h index 641e8906f35..2eb6873a837 100644 --- a/Number_types/doc/Number_types/CGAL/Gmpz.h +++ b/Number_types/doc/Number_types/CGAL/Gmpz.h @@ -5,7 +5,7 @@ namespace CGAL { \ingroup nt_gmp An object of the class `Gmpz` is an arbitrary precision integer -based on the Gmp Library. +based on the \gmp Library. \cgalModels `EuclideanRing` \cgalModels `RealEmbeddable` @@ -101,7 +101,7 @@ size_t bit_size() const; /*! Returns the size in limbs of `z`. A limb is the type used by -Gmp to represent the integer (usually `long`). +\gmp to represent the integer (usually `long`). */ size_t size() const; diff --git a/Number_types/doc/Number_types/CGAL/Gmpzf.h b/Number_types/doc/Number_types/CGAL/Gmpzf.h index cfa7ac46300..fd0e02c8710 100644 --- a/Number_types/doc/Number_types/CGAL/Gmpzf.h +++ b/Number_types/doc/Number_types/CGAL/Gmpzf.h @@ -6,7 +6,7 @@ namespace CGAL { An object of the class `Gmpzf` is a multiple-precision floating-point number which can represent numbers of the form \f$ m*2^e\f$, where \f$ m\f$ is an arbitrary precision integer -based on the Gmp library, and \f$ e\f$ +based on the \gmp library, and \f$ e\f$ is of type `long`. This type can be considered exact, even if the exponent is not a multiple-precision number. This number type offers functionality very similar to `MP_Float` but is generally faster. diff --git a/Number_types/doc/Number_types/CGAL/Mpzf.h b/Number_types/doc/Number_types/CGAL/Mpzf.h index 2515f3988b7..6844b33bdac 100644 --- a/Number_types/doc/Number_types/CGAL/Mpzf.h +++ b/Number_types/doc/Number_types/CGAL/Mpzf.h @@ -6,8 +6,8 @@ namespace CGAL { An object of the class `Mpzf` is a multiple-precision floating-point number which can represent numbers of the form \f$ m*2^e\f$, where \f$ -m\f$ is an arbitrary precision integer based on the GMP library, and \f$ e\f$ is of type `int`. This +m\f$ is an arbitrary precision integer based on the \gmp +library, and \f$ e\f$ is of type `int`. This type can be considered exact, even if the exponent is not a multiple-precision number. A `Mpzf` constructed from an integer or a normalized finite floating point number represents exactly that number. @@ -19,8 +19,7 @@ similar to `MP_Float` and `Gmpzf` but is faster. \cgalHeading{Implementation} -This class is only available on platforms on which GMP uses 64 bit limbs and the endianness is +This class is only available on platforms on which \gmp uses 64 bit limbs and the endianness is either big-endian or little-endian. The macro `CGAL_HAS_MPZF` will be defined when including `CGAL/Mpzf.h` if this is true. This class makes the assumption that the representation of a `double` in memory follows IEEE 754. diff --git a/Number_types/doc/Number_types/CGAL/gmpxx.h b/Number_types/doc/Number_types/CGAL/gmpxx.h index 9c37c10d7f0..4d93317f45d 100644 --- a/Number_types/doc/Number_types/CGAL/gmpxx.h +++ b/Number_types/doc/Number_types/CGAL/gmpxx.h @@ -5,7 +5,7 @@ \ingroup nt_gmp The class `mpq_class` is an exact multiprecision rational number type, -provided by Gmp. +provided by \gmp. CGAL provides the necessary functions to make it compliant to the number type concept. @@ -13,7 +13,7 @@ concept. \cgalModels `RealEmbeddable` \cgalModels `Fraction` -See the Gmp documentation for additional details. +See the \gmp documentation for additional details. */ @@ -27,14 +27,14 @@ class mpq_class { \ingroup nt_gmp The class `mpz_class` is an exact multiprecision integer number type, -provided by Gmp. +provided by \gmp. CGAL provides the necessary functions to make it compliant to the number type concept. \cgalModels `EuclideanRing` \cgalModels `RealEmbeddable` -See the Gmp documentation for additional details. +See the \gmp documentation for additional details. */ diff --git a/Number_types/doc/Number_types/CGAL/leda_integer.h b/Number_types/doc/Number_types/CGAL/leda_integer.h index 0c4f5762985..1f8871f67ba 100644 --- a/Number_types/doc/Number_types/CGAL/leda_integer.h +++ b/Number_types/doc/Number_types/CGAL/leda_integer.h @@ -6,7 +6,7 @@ The class `leda_integer` provides exact computation in \f$ \Z\f$. The class `leda_integer` is a wrapper class that provides the functions needed to use the number type `leda::integer`, representing exact -multiprecision integers provided by LEDA. +multiprecision integers provided by \leda. \cgalModels `EuclideanRing` \cgalModels `RealEmbeddable` diff --git a/Number_types/doc/Number_types/CGAL/leda_rational.h b/Number_types/doc/Number_types/CGAL/leda_rational.h index 66ae8d41cfd..7c2add08b97 100644 --- a/Number_types/doc/Number_types/CGAL/leda_rational.h +++ b/Number_types/doc/Number_types/CGAL/leda_rational.h @@ -5,7 +5,7 @@ The class `leda_rational` provides exact computation in \f$ \mathbb{Q}\f$. The class `leda_rational` is a wrapper class that provides the functions needed to use the number type `rational`, representing exact -multiprecision rational numbers provided by LEDA. +multiprecision rational numbers provided by \leda. \cgalModels `Field` \cgalModels `RealEmbeddable` diff --git a/Number_types/doc/Number_types/NumberTypeSupport.txt b/Number_types/doc/Number_types/NumberTypeSupport.txt index 296f256eb0d..38ec6150b45 100644 --- a/Number_types/doc/Number_types/NumberTypeSupport.txt +++ b/Number_types/doc/Number_types/NumberTypeSupport.txt @@ -27,7 +27,7 @@ routines though which are automatically included by \cgal. All built-in number types of \cpp can represent a discrete (bounded) subset of the rational numbers only. We assume that the -floating-point arithmetic of your machine follows Ieee +floating-point arithmetic of your machine follows \ieee floating-point standard. Since the floating-point culture has much more infrastructural support (hardware, language definition and compiler) than exact computation, it is very efficient. @@ -57,7 +57,7 @@ point values, a generalization of integers scaled by a (potentially negative) power of 2. It allows to deal with ring operations over floating-point values with requiring rational numbers. By plugging it in `Quotient`, one obtains rational numbers. Note that `MP_Float` may not be as efficient as the -integer types provided by Gmp or \leda, but it has the advantage +integer types provided by \gmp or \leda, but it has the advantage to make more parts of \cgal independent on these external libraries for handling robustness issues. @@ -81,7 +81,7 @@ types. \anchor gmpnt -\cgal provides wrapper classes for number types defined in the Gnu Multiple Precision arithmetic library \cgalCite{g-ggmpa}. The file +\cgal provides wrapper classes for number types defined in the \gnu Multiple Precision arithmetic library \cgalCite{g-ggmpa}. The file CGAL/Gmpz.h provides the class `Gmpz`, a wrapper class for the arbitrary-precision integer type `mpz_t`, which is compliant with the \cgal number type requirements. The file CGAL/Gmpq.h @@ -108,12 +108,12 @@ library after each operation. For more details, the reader should refer to \cgalCite{cgal:mt-mpfr} and the `Gmpfr` reference manual. In addition, it is possible to directly use the C++ number types provided by -Gmp : `mpz_class`, `mpq_class` (note that support for +\gmp : `mpz_class`, `mpq_class` (note that support for `mpf_class` is incomplete). The file CGAL/gmpxx.h provides the necessary functions to make these classes compliant to the \cgal number type requirements. -To use these classes, Gmp and Mpfr must be installed. +To use these classes, \gmp and \mpfr must be installed. \section Number_typesLEDA Number Types Provided by LEDA @@ -157,12 +157,12 @@ requirements. \anchor corent -In principle Core \cgalCite{klpy-clp-99} provides the same set of number types as \leda. +In principle \core \cgalCite{klpy-clp-99} provides the same set of number types as \leda. The type `CORE::BigInt` represent integers and `CORE::BigRat` represent rationals of arbitrary length. The number type `CORE::BigFloat` is a variable precision floating-point type. It is also possible to interpret it as an interval type, since it also carries the error of a computed value. -As for \leda, the most sophisticated number type in Core is `CORE::Expr`, +As for \leda, the most sophisticated number type in \core is `CORE::Expr`, which is in its functionality equivalent to `leda_real`. @@ -192,7 +192,7 @@ is implemented on top of `Gmpfr`, the global flags are inherited from the `Gmpfr` interface. See \cgalCite{cgal:r-mpfi} and the `Gmpfi` reference manual for details. -To use the `Gmpfi` class, Mpfi must be installed. +To use the `Gmpfi` class, \mpfi must be installed. \section Number_typesUser User-supplied Number Types @@ -213,12 +213,12 @@ implemented by Stefan Schirra and Andreas Fabri. Later, around 1998-2002, Sylvain Pion implemented `Interval_nt`, `MP_Float` and `Lazy_exact_nt`, together with the interfaces to -the `mpz_class` and `mpq_class` types from Gmp. +the `mpz_class` and `mpq_class` types from \gmp. Number type concepts were then refined, notably by Lutz Kettner and Susan Hert, who also contributed utility algorithms. -The work on concepts was further extended within the Exacus project, and was finally +The work on concepts was further extended within the \exacus project, and was finally contributed to \cgal by Michael Hemmer in 2006, as what is now the separate package \ref Chapter_Algebraic_Foundations "Algebraic Foundations", together with a rewritten interface to operations on number types. diff --git a/Polynomial/doc/Polynomial/Polynomial.txt b/Polynomial/doc/Polynomial/Polynomial.txt index a56dada5306..b94ff218e1e 100644 --- a/Polynomial/doc/Polynomial/Polynomial.txt +++ b/Polynomial/doc/Polynomial/Polynomial.txt @@ -400,10 +400,10 @@ of a polynomial using its principal Sturm-Habicht coefficients. \section PolynomialDesign Design and Implementation History This package is the result of the integration process of the NumeriX library -of Exacus \cgalCite{beh-eeeafcs-05} into \cgal. +of \exacus \cgalCite{beh-eeeafcs-05} into \cgal. The class `Polynomial` had been started by Michael Seel within -CGAL as part of the Nef_2 package. As part of the Exacus project +CGAL as part of the Nef_2 package. As part of the \exacus project it got significantly improved by Arno Eigenwillig and Michael Hemmer. However, due to the recursive definition the class was rather restricted to the diff --git a/Surface_mesh_simplification/doc/Surface_mesh_simplification/CGAL/Surface_mesh_simplification/Policies/Edge_collapse/Edge_profile.h b/Surface_mesh_simplification/doc/Surface_mesh_simplification/CGAL/Surface_mesh_simplification/Policies/Edge_collapse/Edge_profile.h index 65ac73888d1..434ee2c2784 100644 --- a/Surface_mesh_simplification/doc/Surface_mesh_simplification/CGAL/Surface_mesh_simplification/Policies/Edge_collapse/Edge_profile.h +++ b/Surface_mesh_simplification/doc/Surface_mesh_simplification/CGAL/Surface_mesh_simplification/Policies/Edge_collapse/Edge_profile.h @@ -57,17 +57,17 @@ public: typedef GeomTraits Geom_traits; /*! - A Bgl vertex descriptor representing a vertex of the surface mesh. + A \bgl vertex descriptor representing a vertex of the surface mesh. */ typedef typename boost::graph_traits::vertex_descriptor vertex_descriptor; /*! - A Bgl halfedge descriptor representing a halfedge of the surface mesh. + A \bgl halfedge descriptor representing a halfedge of the surface mesh. */ typedef typename boost::graph_traits::halfedge_descriptor halfedge_descriptor; /*! - A Bgl edge descriptor representing an edge of the surface mesh. + A \bgl edge descriptor representing an edge of the surface mesh. */ typedef typename boost::graph_traits::edge_descriptor edge_descriptor; diff --git a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt index 8f2f7d5268e..ed87452ddf6 100644 --- a/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt +++ b/Surface_mesh_simplification/doc/Surface_mesh_simplification/Surface_mesh_simplification.txt @@ -257,7 +257,7 @@ returns `true` the algorithm terminates. \subsection Surface_mesh_simplificationOptionalNamed Optional Named Parameters -The notion of named parameters was also introduced in the Bgl. You can read about it in \cgalCite{cgal:sll-bgl-02} or the following site: https://www.boost.org/libs/graph/doc/bgl_named_params.html. Named parameters allow the user to specify only those parameters which are really needed, by name, making the parameter ordering unimportant. +The notion of named parameters was also introduced in the \bgl. You can read about it in \cgalCite{cgal:sll-bgl-02} or the following site: https://www.boost.org/libs/graph/doc/bgl_named_params.html. Named parameters allow the user to specify only those parameters which are really needed, by name, making the parameter ordering unimportant. Say there is a function `f()` that takes 3 parameters called `name`, `age` and `gender`, and you have variables `n,a and g` to pass as parameters to that function. Without named parameters, you would call it like this: `f(n,a,g)`, but with named parameters, you call it like this: `f(name(n).age(a).gender(g))`. diff --git a/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt b/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt index bb7f1b4f9e1..ace8ee84afc 100644 --- a/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt +++ b/Triangulation_3/doc/Triangulation_3/Triangulation_3.txt @@ -617,7 +617,7 @@ coordinates are generated using the drand48 C function). In the weighted case, the weights are all zero, which means that there are actually no hidden points during execution. -The measurements have been performed using \cgal 3.6, using the Gnu \cpp compiler +The measurements have been performed using \cgal 3.6, using the \gnu \cpp compiler version 4.3.2, under Linux (Fedora 10 distribution), with the compilation options -O3 -DCGAL_NDEBUG. The computer used was equipped with a 64bit Intel Xeon 3GHz processor and 32GB of RAM (a recent desktop machine as of 2009).