From 702ab57f50f8adbf58afd3fe28601ffdd13a81ca Mon Sep 17 00:00:00 2001 From: aminkhalsi Date: Sun, 13 Apr 2025 14:03:44 +0100 Subject: [PATCH 1/2] fixed some typos --- .gitattributes | 2 +- AABB_tree/doc/AABB_tree/aabb_tree.txt | 12 ++++++------ .../Algebraic_foundations.txt | 16 ++++++++-------- .../Algebraic_kernel_d/Algebraic_kernel_d.txt | 4 ++-- .../doc/Alpha_shapes_2/Alpha_shapes_2.txt | 10 +++++----- .../doc/Alpha_shapes_3/Alpha_shapes_3.txt | 18 +++++++++--------- Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt | 10 +++++----- 7 files changed, 36 insertions(+), 36 deletions(-) diff --git a/.gitattributes b/.gitattributes index 0c2e3c3b778d..df5ec64684b4 100644 --- a/.gitattributes +++ b/.gitattributes @@ -16,7 +16,7 @@ *.py text *.xml text *.js text -*.hmtl text +*.html text *.bib text *.css text *.ui text diff --git a/AABB_tree/doc/AABB_tree/aabb_tree.txt b/AABB_tree/doc/AABB_tree/aabb_tree.txt index ca5f84e2fbfa..95e43af572d8 100644 --- a/AABB_tree/doc/AABB_tree/aabb_tree.txt +++ b/AABB_tree/doc/AABB_tree/aabb_tree.txt @@ -106,7 +106,7 @@ it is used only for distance computations. \warning Having degenerate primitives in the AABB-tree is not recommended as the underlying predicates and constructions of the traits class might not be able to handle them. For example if one is using `CGAL::AABB_traits` with a Kernel from \cgal, -having degenerate triangles or segments in the AABB-tree will results in an undefined +having degenerate triangles or segments in the AABB-tree will result in an undefined behavior or a crash. \section aabb_tree_examples Examples @@ -197,8 +197,8 @@ The AABB tree example folder contains three examples of trees constructed with custom primitives. In \ref AABB_tree/AABB_custom_example.cpp "AABB_custom_example.cpp" the primitive contains triangles which are defined by three pointers to custom points. In \ref AABB_tree/AABB_custom_triangle_soup_example.cpp "AABB_custom_triangle_soup_example.cpp" all input -triangles are stored into a single array so as to form a triangle -soup. The primitive internally uses a `boost::iterator_adaptor` so as +triangles are stored into a single array to form a triangle +soup. The primitive internally uses a `boost::iterator_adaptor` to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`, and `AABBPrimitive::reference_point()`) required by the primitive concept. In \ref AABB_tree/AABB_custom_indexed_triangle_set_example.cpp "AABB_custom_indexed_triangle_set_example.cpp" the input is an indexed @@ -213,7 +213,7 @@ contains a set of polyhedron triangle facets. We measure the tree construction time, the memory occupancy and the number of queries per second for a variety of intersection and distance queries. The machine used is a PC running Windows XP64 with an Intel CPU Core2 Extreme -clocked at 3.06 GHz with 4GB of RAM. By default the kernel used is +clocked at 3.06 GHz with 4GB of RAM. By default, the kernel used is `Simple_cartesian` (the fastest in our experiments). The program has been compiled with Visual C++ 2005 compiler with the O2 option which maximizes speed. @@ -244,7 +244,7 @@ internal KD-tree). It increases to approximately 150 bytes per primitive when constructing the internal KD-tree with one reference point per primitive (the default mode when calling the function `AABB_tree::accelerate_distance_queries()`). Note that the polyhedron -facet primitive primitive stores only one facet handle as primitive id +facet primitive stores only one facet handle as primitive id and computes on the fly a 3D triangle from the facet handle stored internally. When explicitly storing a 3D triangle in the primitive the tree occupies approximately 140 bytes per primitive instead of 60 @@ -340,7 +340,7 @@ inside the bounding box. The experiments described above are neither exhaustive nor conclusive as we have chosen one specific case where the input primitives are the -facets of a triangle surface polyhedron. Nevertheless we now provide +facets of a triangle surface polyhedron. Nevertheless, we now provide some general observations and advises about how to put the AABB tree to use with satisfactory performances. While the tree construction times and memory occupancy do not fluctuate much in our experiments diff --git a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt index 80a69b1719a8..e67626e1fd4e 100644 --- a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt +++ b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt @@ -15,7 +15,7 @@ As a consequence types representing polynomials, algebraic extensions and finite fields play a more important role in related implementations. This package has been introduced to stay abreast of these changes. Since in particular polynomials must be supported by the introduced framework -the package avoids the term number type. Instead the package distinguishes +the package avoids the term number type. Instead, the package distinguishes between the algebraic structure of a type and whether a type is embeddable on the real axis, or real embeddable for short. Moreover, the package introduces the notion of interoperable types which @@ -45,11 +45,11 @@ the operations 'sqrt', 'k-th root' and 'real root of a polynomial', respectively. The concept `IntegralDomainWithoutDivision` also corresponds to integral domains in the algebraic sense, the distinction results from the fact that some implementations of -integral domains lack the (algebraically always well defined) integral -division. +integral domains lack the integral division, +which is always well-defined algebraically. Note that `Field` refines `IntegralDomain`. This is because most ring-theoretic notions like greatest common divisors become trivial for -`Field`s. Hence we see `Field` as a refinement of +`Field`s. Hence, we see `Field` as a refinement of `IntegralDomain` and not as a refinement of one of the more advanced ring concepts. If an algorithm wants to rely on gcd or remainder computation, it is trying @@ -119,7 +119,7 @@ Conversely, types as `leda_real` or `CORE::Expr` are exact but sensitive to numerical issues due to the internal use of multi precision floating point arithmetic. We expect that `Is_numerical_sensitive` is used for dispatching of algorithms, while `Is_exact` is useful to enable assertions that can be -check for exact types only. +checked for exact types only. Tags are very useful to dispatch between alternative implementations. The following example illustrates a dispatch for `Field`s using overloaded @@ -134,7 +134,7 @@ category tags reflect the algebraic structure hierarchy. Most number types represent some subset of the real numbers. From those types we expect functionality to compute the sign, absolute value or double -approximations. In particular we can expect an order on such a type that +approximations. In particular, we can expect an order on such a type that reflects the order along the real axis. All these properties are gathered in the concept `::RealEmbeddable`. The concept is orthogonal to the algebraic structure concepts, @@ -190,12 +190,12 @@ In general mixed operations are provided by overloaded operators and 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. +or so-called coercion type, of a mixed arithmetic operation may be unclear. Therefore, the package introduces `Coercion_traits` giving access to the coercion type via \link Coercion_traits::Type `Coercion_traits::Type` \endlink for two interoperable types `A` and `B`. -Some trivial example are `int` and `double` with coercion type double +Some trivial examples are `int` and `double` with coercion type double 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 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 2d8d1f582b69..6f109ff6d958 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 @@ -146,8 +146,8 @@ polynomial is not computed yet. This is in particular relevant in relation to the `AlgebraicKernel_d_2`, where `AlgebraicKernel_d_1::Algebraic_real_1` is used to represent coordinates of solutions of bivariate systems. Hence, the design does -not allow a direct access to any, seemingly obvious, members of an -`AlgebraicKernel_d_1::Algebraic_real_1`. Instead there is, e.g., +not allow direct access to any, seemingly obvious, members of an +`AlgebraicKernel_d_1::Algebraic_real_1`. Instead, there is, e.g., `AlgebraicKernel_d_1::Compute_polynomial_1` which emphasizes that the requested polynomial may not be computed yet. Similarly, there is no way to directly ask for the refinement of the current diff --git a/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt b/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt index ad98502db47f..4a66ffc92bf5 100644 --- a/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt +++ b/Alpha_shapes_2/doc/Alpha_shapes_2/Alpha_shapes_2.txt @@ -35,8 +35,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle). Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named. In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the -carving spoon. A very small value will allow us to eat up all of the -ice-cream except the chocolate points themselves. Thus we already see +carving spoon. A very small value will allow us to eat up all the +ice-cream except the chocolate points themselves. Thus, we already see that the \f$ \alpha\f$-shape degenerates to the point-set \f$ S\f$ for \f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$ will prevent us even from moving the spoon between two points since @@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. Basic alpha shapes are based on the Delaunay triangulation. Weighted alpha shapes are based on its generalization, the regular triangulation (cf. Section \ref Section_2D_Triangulations_Regular "Regular Triangulations"), -replacing the euclidean distance by the power to weighted points. +replacing the Euclidean distance by the power to weighted points. There is a close connection between alpha shapes and the underlying triangulations. More precisely, the \f$ \alpha\f$-complex of \f$ S\f$ is a @@ -100,7 +100,7 @@ It provides iterators to enumerate the vertices and edges that are in the \f$ \alpha\f$-shape, and functions that allow to classify vertices, edges and faces with respect to the \f$ \alpha\f$-shape. They can be in the interior of a face that belongs or does not belong to the \f$ \alpha\f$-shape. -They can be singular/regular, that is be on the boundary of the \f$ \alpha\f$-shape, +They can be singular/regular, that is, they can be on the boundary of the \f$ \alpha\f$-shape, but not incident/incident to a triangle of the \f$ \alpha\f$-complex. Finally, it provides a function to determine the \f$ \alpha\f$-value @@ -213,7 +213,7 @@ cube will be chosen and no optimizations will be used. It is also recommended to switch the triangulation to 1-sheeted covering if possible. Note that a periodic triangulation in 9-sheeted covering space is degenerate. In this case, an exact constructions -kernel needs to be used to compute the alpha shapes. Otherwise the +kernel needs to be used to compute the alpha shapes. Otherwise, the results will suffer from round-off problems. \cgalExample{Alpha_shapes_2/ex_periodic_alpha_shapes_2.cpp} diff --git a/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt b/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt index 0a282196fe48..2348fb63fdc5 100644 --- a/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt +++ b/Alpha_shapes_3/doc/Alpha_shapes_3/Alpha_shapes_3.txt @@ -34,8 +34,8 @@ of this process in 2D (where our ice-cream spoon is simply a circle). Alpha shapes depend on a parameter \f$ \alpha\f$ after which they are named. In the ice-cream analogy above, \f$ \alpha\f$ is the squared radius of the -carving spoon. A very small value will allow us to eat up all of the -ice-cream except the chocolate points themselves. Thus we already see +carving spoon. A very small value will allow us to eat up all the +ice-cream except the chocolate points themselves. Thus, we already see that the alpha shape degenerates to the point-set \f$ S\f$ for \f$ \alpha \rightarrow 0\f$. On the other hand, a huge value of \f$ \alpha\f$ will prevent us even from moving the spoon between two points since @@ -53,7 +53,7 @@ We distinguish two versions of alpha shapes. Basic alpha shapes are based on the Delaunay triangulation. Weighted alpha shapes are based on its generalization, the regular triangulation (cf. Section \ref Triangulation3secclassRegulartriangulation "Regular Triangulations"), -replacing the euclidean distance by the power to weighted points. +replacing the Euclidean distance by the power to weighted points. Let us consider the basic case with a Delaunay triangulation. We first define the alpha complex of the set of points \f$ S\f$. @@ -79,7 +79,7 @@ of the alpha complex where singular faces are removed (See \cgalFigureRef{figgenregex} for an example). \cgalFigureBegin{figgenregex,gen-reg-ex.png} -Comparison of general and regularized alpha-shape. Left: Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; Middle: The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; Right: The regularized version (for the same value of alpha) does not contains any singular facet. +Comparison of general and regularized alpha-shape. Left: Some points are taken on the surface of a torus, three points being taken relatively far from the surface of the torus; Middle: The general alpha-shape (for a large enough alpha value) contains the singular triangle facet of the three isolated points; Right: The regularized version (for the same value of alpha) does not contain any singular facet. \cgalFigureEnd The alpha shapes of a set of points @@ -112,11 +112,11 @@ and radii \f$ r_1, r_2 \f$ are said to be orthogonal iff iff \f$ C_1C_2 ^2 < r_1^2 + r_2^2\f$. For a given value of \f$ \alpha\f$, the weighted alpha complex is formed with the simplices of the -regular triangulation triangulation -such that there is a sphere orthogonal to the weighted points associated +regular triangulation such that there is a sphere +orthogonal to the weighted points associated with the vertices of the simplex and suborthogonal to all the other input weighted points. Once again the alpha shape is then defined as -the domain covered by a the alpha complex and comes in general and +the domain covered by the alpha complex and comes in general and regularized versions. \section Alpha_Shape_3Functionality Functionality @@ -273,7 +273,7 @@ alpha-shape, using the `Alpha_shape_3` requires a ke with exact predicates and exact constructions (or setting `ExactAlphaComparisonTag` to `Tag_true`) while using a kernel with exact predicates is sufficient for the class `Fixed_alpha_shape_3
`. This makes the class `Fixed_alpha_shape_3
` even more efficient in this setting. -In addition, note that the `Fixed` version is the only of the +In addition, note that the `Fixed` version is the only one of the two that supports incremental insertion and removal of points. We give the time spent while computing the alpha shape of a protein (considered @@ -345,7 +345,7 @@ cube will be chosen and no optimizations will be used. It is also recommended to switch the triangulation to 1-sheeted covering if possible. Note that a periodic triangulation in 27-sheeted covering space is degenerate. In this case, an exact constructions -kernel needs to be used to compute the alpha shapes. Otherwise the +kernel needs to be used to compute the alpha shapes. Otherwise, the results will suffer from round-off problems. \cgalExample{Alpha_shapes_3/ex_periodic_alpha_shapes_3.cpp} diff --git a/Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt b/Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt index d3bebfe2ab76..872bb26cf0f8 100644 --- a/Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt +++ b/Alpha_wrap_3/doc/Alpha_wrap_3/alpha_wrap_3.txt @@ -264,7 +264,7 @@ Secondly, the farther the isosurface is from the input, the more new points are through the first criterion (i.e., through intersection with dual Voronoi edge, see Section \ref aw3_algorithm); thus, the quality of the output improves in terms of angles of the triangle elements. Finally, and depending on the value of the alpha parameter, a large offset can also offer defeaturing capabilities. -However using a small offset parameter will tend to better preserve sharp features as projection +However, using a small offset parameter will tend to better preserve sharp features as projection Steiner points tend to project onto convex sharp features. \cgalFigureAnchor{6} @@ -278,7 +278,7 @@ Impact of the offset parameter on the output. The offset parameter is decreasing from left to right, to respectively 1/50, 1/200 and 1/1000 of the longest diagonal of the input bounding box. The alpha parameter is equal to 1/50 of the longest diagonal of the input bounding box for all level of details. A larger offset will produce an output less complex with better triangle quality. -However the sharp features (red edges) are well preserved when the offset parameter is small. +However, the sharp features (red edges) are well-preserved when the offset parameter is small. \cgalFigureCaptionEnd \cgalFigureAnchor{7} @@ -346,15 +346,15 @@ The charts below plots the computation times of the wrapping algorithm on the Th \cgalFigureCaptionBegin{9} Execution times and output complexity for different values of alpha on the Thingi10k data set. Alpha increases from 1/20 to 1/200 of the length of bounding box diagonal. -The x axis represents the complexity of the output wrap mesh in number of triangle facets. -The y axis represents the total computation time, in seconds. +The x-axis represents the complexity of the output wrap mesh in number of triangle facets. +The y-axis represents the total computation time, in seconds. The color and diameter of the dots represent the number of faces in the input triangle soup, ranging from 10 (green) to 3154000 (blue). \cgalFigureCaptionEnd \section aw3_examples Examples -Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box longest diagonal edge length, +Here is an example with an input triangle mesh, with alpha set to 1/20 of the bounding box's longest diagonal edge length, and offset set to 1/30 of alpha (i.e., 1/600 of the bounding box diagonal edge length). \cgalExample{Alpha_wrap_3/triangle_mesh_wrap.cpp} From 96a13740e8d1f3b29e010ce7d9ac5d5d1783e30b Mon Sep 17 00:00:00 2001 From: aminkhalsi Date: Thu, 24 Apr 2025 18:43:46 +0100 Subject: [PATCH 2/2] review fix --- AABB_tree/doc/AABB_tree/aabb_tree.txt | 4 ++-- .../doc/Algebraic_foundations/Algebraic_foundations.txt | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/AABB_tree/doc/AABB_tree/aabb_tree.txt b/AABB_tree/doc/AABB_tree/aabb_tree.txt index 95e43af572d8..fbdc0b890c32 100644 --- a/AABB_tree/doc/AABB_tree/aabb_tree.txt +++ b/AABB_tree/doc/AABB_tree/aabb_tree.txt @@ -197,9 +197,9 @@ The AABB tree example folder contains three examples of trees constructed with custom primitives. In \ref AABB_tree/AABB_custom_example.cpp "AABB_custom_example.cpp" the primitive contains triangles which are defined by three pointers to custom points. In \ref AABB_tree/AABB_custom_triangle_soup_example.cpp "AABB_custom_triangle_soup_example.cpp" all input -triangles are stored into a single array to form a triangle +triangles are stored into a single array as to form a triangle soup. The primitive internally uses a `boost::iterator_adaptor` -to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`, +as to provide the three functions `AABBPrimitive::id()`, `AABBPrimitive::datum()`, and `AABBPrimitive::reference_point()`) required by the primitive concept. In \ref AABB_tree/AABB_custom_indexed_triangle_set_example.cpp "AABB_custom_indexed_triangle_set_example.cpp" the input is an indexed triangle set stored through two arrays: one array of points and one diff --git a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt index e67626e1fd4e..558d702464f5 100644 --- a/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt +++ b/Algebraic_foundations/doc/Algebraic_foundations/Algebraic_foundations.txt @@ -45,8 +45,8 @@ the operations 'sqrt', 'k-th root' and 'real root of a polynomial', respectively. The concept `IntegralDomainWithoutDivision` also corresponds to integral domains in the algebraic sense, the distinction results from the fact that some implementations of -integral domains lack the integral division, -which is always well-defined algebraically. +integral domains lack the (algebraically always well-defined) integral +division. Note that `Field` refines `IntegralDomain`. This is because most ring-theoretic notions like greatest common divisors become trivial for `Field`s. Hence, we see `Field` as a refinement of @@ -269,7 +269,7 @@ 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}, which in the main goes back to -Lutz Kettner, Susan Hert, Arno Eigenwillig and Michael Hemmer. +Lutz Kettner, Susan Hert, Arno Eigenwillig, and Michael Hemmer. However, the package abstracts from the pure support for number types that are embedded on the real axis which allows the support of polynomials, finite fields, and algebraic extensions as well. See also related