mirror of https://github.com/CGAL/cgal
remove doc_tex documentation (including developer manual) and old manual tools
This commit is contained in:
Sébastien Loriot
parent
032c6e428a
commit
0fa2cacb60
|
|
@ -1,10 +0,0 @@
|
|||
\begin{ccPkgDescription}{3D Fast Intersection and Distance Computation (AABB Tree)\label{Pkg:AABB_tree}}
|
||||
\ccPkgSummary{The AABB (axis-aligned bounding box) tree component offers a static data structure and algorithms to perform efficient intersection and distance queries on sets of finite 3D geometric objects.}
|
||||
%
|
||||
\ccPkgHowToCiteCgal{cgal:atw-aabb-12}
|
||||
\ccPkgIntroducedInCGAL{3.5}
|
||||
\ccPkgDemo{AABB Tree}{AABB_demo.zip}
|
||||
\ccPkgIllustration{AABB_tree/figs/teaser-thumb.png}{AABB_tree/figs/teaser.png}
|
||||
\ccPkgLicense{\ccLicenseGPL}
|
||||
%
|
||||
\end{ccPkgDescription}
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
\section{Implementation Details}
|
||||
\label{AABB_tree_section_details}
|
||||
|
||||
The AABB tree construction is initialized by computing the AABB of the whole set of input primitives. All primitives are then sorted along the longest coordinate axis of this box, and the primitives are separated into two equal size sets. This procedure is applied recursively until an AABB contains a single primitive. The tree is leafless as presented in {\sc opcode} \cite{cgal:t-ocdl-05}. An intersection query traverses the tree by computing intersection tests only with respect to the AABBs during traversal, and with respect to the input primitives at the end of traversal (in the leafs of the tree).\\
|
||||
|
||||
The reference id is not used internally but simply used by the AABB tree to refer to the primitive in the results provided to the user. It follows that, while in most cases each reference id corresponds to a unique primitive, this is not a requirement of the component. This way a user may use these reference ids as labels, each of them being shared by several geometric object. \\
|
||||
|
||||
A distance query between a query point $q$ and the input primitives is turned into a \emph{ball} query centered at $q$. The ball traverses the tree while recursively querying intersections with the AABBs, and computes the closest point $p$ from the query point to the input primitives at the leafs of the tree. The ball radius is then shrunk to the distance between $p$ and $q$ for all remaining recursive traversals of the tree. Efficiency is achieved through setting the initial ball radius to a small value still guaranteed to intersect the input primitives. This is achieved by constructing through the function \ccc{accelerate_distance_queries} an internal secondary data structure which provides a good hint to the algorithm at the beginning of the traversal.
|
||||
|
||||
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
\section{Examples}
|
||||
\label{AABB_tree_section_examples}
|
||||
|
||||
\subsection{Tree of Triangles, for Intersection and Distance Queries}
|
||||
In the following example a set of 3D triangles is stored in a list. The AABB primitive wraps a triangle as \ccc{datum} and an iterator in the list as \ccc{id}. We compute the number of input triangles intersected by a ray query, as well as the closest point and the squared distance from a point query.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_triangle_3_example.cpp}
|
||||
|
||||
\subsection{Tree of Polyhedron Triangle Facets for Intersection Queries}
|
||||
In the following example the AABB primitive wraps a facet handle of a triangle polyhedral surface as \ccc{id} and the corresponding 3D triangle as geometric object. From a segment query we test the intersections, then compute the number of intersections, compute the first encountered intersection (generally a point), compute all intersections (where each intersection is a pair of one \cgal\ object and one primitive id - here a face handle) and compute all intersected primitives. The latter involves only tests and no predicates and is hence faster than computing all intersections. We also compute the first encountered intersection with a plane query, which is generally a segment.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_polyhedron_facet_intersection_example.cpp}
|
||||
|
||||
\subsection{Tree of Polyhedron Triangle Facets for Distance Queries}
|
||||
In the following example the AABB primitive wraps a facet handle of a triangle polyhedral surface as \ccc{id} and the corresponding 3D triangle as geometric object. From a point query we compute the squared distance, the closest point as well as the closest point and primitive id. The latter returns a pair composed of a point and a face handle.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_polyhedron_facet_distance_example.cpp}
|
||||
|
||||
\subsection{Tree of Segments for Intersection and Distance Queries}
|
||||
In the following example the segments are stored into a list, and the AABB primitive wraps a segment as \ccc{datum} and an iterator in the list as \ccc{id}. We compute the number of intersections with plane and triangles queries, and the closest point from a point query.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_segment_3_example.cpp}
|
||||
|
||||
\subsection{Tree of Polyhedron Edge Segments for Intersection and Distance Queries}
|
||||
In the following example the AABB primitive wraps a halfedge handle as \ccc{id} and generates a 3D segment on the fly, each time its method \ccc{datum} is called. We compute the number of intersections with a triangle query and the closest point from a point query.
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_polyhedron_edge_example.cpp}
|
||||
|
||||
\subsection{Incremental Insertion of Primitives}
|
||||
The AABB tree is a static data structure, but it allows to insert primitives, and will internally
|
||||
rebuild triggered by the first query, or because the user calls the \ccc{build} method.
|
||||
The following example illustrates this for two polyhedral surfaces.
|
||||
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_insertion_example.cpp}
|
||||
|
||||
\subsection{Trees of Custom Primitives}
|
||||
|
||||
The AABB tree example folder contains three examples of trees constructed with customize primitives. In \ccc{AABB_custom_example.cpp} the primitive contains triangles which are defined by three pointers to custom points. In \ccc{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 \ccc{boost::iterator_adaptor} so as to provide the three functions (\ccc{id()}, \ccc{datum()}, \ccc{reference_point()}) required by the primitive concept. In \ccc{AABB_custom_indexed_triangle_set_example.cpp} the input is an indexed triangle set stored through two arrays: one array of points and one array of indices which refer to the point array. Here also the primitive internally uses a \ccc{boost::iterator_adaptor}.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 80 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 66 KiB |
Binary file not shown.
|
|
@ -1,4 +0,0 @@
|
|||
\section{Design and Implementation History}
|
||||
\label{AABB_tree_section_history}
|
||||
|
||||
Camille Wormser and Pierre Alliez started working on a data structure for efficient collision detection in 2007. The generic design for implementing both intersection and distance queries, and for generic queries and primitives was developed by Camille Wormser. In 2009, Pierre Alliez, St\'ephane Tayeb and Camille Wormser made the implementation CGAL-compliant, with the help of Laurent Rineau for optimizing the tree construction. The authors wish to thank Andreas Fabri, Jane Tournois, Mariette Yvinec and Sylvain Lef\`ebvre for helpful comments and discussions.
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
\section{Interface}
|
||||
\label{AABB_tree_section_interface}
|
||||
|
||||
The main entry point to the component is the class \ccc{AABB_tree} which represents a static AABB tree constructed from an iterator range of geometric data. Once instantiated an AABB tree can be queried for intersection and distance queries.\\
|
||||
|
||||
|
||||
|
||||
\paragraph{Intersections.} Assume for example that the tree contains triangle primitives. The tree can be queried for intersection against line objects (rays, segments or line) in various ways. We distinguish intersection \emph{tests} which do not construct any intersection objects, from \emph{intersections} which construct the intersection objects.\\
|
||||
|
||||
Tests:
|
||||
\begin{itemize}
|
||||
\item Function \ccc{do_intersect} tests if the input primitives are intersected by the query. This function is fast as it involves only predicates and stops after the first encountered intersection.
|
||||
\item Function \ccc{number_of_intersected_primitives} counts all intersected primitives.
|
||||
\item Function \ccc{all_intersected_primitives} enumerates all intersected primitives ids without constructing the corresponding intersection objects.
|
||||
\item Function \ccc{any_intersected_primitive} returns the first encountered intersecting primitive id (if any) without constructing the corresponding intersection object, and stops after the first encountered intersection. Note that the traversal order of the tree is such that first herein does not refer to any particular ordering of the intersections with respect to the query.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
Constructions:
|
||||
\begin{itemize}
|
||||
\item Function \ccc{all_intersections} detects and constructs all intersection objects with the input primitives.
|
||||
\item Function \ccc{any_intersection} detects and constructs the first encountered intersection and constructs the corresponding object. This function is fast as it stops after the first encountered intersection.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
||||
\paragraph{Distance.} An AABB tree computes the closest point from a given point query to the input primitives through the function \ccc{closest_point(query)}. In addition, it can compute the id of the closest primitive from a given point query through the function \ccc{closest_point_and_primitive(query)}, i.e., the id of the primitive which realizes the minimum distance from the point query. The AABB tree uses a secondary search structure to speed up the distance queries. The construction of this secondary structure should be requested by the user by a call to \ccc{accelerate_distance_queries} before the first the distance computation. This data structure is not generated by default because it is used only for distance computations.
|
||||
|
||||
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
\section{Introduction}
|
||||
\label{AABB_tree_section_intro}
|
||||
|
||||
The AABB tree component offers a static data structure and algorithms to perform efficient intersection and distance queries against sets of finite 3D geometric objects. The set of geometric objects stored in the data structure can be queried for intersection detection, intersection computation and distance. The intersection queries can be of any type, provided that the corresponding intersection predicates and constructors are implemented in the traits class. The distance queries are limited to point queries. Examples of intersection queries include line objects (rays, lines, segments) against sets of triangles, or plane objects (planes, triangles) against sets of segments. An example of a distance query consists of finding the closest point from a point query to a set of triangles.\\
|
||||
|
||||
Note that this component is not suited to the problem of finding all intersecting pairs of objects. We refer to the component \ccc{Box_intersection_d} (Intersecting Sequences of dD Iso-oriented Boxes) which can find all intersecting pairs of iso-oriented boxes.\\
|
||||
|
||||
The AABB tree data structure takes as input an iterator range of geometric data, which is then converted into primitives. From these primitives a hierarchy of axis-aligned bounding boxes (AABBs) is constructed and used to speed up intersection and distance queries (see Figure~\ref{fig:AABB-tree-anchor}).
|
||||
Each primitive gives access to both one input geometric object (so-called datum) and one reference id to this object. A typical example primitive wraps a 3D triangle as datum and a face handle of a polyhedral surface as id. Each intersection query can return the intersection objects (e.g., 3D points or segments for ray queries) as well the as id (here the face handle) of the intersected primitives. Similarly, each distance query can return the closest point from the point query as well as the id of the closest primitive.
|
||||
|
||||
% AABB tree over anchor triangle surface mesh model.
|
||||
\begin{center}
|
||||
\label{fig:AABB-tree-anchor}
|
||||
\begin{ccTexOnly}
|
||||
\includegraphics[width=0.8\textwidth]{AABB_tree/figs/anchor}
|
||||
\end{ccTexOnly}
|
||||
\begin{ccHtmlOnly}
|
||||
<img style="max-width: 75%;" border=0 src="./figs/anchor.png"><P>
|
||||
\end{ccHtmlOnly}
|
||||
\begin{figure}[h]
|
||||
\caption{AABB tree.
|
||||
Left: surface triangle mesh of a mechanical part.
|
||||
Right: AABB tree constructed.}
|
||||
\end{figure}
|
||||
\end{center}
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
\ccUserChapter{3D Fast Intersection and Distance Computation (AABB Tree)\label{AABB_tree}}
|
||||
\label{user_chapter_AABB_tree}
|
||||
|
||||
\ccChapterAuthor{Pierre Alliez,
|
||||
St{\'e}phane Tayeb,
|
||||
Camille Wormser}
|
||||
|
||||
\input{AABB_tree/PkgDescription}
|
||||
|
||||
\minitoc
|
||||
|
||||
\input{AABB_tree/introduction}
|
||||
\input{AABB_tree/interface}
|
||||
\input{AABB_tree/examples}
|
||||
\input{AABB_tree/performances}
|
||||
\input{AABB_tree/details}
|
||||
\input{AABB_tree/history}
|
||||
|
|
@ -1,127 +0,0 @@
|
|||
\section{Performances}
|
||||
\label{AABB_tree_section_performances}
|
||||
|
||||
We provide some performance numbers for the case where the AABB tree 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 \ccc{Simple_cartesian<double>} (the fastest in our experiments). The program has been compiled with Visual C++ 2005 compiler with the O2 option which maximizes speed.
|
||||
|
||||
\subsection{Construction}
|
||||
|
||||
The surface triangle mesh chosen for benchmarking the tree construction is the knot model (14,400 triangles) depicted by Figure \ref{fig:AABB-tree-bench}. We measure the tree construction time (both AABB tree alone and AABB tree with internal KD-tree) for this model as well as for three denser versions subdivided through the Loop subdivision scheme which multiplies the number of triangles by four.
|
||||
|
||||
\begin{tabular}{|l|c|c|}
|
||||
\hline
|
||||
Number of triangles & Construction (in ms) & Construction with internal KD-tree (in ms)\\
|
||||
\hline
|
||||
14,400 & 156 & 157 \\
|
||||
57,600 & 328 & 328 \\
|
||||
230,400 & 1,141 & 1,437 \\
|
||||
921,600 & 4,813 & 5,953 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
|
||||
|
||||
\subsection{Memory}
|
||||
|
||||
When using the polyhedron triangle facet primitive (defined in \ccc{AABB_polyhedron_triangle_primitive.h}) the AABB tree occupies approximately 61 bytes per primitive (without constructing the 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 \ccc{tree.accelerate_distance_queries()}). Note that the polyhedron facet primitive 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 (without constructing the internal KD-tree).\\
|
||||
|
||||
The following table provides orders of memory occupancy in MBytes for an increasing number of triangles. As the internal KD-tree used to accelerate the distance queries dominates the memory occupancy, we recommend to specify for large models a lower number of reference point (evenly distributed) to construct the internal KD-tree through the function \ccc{tree.accelerate_distance_queries(begin,end)} which takes an iterator range as input.
|
||||
|
||||
\begin{tabular}{|l|c|c|}
|
||||
\hline
|
||||
Number of triangles & AABB tree (in MBytes) & AABB tree with internal KD-tree (in MBytes)\\
|
||||
\hline
|
||||
18,400 & 1.10 & 2.76 \\
|
||||
102,400 & 6.33 & 14.73 \\
|
||||
1,022,400 & 59.56 & 151.31 \\
|
||||
1,822,400 & 108.34 & 291.84 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
|
||||
|
||||
\subsection{Intersections}
|
||||
|
||||
The following table measures the number of intersection queries per second on the 14,400 triangle version of the knot mesh model for ray, line, segment and plane queries. Each ray query is generated by choosing a random source point within the mesh bounding box and a random vector. A line or segment query is generated by choosing two random points inside the bounding box. A plane query is generated by picking a random point inside the bounding box and a random normal vector. Note that a plane query generally intersects many triangles of the input surface mesh. This explains the low performance numbers for the intersection functions which enumerate all intersections.
|
||||
|
||||
\begin{tabular}{|l|r|r|r|r|}
|
||||
\hline
|
||||
Function & Segment & Ray & Line & Plane \\
|
||||
\hline
|
||||
do\_intersect() & 187,868 & 185,649 & 206,096 & 377,969 \\
|
||||
any\_intersected\_primitive() & 190,684 & 190,027 & 208,941 & 360,337 \\
|
||||
any\_intersection() & 147,468 & 143,230 & 148,235 & 229,336 \\
|
||||
number\_of\_intersected\_primitives() & 64,389 & 52,943 & 54,559 & 7,906 \\
|
||||
all\_intersected\_primitives() & 65,553 & 54,838 & 53,183 & 5,693 \\
|
||||
all\_intersections() & 46,507 & 38,471 & 36,374 & 2,644 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
Curve \ref{fig:AABB-tree-bench} plots the number of queries per second (here the \ccc{all_intersections} function with random segment queries) against the number of input triangles for the knot triangle surface mesh.
|
||||
|
||||
% benchs over knot model
|
||||
\begin{center}
|
||||
\label{fig:AABB-tree-bench}
|
||||
\begin{ccTexOnly}
|
||||
\includegraphics[width=0.8\textwidth]{AABB_tree/figs/bench}
|
||||
\end{ccTexOnly}
|
||||
\begin{ccHtmlOnly}
|
||||
<img style="max-width: 75%;" border=0 src="./figs/bench.png"><P>
|
||||
\end{ccHtmlOnly}
|
||||
\begin{figure}[ht]
|
||||
\caption{Number of queries per second against number of triangles
|
||||
for the knot model with 14K (shown), 57K, 230K and 921K
|
||||
triangles. We call the \ccc{all_intersections} function
|
||||
with segment queries randomly chosen within
|
||||
the bounding box. }
|
||||
\end{figure}
|
||||
\end{center}
|
||||
|
||||
The following table measures the number of \ccc{all_intersections()} queries per second against several kernels. We use the 14,400 triangle version of the knot mesh model for random segment queries. Note how the \ccc{Simple_cartesian} kernel is substantially faster than the \ccc{Cartesian} kernel.
|
||||
|
||||
\begin{tabular}{|l|c|}
|
||||
\hline
|
||||
Kernel & Queries/s (all\_intersections() with segment queries)\\
|
||||
\hline
|
||||
\ccc{Simple_cartesian<double>} & 46,507 \\
|
||||
\ccc{Simple_cartesian<float>} & 43,187 \\
|
||||
\ccc{Cartesian<double>} & 5,335 \\
|
||||
\ccc{Cartesian<float>} & 5,522 \\
|
||||
\ccc{Exact_predicates_inexact_constructions} & 18,411 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
|
||||
|
||||
\subsection{Distances}
|
||||
|
||||
The surface triangle mesh chosen for benchmarking distances is again the knot model in four increasing resolutions obtained through Loop subdivision. In the following table we first measure the tree construction time (which includes the construction of the internal KD-tree data structure used to accelerate the distance queries by up to one order of magnitude in our experiments). We then measure the number of queries per second for the three types distance queries (\ccc{closest_point}, \ccc{squared_distance} and \ccc{closest_point_and_primitive}) from point queries randomly chosen inside the bounding box.
|
||||
|
||||
\begin{tabular}{|l|c|c|c|c|}
|
||||
\hline
|
||||
Nb triangles & Construction (ms) & Closest\_point() & squared\_distance() & closest\_point\_and\_primitive() \\
|
||||
\hline
|
||||
14,400 & 157 & 45,132 & 45,626 & 45,770 \\
|
||||
57,600 & 328 & 21,589 & 21,312 & 21,137 \\
|
||||
230,400 & 1,437 & 11,063 & 10,962 & 11,086 \\
|
||||
921,600 & 5,953 & 5,636 & 5,722 & 5,703 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
|
||||
|
||||
\subsection{Summary}
|
||||
|
||||
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 some general observations and advices 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 depending on the input surface triangle mesh, the performance expressed in number of queries varies greatly depending on a complex combination of criteria: type of kernel, number of input primitives, distribution of primitives in space, type of function queried, type of query and location of query in space.
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
\item Kernel: The type of \cgal\ kernel turns out to dominate the final execution times, the maximum performances being obtained with the simple Cartesian kernel parameterized with the double precision number type. In applications where the intersection and distance execution times are crucial it is possible to use this kernel for the AABB tree in combination with a more robust kernel for the main data structure.
|
||||
|
||||
\item Primitives: Although the number of input primitives plays an obvious role in the final performance, their distribution in space is at least equally important in order to obtain a well-balanced AABB tree. Ideally the primitives must be evenly distributed in space and the long primitives spanning the bounding box of the tree root node must be avoided as much as possible. It is often beneficial to split these long primitives into smaller ones before constructing the tree, e.g., through recursive longest edge bisection for triangle surface meshes.
|
||||
|
||||
\item Function: The type of function queried plays another important role. Obviously the ``exhaustive'' functions, which list all intersections, are slower than the ones stopping after the first intersection. Within each of these functions the ones which call only intersection tests (do\_intersect(), number\_of\_intersected\_primitives(), any\_intersected\_primitive(), all\_intersected\_primitives()) are faster than the ones which explicitly construct the intersections (any\_intersection() and all\_intersections()).
|
||||
|
||||
\item Query: The type of query (e.g., line, ray, segment or plane used above) plays another role, strongly correlated with the type of function (exhaustive or not, and whether or not it constructs the intersections). When all intersection constructions are needed, the final execution times highly depend on the complexity of the general intersection object. For example a plane query generally intersects a surface triangle mesh into many segments while a segment query generally intersects a surface triangle mesh into few points. Finally, the location of the query in space also plays an obvious role in the performances, especially for the distance queries. Assuming the internal KD-tree constructed through the function \ccc{tree.accelerate_distance_queries()}, it is preferable to specify a query point already close to the surface triangle mesh so that the query traverses only few AABBs of the tree. For a large number of primitive data (greater than 2M faces in our experiments) however we noticed that it is not necessary (and sometimes even slower) to use all reference points when constructing the KD-tree. In these cases we recommend to specify trough the function \ccc{tree.accelerate_distance_queries(begin,end)} fewer reference points (typically not more than 100K) evenly distributed over the input primitives.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
|
|
@ -1,91 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABBGeomTraits.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 25.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBGeomTraitsRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBGeomTraitsDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefConcept}{AABBGeomTraits}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[concept]{} %% add further index entries
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ defines the requirements for the first template parameter of the class \ccc{AABB_traits<GeomTraits, Primitive>}. It provides predicates and constructors to detect and compute intersections between query objects and the primitives stored in the AABB tree. In addition, it contains predicates and constructors to compute distances between a point query and the primitives stored in the AABB tree.
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccNestedType{Sphere_3}{Sphere type, that should be consistent with the distance function chosen for the distance queries, namely the \ccc{Squared_distance_3} functor.}
|
||||
\ccNestedType{Point_3}{Point type.}
|
||||
|
||||
\ccNestedType{Do_intersect_3}{A functor object to detect intersections between two geometric objects.
|
||||
Provides the operators:
|
||||
\ccc{bool operator()(const Type_1& type_1, const Type_2& type_2);}
|
||||
where \ccc{Type_1} and \ccc{Type_2} are relevant types
|
||||
among \ccc{Ray_3}, \ccc{Segment_3}, \ccc{Line_3}, \ccc{Triangle_3}, \ccc{Plane_3} and \ccc{Bbox_3}. Relevant herein means that a line primitive (ray, segment, line) is tested against a planar or solid primitive (plane, triangle, box), and a solid primitive is tested against another solid primitive (box against box). The operator returns \ccc{true} iff \ccc{type_1} and \ccc{type_2} have a non empty intersection.}
|
||||
|
||||
\ccNestedType{Intersect_3}{A functor to construct the intersection between two geometric objects. \\
|
||||
Provides the nested type: \\
|
||||
\ccc{Result<A, B>}; where \ccc{Result<A, B>::Type} is the return type of the \ccc{operator()(A, B)} \\
|
||||
and the operator: \\
|
||||
\ccc{Result<A, B>::Type operator()(const A& a, const B& b);} \\ where \ccc{A} and \ccc{B} are any relevant types among \ccc{Ray_3}, \ccc{Segment_3}, \ccc{Line_3}, \ccc{Triangle_3}, \ccc{Plane_3} and \ccc{Bbox_3}. Relevant herein means that a line primitive (ray, segment, line) is tested against a planar or solid primitive (plane, triangle, box). A model of \ccc{Kernel::Intersect_3} fulfills those requirements.
|
||||
}
|
||||
|
||||
\ccNestedType{Construct_sphere_3}{A functor object to construct the sphere centered at one point and passing through another one. Provides the operator:
|
||||
\ccc{Sphere_3 operator()(const Point_3& p, const Point_3 & q);} which returns the sphere centered at \ccc{p} and passing through \ccc{q}.}
|
||||
|
||||
\ccNestedType{Compute_closest_point_3}{A functor object to compute the point on a geometric primitive which is closest from a query. Provides the operator:
|
||||
\ccc{Point_3 operator()(const Point_3& p, const Type_2& type_2);} where \ccc{Type_2} is any type among \ccc{Segment_3} and \ccc{Triangle_3}. The operator returns the point on \ccc{type_2} which is closest to \ccc{p}.}
|
||||
|
||||
\ccNestedType{Has_on_bounded_side_3}{A functor object to detect if a point lies inside a sphere or not.
|
||||
Provides the operator:
|
||||
\ccc{bool operator()(const Sphere_3& s, const Point_3& p);} which returns \ccc{true} iff the closed volume bounded by \ccc{s} contains \ccc{p}.}
|
||||
|
||||
\ccNestedType{Compute_squared_radius_3}{A functor object to compute the squared radius of a sphere. Provides the operator:
|
||||
\ccc{FT operator()(const Sphere_3& s);} which returns the squared radius of \ccc{s}.}
|
||||
|
||||
\ccNestedType{Compute_squared_distance_3}{A functor object to compute the squared distance between two points. Provides the operator:
|
||||
\ccc{FT operator()(const Point_3& p, const Point_3& q);} which returns the squared distance between \ccc{p} and \ccc{q}.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{geomtraits} %% choose variable name
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccMethod{Do_intersect_3 do_intersect_3_object();}{Returns the intersection detection functor.}
|
||||
|
||||
\ccMethod{Intersect_3 intersect_3_object();}{Returns the intersection constructor.}
|
||||
|
||||
\ccMethod{Construct_sphere_3 construct_sphere_3_object();}{Returns the distance comparison functor.}
|
||||
|
||||
\ccMethod{Compute_closest_point_3 compute_closest_point_3_object();}{Returns the closest point constructor.}
|
||||
|
||||
\ccMethod{Has_on_bounded_side_3 has_on_bounded_side_3_object();}{Returns the closest point constructor.}
|
||||
|
||||
\ccMethod{Compute_squared_radius_3 compute_squared_radius_3_object();}{Returns the squared radius functor.}
|
||||
|
||||
\ccMethod{Compute_squared_distance_3 compute_squared_distance_3_object();}{Returns the squared distance functor.}
|
||||
|
||||
\ccHasModels
|
||||
Any instantiation of \ccc{CGAL::Kernel} is a model of this traits concept.
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABB_traits<GeomTraits,AABBPrimitive>}.
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,74 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABBPrimitive.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBPrimitiveRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBPrimitiveDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefConcept}{AABBPrimitive}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[concept]{} %% add further index entries
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ describes the requirements for the primitives stored in the AABB tree data structure. The concept encapsulates a type for the input datum (a geometric object) and an identifier (id) type through which those primitives are referred to. The concept \ccRefName\ also refines the concepts DefaultConstructible and Assignable.
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccNestedType{Point}{3D point type.}
|
||||
|
||||
\ccNestedType{Datum}{Type of input datum.}
|
||||
|
||||
\ccNestedType{Point_reference}{The type of a reference to an element of type \ccc{Point} returned by the \ccc{point()} function. It is convertible to the type \ccc{Point}.}
|
||||
|
||||
\ccNestedType{Datum_reference}{The type of a reference to an element of type \ccc{Datum} returned by the \ccc{datum()} function. It is convertible to the type \ccc{Datum}.}
|
||||
|
||||
|
||||
|
||||
|
||||
\ccNestedType{Id}{Type of identifiers through which the input objects are referred to. It must be a model of the concepts DefaultConstructible and Assignable.}
|
||||
|
||||
|
||||
% variable name
|
||||
\ccCreationVariable{primitive}
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccMethod{Datum_reference datum();}{Returns the datum (geometric object) represented by the primitive.}
|
||||
|
||||
\ccMethod{Id id();}{Returns the corresponding identifier. This identifier is only used as a reference for the objects in the output of the \ccc{AABB_tree} methods.}
|
||||
|
||||
\ccMethod{Point_reference reference_point();}{Returns a 3D point located on the geometric object represented by the primitive. This function is used to sort the primitives during the AABB tree construction as well as to construct the search KD-tree internal to the AABB tree used to accelerate distance queries.}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccc{AABBPrimitiveWithSharedData}\\
|
||||
\ccc{AABB_tree<AT>}
|
||||
|
||||
\ccExample
|
||||
|
||||
The \ccc{Primitive} type can be, e.g., a wrapper around a \ccc{Handle}. Assume for instance that the input objects are the triangle faces of a mesh stored as a \ccc{CGAL::Polyhedron}. The \ccc{Datum} would be a \ccc{Triangle_3} and the \ccc{Id} would be a polyhedron \ccc{Face_handle}. Method \ccc{datum()} can return either a \ccc{Triangle_3} constructed on the fly from the face handle or a \ccc{Triangle_3} stored internally. This provides a way for the user to trade memory for efficiency.
|
||||
|
||||
\ccHasModels
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,Tag_false,CacheDatum>},\\
|
||||
\ccc{AABB_segment_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_triangle_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,Tag_false,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,Tag_false,CacheDatum>}.\\
|
||||
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
\ccRefPageBegin
|
||||
|
||||
\begin{ccRefConcept}{AABBPrimitiveWithSharedData}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ describes the requirements for the primitives stored in the AABB tree data structure. The concept encapsulates a type for the input datum (a geometric object) and an identifier (id) type through which those primitives are referred to. The concept \ccRefName\ also refines the concepts DefaultConstructible and Assignable.
|
||||
The concept is similar to \ccc{AABBPrimitive} except that some data stored outside of the primitives are required to access the datum and the reference point.
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccNestedType{Point}{3D point type.}
|
||||
|
||||
\ccNestedType{Datum}{Type of input datum.}
|
||||
|
||||
\ccNestedType{Id}{Type of identifiers through which the input objects are referred to. It must be a model of the concepts DefaultConstructible and Assignable.}
|
||||
|
||||
\ccNestedType{Point_reference}{The type of a reference to an element of type \ccc{Point} returned by the \ccc{point(const Shared_data&)} function. It is convertible to the type \ccc{Point}.}
|
||||
|
||||
\ccNestedType{Datum_reference}{The type of a reference to an element of type \ccc{Datum} returned by the \ccc{datum(const Shared_data&)} function. It is convertible to the type \ccc{Datum}.}
|
||||
|
||||
\ccNestedType{Shared_data}{An arbitrary type default constructible.}
|
||||
|
||||
% variable name
|
||||
\ccCreationVariable{primitive}
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccMethod{Datum_reference datum(const Shared_data& data);}{Returns the datum (geometric object) represented by the primitive.}
|
||||
|
||||
\ccMethod{Id id();}{Returns the corresponding identifier. This identifier is only used as a reference for the objects in the output of the \ccc{AABB_tree} methods.}
|
||||
|
||||
\ccMethod{Point_reference reference_point(const Shared_data& data);}{Returns a 3D point located on the geometric object represented by the primitive. This function is used to sort the primitives during the AABB tree construction as well as to construct the search KD-tree internal to the AABB tree used to accelerate distance queries.}
|
||||
|
||||
\ccMethod{template <class ... T> static Shared_data construct_shared_data(T ... t);}
|
||||
{A static function responsible for the creation of the shared data of a primitive type \ccc{T...}.
|
||||
The parameter pack is such that there exists a constructor \ccc{template <class T1, class ... T>} \ccRefName\ \ccc{(T1,T...)}.
|
||||
}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccc{AABBPrimitive}\\
|
||||
\ccc{AABB_tree<AT>}
|
||||
|
||||
\ccExample
|
||||
|
||||
The \ccc{Primitive} type can be, e.g., a wrapper around a \ccc{Handle}. Assume for instance that the input objects are the triangle faces of a mesh stored as a \ccc{CGAL::Polyhedron}. The \ccc{Datum} would be a \ccc{Triangle_3} and the \ccc{Id} would be a polyhedron \ccc{Face_handle}. Method \ccc{datum()} can return either a \ccc{Triangle_3} constructed on the fly from the face handle or a \ccc{Triangle_3} stored internally. This provides a way for the user to trade memory for efficiency.
|
||||
|
||||
\ccHasModels
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,Tag_true,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,Tag_true,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,Tag_true,CacheDatum>}.\\
|
||||
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,136 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABBTraits.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBTraitsRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBTraitsDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefConcept}{AABBTraits}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[concept]{} %% add further index entries
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ provides the geometric primitive types and methods for the class \ccc{AABB_tree<AT>}.
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccNestedType{FT}{Value type of the \ccc{Squared_distance} functor.}
|
||||
|
||||
\ccNestedType{Point_3}{Type of a 3D point.}
|
||||
|
||||
\ccNestedType{Primitive}{Type of primitive.
|
||||
Must be a model of the concepts \ccc{AABBPrimitive} or \ccc{AABBPrimitiveWithSharedData}.}
|
||||
|
||||
\ccNestedType{Bounding_box}{Bounding box type.}
|
||||
|
||||
\ccNestedType{enum Axis \{ X_AXIS, Y_AXIS, Z_AXIS \}}{}
|
||||
|
||||
\ccTypedef{typedef std::pair<Point_3, Primitive::Id> Point_and_primitive_id;}{}
|
||||
|
||||
\begin{ccDeprecated}
|
||||
\ccTypedef{typedef std::pair<Object, Primitive::Id> Object_and_primitive_id;}{}
|
||||
\end{ccDeprecated}
|
||||
|
||||
\ccNestedType{Intersection_and_primitive_id<Query>}{A nested type to aquire the
|
||||
a pair of the return type of intersections with an object of type \ccStyle{Query} and a \ccStyle{Primitive::Id} through the member typedef \ccStyle{Type}.}
|
||||
|
||||
During the construction of the \ccc{AABB_tree}, the primitives are sorted according to some comparison functions related to the $x$, $y$ or $z$ coordinate axis:
|
||||
|
||||
\ccNestedType{Split_primitives_along_x_axis}{A functor object to split a range of primitives into two sub-ranges along the X-axis. Provides the operator:
|
||||
\ccc{void operator()(InputIterator first, InputIterator beyond);} Iterator \ccc{InputIterator} must be a model of RandomAccessIterator and have \ccc{Primitive} as value type. The operator is used for determining the primitives assigned to the two children nodes of a given node, assuming that the goal is to split the X-dimension of the bounding box of the node. The primitives assigned to this node are passed as argument to the operator. It should modify the iterator range in such a way that its first half and its second half correspond to the two children nodes.}
|
||||
|
||||
\ccNestedType{Split_primitives_along_y_axis}{A functor object to split a range of primitives into two sub-ranges along the Y-axis. See \ccc{Split_primitives_along_x_axis} for the detailed description.}
|
||||
|
||||
\ccNestedType{Split_primitives_along_z_axis}{A functor object to split a range of primitives into two sub-ranges along the Z-axis. See \ccc{Split_primitives_along_x_axis} for the detailed description.}
|
||||
|
||||
\ccNestedType{Compute_bbox}{A functor object to compute the bounding box of a set of primitives. Provides the operator:
|
||||
\ccc{Bounding_box operator()(Input_iterator begin, Input_iterator beyond);} Iterator \ccc{InputIterator} must have \ccc{Primitive} as value type. }
|
||||
|
||||
%remove as not used any where in the code
|
||||
%\ccNestedType{Splitting_direction}{A functor object to specify the direction along which the bounding box should be split:
|
||||
%\ccc{Axis operator()(const Bounding_box& bbox);} which returns the direction used for splitting \ccc{bbox}. It is usually the axis aligned with the longest edge of \ccc{bbox}.}
|
||||
|
||||
\ccNestedType{Squared_distance}{A functor object to compute the squared distance between two points. Provides the operator:
|
||||
\ccc{FT operator()(const Point_3& p, const Point_3 & q);} which returns the squared distance between \ccc{p} and \ccc{q}.}
|
||||
|
||||
The following predicates are required for each type \ccc{Query}
|
||||
for which the class \ccc{AABB_tree<AT>} may receive an intersection detection or computation query.
|
||||
|
||||
\ccNestedType{Do_intersect}{A functor object to compute intersection predicates between the query and the nodes of the tree. Provides the operators:
|
||||
\ccc{bool operator()(const Query & q, const Bounding_box & box);} which returns \ccc{true} iff the query intersects the bounding box, and \ccc{bool operator()(const Query & q, const Primitive & primitive);} which returns \ccc{true} iff the query intersects the primitive.}
|
||||
|
||||
\begin{ccDeprecated}
|
||||
\ccNestedType{Intersect}{A functor object to compute the intersection of a query and a primitive. Provides the operator:
|
||||
\ccc{boost::optional<Object_and_primitive_id> operator()(const Query & q, const Primitive& primitive);} which returns the intersection as a pair composed of an object and a primitive id, iff the query intersects the primitive.}
|
||||
\end{ccDeprecated}
|
||||
|
||||
\ccNestedType{Intersect}{A functor object to compute the intersection of a query and a primitive. Provides the operator:
|
||||
\ccc{Intersection_and_primitive_id<Query>::type operator()(const Query & q, const Primitive& primitive);} which returns the intersection as a pair composed of an intersection object and the id of the primitive.}
|
||||
|
||||
The following predicates are required for each type \ccc{Query}
|
||||
for which the class \ccc{AABB_tree<AT>} may receive a distance query.
|
||||
|
||||
\ccNestedType{Compare_distance}{A functor object to compute distance comparisons between the query and the nodes of the tree. Provides the operators:
|
||||
\ccc{bool operator()(const Query & query, const Bounding_box& box, const Point & closest);} which returns \ccc{true} iff the bounding box is closer to \ccc{query} than \ccc{closest} is, and \ccc{bool operator()(const Query & query, const Primitive & primitive, const Point & closest);} which returns \ccc{true} iff \ccc{primitive} is closer to the \ccc{query} than \ccc{closest} is.}
|
||||
|
||||
\ccNestedType{Closest_point}{A functor object to compute closest point from the query on a primitive. Provides the operator:
|
||||
\ccc{Point_3 operator()(const Query& query, const Primitive& primitive, const Point_3 & closest);} which returns the closest point to \ccc{query}, among \ccc{closest} and all points of the primitive.}
|
||||
|
||||
|
||||
|
||||
\ccCreationVariable{traits} %% choose variable name
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccMethod{Split_primitives_along_x_axis split_primitives_along_x_axis_object();}{Returns the primitive splitting functor for the X axis.}
|
||||
|
||||
\ccMethod{Split_primitives_along_y_axis split_primitives_along_y_axis_object();}{Returns the primitive splitting functor for the Y axis.}
|
||||
|
||||
\ccMethod{Split_primitives_along_z_axis split_primitives_along_z_axis_object();}{Returns the primitive splitting functor for the Z axis.}
|
||||
|
||||
\ccMethod{Compute_bbox compute_bbox_object();}{Returns the bounding box constructor.}
|
||||
|
||||
\ccMethod{Do_intersect do_intersect_object();}{Returns the intersection detection functor.}
|
||||
|
||||
\ccMethod{Intersect intersect_object();}{Returns the intersection constructor.}
|
||||
|
||||
\ccMethod{Compare_distance compare_distance_object();}{Returns the distance comparison functor.}
|
||||
|
||||
\ccMethod{Closest_point closest_point_object();}{Returns the closest point constructor.}
|
||||
|
||||
\ccMethod{Squared_distance squared_distance_object();}{Returns the squared distance functor.}
|
||||
|
||||
In addition, if \ccc{Primitive} is a model of the concept \ccc{AABBPrimitiveWithSharedData}, the following functions are part of the concept:
|
||||
|
||||
\ccMethod{template <class ... T> void set_shared_data(T ... t);}
|
||||
{the signature of that function must be the same as the static function \ccc{Primitive::construct_shared_data}. The type \ccc{Primitive} expects that the data constructed
|
||||
by a call to \ccc{Primitive::construct_shared_data(t...)} is the one given back when accessing the reference point and the datum of a primitive.}
|
||||
|
||||
\ccMethod{const Primitive::Shared_data& shared_data() const;}{Returns the shared data of the primitive constructed after a call to \ccc{set_shared_data}. If no call to \ccc{set_shared_data}
|
||||
has been done, \ccc{Primitive::Shared_data()} is returned.}
|
||||
|
||||
\ccHasModels
|
||||
\ccc{AABB_traits<GeomTraits,Primitive>}.
|
||||
|
||||
\ccSeeAlso
|
||||
\ccc{AABB_traits<GeomTraits,Primitive>}\\
|
||||
\ccc{AABB_tree<AT>}
|
||||
\ccc{AABBPrimitive}
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
\ccRefPageBegin
|
||||
|
||||
\begin{ccRefClass}{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
If \ccc{OneFaceGraphPerTree} is \ccc{CGAL::Tag_false}, the class is a model of the concept \ccc{AABBPrimitive}.
|
||||
If \ccc{OneFaceGraphPerTree} is \ccc{CGAL::Tag_true}, the class is a model of the concept \ccc{AABBPrimitiveWithSharedData}.
|
||||
It wraps a \ccc{face_descriptor} of a class model of \ccc{FaceGraph} to a 3D triangle.
|
||||
The class model of \ccc{FaceGraph} from which the primitive is built should not be deleted
|
||||
while the AABB tree holding the primitive is in use.
|
||||
|
||||
|
||||
|
||||
\ccParameters
|
||||
\ccc{FaceGraph} is a CGAL polyhedron.\\
|
||||
\ccc{OneFaceGraphPerTree} is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, we guarantee that all the primitives will be from a common \ccc{FaceGraph} and some data
|
||||
will be factorized so that the size of the primitive is reduced. In the latter case, the primitives can be from different graphs and extra storage is required in the primitives. The default is \ccc{CGAL::Tag_true}.\\
|
||||
\ccc{CacheDatum} is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the datum is stored in the primitive, while in the latter it is constructed on the fly to reduce
|
||||
the memory footprint. The default is \ccc{CGAL::Tag_false} (datum is not stored).\\
|
||||
|
||||
\ccInclude{CGAL/AABB_face_graph_triangle_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
\ccTypedef{typedef boost::property_traits< boost::property_map< FaceGraph, vertex_point_t>::type >::value_type Point;}{The point type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Kernel_traits<Point>::Kernel::Triangle_3 Datum;}{Geometric data type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef boost::graph_traits<FaceGraph>::face_descriptor Id;}{Id type.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{p}
|
||||
|
||||
\ccConstructor{
|
||||
template <class Iterator>
|
||||
AABB_face_graph_triangle_primitive(Iterator it,const FaceGraph& graph)}
|
||||
{Constructs a primitive. \ccc{Iterator} is an input iterator with \ccc{Id} as \ccc{value_type}.}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>}.\\
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
\ccRefPageBegin
|
||||
|
||||
\begin{ccRefClass}{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
If \ccc{OneHalfedgeGraphPerTree} is \ccc{CGAL::Tag_false}, the class is a model of the concept \ccc{AABBPrimitive}.
|
||||
If \ccc{OneHalfedgeGraphPerTree} is \ccc{CGAL::Tag_true}, the class is a model of the concept \ccc{AABBPrimitiveWithSharedData}.
|
||||
It wraps an \ccc{edge_descriptor} of a class model of \ccc{HalfedgeGraph} to a 3D segment.
|
||||
The class model of \ccc{HalfedgeGraph} from which the primitive is built should not be deleted
|
||||
while the AABB tree holding the primitive is in use.
|
||||
|
||||
|
||||
|
||||
\ccParameters
|
||||
\ccc{HalfedgeGraph} is a model of the halfedge graph concept.\\
|
||||
\ccc{OneHalfedgeGraphPerTree} is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, we guarantee that all the primitives will be from a common \ccc{HalfedgeGraph} and some data
|
||||
will be factorized so that the size of the primitive is reduced. In the latter case, the primitives can be from different graphs and extra storage is required in the primitives. The default is \ccc{CGAL::Tag_true}.\\
|
||||
\ccc{CacheDatum} is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the datum is stored in the primitive, while in the latter it is constructed on the fly to reduce
|
||||
the memory footprint. The default is \ccc{CGAL::Tag_false} (datum is not stored).
|
||||
|
||||
\ccInclude{CGAL/AABB_halfedge_graph_segment_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
\ccTypedef{typedef boost::property_traits< boost::property_map< HalfedgeGraph, vertex_point_t>::type >::value_type Point;}{The point type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Kernel_traits<Point>::Kernel::Segment_3 Datum;}{Geometric data type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef boost::graph_traits<HalfedgeGraph>::edge_descriptor Id;}{Id type.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{p}
|
||||
|
||||
\ccConstructor{
|
||||
template <class Iterator>
|
||||
AABB_halfedge_graph_segment_primitive(Iterator it,const HalfedgeGraph& graph)}
|
||||
{Constructs a primitive. \ccc{Iterator} is an input iterator with \ccc{Id} as \ccc{value_type}.
|
||||
The example below gives a way to call this constructor the insert-by-range method of the class \ccc{CGAL::AABB_tree<Traits>}.}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}.\\
|
||||
|
||||
\ccIncludeExampleCode{AABB_tree/AABB_halfedge_graph_edge_example.cpp}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABB_traits_base.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBtraitsbaseRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBtraitsbaseDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefClass}{AABB_polyhedron_segment_primitive<GeomTraits,Polyhedron>}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[class]{} %% add further index entries
|
||||
|
||||
This class is deprecated since \cgal\ 4.3, the class \ccc{CGAL::AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>} should be used instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is a model of the concept \ccc{AABBPrimitive}. It wraps a halfedge handle of a polyhedron, which is used as id, and allows the construction of the datum on the fly. Since only the halfedge handle is stored in this primitive, the polyhedron from which the AABB tree is built should not be deleted while the AABB tree is in use.
|
||||
|
||||
\ccParameters
|
||||
The template parameter \ccc{GeomTraits} provides a \ccc{Point_3} type, used as \ccc{Point}, and a \ccc{Segment_3} type, used as \ccc{Datum} and constructible from two arguments of type \ccc{Point}. The template parameter \ccc{Polyhedron} should be a \ccc{CGAL::Polyhedron} whose points have type \ccc{Point}.
|
||||
|
||||
\ccInclude{CGAL/AABB_polyhedron_segment_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
\ccTypedef{typedef GeomTraits::Segment_3 Datum;}{Geometric data type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Polyhedron::Halfedge_handle Id;}{Id type.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_polyhedron_triangle_primitive<GeomTraits,Polyhedron>}\\
|
||||
\end{ccDeprecated}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABB_traits_base.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBtraitsbaseRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBtraitsbaseDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
|
||||
\begin{ccRefClass}{AABB_polyhedron_triangle_primitive<GeomTraits,Polyhedron>}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[class]{} %% add further index entries
|
||||
|
||||
This class is deprecated since \cgal\ 4.3, the class \ccc{CGAL::AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>} should be used instead.
|
||||
|
||||
\begin{ccDeprecated}
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is a model of the concept \ccc{AABBPrimitive}. It wraps a facet handle of a polyhedron, which is used as id, and allows the construction of the datum on the fly. Since only the facet handle is stored in this primitive, the polyhedron from which the AABB tree is built should not be deleted while the AABB tree is in use.
|
||||
|
||||
\ccParameters
|
||||
The template parameter \ccc{GeomTraits} provides a \ccc{Point_3} type, used as \ccc{Point}, and a \ccc{Triangle_3} type, used as \ccc{Datum} and constructible from three arguments of type \ccc{Point}. The template parameter \ccc{Polyhedron} should be a \ccc{CGAL::Polyhedron} whose points have type \ccc{Point}.
|
||||
|
||||
\ccInclude{CGAL/AABB_polyhedron_triangle_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccTypedef{typedef GeomTraits::Triangle_3 Datum;}{Geometric data type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Polyhedron::Facet_handle Id;}{Id type.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_polyhedron_segment_primitive<GeomTraits,Polyhedron>}\\
|
||||
\end{ccDeprecated}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
|
||||
\begin{ccRefClass}{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
If \ccc{ExternalPropertyMaps} is \ccc{CGAL::Tag_false}, the class is a model of the concept \ccc{AABBPrimitive}.
|
||||
If \ccc{ExternalPropertyMaps} is \ccc{CGAL::Tag_true}, the class is a model of the concept \ccc{AABBPrimitiveWithSharedData}.
|
||||
The two property maps which are template parameters of the class enable to get the datum and the reference point of
|
||||
the primitive from the identifier. The last template parameter controls whether the primitive class holds a copy of the datum.
|
||||
|
||||
|
||||
\ccParameters
|
||||
\ccc{ObjectPropertyMap} is a model of \ccAnchor{http://www.boost.org/doc/libs/release/libs/property_map/doc/ReadablePropertyMap.html}{boost::ReadablePropertyMap}
|
||||
with \ccc{Id} as \ccc{key_type}. It must be default constructible.\\
|
||||
\ccc{PointPropertyMap} is a model of \ccAnchor{http://www.boost.org/doc/libs/release/libs/property_map/doc/ReadablePropertyMap.html}{boost::ReadablePropertyMap}
|
||||
with \ccc{Id} as \ccc{key_type}. It must be default constructible.\\
|
||||
\ccc{ExternalPropertyMaps}: either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the property maps will be stored in the traits class, while in the latter they will be stored in the primitive (which increases the size of each primitive).\\
|
||||
\ccc{CacheDatum}: either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the datum is stored in the primitive, while in the latter it is constructed on the fly to reduce
|
||||
the memory footprint. The default is \ccc{CGAL::Tag_false} (datum is not stored).
|
||||
|
||||
\ccInclude{CGAL/AABB_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccTypedef{typedef boost::property_traits< ObjectPropertyMap >::value_type Datum;}{The geometric data type is the \ccc{value_type} of \ccc{ObjectPropertyMap}.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef boost::property_traits< PointPropertyMap >::value_type Point;}{The point type is the \ccc{value_type} of \ccc{PointPropertyMap}.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Id Id;}{Id type.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{p}
|
||||
|
||||
\ccConstructor{AABB_primitive(Id id,ObjectPropertyMap o_pmap=ObjectPropertyMap(),PointPropertyMap p_pmap=PointPropertyMap());}
|
||||
{Constructs a primitive and initialize the property maps.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_segment_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_triangle_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}.
|
||||
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
|
||||
\begin{ccRefClass}{AABB_segment_primitive<Iterator,CacheDatum>}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is a model of the concept \ccc{AABBPrimitive}.
|
||||
An iterator with a 3D segment as \ccc{value_type} is used as identifier.
|
||||
The iterator from which the primitive is built should not be invalided while the AABB tree holding the primitive is in use.
|
||||
|
||||
\ccParameters
|
||||
\ccc{Iterator} is a model of Forward Iterator concept, with \ccc{value_type} being \ccc{CGAL::Segment_3<Kernel>}.\\
|
||||
\ccc{CacheDatum}: either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the datum is stored in the primitive, while in the latter it is constructed on the fly to reduce
|
||||
the memory footprint. The default is \ccc{CGAL::Tag_false} (datum is not stored).
|
||||
|
||||
\ccInclude{CGAL/AABB_segment_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccTypedef{typedef std::iterator_traits< Iterator >::value_type Datum;}{The geometric data type is the \ccc{value_type} of \ccc{Iterator}.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef CGAL::Kernel_traits<Datum>::Kernel::Point_3 Point;}{The point type is from the same Kernel as the 3D segment.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Iterator Id;}{Id type.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{p}
|
||||
|
||||
\ccConstructor{AABB_primitive(Id id);}{Constructs a primitive.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>},\\
|
||||
\ccc{AABB_triangle_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}.
|
||||
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,65 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABB_traits_base.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBtraitsbaseRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBtraitsbaseDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefClass}{AABB_traits<GeomTraits,Primitive>}
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[class]{} %% add further index entries
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is a model of the concept \ccc{AABBTraits}. This traits class handles any type of 3D geometric primitives provided that the proper intersection tests and constructions are implemented. It handles points, rays, lines and segments as query types for intersection detection and computations, and it handles points as query type for distance queries.
|
||||
|
||||
\ccParameters
|
||||
The template parameter \ccc{GeomTraits} provides the geometric types as well as the intersection tests and computations required. This type must be a model of the concept \ccc{AABBGeomTraits}. The template parameter \ccc{Primitive} provides the type of primitives stored in the AABB tree. This parameter must be a model of the concept \ccc{AABBPrimitive} or of the concept \ccc{AABBPrimitiveWithSharedData}.
|
||||
|
||||
\ccInclude{CGAL/AABB_traits.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccTypedef{typedef GeomTraits::FT FT;}{}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef GeomTraits::Point_3 Point_3;}{}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef CGAL::Bbox_3 Bounding_box;}{}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef GeomTraits::Line_3 Line_3;}{Line query type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef GeomTraits::Segment_3 Segment_3;}{Segment query type.}
|
||||
\ccGlue
|
||||
\ccNestedType{size_type}{Unsigned integral type.}
|
||||
\ccGlue
|
||||
\ccNestedType{Intersection}{The function object used for Intersection computation.}
|
||||
|
||||
%\ccCreation
|
||||
\ccCreationVariable{traits}
|
||||
|
||||
\ccConstructor{AABB_traits(GeomTraits gt = GeomTraits());}{Default constructor.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBTraits},\\
|
||||
\ccc{AABB_tree<AT>}, \\
|
||||
\ccc{AABBPrimitive}\\
|
||||
\ccc{AABBPrimitiveWithSharedData}\\
|
||||
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
|
@ -1,205 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | Reference manual page: AABB_tree.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | 21.02.2009 Author
|
||||
% | Package: Package
|
||||
% |
|
||||
\RCSdef{\RCSAABBtreeRev}{$Id: header.tex 40270 2007-09-07 15:29:10Z lsaboret $}
|
||||
\RCSdefDate{\RCSAABBtreeDate}{$Date: 2007-09-07 17:29:10 +0200 (Ven, 07 sep 2007) $}
|
||||
% |
|
||||
\ccRefPageBegin
|
||||
%%RefPage: end of header, begin of main body
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
|
||||
\begin{ccRefClass}{AABB_tree<AT>} %% add template arg's if necessary
|
||||
|
||||
%% \ccHtmlCrossLink{} %% add further rules for cross referencing links
|
||||
%% \ccHtmlIndexC[class]{} %% add further index entries
|
||||
|
||||
\ccDefinition
|
||||
|
||||
Class \ccRefName\ is a static data structure for efficient intersection and distance computations in 3D. It builds a hierarchy of axis-aligned bounding boxes (an AABB tree) from a set of 3D geometric objects, and can receive intersection and distance queries, provided that the corresponding predicates are implemented in the traits class \ccc{AT}. The template parameter \ccc{AT} stands for a traits class which must be a model of the concept \ccc{AABBTraits}.
|
||||
An instance of the class \ccc{AABBTraits} is internally stored.
|
||||
|
||||
\ccInclude{CGAL/AABB_tree.h}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{size_type;}{Unsigned integral size type.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef AT::FT FT;}{Number type returned by the distance queries.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef AT::Point_3 Point;}{Type of 3D point.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef AT::Primitive Primitive;}{Type of input primitive.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef AT::Bounding_box Bounding_box;}{Type of bounding box.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef std::pair<Point, Primitive::Id> Point_and_primitive_id;}{}
|
||||
\ccGlue
|
||||
\begin{ccDeprecated}
|
||||
\ccTypedef{typedef std::pair<CGAL::Object, Primitive::Id> Object_and_primitive_id;}{}
|
||||
\end{ccDeprecated}
|
||||
\ccGlue
|
||||
\ccNestedType{Intersection_and_primitive_id<Query>}{A nested type to aquire the
|
||||
return type of intersections with an object of type \ccStyle{Query} through the member typedef \ccStyle{Type} equal to \ccStyle{std::pair< >}}
|
||||
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{tree}
|
||||
|
||||
\ccConstructor{AABB_tree(AABBTraits traits=AABBTraits());}{Constructs an empty tree, and initializes the internally stored traits class using \ccc{traits}.}
|
||||
\ccConstructor{template < class InputIterator, class ... T>
|
||||
AABB_tree( InputIterator begin,
|
||||
InputIterator beyond,
|
||||
T ... t);}
|
||||
{ Equivalent to constructing an empty tree and calling \ccc{insert(first,last,t...)}.
|
||||
For compilers that do not support variadic templates, overloads up to 5 template arguments are provided.}
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccMethod{template < class InputIterator, class ... T>
|
||||
void rebuild(InputIterator begin,
|
||||
InputIterator beyond,
|
||||
T ... t);}
|
||||
{ Equivalent to calling \ccc{clear()} followed by \ccc{insert(first,last,t...)}.
|
||||
For compilers that do not support variadic templates, overloads up to 5 template arguments are provided.}
|
||||
|
||||
\ccMethod{void clear();}{Clears the AABB tree. }
|
||||
|
||||
|
||||
\ccMethod{template <class InputIterator, class ... T>
|
||||
void insert(InputIterator begin, InputIterator beyond, T ... t);}
|
||||
{Add a sequence of primitives to the set of primitives of the AABB
|
||||
tree. Type \ccc{InputIterator} is any iterator and parameter pack \ccc{T} any types such that \ccc{Primitive}
|
||||
has a constructor with the following signature: \ccc{Primitive(InputIterator, T...)}. If \ccc{Primitive} is a model of
|
||||
the concept \ccc{AABBPrimitiveWithSharedData}, a call to \ccc{AABBTraits::set_shared_data(t...)} is made using the internally stored traits.
|
||||
For compilers that do not support variadic templates, overloads up to 5 template arguments are provided.}
|
||||
|
||||
\ccMethod{void insert(const Primitive p);}
|
||||
{Add a primitive to the set of primitives of the AABB tree.}
|
||||
|
||||
\begin{ccAdvanced}
|
||||
\ccMethod{void build();}
|
||||
{After one or more calls to \ccHtmlNoLinksFrom{\ccc{insert}}, the internal data structure
|
||||
of \ccRefName\ must be reconstructed. This procedure has a complexity of
|
||||
\ccc{O(n log(n))}, where n is the number of primitives of the tree. This
|
||||
procedure is called implicitly at the first call to a query member
|
||||
function. You can call \ccc{build()} explicitly to ensure that the
|
||||
next call to query functions will not trigger the reconstruction of the
|
||||
data structure.}
|
||||
\end{ccAdvanced}
|
||||
|
||||
|
||||
\ccMethod{Bounding_box bbox() const;}{Returns the axis-aligned bounding box of the whole tree. }
|
||||
\ccGlue
|
||||
\ccMethod{size_type size() const;}{Returns the number of primitives in the tree. }
|
||||
\ccGlue
|
||||
\ccMethod{bool empty() const;}{Returns \ccc{true}, iff tree contains no primitive. }
|
||||
\ccGlue
|
||||
\ccMethod{const AABBTraits& traits() const;}{Returns a const reference to the internally stored traits class.}
|
||||
% INTERSECTION TESTS
|
||||
\ccHeading{Intersection Tests}
|
||||
|
||||
\ccMethod{template <class Query>
|
||||
bool do_intersect(const Query& query) const;}{Returns \ccc{true}, iff the query intersects at least one of the input primitives. Type \ccc{Query} must be a type for which \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates are defined in the \ccc{AT} class.}
|
||||
\ccGlue
|
||||
\ccMethod{template <class Query>
|
||||
size_type number_of_intersected_primitives(const Query& query) const;}{Returns the number of primitives intersected by the query. Type \ccc{Query} must be a type for which \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates are defined in the \ccc{AT} class.}
|
||||
\ccGlue
|
||||
\ccMethod{template <class Query, class OutputIterator>
|
||||
OutputIterator
|
||||
all_intersected_primitives(const Query& query,
|
||||
OutputIterator out) const;}{Outputs to the iterator the list of all intersected primitives ids. This function does not compute the intersection points and is hence faster than the function \ccc{all_intersections} function below. Type \ccc{Query} must be a type for which \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates are defined in the \ccc{AT} class.}
|
||||
\ccGlue
|
||||
\ccMethod{template <class Query>
|
||||
boost::optional<Primitive::Id>
|
||||
any_intersected_primitive(const Query& query) const;}{Returns the first encountered intersected primitive id, iff the query intersects at least one of the input primitives. No particular order is guaranteed over the tree traversal, such that, e.g, the primitive returned is not necessarily the closest from the source point of a ray query. Type \ccc{Query} must be a type for which \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates are defined in the \ccc{AT} class.}
|
||||
|
||||
|
||||
% INTERSECTIONS
|
||||
\ccHeading{Intersections}
|
||||
|
||||
\ccMethod{template <class Query, class OutputIterator>
|
||||
OutputIterator all_intersections(const Query& query,
|
||||
OutputIterator out);}{Outputs the list of all intersections, as objects of
|
||||
type \ccc{Intersection__and_primitive_id<Query>::Type},
|
||||
between the query and the input data to
|
||||
the iterator. \ccHtmlNoLinksFrom{\ccc{do_intersect}}
|
||||
predicates and intersections must be defined for \ccc{Query}
|
||||
in the \ccc{AT} class.}
|
||||
\ccGlue
|
||||
\begin{ccDeprecated}
|
||||
\ccMethod{template <class Query>
|
||||
boost::optional<Object_and_primitive_id>
|
||||
any_intersection(const Query& query);}{Returns the first encountered intersection, iff the query intersects at least one of the input primitives. No particular order is guaranteed over the tree traversal, such that, e.g, the primitive returned is not necessarily the closest from the source point of a ray query. Type \ccc{Query} must be a type for which \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates and intersections are defined in the \ccc{AT} class.}
|
||||
\end{ccDeprecated}
|
||||
\ccGlue
|
||||
\ccMethod{template<class Query> Intersection_and_primitive_id<Query>::Type any_intersection(const Query& query);}{Returns the first encountered intersection. No particular order is guaranteed over the tree traversal, e.g, the primitive returned is not necessarily the closest from the source point of a ray query. \ccHtmlNoLinksFrom{\ccc{do_intersect}} predicates and intersections must be defined for \ccc{Query} in the \ccc{AT} class.}
|
||||
|
||||
% DISTANCE QUERIES
|
||||
\ccHeading{Distance Queries}
|
||||
|
||||
\ccMethod{FT
|
||||
squared_distance(const Point& query) const;}{Returns the minimum squared distance between the query point and all input primitives. Method \ccc{accelerate_distance_queries} should be called before the first distance query, so that an internal secondary search structure is build, for improving performance.}
|
||||
\ccGlue
|
||||
\ccMethod{Point
|
||||
closest_point(const Point& query) const;}{Returns the point in the union of all input primitives which is closest to the query. In case there are several closest points, one arbitrarily chosen closest point is returned. Method \ccc{accelerate_distance_queries} should be called before the first distance query, so that an internal secondary search structure is build, for improving performance.}
|
||||
\ccGlue
|
||||
\ccMethod{Point_and_primitive_id
|
||||
closest_point_and_primitive(const Point& query) const;}{Returns a \ccc{Point_and_primitive_id} which realizes the smallest distance between the query point and all input primitives. Method \ccc{accelerate_distance_queries} should be called before the first distance query, so that an internal secondary search structure is build, for improving performance.}
|
||||
|
||||
% ACCELERATING THE DISTANCE QUERIES
|
||||
|
||||
\ccHeading{Accelerating the Distance Queries}
|
||||
|
||||
\ccMethod{bool accelerate_distance_queries() const;}{ Constructs an internal data structure for accelerating distance queries. This method should be called once, before the first distance query.
|
||||
Returns \ccc{true}, iff the memory allocation is successful.}
|
||||
|
||||
\begin{ccAdvanced}
|
||||
In the following paragraphs, we discuss details of the implementation of the distance queries. We explain the internal use of hints, how the user can pass his own hints to the tree, and how the user can influence the construction of the secondary data structure used for accelerating distance queries.
|
||||
|
||||
Internally, the distance queries algorithms are initialized with some hint, which has the same type as the return type of the query, and this value is refined along a traversal of the tree, until it is optimal, that is to say until it realizes the shortest distance to the primitives. In particular, the exact specification of these internal algorithms is that they minimize the distance to the object composed of the union of the primitives and the hint.
|
||||
|
||||
It follows that
|
||||
\begin{itemize}
|
||||
\item in order to return the exact distance to the set of primitives, the algorithms need the hint to be exactly on the primitives;
|
||||
\item if this is not the case, and if the hint happens to be closer to the query point than any of the primitives, then the hint is returned.
|
||||
\end{itemize}
|
||||
This second observation is reasonable, in the sense that providing a hint to the algorithm means claiming that this hint belongs to the union of the primitives. These considerations about the hints being exactly on the primitives or not are important: in the case where the set of primitives is a triangle soup, and if some of the primitives are large, one may want to provide a much better hint than a vertex of the triangle soup could be. It could be, for example, the barycenter of one of the triangles. But, except with the use of an exact constructions kernel, one cannot easily construct points other than the vertices, that lie exactly on a triangle soup. Hence, providing a good hint sometimes means not being able to provide it exactly on the primitives. In rare occasions, this hint can be returned as the closest point.
|
||||
|
||||
In order to accelerate distance queries significantly, the AABB tree builds an internal KD-tree containing a set of potential hints, when the method \ccc{accelerate_distance_queries} is called. This KD-tree provides very good hints that allow the algorithms to run much faster than with a default hint (such as the \ccc{reference_point} of the first primitive). The set of potential hints is a sampling of the union of the primitives, which is obtained, by default, by calling the method \ccc{reference_point} of each of the primitives. However, such a sampling with one point per primitive may not be the most relevant one: if some primitives are very large, it helps inserting more than one sample on them. Conversely, a sparser sampling with less than one point per input primitive is relevant in some cases.
|
||||
|
||||
For this reason, the user can provide his own set of sample points:
|
||||
|
||||
\ccMethod{template <class InputIterator>
|
||||
bool accelerate_distance_queries(InputIterator begin,
|
||||
InputIterator beyond) const;}{Constructs an internal KD-tree containing the specified point set, to be used as the set of potential hints for accelerating the distance queries. \ccc{InputIterator} is an iterator with value type \ccc{Point_and_primitive_id}.}
|
||||
|
||||
Note that, in some cases, the user is not able to provide ids of the primitives on which the points lie. In these cases, providing a default value for the ids of the hints is possible. Still, the user should be aware that if she uses the \ccc{closest_point_and_primitive} method, there is a (tiny) chance that a hint is returned, along with this default value as corresponding primitive id. Hence, the validity of the returned primitive id should be checked in these cases.
|
||||
|
||||
As an alternative to using the KD-tree, the user can also provide the hints directly, by using the following methods:
|
||||
|
||||
\ccMethod{FT
|
||||
squared_distance(const Point& query, const Point& hint) const;}{Returns the minimum squared distance between the query point and all input primitives. The internal KD-tree is not used.}
|
||||
|
||||
\ccMethod{Point
|
||||
closest_point(const Point& query, const Point& hint) const;}{Returns the point in the union of all input primitives which is closest to the query. In case there are several closest points, one arbitrarily chosen closest point is returned. The internal KD-tree is not used.}
|
||||
|
||||
\ccMethod{Point_and_primitive_id
|
||||
closest_point_and_primitive(const Point& query, const Point_and_primitive_id& hint) const;}{Returns a \ccc{Point_and_primitive_id} which realizes the smallest distance between the query point and all input primitives. The internal KD-tree is not used.}
|
||||
|
||||
\end{ccAdvanced}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBTraits}, \\
|
||||
\ccc{AABBPrimitive}.
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
% +------------------------------------------------------------------------+
|
||||
%%RefPage: end of main body, begin of footer
|
||||
\ccRefPageEnd
|
||||
% EOF
|
||||
% +------------------------------------------------------------------------+
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
|
||||
\begin{ccRefClass}{AABB_triangle_primitive<Iterator,CacheDatum>}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is a model of the concept \ccc{AABBPrimitive}.
|
||||
An iterator with a 3D triangle as \ccc{value_type} is used as identifier.
|
||||
The iterator from which the primitive is built should not be invalided while the AABB tree holding the primitive is in use.
|
||||
|
||||
\ccParameters
|
||||
\ccc{Iterator} is a model of Forward Iterator concept, with \ccc{value_type} being \ccc{CGAL::Triangle_3<Kernel>}.\\
|
||||
\ccc{CacheDatum}: either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. In the former case, the datum is stored in the primitive, while in the latter it is constructed on the fly to reduce
|
||||
the memory footprint. The default is \ccc{CGAL::Tag_false} (datum is not stored).
|
||||
|
||||
\ccInclude{CGAL/AABB_triangle_primitive.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccTypedef{typedef std::iterator_traits< Iterator >::value_type Datum;}{The geometric data type is the \ccc{value_type} of \ccc{Iterator}.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef CGAL::Kernel_traits<Datum>::Kernel::Point_3 Point;}{The point type is from the same Kernel as the 3D triangle.}
|
||||
\ccGlue
|
||||
\ccTypedef{typedef Iterator Id;}{Id type.}
|
||||
|
||||
\ccCreation
|
||||
\ccCreationVariable{p}
|
||||
|
||||
\ccConstructor{AABB_primitive(Id id);}{Constructs a primitive.}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccc{AABBPrimitive},\\
|
||||
\ccc{AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>},\\
|
||||
\ccc{AABB_segment_primitive<Iterator,CacheDatum>},\\
|
||||
\ccc{AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>},\\
|
||||
\ccc{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}.
|
||||
|
||||
|
||||
\end{ccRefClass}
|
||||
|
||||
\ccRefPageEnd
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
\ccRefChapter{3D Fast Intersection and Distance Computation (AABB Tree)}
|
||||
\ccChapterAuthor{Pierre Alliez,
|
||||
St{\'e}phane Tayeb,
|
||||
Camille Wormser}
|
||||
|
||||
\section{Classified Reference Pages}
|
||||
|
||||
\subsection*{Concepts}
|
||||
\ccRefConceptPage{AABBPrimitive} \\
|
||||
\ccRefConceptPage{AABBPrimitiveWithSharedData} \\
|
||||
\ccRefConceptPage{AABBTraits} \\
|
||||
\ccRefConceptPage{AABBGeomTraits}
|
||||
|
||||
\subsection*{Classes}
|
||||
\ccRefIdfierPage{CGAL::AABB_traits<GeomTraits,Primitive>} \\
|
||||
\ccRefIdfierPage{CGAL::AABB_tree<AT>} \\
|
||||
\ccRefIdfierPage{CGAL::AABB_triangle_primitive<Iterator,CacheDatum>}\\
|
||||
\ccRefIdfierPage{CGAL::AABB_segment_primitive<Iterator,CacheDatum>}\\
|
||||
\ccRefIdfierPage{CGAL::AABB_primitive<Id,ObjectPropertyMap,PointPropertyMapPolyhedron,ExternalPropertyMaps,CacheDatum>}\\
|
||||
\ccRefIdfierPage{CGAL::AABB_halfedge_graph_segment_primitive<HalfedgeGraph,OneHalfedgeGraphPerTree,CacheDatum>}\\
|
||||
\ccRefIdfierPage{AABB_face_graph_triangle_primitive<FaceGraph,OneFaceGraphPerTree,CacheDatum>}
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
% +------------------------------------------------------------------------+
|
||||
% | CBP Reference Manual: main.tex
|
||||
% +------------------------------------------------------------------------+
|
||||
% | Automatically generated driver file for the reference manual chapter
|
||||
% | of this package. Do not edit manually, you may loose your changes.
|
||||
% +------------------------------------------------------------------------+
|
||||
|
||||
\input{AABB_tree_ref/introduction.tex}
|
||||
|
||||
\input{AABB_tree_ref/AABB_tree.tex}
|
||||
\input{AABB_tree_ref/AABBGeomTraits.tex}
|
||||
\input{AABB_tree_ref/AABBPrimitive.tex}
|
||||
\input{AABB_tree_ref/AABBPrimitiveWithSharedData.tex}
|
||||
\input{AABB_tree_ref/AABB_primitive.tex}
|
||||
\input{AABB_tree_ref/AABB_triangle_primitive.tex}
|
||||
\input{AABB_tree_ref/AABB_segment_primitive.tex}
|
||||
\input{AABB_tree_ref/AABB_halfedge_graph_segment_primitive.tex}
|
||||
\input{AABB_tree_ref/AABB_face_graph_triangle_primitive.tex}
|
||||
\input{AABB_tree_ref/AABBTraits.tex}
|
||||
\input{AABB_tree_ref/AABB_traits.tex}
|
||||
\input{AABB_tree_ref/AABB_polyhedron_triangle_primitive.tex}
|
||||
\input{AABB_tree_ref/AABB_polyhedron_segment_primitive.tex}
|
||||
|
||||
%% EOF
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 KiB |
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccPkgDescription}{Algebraic Foundations\label{Pkg:AlgebraicFoundations}}
|
||||
\ccPkgHowToCiteCgal{cgal:h-af-12}
|
||||
\ccPkgSummary{
|
||||
This package defines what algebra means for \cgal, in terms of
|
||||
concepts, classes and functions. The main features are:
|
||||
(i) explicit concepts for interoperability of types
|
||||
(ii) separation between algebraic types (not necessarily embeddable
|
||||
into the reals), and number types (embeddable into the reals).
|
||||
}
|
||||
%
|
||||
%\ccPkgDependsOn{}
|
||||
\ccPkgIntroducedInCGAL{3.3}
|
||||
\ccPkgLicense{\ccLicenseLGPL}
|
||||
\ccPkgIllustration{Algebraic_foundations/Algebraic_foundations2.png}
|
||||
{Algebraic_foundations/Algebraic_foundations2.png}
|
||||
\end{ccPkgDescription}
|
||||
|
|
@ -1,247 +0,0 @@
|
|||
|
||||
\section{Algebraic Structures}
|
||||
|
||||
%\subsection{Software Design}
|
||||
|
||||
The algebraic structure concepts introduced within this section are
|
||||
motivated by their well known counterparts in traditional algebra,
|
||||
but we also had to pay tribute to existing types and their restrictions.
|
||||
To keep the interface minimal,
|
||||
it was not desirable to cover all known algebraic structures,
|
||||
e.g., we did not introduce concepts for such basic structures as {\em groups} or
|
||||
exceptional structures as {\em skew fields}.
|
||||
|
||||
\begin{figure}[htbp]
|
||||
\begin{ccTexOnly}
|
||||
\begin{center}
|
||||
\includegraphics[width=3in]{Algebraic_foundations/fig/AlgebraicConceptHierarchy}
|
||||
%.ps(PS) .png(PDF)
|
||||
\end{center}
|
||||
\end{ccTexOnly}
|
||||
\begin{ccHtmlOnly}
|
||||
<CENTER>
|
||||
<IMG BORDER=0 SRC="fig/AlgebraicConceptHierarchy.gif"
|
||||
ALIGN=middle ALT="Concept Hierarchy of Algebraic Structures">
|
||||
</CENTER>
|
||||
\end{ccHtmlOnly}
|
||||
\caption{Concept Hierarchy of Algebraic Structures
|
||||
\label{fig::ConceptHierarchyOfAlgebraicStructures}}
|
||||
\end{figure}
|
||||
|
||||
Figure~\ref{fig::ConceptHierarchyOfAlgebraicStructures} shows the refinement
|
||||
relationship of the algebraic structure concepts.
|
||||
\ccc{IntegralDomain}, \ccc{UniqueFactorizationDomain}, \ccc{EuclideanRing} and
|
||||
\ccc{Field} correspond to the algebraic structures with the
|
||||
same name. \ccc{FieldWithSqrt}, \ccc{FieldWithKthRoot} and
|
||||
\ccc{FieldWithRootOf} are fields that in addition are closed under
|
||||
the operations 'sqrt', 'k-th root' and 'real root of a polynomial',
|
||||
respectively. The concept \ccc{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.
|
||||
Note that \ccc{Field} refines \ccc{IntegralDomain}. This is because
|
||||
most ring-theoretic notions like greatest common divisors become trivial for
|
||||
\ccc{Field}s. Hence we see \ccc{Field} as a refinement of
|
||||
\ccc{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
|
||||
to do things it should not do with a \ccc{Field} in the first place.
|
||||
|
||||
|
||||
The main properties of an algebraic structure are collected in the class
|
||||
\ccc{Algebraic_structure_traits}.
|
||||
In particular the (most refined) concept each concrete model \ccc{AS}
|
||||
fulfills is encoded in the tag
|
||||
\ccc{Algebraic_structure_traits<AS>::Algebraic_category}.
|
||||
An algebraic structure is at least \ccc{Assignable},
|
||||
\ccc{CopyConstructible}, \ccc{DefaultConstructible} and
|
||||
\ccc{EqualityComparable}. Moreover, we require that it is
|
||||
constructible from \ccc{int}.
|
||||
For ease of use and since their semantic is sufficiently standard to presume
|
||||
their existence, the usual arithmetic and comparison operators are required
|
||||
to be realized via \CC\ operator overloading.
|
||||
The division operator is reserved for division in fields.
|
||||
All other unary (e.g., sqrt) and binary functions
|
||||
(e.g., gcd, div) must be models of the well known \stl-concepts
|
||||
\ccc{AdaptableUnaryFunction} or \ccc{AdaptableBinaryFunction}
|
||||
concept and local to the traits class
|
||||
(e.g., \ccc{Algebraic_structure_traits<AS>::Sqrt()(x)}).
|
||||
This design allows us to profit from all parts in the
|
||||
\stl\ and its programming style and avoids the name-lookup and
|
||||
two-pass template compilation problems experienced with the old design
|
||||
using overloaded functions. However, for ease of use and backward
|
||||
compatibility all functionality is also
|
||||
accessible through global functions defined within namespace \ccc{CGAL},
|
||||
e.g., \ccc{CGAL::sqrt(x)}. This is realized via function templates using
|
||||
the according functor of the traits class. For an overview see
|
||||
Section~\ref{caf_ref::classified_refernce_pages} in the reference manual.
|
||||
|
||||
%Dispatching
|
||||
\subsection{Tags in Algebraic Structure Traits}
|
||||
|
||||
\subsubsection{Algebraic Category}
|
||||
|
||||
For a type \ccc{AS}, \ccc{Algebraic_structure_traits<AS>}
|
||||
provides several tags. The most important tag is the \ccc{Algebraic_category}
|
||||
tag, which indicates the most refined algebraic concept the type \ccc{AS}
|
||||
fulfills. The tag is one of;
|
||||
\ccc{Integral_domain_without_division_tag}, \ccc{Integral_domain_tag},
|
||||
\ccc{Field_tag}, \ccc{Field_with_sqrt_tag}, \ccc{Field_with_kth_root_tag},
|
||||
\ccc{Field_with_root_of_tag}, \ccc{Unique_factorization_domain_tag},
|
||||
\ccc{Euclidean_ring_tag}, or even \ccc{Null_tag}
|
||||
in case the type is not a model of an algebraic structure concept.
|
||||
The tags are derived from each other such that they reflect the
|
||||
hierarchy of the algebraic structure concept, e.g.,
|
||||
\ccc{Field_with_sqrt_tag} is derived from \ccc{Field_tag}. \\
|
||||
|
||||
\subsubsection{ Exact and Numerical Sensitive}
|
||||
|
||||
Moreover, \ccc{Algebraic_structure_traits<AS>} provides the tags \ccc{Is_exact}
|
||||
and \ccc{Is_numerical_sensitive}, which are both \ccc{Boolean_tag}s. \\
|
||||
An algebraic structure is considered {\em exact},
|
||||
if all operations required by its concept are computed such that a comparison
|
||||
of two algebraic expressions is always correct.\\
|
||||
An algebraic structure is considered as {\em numerically sensitive},
|
||||
if the performance of the type is sensitive to the condition number of an
|
||||
algorithm.
|
||||
%performance includes both rounding errors or runtime.
|
||||
Note that there is really a difference among these two notions,
|
||||
e.g., the fundamental type \ccc{int}\ is not numerical sensitive but
|
||||
considered inexact due to overflow.
|
||||
Conversely, types as \ccc{leda_real} or \ccc{CORE::Expr} are exact but sensitive
|
||||
to numerical issues due to the internal use of multi precision floating point
|
||||
arithmetic. We expect that \ccc{Is_numerical_sensitive} is used for dispatching
|
||||
of algorithms, while \ccc{Is_exact} is useful to enable assertions that can be
|
||||
check for exact types only.
|
||||
|
||||
|
||||
Tags are very useful to dispatch between alternative implementations.
|
||||
The following example illustrates a dispatch for \ccc{Field}s using overloaded
|
||||
functions. The example only needs two overloads since the algebraic
|
||||
category tags reflect the algebraic structure hierarchy.
|
||||
|
||||
\ccIncludeExampleCode{Algebraic_foundations/algebraic_structure_dispatch.cpp}
|
||||
|
||||
\ccIgnore{
|
||||
|
||||
For dispatching \ccc{Algebraic_structure_traits} provides the tags:
|
||||
\ccc{Algebraic_category}, \ccc{Is_exact} and \ccc{Is_numerical_sensitive}. \\
|
||||
\ccc{Algebraic_category} is the most important tag and indicates the most
|
||||
refined algebraic concept a type fulfills and is one of
|
||||
\ccc{Integral_domain_without_division_tag}, \ccc{Integral_domain_tag},
|
||||
\ccc{Field_tag}, \ccc{Field_with_sqrt_tag}, \ccc{Field_with_kth_root_tag},
|
||||
\ccc{Field_with_root_of_tag}, \ccc{Unique_factorization_domain_tag},
|
||||
\ccc{Euclidean_ring_tag} or even \ccc{Null_tag}
|
||||
in case the type is not a model of an algebraic structure concept.
|
||||
The tags are derived
|
||||
from each other such that they reflect the hierarchy of the algebraic
|
||||
structure concept, e.g., \ccc{Field_with_sqrt_tag} is derived from
|
||||
\ccc{Field_tag}. \\
|
||||
\ccc{Is_exact} and \ccc{Is_numerical_sensitive} are both either \ccc{Tag_true}
|
||||
or \ccc{Tag_false}.
|
||||
An algebraic structure is considered exact,
|
||||
if all operations required by its concept are computed such that a comparison
|
||||
of two algebraic expressions is always correct.
|
||||
An algebraic structure is considered as numerically sensitive,
|
||||
if the performance of the type is sensitive to the condition number of an
|
||||
algorithm.
|
||||
%performance includes both rounding errors or runtime.
|
||||
Note that there is really a difference among these two notions, e.g., the fundamental type \ccc{int}
|
||||
is not numerical sensitive but considered inexact due to overflow.
|
||||
Conversely, types as \ccc{leda_real} or \ccc{CORE::Expr} are exact but sensitive
|
||||
to numerical issues due to the internal use of multi precision floating point
|
||||
arithmetic. We expect that \ccc{Is_numerical_sensitive} is used for dispatching
|
||||
of algorithms, while \ccc{Is_exact} is useful to enable assertions that can be
|
||||
check for exact types only.
|
||||
|
||||
|
||||
|
||||
\begin{tabular}{|l|l|}
|
||||
Algebraic Structure Concept & provided functions \\
|
||||
\hline
|
||||
\ccc{IntegralDomainWithoutDivision}& \ccc{CGAL::is_zero} \\
|
||||
& \ccc{CGAL::is_one} \\
|
||||
& \ccc{CGAL::unit_part} \\
|
||||
& \ccc{CGAL::simplify} \\
|
||||
& \ccc{CGAL::square} \\
|
||||
\ccc{IntegralDomain} & \ccc{CGAL::integral_division} \\
|
||||
\hline
|
||||
\ccc{UniqueFactorizationDomain} & \ccc{CGAL::gcd}\\
|
||||
\hline
|
||||
\ccc{EuclideanRing} & \ccc{CGAL::div_mod} \\
|
||||
& \ccc{CGAL::mod} \\
|
||||
& \ccc{CGAL::div} \\
|
||||
\hline
|
||||
\hline
|
||||
\ccc{Field} & \\
|
||||
\hline
|
||||
\ccc{FieldWithSqrt} & \ccc{CGAL::sqrt} \\
|
||||
\hline
|
||||
\ccc{FieldWithKthRoot} & \ccc{CGAL::kth_root}\\
|
||||
\hline
|
||||
\ccc{FieldWithRootOf} & \ccc{CGAL::root_of}\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\ccIgnore {
|
||||
\subsection{Algebraic Structure Concepts}
|
||||
|
||||
The algebraic structure concepts form an concept hierarchy, as it is shown in
|
||||
figure: \ref{fig::ConceptHierarchyOfAlgebraicStructures}. We will now present
|
||||
the different algebraic structure concepts for short.
|
||||
For more details we refer to the reference manual.
|
||||
|
||||
The concept \ccc{IntegralDomainWithoutDivision} is the most basic
|
||||
algebraic structure concept. Therefore, it first of all refines
|
||||
\ccc{Assignable}, \ccc{CopyConstructible}, \ccc{DefaultConstructible} and
|
||||
\ccc{EqualityComparable}. Moreover, we require that any {\em algebraic structure} is
|
||||
constructible from \ccc{int}, for any int in the range from -128 to 127. \\
|
||||
An \ccc{IntegralDomainWithoutDivision} is a commutative ring with 0, 1, + and *,
|
||||
which has no divisors of 0.
|
||||
The concept does not require an integral division even though it is always well
|
||||
defined for an {\em integral domain}. This is because some types may not offer
|
||||
this division.
|
||||
%On the other hand with this concept it is very easy to
|
||||
%document that an algorithm evades any kind of division.
|
||||
|
||||
\ccc{IntegralDomain} refines \ccc{IntegralDomain} by
|
||||
requiring the missing integral division.
|
||||
This functionality is provided through the global function
|
||||
\ccc{CGAL::integral_division}, while the operator / is reserved for the division
|
||||
within a \ccc{Field}.
|
||||
|
||||
Here the hierarchy splits into the concepts \ccc{Field} and
|
||||
\ccc{UniqueFactorizationDomain}.
|
||||
|
||||
A \ccc{Field} is an \ccc{IntegralDomain} in which every non-zero
|
||||
element has a multiplicative inverse.
|
||||
Hence division is defined for any divisor != 0.
|
||||
For a Field, we require this division operation to be available through
|
||||
operators / and /=. This is further refined by the concepts \ccc{FieldWithSqrt},
|
||||
\ccc{FieldWithKthRoot} and \ccc{FieldWithRootOf}, by requiring that a model
|
||||
is closed under the operations {\em sqrt}, {\em kth root} and
|
||||
{\em extracting the real root of a polynomial} respectively.
|
||||
|
||||
\ccc{UniqueFactorizationDomain} also refines \ccc{IntegralDomain}.
|
||||
An \ccc{UniqueFactorizationDomain} is an \ccc{IntegralDomain} with the
|
||||
additional property that the ring it represents is a unique factorization domain
|
||||
i.e. any two elements, not both zero, possess a greatest common
|
||||
divisor (gcd).
|
||||
|
||||
\ccc{EuclideanRing} refines \ccc{UniqueFactorizationDomain}.
|
||||
It is an \ccc{UniqueFactorizationDomain} that affords a
|
||||
suitable notion for remainders of divisions. In particular
|
||||
it is possible to use the Euclidean algorithm in order to compute the
|
||||
{\em gcd} of two elements.
|
||||
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,54 +0,0 @@
|
|||
#FIG 3.2 Produced by xfig version 3.2.5-alpha5
|
||||
Landscape
|
||||
Center
|
||||
Metric
|
||||
A4
|
||||
100.00
|
||||
Single
|
||||
-2
|
||||
1200 2
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
4050 2700 5850 2700 5850 3150 4050 3150 4050 2700
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
3420 1800 6480 1800 6480 2250 3420 2250 3420 1800
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
5400 4050 8100 4050 8100 4500 5400 4500 5400 4050
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
2700 4950 4500 4950 4500 5400 2700 5400 2700 4950
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
3150 4050 4050 4050 4050 4500 3150 4500 3150 4050
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
2700 5850 4500 5850 4500 6300 2700 6300 2700 5850
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
2700 6750 4500 6750 4500 7200 2700 7200 2700 6750
|
||||
2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
|
||||
5850 4950 7650 4950 7650 5400 5850 5400 5850 4950
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
4950 2700 4950 2250
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
6750 4050 4950 3150
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
3600 4050 4950 3150
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
3600 4950 3600 4500
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
6750 4950 6750 4500
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
3600 5850 3600 5400
|
||||
2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
|
||||
2 1 2.00 120.00 90.00
|
||||
3600 6750 3600 6300
|
||||
4 1 0 50 -1 0 12 0.0000 4 195 2655 4950 2070 IntegralDomainWithoutDivision\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 195 1275 4950 2970 IntegralDomain\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 150 420 3600 4320 Field\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 180 2325 6750 4320 UniqueFactorizationDomain\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 195 1155 3600 5220 FieldWithSqrt\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 150 1530 3600 6120 FieldWithKthRoot\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 150 1425 3600 7020 FieldWithRootOf\001
|
||||
4 1 0 50 -1 0 12 0.0000 4 195 1230 6750 5220 EuclideanRing\001
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 4.4 KiB |
Binary file not shown.
|
|
@ -1,32 +0,0 @@
|
|||
\section{Fractions}
|
||||
|
||||
Beyond the need for performing algebraic operations on objects as a
|
||||
whole, there are also number types which one would like to decompose into
|
||||
numerator and denominator. This does not only hold for rational numbers
|
||||
as \ccc{Quotient}, \ccc{Gmpq}, \ccc{mpq_class} or \ccc{leda_rational}, but
|
||||
also for compound objects as \ccc{Sqrt_extension} or \ccc{Polynomial}
|
||||
which may decompose into a (scalar)
|
||||
denominator and a compound numerator with a simpler coefficient type
|
||||
(e.g. integer instead of rational). Often operations can be performed faster on
|
||||
these denominator-free multiples. In case a type is a \ccc{Fraction}
|
||||
the relevant functionality as well as the numerator and denominator
|
||||
type are provided by \ccc{CGAL::Fraction_traits}. In particular
|
||||
\ccc{CGAL::Fraction_traits} provides a tag \ccc{Is_fraction} that can be
|
||||
used for dispatching.
|
||||
|
||||
A related class is \ccc{CGAL::Rational_traits} which has been kept for backward
|
||||
compatibility reasons. However, we recommend to use \ccc{Fraction_traits} since
|
||||
it is more general and offers dispatching functionality.
|
||||
|
||||
\subsection{Examples}
|
||||
|
||||
The following example show a simple use of \ccc{Fraction_traits}:
|
||||
\ccIncludeExampleCode{Algebraic_foundations/fraction_traits.cpp}
|
||||
|
||||
The following example illustrates the integralization of a vector,
|
||||
i.e., the coefficient vector of a polynomial. Note that for minimizing
|
||||
coefficient growth \ccc{Fraction_traits<Type>::Common_factor} is used to
|
||||
compute the 'least' common multiple of the denominators.
|
||||
|
||||
\ccIncludeExampleCode{Algebraic_foundations/integralize.cpp}
|
||||
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
\section{Design and Implementation History}
|
||||
|
||||
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~\cite{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
|
||||
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
|
||||
subsequent chapters.
|
||||
|
||||
|
|
@ -1,87 +0,0 @@
|
|||
\section{Interoperability}
|
||||
|
||||
This section introduces two concepts for interoperability of types,
|
||||
namely \ccc{ImplicitInteroperable} and \ccc{ExplicitInteroperable}. While
|
||||
\ccc{ExplicitInteroperable} is the base concept, we start with
|
||||
\ccc{ImplicitInteroperable} since it is the more intuitive one.
|
||||
|
||||
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
|
||||
\ccc{ImplicitInteroperable}. However, within template code the result type,
|
||||
or so called coercion type, of a mixed arithmetic operation may be unclear.
|
||||
Therefore, the package introduces \ccc{CGAL::Coercion_traits}
|
||||
giving access to the coercion type via \ccc{CGAL::Coercion_traits<A,B>::Type}
|
||||
for two interoperable types \ccc{A} and \ccc{B}.
|
||||
|
||||
%Examples for \ccc{ImplicitInteroperable} types are: \\
|
||||
%\begin{tabular}{|l|l|l|}
|
||||
%\hline
|
||||
%A&B&Coercion type\\
|
||||
%\hline
|
||||
% \ccc{int}& \ccc{double} & \ccc{double} \\
|
||||
% \ccc{leda_integer}& \ccc{leda_rational}& \ccc{leda_rational}\\
|
||||
% \ccc{CORE::BigInt} & \ccc{CORE::BigRat} & \ccc{CORE::BigRat}\\
|
||||
% \ccc{CGAL::Gmpz}& \ccc{CGAL::Gmpq}& \ccc{CGAL::Gmpq}\\
|
||||
%\hline
|
||||
%\end{tabular}
|
||||
|
||||
Some trivial example are \ccc{int} and \ccc{double} with coercion type double
|
||||
or \ccc{CGAL::Gmpz} and \ccc{CGAL::Gmpq} with coercion type \ccc{CGAL::Gmpq}.
|
||||
However, the coercion type is not necessarily one of the input types,
|
||||
e.g. the coercion type of a polynomial
|
||||
with integer coefficients that is multiplied by a rational type
|
||||
is supposed to be a polynomial with rational coefficients.
|
||||
|
||||
\ccc{CGAL::Coercion_traits} is also
|
||||
required to provide a functor \ccc{CGAL::Coercion_traits<A,B>::Cast()}, that
|
||||
converts from an input type into the coercion type. This is in fact the core
|
||||
of the more basic concept \ccc{ExplicitInteroperable}.
|
||||
\ccc{ExplicitInteroperable} has been introduced to cover more complex cases
|
||||
for which it is hard or impossible to guarantee implicit interoperability.
|
||||
Note that this functor can be useful for \ccc{ImplicitInteroperable} types
|
||||
as well, since it can be used to void redundant type conversions.
|
||||
|
||||
In case two types \ccc{A} and \ccc{B} are \ccc{ExplicitInteroperable} with
|
||||
coercion type \ccc{C} they are valid argument types for all binary functors
|
||||
provided by \ccc{Algebraic_structure_traits} and \ccc{Real_embeddable_traits} of
|
||||
\ccc{C}. This is also true for the according global functions.
|
||||
|
||||
\subsection{Examples}
|
||||
|
||||
The following example illustrates how two write code for
|
||||
\ccc{ExplicitInteroperable} types.
|
||||
|
||||
\ccIncludeExampleCode{Algebraic_foundations/interoperable.cpp}
|
||||
|
||||
The following example illustrates a dispatch for \ccc{ImplicitInteroperable} and
|
||||
\ccc{ExplicitInteroperable} types.
|
||||
The binary function (that just multiplies its two arguments) is supposed to
|
||||
take two \ccc{ExplicitInteroperable} arguments. For \ccc{ImplicitInteroperable}
|
||||
types a variant that avoids the explicit cast is selected.
|
||||
|
||||
\ccIncludeExampleCode{Algebraic_foundations/implicit_interoperable_dispatch.cpp}
|
||||
|
||||
\ccIgnore{
|
||||
A frequent problem in generic programming is how to handle mixed operations
|
||||
of two types.
|
||||
In most cases it is possible to rely on implicit interoperability
|
||||
of the involved types, which is in general achieved by implicit constructors
|
||||
or operator and function overloads. This level of interoperability is
|
||||
reflected by the concept \ccc{ImplicitInteroperable}.
|
||||
For template code, th
|
||||
But in case of template code, the
|
||||
result type, or so called coercion type, of a mixed operation can be unclear.
|
||||
For these cases the package provides the class
|
||||
\ccc{CGAL::Coercion_traits}, which gives access to the coercion type via
|
||||
\ccc{CGAL::Coercion_traits<A,B>::Type} for two \ccc{ImplicitInteroperable}
|
||||
types \ccc{A} and \ccc{B}.
|
||||
|
||||
|
||||
The concept \ccc{ExplicitInteroperable} has been introduced for cases in
|
||||
which is not possible or very hard to provide implicit interoperability.
|
||||
\ccc{ExplicitInteroperable} is more basic than \ccc{ImplicitInteroperable}
|
||||
and just requires \ccc{Coercion_traits} to provide a suitable coercion
|
||||
type and a functor \ccc{Coercion_traits<A,B>::Cast()} that converts each of
|
||||
the input types into the coercion type.
|
||||
}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
|
||||
\section{Introduction}
|
||||
|
||||
\cgal ~is targeting towards exact computation with non-linear objects,
|
||||
in particular objects defined on algebraic curves and surfaces.
|
||||
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 {\em number type}. Instead the package distinguishes
|
||||
between the {\em algebraic structure} of a type and whether a type is embeddable on
|
||||
the real axis, or {\em real embeddable} for short.
|
||||
Moreover, the package introduces the notion of {\em interoperable} types which
|
||||
allows an explicit handling of mixed operations.
|
||||
%In particular it is possible to access the result type of a binary operation.
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
\cleardoublepage
|
||||
\ccUserChapter{Algebraic Foundations\label{ChapterAlgebraicFoundations}}
|
||||
|
||||
\ccChapterAuthor{Michael Hemmer}
|
||||
\input{Algebraic_foundations/PkgDescription.tex}
|
||||
\minitoc
|
||||
\input{Algebraic_foundations/intro.tex}
|
||||
\input{Algebraic_foundations/algebraic_structures.tex}
|
||||
\input{Algebraic_foundations/real_embeddable.tex}
|
||||
\input{Algebraic_foundations/real_number_types.tex}
|
||||
\input{Algebraic_foundations/interoperability.tex}
|
||||
\input{Algebraic_foundations/fractions.tex}
|
||||
\input{Algebraic_foundations/history.tex}
|
||||
|
||||
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
\section{Real Embeddable}
|
||||
\label{sec:RealEmbeddable}
|
||||
|
||||
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
|
||||
reflects the order along the real axis.
|
||||
All these properties are gathered in the concept \ccc{RealComparable}.
|
||||
The concept is orthogonal to the algebraic structure concepts,
|
||||
i.e., it is possible
|
||||
that a type is a model of \ccc{RealEmbeddable} only,
|
||||
since the type may just represent values on the real axis
|
||||
but does not provide any arithmetic operations.
|
||||
|
||||
|
||||
As for algebraic structures this concept is also traits class oriented.
|
||||
The main functionality related to \ccc{RealEmbeddable} is gathered in
|
||||
the class \ccc{Real_embeddable_traits}. In particular, it porivdes the boolean
|
||||
tag \ccc{Is_real_embeddable} indicating whether a type is a model of
|
||||
\ccc{RealEmbeddable}. The comparison operators are required to be realized via
|
||||
\CC\ operator overloading.
|
||||
All unary functions (e.g. {\em sign}, {\em to\_double}) and
|
||||
binary functions (e.g. {\em compare} ) are models of the \stl-concepts
|
||||
\ccc{AdaptableUnaryFunction} and \ccc{AdaptableBinaryFunction} and are local
|
||||
to \ccc{Real_embeddable_traits}.
|
||||
|
||||
|
||||
In case a type is a model of \ccc{IntegralDomainWithoutDivision} and
|
||||
\ccc{RealEmbeddable} the number represented by an object of this type is
|
||||
the same for arithmetic and comparison.
|
||||
It follows that the ring represented by this type is a superset of the integers
|
||||
and a subset of the real numbers and hence has characteristic zero.
|
||||
\ccIgnore{see http://mathworld.wolfram.com/CharacteristicField.html )}
|
||||
In case the type is a model of \ccc{Field} and \ccc{RealEmbeddable} it is a
|
||||
superset of the rational numbers.
|
||||
|
||||
|
||||
\ccIgnore{
|
||||
All algebraic structure concepts do not require any order on a type,
|
||||
in particular they refine \ccc{EqualityComparable} but not \ccc{LessThanComparable}.
|
||||
From that it is possible for a type representing $\Z/p \Z$ to be a model of \ccc{Field}.
|
||||
However, from those types that are embedded on the real axis we can expect an order
|
||||
that correlates to the one of the real numbers, a sign, an absolute value and
|
||||
|
||||
However, most number types are representing some subset of the real numbers and from that
|
||||
we can expect an order on these types that correlates to the one of the real numbers.
|
||||
}
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
\section{Real Number Types}
|
||||
Every \cgal\ \ccc{Kernel} comes with two \emph{real number types}
|
||||
(number types embeddable into the real numbers). One of them is a
|
||||
\ccc{FieldNumberType}, and the other a \ccc{RingNumberType}. The
|
||||
coordinates of the basic kernel objects (points, vectors, etc.) come
|
||||
from one of these types (the \ccc{FieldNumberType} in case of Cartesian
|
||||
kernels, and the \ccc{RingNumberType} for Homogeneous kernels).
|
||||
|
||||
The concept \ccc{FieldNumberType} combines the requirements of the
|
||||
concepts \ccc{Field} and \ccc{RealEmbeddable}, while
|
||||
\ccc{RingNumberType} combines \ccc{IntegralDomainWithoutDivision} and
|
||||
\ccc{RealEmbeddable}. Algebraically, the real number types do not form
|
||||
distinct structures and are therefore not listed in the concept
|
||||
hierarchy of Figure~\ref{fig::ConceptHierarchyOfAlgebraicStructures}.
|
||||
|
|
@ -1,183 +0,0 @@
|
|||
\begin{ccRefConcept}{AlgebraicStructureTraits}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{AlgebraicStructureTraits} reflects the algebraic structure
|
||||
of an associated type \ccc{Type}.
|
||||
|
||||
|
||||
Depending on the concepts that \ccc{Type} fulfills,
|
||||
it contains various functors and descriptive tags.
|
||||
Moreover it gives access to the several possible
|
||||
algebraic operations within that structure.
|
||||
|
||||
|
||||
\ccTypes
|
||||
\ccSetTwoColumns{xxxxxxxxxxxxxx}{}
|
||||
A model of \ccc{AlgebraicStructureTraits} is supposed to provide:\\
|
||||
|
||||
\ccNestedType{Type} {The associated type.}
|
||||
|
||||
\ccNestedType{Algebraic_category}
|
||||
{ Tag indicating the algebraic structure of the associated type. \\
|
||||
|
||||
\begin{tabular}{|l|l|}
|
||||
\hline
|
||||
Tag is: & \ccc{Type} is model of:\\
|
||||
\hline
|
||||
\ccc{CGAL::Null_tag} & no algebraic concept\\
|
||||
\ccc{CGAL::Integral_domain_without_division_tag}& \ccc{IntegralDomainWithoutDivision}\\
|
||||
\ccc{CGAL::Integral_domain_tag} & \ccc{IntegralDomain}\\
|
||||
\ccc{CGAL::Unique_factorization_domain_tag} & \ccc{UniqueFactorizationDomain}\\
|
||||
\ccc{CGAL::Euclidean_ring_tag} & \ccc{EuclideanRing}\\
|
||||
\ccc{CGAL::Field_tag} & \ccc{Field}\\
|
||||
\ccc{CGAL::Field_with_sqrt_tag} & \ccc{FieldWithSqrt}\\
|
||||
\ccc{CGAL::Field_with_kth_root_tag} & \ccc{FieldWithKthRoot}\\
|
||||
\ccc{CGAL::Field_with_root_of_tag} & \ccc{FieldWithRootOf}\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
}
|
||||
|
||||
\ccNestedType{Is_exact}
|
||||
{ Tag indicating whether \ccc{Type} is exact. \\
|
||||
This is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}.\\
|
||||
An algebraic structure is considered exact, if all operations
|
||||
required by its concept are computed such that a comparison
|
||||
of two algebraic expressions is always correct.
|
||||
The exactness covers only those operations that are required by
|
||||
the algebraic structure concept. \\
|
||||
e.g. an exact \ccc{Field} may have a \ccc{Sqrt} functor that
|
||||
is not exact. \\
|
||||
}
|
||||
|
||||
\ccNestedType{Is_numerical_sensitive}
|
||||
{ Tag indicating whether \ccc{Type} is numerical sensitive. \\
|
||||
This is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}.\\
|
||||
An algebraic structure is considered as numerically sensitive,
|
||||
if the performance of the type is sensitive to the condition
|
||||
number of an algorithm.
|
||||
}
|
||||
|
||||
\ccNestedType{Boolean}
|
||||
{ This type specifies the return type of the predicates provided
|
||||
by this traits. The type must be convertible to \ccc{bool} and
|
||||
typically the type indeed maps to \ccc{bool}. However, there are also
|
||||
cases such as interval arithmetic, in which it is \ccc{Uncertain<bool>}
|
||||
or some similar type.
|
||||
}
|
||||
|
||||
\ccHeading{Functors}
|
||||
|
||||
In case a functor is not provided, it is set to \ccc{CGAL::Null_functor}.
|
||||
|
||||
\ccNestedType{Is_zero}{
|
||||
A model of \ccc{AlgebraicStructureTraits::IsZero}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
In case \ccc{Type} is also model of \ccc{RealEmbeddable} this is a
|
||||
model of \ccc{RealEmbeddableTraits::IsZero}.
|
||||
}
|
||||
|
||||
\ccNestedType{Is_one}{
|
||||
A model of \ccc{AlgebraicStructureTraits::IsOne}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
}
|
||||
|
||||
\ccNestedType{Square}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Square}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
}
|
||||
|
||||
\ccNestedType{Simplify}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Simplify}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
}
|
||||
|
||||
\ccNestedType{Unit_part}{
|
||||
A model of \ccc{AlgebraicStructureTraits::UnitPart}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
}
|
||||
|
||||
\ccNestedType{Integral_division}{
|
||||
A model of \ccc{AlgebraicStructureTraits::IntegralDivision}.\\
|
||||
Required by the concept \ccc{IntegralDomain}.
|
||||
}
|
||||
\ccNestedType{Divides}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Divides}.\\
|
||||
Required by the concept \ccc{IntegralDomain}.
|
||||
}
|
||||
|
||||
\ccNestedType{Is_square}{
|
||||
A model of \ccc{AlgebraicStructureTraits::IsSquare}.\\
|
||||
Required by the concept \ccc{IntegralDomainWithoutDivision}.
|
||||
}
|
||||
|
||||
\ccNestedType{Gcd}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Gcd}.\\
|
||||
Required by the concept \ccc{UniqueFactorizationDomain}.
|
||||
}
|
||||
|
||||
|
||||
\ccNestedType{Mod}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Mod}.\\
|
||||
Required by the concept \ccc{EuclideanRing}.
|
||||
}
|
||||
|
||||
\ccNestedType{Div}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Div}.\\
|
||||
Required by the concept \ccc{EuclideanRing}.
|
||||
}
|
||||
\ccNestedType{Div_mod}{
|
||||
A model of \ccc{AlgebraicStructureTraits::DivMod}.\\
|
||||
Required by the concept \ccc{EuclideanRing}.
|
||||
}
|
||||
|
||||
\ccNestedType{Inverse}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Inverse}.\\
|
||||
Required by the concept \ccc{Field}.
|
||||
}
|
||||
|
||||
\ccNestedType{Sqrt}{
|
||||
A model of \ccc{AlgebraicStructureTraits::Sqrt}.\\
|
||||
Required by the concept \ccc{FieldWithSqrt}.
|
||||
}
|
||||
|
||||
%\begin{ccAdvanced}
|
||||
\ccNestedType{Kth_root}{
|
||||
A model of \ccc{AlgebraicStructureTraits::KthRoot}.\\
|
||||
Required by the concept \ccc{FieldWithKthRoot}.
|
||||
}
|
||||
|
||||
\ccNestedType{Root_of}{
|
||||
A model of \ccc{AlgebraicStructureTraits::RootOf}.\\
|
||||
Required by the concept \ccc{FieldWithRootOf}.
|
||||
}
|
||||
%\end{ccAdvanced}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\\
|
||||
\ccRefIdfierPage{CGAL::Integral_domain_without_division_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Integral_domain_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Unique_factorization_domain_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Euclidean_ring_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Field_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Field_with_sqrt_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Field_with_kth_root_tag}\\
|
||||
\ccRefIdfierPage{CGAL::Field_with_root_of_tag}\\
|
||||
|
||||
\ccHasModels
|
||||
\ccRefIdfierPage{CGAL::Algebraic_structure_traits<T>}\\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Div}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} computes the integral quotient of division
|
||||
with remainder.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{div}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type x,
|
||||
second_argument_type y);}{}
|
||||
|
||||
\ccMethod{template <class NT1, class NT2> result_type operator()(NT1 x, NT2 y);}
|
||||
{This operator is defined if \ccc{NT1} and \ccc{NT2} are \ccc{ExplicitInteroperable}
|
||||
with coercion type \ccc{AlgebraicStructureTraits::Type}. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::Mod}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::DivMod}\\
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::DivMod}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableFunctor} computes both integral quotient and remainder
|
||||
of division with remainder. The quotient $q$ and remainder $r$ are computed
|
||||
such that $x = q*y + r$ and $|r| < |y|$ with respect to the proper integer norm of
|
||||
the represented ring.
|
||||
\footnote{
|
||||
For integers this norm is the absolute value.\\
|
||||
For univariate polynomials this norm is the degree.}
|
||||
In particular, $r$ is chosen to be $0$ if possible.
|
||||
Moreover, we require $q$ to be minimized with respect to the proper integer norm.
|
||||
|
||||
\ccIgnore{
|
||||
For types representing \Z, this is round $q$ towards zero.
|
||||
For univariate polynomials this has no effect at all.
|
||||
MP_Float Z[1/2] is not clear yet.
|
||||
}
|
||||
|
||||
|
||||
Note that the last condition is needed to ensure a unique computation of the
|
||||
pair $(q,r)$. However, an other option is to require minimality for $|r|$,
|
||||
with the advantage that
|
||||
a {\em mod(x,y)} operation would return the unique representative of the
|
||||
residue class of $x$ with respect to $y$, e.g. $mod(2,3)$ should return $-1$.
|
||||
But this conflicts with nearly all current implementation
|
||||
of integer types. From there, we decided to stay conform with common
|
||||
implementations and require $q$ to be computed as $x/y$ rounded towards zero.
|
||||
|
||||
\ccIgnore{
|
||||
Note that in general the above definition does not force a unique computation
|
||||
of the pair $(q,r)$. This could be solved by requiring $|r|$ to be minimal,
|
||||
in particular a {\em mod} operation would return the unique representative of
|
||||
its residue class. But this conflicts with nearly all current implementation
|
||||
of integer types. From there, we decided to stay conform with common
|
||||
implementation and require $q$ to be computed as $x/y$ rounded towards zero,
|
||||
for \ccc{RealEmbeddable} \ccc{EuclideanRing}s.
|
||||
}
|
||||
|
||||
The following table illustrates the behavior for integers:
|
||||
|
||||
\begin{tabular}{ccc}
|
||||
\begin{tabular}{|c|c|c|c|}
|
||||
\hline
|
||||
$\ x\ $ & $\ y\ $ & $\ q\ $ & $\ r\ $\\
|
||||
\hline
|
||||
3 & 3 & 1 & 0\\
|
||||
2 & 3 & 0 & 2\\
|
||||
1 & 3 & 0 & 1\\
|
||||
0 & 3 & 0 & 0\\
|
||||
-1 & 3 & 0 & -1\\
|
||||
-2 & 3 & 0 & -2\\
|
||||
-3 & 3 & -1 & 0\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
& - &
|
||||
\begin{tabular}{|c|c|c|c|}
|
||||
\hline
|
||||
$\ x\ $ & $\ y\ $ & $\ q\ $ & $\ r\ $\\
|
||||
\hline
|
||||
3 & -3 & -1 & 0\\
|
||||
2 & -3 & 0 & 2\\
|
||||
1 & -3 & 0 & 1\\
|
||||
0 & -3 & 0 & 0\\
|
||||
-1 & -3 & 0 & -1\\
|
||||
-2 & -3 & 0 & -2\\
|
||||
-3 & -3 & 1 & 0\\
|
||||
\hline
|
||||
\end{tabular}\\
|
||||
\end{tabular}
|
||||
|
||||
|
||||
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableFunctor}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is void.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{third_argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type&}.}
|
||||
\ccGlue
|
||||
\ccNestedType{fourth_argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type&}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{div_mod}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
\ccMethod{result_type operator()( first_argument_type x,
|
||||
second_argument_type y,
|
||||
third_argument_type q,
|
||||
fourth_argument_type r);}{
|
||||
computes the quotient $q$ and remainder $r$, such that $x = q*y + r$
|
||||
and $r$ minimal with respect to the Euclidean Norm on
|
||||
\ccc{Type}. }
|
||||
|
||||
\ccMethod{template <class NT1, class NT2> result_type
|
||||
operator()(NT1 x, NT2 y, third_argument_type q, fourth_argument_type r);}
|
||||
{This operator is defined if \ccc{NT1} and \ccc{NT2} are \ccc{ExplicitInteroperable}
|
||||
with coercion type \ccc{AlgebraicStructureTraits::Type}. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::Mod}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::Div}\\
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Divides}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction},
|
||||
returns true if the first argument divides the second argument.
|
||||
|
||||
Integral division (a.k.a. exact division or division without remainder) maps
|
||||
ring elements $(n,d)$ to ring element $c$ such that $n = dc$ if such a $c$
|
||||
exists. In this case it is said that $d$ divides $n$.
|
||||
|
||||
This functor is required to provide two operators. The first operator takes two
|
||||
arguments and returns true if the first argument divides the second argument.
|
||||
The second operator returns $c$ via the additional third argument.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Boolean}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{divides}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type d,
|
||||
second_argument_type n);}
|
||||
{ Computes whether $d$ divides $n$. }
|
||||
|
||||
\ccMethod{result_type operator()(
|
||||
first_argument_type d,
|
||||
second_argument_type n,
|
||||
AlgebraicStructureTraits::Type& c);}
|
||||
{
|
||||
Computes whether $d$ divides $n$.
|
||||
Moreover it computes $c$ if $d$ divides $n$,
|
||||
otherwise the value of $c$ is undefined.
|
||||
}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::IntegralDivision}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Gcd}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} providing the gcd.
|
||||
|
||||
The greatest common divisor ($gcd$) of ring elements $x$ and $y$ is the unique
|
||||
ring element $d$ (up to a unit) with the property that any common divisor of
|
||||
$x$ and $y$ also divides $d$. (In other words: $d$ is the greatest lower bound
|
||||
of $x$ and $y$ in the partial order of divisibility.) We demand the $gcd$ to be
|
||||
unit-normal (i.e. have unit part 1).
|
||||
|
||||
$gcd(0,0)$ is defined as $0$, since $0$ is the greatest element with respect
|
||||
to the partial order of divisibility. This is because an element $a \in R$ is said to divide $b \in R$, iff $\exists r \in R$ such that $a \cdot r = b$.
|
||||
Thus, $0$ is divided by every element of the Ring, in particular by itself.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{gcd}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type x,
|
||||
second_argument_type y);}
|
||||
{ returns $gcd(x,y)$. }
|
||||
|
||||
\ccMethod{template <class NT1, class NT2> result_type operator()(NT1 x, NT2 y);}
|
||||
{This operator is defined if \ccc{NT1} and \ccc{NT2} are \ccc{ExplicitInteroperable}
|
||||
with coercion type \ccc{AlgebraicStructureTraits::Type}. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::IntegralDivision}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} providing an integral division.
|
||||
|
||||
Integral division (a.k.a. exact division or division without remainder) maps
|
||||
ring elements $(x,y)$ to ring element $z$ such that $x = yz$ if such a $z$
|
||||
exists (i.e. if $x$ is divisible by $y$). Otherwise the effect of invoking
|
||||
this operation is undefined. Since the ring represented is an integral domain,
|
||||
$z$ is uniquely defined if it exists.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{integral_division}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type x,
|
||||
second_argument_type y);}
|
||||
{ returns $x/y$, this is an integral division. }
|
||||
|
||||
|
||||
\ccMethod{template <class NT1, class NT2> result_type operator()(NT1 x, NT2 y);}
|
||||
{This operator is defined if \ccc{NT1} and \ccc{NT2} are \ccc{ExplicitInteroperable}
|
||||
with coercion type \ccc{AlgebraicStructureTraits::Type}. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::Divides}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Inverse}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction} providing the inverse element with
|
||||
respect to multiplication of a \ccc{Field}.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
\ccCreationVariable{inverse}
|
||||
\ccMethod{result_type operator()(argument_type x) const;}
|
||||
{ returns the inverse element of $x$ with respect to multiplication.
|
||||
\ccPrecond $x \neq 0$
|
||||
}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::IsOne}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction},
|
||||
returns true in case the argument is the one of the ring.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Boolean}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{is_one}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
\ccMethod{result_type operator()(argument_type x);}{
|
||||
returns true in case $x$ is the one of the ring. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
|
||||
|
||||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::IsSquare}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} that computes whether the first argument is a square.
|
||||
If the first argument is a square the second argument, which is taken by reference, contains the square root.
|
||||
Otherwise, the content of the second argument is undefined.
|
||||
|
||||
A ring element $x$ is said to be a square iff there exists a ring element $y$ such
|
||||
that $x= y*y$. In case the ring is a \ccc{UniqueFactorizationDomain},
|
||||
$y$ is uniquely defined up to multiplication by units. \\
|
||||
|
||||
%Note that this is an optional functor and not required by any algebraic structure concept.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Boolean}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type&}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{is_square}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type x,
|
||||
second_argument_type y);}
|
||||
{ returns {\tt true} in case $x$ is a square, i.e. $x = y*y$.
|
||||
\ccPostcond $unit\_part(y) == 1$.
|
||||
}
|
||||
\ccMethod{result_type operator()(first_argument_type x);}
|
||||
{ returns {\tt true} in case $x$ is a square.
|
||||
}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::IsZero}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction}, returns true in case the argument is the zero element of the ring. \\
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Boolean}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{is_zero}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(argument_type x) const;}{
|
||||
returns true in case $x$ is the zero element of the ring. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
\ccRefIdfierPage{RealEmbeddableTraits::IsZero}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::KthRoot}
|
||||
|
||||
%\begin{ccAdvanced}
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} providing the k-th root.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is int.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{kth_root}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(int k, second_argument_type x);}
|
||||
{ returns the $k$-th root of $x$.
|
||||
\ccPrecond{ $k \geq 1$ }
|
||||
}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
%\end{ccAdvanced}
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Mod}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction} computes the remainder of division with remainder.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{first_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccGlue
|
||||
\ccNestedType{second_argument}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{mod}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(first_argument_type x,
|
||||
second_argument_type y);}{}
|
||||
|
||||
\ccMethod{template <class NT1, class NT2> result_type operator()(NT1 x, NT2 y);}
|
||||
{This operator is defined if \ccc{NT1} and \ccc{NT2} are \ccc{ExplicitInteroperable}
|
||||
with coercion type \ccc{AlgebraicStructureTraits::Type}. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::Div}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits::DivMod}\\
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::RootOf}
|
||||
|
||||
%\begin{ccAdvanced}
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableFunctor} computes a real root of a square-free univariate
|
||||
polynomial.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableFunctor}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{root_of}
|
||||
|
||||
\ccMethod{
|
||||
template<class InputIterator>
|
||||
result_type operator() (int k, InputIterator begin, InputIterator end);}
|
||||
{returns the k-th real root of the univariate polynomial,
|
||||
which is defined by the iterator range,
|
||||
where begin refers to the constant term.
|
||||
\ccPrecond The polynomial is square-free.
|
||||
\ccPrecond The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}\\ }
|
||||
|
||||
%\begin{ccAdvanced}
|
||||
%\ccMethod{
|
||||
%template<class InputIterator>
|
||||
%result_type operator()(const Type& lower,
|
||||
% const Type& upper,
|
||||
% InputIterator begin,
|
||||
% InputIterator end);}
|
||||
% {returns the only real root within the interval [lower,upper]
|
||||
% of the univariate polynomial, which is defined by the iterator
|
||||
% range, where begin refers to the constant term.
|
||||
% \ccPrecond The polynomial is square-free.
|
||||
% \ccPrecond The value type of the InputIterator is \ccc{AlgebraicStructureTraits::Type}\\
|
||||
%}
|
||||
%\end{ccAdvanced}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
%\end{ccAdvanced}
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Simplify}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
This \ccc{AdaptableUnaryFunction} may simplify a given object.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is void.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{simplify}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(argument_type x);}{ may simplify $x$.}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Sqrt}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction} providing the square root.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
\ccCreationVariable{sqrt}
|
||||
\ccMethod{result_type operator()(argument_type x) const;}
|
||||
{ returns $\sqrt{x}$. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::Square}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction}, computing the square of the argument.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{square}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(argument_type x);}{ returns the square of $x$.}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{AlgebraicStructureTraits::UnitPart}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
This \ccc{AdaptableUnaryFunction} computes the unit part of a given ring
|
||||
element.
|
||||
|
||||
The mathematical definition of unit part is as follows: Two ring elements $a$
|
||||
and $b$ are said to be associate if there exists an invertible ring element
|
||||
(i.e. a unit) $u$ such that $a = ub$. This defines an equivalence relation.
|
||||
We can distinguish exactly one element of every equivalence class as being
|
||||
unit normal. Then each element of a ring possesses a factorization into a unit
|
||||
(called its unit part) and a unit-normal ring element
|
||||
(called its unit normal associate).
|
||||
|
||||
For the integers, the non-negative numbers are by convention unit normal,
|
||||
hence the unit-part of a non-zero integer is its sign. For a \ccc{Field}, every
|
||||
non-zero element is a unit and is its own unit part, its unit normal
|
||||
associate being one. The unit part of zero is, by convention, one.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{AlgebraicStructureTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
\ccCreationVariable{unit_part}
|
||||
|
||||
\ccMethod{result_type operator()(argument_type x);}
|
||||
{ returns the unit part of $x$.}
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
\begin{ccRefClass}{Algebraic_structure_traits<T>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
An instance of \ccClassTemplateName\ is a model of \ccc{AlgebraicStructureTraits}, where {\sc T} is the associated type.
|
||||
|
||||
\ccInclude{CGAL/Algebraic_structure_traits.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
\begin{ccRefClass}{Coercion_traits<A,B>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
An instance of \ccClassTemplateName\ reflects the type coercion of the types
|
||||
{\sc A} and {\sc B}, it is symmetric in the two template arguments.
|
||||
|
||||
\ccInclude{CGAL/Coercion_traits.h}
|
||||
|
||||
\ccTypes
|
||||
%=======
|
||||
|
||||
%%ThreeToTwo
|
||||
|
||||
\ccNestedType{Are_explicit_interoperable}
|
||||
{ Tag indicating whether the two types A and B are a model of \ccc{ExplicitInteroperable} \\
|
||||
This is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. }
|
||||
\ccNestedType{Are_implicit_interoperable}
|
||||
{ Tag indicating whether the two types A and B are a model of \ccc{ImplicitInteroperable} \\
|
||||
This is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}. }
|
||||
|
||||
\ccNestedType{Type}
|
||||
{The coercion type of \ccc{ A} and \ccc{ B}. \\
|
||||
In case A and B are not \ccc{ExplicitInteroperable} this is undefined. }
|
||||
\ccNestedType{Cast}
|
||||
{A model of the \ccc{AdaptableFunctor} concept, providing the conversion of \ccc{ A} or \ccc{ B} to \ccc{ Type}. \\
|
||||
In case A and B are not \ccc{ExplicitInteroperable} this is undefined. }
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{ExplicitInteroperable} \\
|
||||
\ccRefConceptPage{ImplicitInteroperable} \\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Abs<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ computes the absolute value of a number.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval);}{returns the absolute value of
|
||||
\ccc{ntval}.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Compare<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ compares two numbers to see which is
|
||||
larger or smaller or if they are equal.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
|
||||
\ccMethod{Comparison_result operator()(const NT &n1, const NT &n2);}
|
||||
{returns \ccc{LARGER} iff $n1>n2$, \ccc{EQUAL} iff $n1=n2$, and \ccc{SMALLER} i
|
||||
ff $n1<n2$.}
|
||||
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Div<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ computes the integral division of two
|
||||
numbers.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval1, const NT& ntval2);}
|
||||
{computes the integral divisor of two numbers.}
|
||||
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
\begin{ccRefConcept}{EuclideanRingNumberType}
|
||||
|
||||
The number type supports the operations $+$, $-$ and $*$ as well as a function
|
||||
$div$, which performs an integer division, the modulus operator $\%$,
|
||||
that returns the remainder of integer division and the function $gcd$.
|
||||
This implies that
|
||||
\ccc{CGAL::Number_type_traits<EuclideanRingNumberType>::Has_gcd} is
|
||||
\ccc{CGAL::Tag_true}.
|
||||
|
||||
\ccRefines
|
||||
RingNumberType
|
||||
|
||||
\ccCreationVariable{n1}
|
||||
|
||||
\ccThree{EuclideanRingNumberType}{xxxxxxxxxxxx}{}
|
||||
\ccOperations
|
||||
|
||||
\ccFunction{EuclideanRingNumberType div(
|
||||
const EuclideanRingNumberType& n1,
|
||||
const EuclideanRingNumberType &n2) const;}
|
||||
{returns the result of the integer division \ccc{n1}/\ccc{n2}.}
|
||||
|
||||
\ccGlue
|
||||
\ccFunction{EuclideanRingNumberType gcd(const EuclideanRingNumberType &n1,
|
||||
const EuclideanRingNumberType &n2);}
|
||||
{computes the greatest common divisor between \ccc{n1} and \ccc{n2}.}
|
||||
|
||||
\ccGlue
|
||||
\ccMethod{EuclideanRingNumberType operator%(const EuclideanRingNumberType &n2) const;}
|
||||
{returns the remainder achieved when dividing \ccVar\ by \ccc{n2}.}
|
||||
|
||||
\ccGlue
|
||||
\ccMethod{EuclideanRingNumberType operator%=(const EuclideanRingNumberType &n2);}
|
||||
{computes the remainder achieved when dividing \ccVar\ by \ccc{n2} and
|
||||
assigns it to \ccVar.}
|
||||
|
||||
|
||||
\ccHasModels
|
||||
\ccc{int} \\
|
||||
\ccc{long} \\
|
||||
\ccc{long long} \\
|
||||
\ccc{CGAL::MP_Float} \\
|
||||
\ccc{CGAL::Gmpz} \\
|
||||
\ccc{leda_integer}
|
||||
|
||||
%\ccc{CGAL::Lazy_exact_nt<EuclideanRingNumberType>} \\
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FieldNumberType} \\
|
||||
\ccRefConceptPage{Kernel} \\
|
||||
\ccRefIdfierPage{CGAL::Euclidean_ring_tag} \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
\begin{ccRefClass} {Euclidean_ring_tag}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is used as a tag in some algorithms. It
|
||||
indicates that a number type is to be considered as a model for
|
||||
EuclideanRingNumberType. Only operations defined for
|
||||
EuclideanRingNumberType are used. For example, no divisions are
|
||||
computed, even if the number type as such supports divisions.
|
||||
|
||||
\ccInclude{CGAL/Number_type_traits.h}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{EuclideanRingNumberType} \\
|
||||
\ccRefIdfierPage{Ring_tag} \\
|
||||
\ccRefIdfierPage{Field_tag} \\
|
||||
\ccRefIdfierPage{Sqrt_field_tag}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
\begin{ccRefClass} {Field_tag}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is used as a tag in some algorithms. It
|
||||
indicates that a number type is to be considered as a model for
|
||||
FieldNumberType. Only operations defined for FieldNumberType are used.
|
||||
For example, no squareroot operations are computed, even if the number
|
||||
type as such supports squareroots.
|
||||
|
||||
\ccInclude{CGAL/Number_type_traits.h}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FieldNumberType} \\
|
||||
\ccRefIdfierPage{Ring_tag} \\
|
||||
\ccRefIdfierPage{Euclidean_ring_tag} \\
|
||||
\ccRefIdfierPage{Sqrt_field_tag}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Gcd<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ computes the greatest common divisor of two values.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval1, const NT& ntval2);}
|
||||
{
|
||||
computes the greatest common divisor of two numbers. If \ccc{ntval1} is
|
||||
0, the function returns \ccc{ntval2}.
|
||||
\ccPrecond: \ccc{ntval2} is not zero.
|
||||
}
|
||||
|
||||
\ccImplementation
|
||||
|
||||
Uses Euclid's algorithm.
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Is_negative<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ determines if a value is negative or not.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{bool operator()(const NT& ntval);}
|
||||
{returns \ccc{true} if \ccc{ntval} is negative and \ccc{false} otherwise.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Is_one<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ determines if a value is equal to 1 or not.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{bool operator()(const NT& ntval);}
|
||||
{returns \ccc{true} if \ccc{ntval} is 1 and \ccc{false} otherwise.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Is_positive<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ determines if a value is positive or not.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{bool operator()(const NT& ntval);}
|
||||
{returns \ccc{true} if \ccc{ntval} is positive and \ccc{false} otherwise.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Is_zero<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ determines if a value is equal to 0 or not.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{bool operator()(const NT& ntval);}
|
||||
{returns \ccc{true} if \ccc{ntval} is 0 and \ccc{false} otherwise.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Max<NT,Compare>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ returns the larger of two values.
|
||||
The default value for \ccc{Compare} is \ccc{std::less}.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval1, const NT& ntval2);}
|
||||
{returns the larger of \ccc{ntval1} and \ccc{ntval2}.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
\begin{ccRefClass}{Number_type_traits<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ can be used to determine if a certain number type
|
||||
supports certain operations and thus to determine which number type concept
|
||||
it is a model of. It also specifies if the number type supports some
|
||||
operations exactly.
|
||||
%By that it is meant that when a number is
|
||||
%constructed using these operations, the sign of the result of these
|
||||
%operations is computed exactly.
|
||||
|
||||
\ccInclude{CGAL/Number_type_traits.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
The following types are each set to either \ccc{CGAL::Tag_true} or
|
||||
\ccc{CGAL::Tag_false} depending on whether the indicated operation is
|
||||
supported or not by the number type \ccc{NT}.
|
||||
|
||||
\ccNestedType{Has_gcd}{indicates if the number type \ccc{NT} supports the
|
||||
\ccc{gcd} operation or not.}
|
||||
\ccNestedType{Has_division}{indicates if the number type \ccc{NT} has
|
||||
\ccc{operator/} defined or not.}
|
||||
\ccNestedType{Has_sqrt}{indicates if the number type \ccc{NT}
|
||||
has \ccc{sqrt} defined or not.}
|
||||
\ccNestedType{Has_exact_ring_operations}{indicates if the number type
|
||||
\ccc{NT} supports ring operations exactly.}
|
||||
\ccNestedType{Has_exact_division}{indicates if the number type
|
||||
\ccc{NT} supports divisions exactly.}
|
||||
\ccNestedType{Has_exact_sqrt}{indicates if the number type \ccc{NT}
|
||||
supports the operation \ccc{sqrt} exactly.}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
\begin{ccRefConcept}{RealEmbeddableTraits::IsFinite}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableUnaryFunction} determines whether the argument represents
|
||||
a value in $\R$, this implies that the argument \ccc{is_valid}.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableUnaryFunction}
|
||||
|
||||
|
||||
\ccTypes
|
||||
\ccNestedType{result_type}
|
||||
{ Type convertible to \ccc{bool}.}
|
||||
\ccNestedType{argument_type}
|
||||
{ Is \ccc{RealEmbeddableTraits::Type}.}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{is_finite}
|
||||
\ccThree{xxxxxxxxxxx}{xxxxxxxxxxx}{}
|
||||
|
||||
\ccMethod{result_type operator()(argument_type x);}
|
||||
{ Determines whether the argument represents a value in $\R$. }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{RealEmbeddableTraits}\\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
\begin{ccRefClass} {Ring_tag}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is used as a tag in some algorithms. It
|
||||
indicates that a number type is to be considered as a model for
|
||||
RingNumberType. Only operations defined for RingNumberType are used.
|
||||
For example, no divisions are computed, even if the number type as
|
||||
such supports divisions.
|
||||
|
||||
\ccInclude{CGAL/Number_type_traits.h}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{RingNumberType} \\
|
||||
\ccRefIdfierPage{Euclidean_ring_tag} \\
|
||||
\ccRefIdfierPage{Field_tag} \\
|
||||
\ccRefIdfierPage{Sqrt_field_tag}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Sgn<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ computes the sign of a number.
|
||||
It is named \ccc{Sgn} to avoid a conflict with the type \ccc{Sign}.
|
||||
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{Sign operator()(const NT& ntval);}
|
||||
{returns the sign: \ccc{POSITIVE}, \ccc{ZERO}, or \ccc{NEGATIVE}.}
|
||||
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
\begin{ccRefConcept}{SqrtFieldNumberType}
|
||||
|
||||
The concept \ccRefName\ defines the syntactic requirements of a number
|
||||
type to be used as a template parameter for the Cartesian kernels.
|
||||
This number type supports the operations $+$, $-$, $*$, $/$, and
|
||||
$\sqrt{\cdot}$. This implies that both
|
||||
\ccc{CGAL::Number_type_traits<SqrtFieldNumberType>::Has_division} and
|
||||
\ccc{CGAL::Number_type_traits<SqrtFieldNumberType>::Has_sqrt} are
|
||||
\ccc{CGAL::Tag_true}.
|
||||
|
||||
\ccRefines
|
||||
FieldNumberType
|
||||
|
||||
\ccHasModels
|
||||
\ccc{float} \\
|
||||
\ccc{double} \\
|
||||
\ccc{CGAL::Lazy_exact_nt<FieldNumberType>} \\
|
||||
\ccc{leda_bigfloat} \\
|
||||
\ccc{leda_real} \\
|
||||
|
||||
\ccCreationVariable{ntvar}
|
||||
|
||||
\ccOperations
|
||||
|
||||
\ccFunction{SqrtFieldNumberType sqrt(const SqrtFieldNumberType
|
||||
&ntval);} {}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{RingNumberType} \\
|
||||
\ccRefConceptPage{EuclideanRingNumberType} \\
|
||||
\ccRefConceptPage{Kernel} \\
|
||||
\ccRefIdfierPage{CGAL::Sqrt_field_tag} \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefClass} {Sqrt_field_tag}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The class \ccRefName\ is used as a tag in some algorithms. It
|
||||
indicates that a number type is to be considered as a model for
|
||||
SqrtFieldNumberType. All operations defined for SqrtFieldNumberType
|
||||
are used, including divisions and squareroot computations.
|
||||
|
||||
\ccInclude{CGAL/Number_type_traits.h}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{SqrtFieldNumberType} \\
|
||||
\ccRefIdfierPage{Ring_tag} \\
|
||||
\ccRefIdfierPage{Euclidean_ring_tag} \\
|
||||
\ccRefIdfierPage{Field_tag}
|
||||
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Sqrt<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function object class \ccRefName\ computes the square root of a number.
|
||||
|
||||
\ccInclude{CGAL/number_utils.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval);}
|
||||
{returns the square root of \ccc{ntval}.}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{Square<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ computes the square root of a number.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{NT operator()(const NT& ntval);}
|
||||
{returns the square root of \ccc{ntval}}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{To_double<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ computes an approximation of a number.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{double operator()(const NT& ntval);}
|
||||
{returns an approximation of \ccc{ntval}}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
\begin{ccRefFunctionObjectClass}{To_interval<NT>}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The function \ccRefName\ computes an enclosing interval of a number.
|
||||
|
||||
\ccInclude{CGAL/number_utils_classes.h}
|
||||
|
||||
\ccIsModel
|
||||
\ccRefConceptPage{AdaptableFunctor}
|
||||
|
||||
\ccCreationVariable{f}
|
||||
\ccMethod{std::pair<double, double> operator()(const NT& ntval);}
|
||||
{returns an enclosing interval of \ccc{ntval}}
|
||||
|
||||
\end{ccRefFunctionObjectClass}
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
\begin{ccRefFunction}{is_finite}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The template function \ccRefName\ determines whether the argument represents
|
||||
a value in $\R$.\\
|
||||
|
||||
\ccc{is_finite} implies \ccc{is_valid}.
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccInclude{CGAL/number_utils.h}
|
||||
|
||||
\ccFunction{template<NT> result_type is_finite(const NT& x);}
|
||||
{ The \ccc{result_type} is convertible to \ccc{bool}. }
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{RealEmbeddable} \\
|
||||
\ccRefConceptPage{RealEmbeddableTraits::IsFinite}\\
|
||||
|
||||
\end{ccRefFunction}
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
\begin{ccRefConcept}{EuclideanRing}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{EuclideanRing} represents an euclidean ring (or Euclidean domain).
|
||||
It is an \ccc{UniqueFactorizationDomain} that affords a suitable notion of minimality of remainders
|
||||
such that given $x$ and $y \neq 0$ we obtain an (almost) unique solution to
|
||||
$ x = qy + r $ by demanding that a solution $(q,r)$ is chosen to minimize $r$.
|
||||
In particular, $r$ is chosen to be $0$ if possible.
|
||||
|
||||
Moreover, \ccc{CGAL::Algebraic_structure_traits< EuclideanRing >} is a model of
|
||||
\ccc{AlgebraicStructureTraits} providing:\\
|
||||
|
||||
- \ccc{CGAL::Algebraic_structure_traits< EuclideanRing >::Algebraic_type} derived from \ccc{Unique_factorization_domain_tag} \\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< EuclideanRing >::Mod} a model of \ccc{AlgebraicStructureTraits::Mod}\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< EuclideanRing >::Div} a model of \ccc{AlgebraicStructureTraits::Div}\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< EuclideanRing >::Div_mod} a model of \ccc{AlgebraicStructureTraits::DivMod}\\
|
||||
|
||||
|
||||
|
||||
|
||||
\ccHeading{Remarks}
|
||||
|
||||
The most prominent example of a Euclidean ring are the integers.
|
||||
Whenever both $x$ and $y$ are positive, then it is conventional to choose
|
||||
the smallest positive remainder $r$.
|
||||
|
||||
|
||||
%Another important example of a Euclidean ring are univariate polynomials over a field.
|
||||
%Here the degree of $r$ is to be minimized. There is no remaining ambiguity.
|
||||
|
||||
%Any Euclidean ring is necessarily a \ccc{UniqueFactorizationDomain}, and the ability to take remainders allows
|
||||
%to use the Euclidean Algorithm to compute gcds.
|
||||
|
||||
\ccRefines
|
||||
\ccc{UniqueFactorizationDomain}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
|
||||
%\ccHasModels
|
||||
%\ccc{int}\\
|
||||
%\ccc{long}\\
|
||||
|
||||
%\ccc{CGAL::Gmpz} \\
|
||||
%\ccc{CGAL::Gmpzf} \\
|
||||
|
||||
%\ccc{mpz_class} \\
|
||||
|
||||
%\ccc{leda_integer} \\
|
||||
|
||||
%\ccc{CORE::BigInt} \\
|
||||
|
||||
%\ccc{CGAL::MP_Float} ( exact version )\\
|
||||
%\ccc{CGAL::Lazy_exact_nt< NT > } (depends on NT) \\
|
||||
|
||||
%%\ccc{CGAL::Polynomial< T >} \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
\begin{ccRefClass}{Euclidean_ring_tag}
|
||||
\label{Euclidean_ring_tag}
|
||||
|
||||
\ccDefinition
|
||||
Tag indicating that a type is a model of the
|
||||
\ccc{EuclideanRing} concept.
|
||||
|
||||
\ccInheritsFrom
|
||||
\ccc{Unique_factorization_domain_tag}
|
||||
|
||||
\ccIsModel
|
||||
\ccc{DefaultConstructible}
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{EuclideanRing} \\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
\begin{ccRefConcept}{ExplicitInteroperable}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
Two types \ccc{A} and \ccc{B} are a model of the \ccc{ExplicitInteroperable}
|
||||
concept, if it is possible to derive a superior type for \ccc{A} and \ccc{B},
|
||||
such that both types are embeddable into this type.
|
||||
This type is \ccc{Coercion_traits<A,B>::Type}.
|
||||
|
||||
In this case \ccc{Coercion_traits<A,B>::Are_explicit_interoperable}
|
||||
is \ccc{Tag_true}.
|
||||
|
||||
\ccc{A} and \ccc{B} are valid argument types for all binary functors in
|
||||
\ccc{Algebraic_structure_traits<Type>} and \ccc{Real_embeddable_traits<Type>}.
|
||||
This is also the case for the respective global functions.
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefIdfierPage{CGAL::Coercion_traits<A,B>}\\
|
||||
\ccRefConceptPage{ImplicitInteroperable}\\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\ccRefConceptPage{RealEmbeddableTraits}\\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
\begin{ccRefConcept}{Field}
|
||||
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{Field} is an \ccc{IntegralDomain} in which every non-zero element
|
||||
has a multiplicative inverse.
|
||||
Thus, one can divide by any non-zero element.
|
||||
Hence division is defined for any divisor != 0.
|
||||
For a Field, we require this division operation to be available through
|
||||
operators / and /=.
|
||||
|
||||
Moreover, \ccc{CGAL::Algebraic_structure_traits< Field >} is a model of
|
||||
\ccc{AlgebraicStructureTraits} providing:\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< Field >::Algebraic_type} derived from \ccc{Field_tag} \\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithSqrt >::Inverse} a model of \ccc{AlgebraicStructureTraits::Inverse}\\
|
||||
|
||||
|
||||
\ccRefines
|
||||
\ccc{IntegralDomain}
|
||||
|
||||
\ccOperations
|
||||
\ccCreationVariable{a}
|
||||
\ccFunction{Field operator/(const Field &a, const Field &b);}{}
|
||||
\ccGlue
|
||||
\ccMethod{Field operator/=(const Field &b);}{}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
|
||||
%\ccHasModels
|
||||
%\ccc{float}\\
|
||||
%\ccc{double}\\
|
||||
%\ccc{long_double}\\
|
||||
|
||||
%\ccc{CGAL::Gmpq} \\
|
||||
|
||||
%\ccc{mpq_class} \\
|
||||
%%\ccc{mpf_class} \\
|
||||
|
||||
%\ccc{leda_rational} \\
|
||||
%\ccc{leda_bigfloat} \\
|
||||
%\ccc{leda_real} \\
|
||||
|
||||
%\ccc{CORE::BigRat} \\
|
||||
%%\ccc{CORE::BigFloat} \\
|
||||
%\ccc{CORE::Expr} \\
|
||||
|
||||
%%\ccc{CGAL::Interval_nt} \\
|
||||
%%\ccc{CGAL::Interval_nt_advanced} \\
|
||||
|
||||
%\ccc{CGAL::MP_Float} (inexact version)\\
|
||||
%\ccc{CGAL::Lazy_exact_nt< NT >} (depends on NT) \\
|
||||
%\ccc{CGAL::Quotient< NT >} \\
|
||||
|
||||
%\ccc{CGAL::Sqrt_extension< NT, Root >} (depends on NT) \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
\begin{ccRefConcept}{FieldNumberType}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
The concept \ccRefName\ combines the requirements of the concepts
|
||||
\ccc{Field} and \ccc{RealEmbeddable}.
|
||||
A model of \ccRefName\ can be used as a template parameter
|
||||
for Cartesian kernels.
|
||||
|
||||
\ccRefines
|
||||
\ccc{Field}\\
|
||||
\ccc{RealEmbeddable}
|
||||
|
||||
\ccHasModels
|
||||
\ccc{float} \\
|
||||
\ccc{double} \\
|
||||
\ccc{CGAL::Gmpq} \\
|
||||
\ccc{CGAL::Interval_nt} \\
|
||||
\ccc{CGAL::Interval_nt_advanced} \\
|
||||
\ccc{CGAL::Lazy_exact_nt<FieldNumberType>} \\
|
||||
\ccc{CGAL::Quotient<RingNumberType>} \\
|
||||
\ccc{leda_rational} \\
|
||||
\ccc{leda_bigfloat} \\
|
||||
\ccc{leda_real} \\
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{RingNumberType} \\
|
||||
\ccRefConceptPage{Kernel} \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
\begin{ccRefConcept}{FieldWithKthRoot}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{FieldWithKthRoot} is a \ccc{FieldWithSqrt} that has operations to take k-th roots.
|
||||
|
||||
Moreover, \ccc{CGAL::Algebraic_structure_traits< FieldWithKthRoot >} is a model of \ccc{AlgebraicStructureTraits} providing:\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithKthRoot >::Algebraic_type} derived from \ccc{Field_with_kth_root_tag} \\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithKthRoot >::Kth_root} a model of \ccc{AlgebraicStructureTraits::KthRoot}\\
|
||||
|
||||
\ccRefines
|
||||
\ccc{FieldWithSqrt}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
|
||||
%\ccHasModels
|
||||
%\ccc{float}\\
|
||||
%\ccc{double}\\
|
||||
%\ccc{long_double}\\
|
||||
|
||||
%%\ccc{mpf_class} \\ ??
|
||||
|
||||
%\ccc{leda_bigfloat} \\
|
||||
%\ccc{leda_real} \\
|
||||
|
||||
%%\ccc{CORE::BigFloat} \\
|
||||
%\ccc{CORE::Expr} \\
|
||||
|
||||
%%\ccc{CGAL::Interval_nt} \\
|
||||
%%\ccc{CGAL::Interval_nt_advanced} \\
|
||||
|
||||
%\ccc{CGAL::MP_Float} (inexact version)\\
|
||||
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
\begin{ccRefConcept}{FieldWithRootOf}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{FieldWithRootOf} is a \ccc{FieldWithKthRoot} with the possibility to
|
||||
construct it as the root of a univariate polynomial.
|
||||
|
||||
Moreover, \ccc{CGAL::Algebraic_structure_traits< FieldWithRootOf >} is a model of \ccc{AlgebraicStructureTraits} providing:\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithRootOf >::Algebraic_type} derived from \ccc{Field_with_kth_root_tag} \\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithRootOf >::Root_of} model of \ccc{AlgebraicStructureTraits::RootOf}\\
|
||||
|
||||
\ccRefines
|
||||
\ccc{FieldWithKthRoot}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
|
||||
%\ccHasModels
|
||||
%\ccc{leda_real} (version > 5.1)\\
|
||||
%\ccc{CORE::Expr} \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
\begin{ccRefConcept}{FieldWithSqrt}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccc{FieldWithSqrt} is a \ccc{Field} that has operations to take square roots.
|
||||
|
||||
Moreover, \ccc{CGAL::Algebraic_structure_traits< FieldWithSqrt >} is a model of \ccc{AlgebraicStructureTraits} providing:\\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithSqrt >::Algebraic_type} derived from \ccc{Field_with_sqrt_tag} \\
|
||||
- \ccc{CGAL::Algebraic_structure_traits< FieldWithSqrt >::Sqrt} a model of \ccc{AlgebraicStructureTraits::Sqrt} \\
|
||||
|
||||
\ccRefines
|
||||
\ccc{Field}
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefIdfierPage{IntegralDomainWithoutDivision}\\
|
||||
\ccRefIdfierPage{IntegralDomain}\\
|
||||
\ccRefIdfierPage{UniqueFactorizationDomain}\\
|
||||
\ccRefIdfierPage{EuclideanRing}\\
|
||||
\ccRefIdfierPage{Field}\\
|
||||
\ccRefIdfierPage{FieldWithSqrt}\\
|
||||
\ccRefIdfierPage{FieldWithKthRoot}\\
|
||||
\ccRefIdfierPage{FieldWithRootOf}\\
|
||||
\ccRefIdfierPage{AlgebraicStructureTraits}\\
|
||||
|
||||
%\ccHasModels
|
||||
%\ccc{float}\\
|
||||
%\ccc{double}\\
|
||||
%\ccc{long_double}\\
|
||||
|
||||
%%\ccc{mpf_class} \\ ??
|
||||
|
||||
%\ccc{leda_bigfloat} \\
|
||||
%\ccc{leda_real} \\
|
||||
|
||||
%%\ccc{CORE::BigFloat} \\
|
||||
%\ccc{CORE::Expr} \\
|
||||
|
||||
%%\ccc{CGAL::Interval_nt} \\
|
||||
%%\ccc{CGAL::Interval_nt_advanced} \\
|
||||
|
||||
%\ccc{CGAL::MP_Float} (inexact version)\\
|
||||
%\ccc{CGAL::Lazy_exact_nt< NT >} (depends on NT) \\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
\begin{ccRefClass}{Field_tag}
|
||||
\label{Field_tag}
|
||||
|
||||
\ccDefinition
|
||||
Tag indicating that a type is a model of the \ccc{Field} concept.
|
||||
|
||||
\ccInheritsFrom
|
||||
\ccc{Integral_domain_tag}
|
||||
|
||||
\ccIsModel
|
||||
\ccc{DefaultConstructible}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{Field} \\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefClass}{Field_with_kth_root_tag}
|
||||
\label{Field_with_kth_root_tag}
|
||||
|
||||
\ccDefinition
|
||||
Tag indicating that a type is a model of the \ccc{FieldWithKthRoot} concept.
|
||||
|
||||
|
||||
\ccInheritsFrom
|
||||
\ccc{Field_with_sqrt_tag}
|
||||
|
||||
\ccIsModel
|
||||
\ccc{DefaultConstructible}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FieldWithKthRoot} \\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefClass}{Field_with_root_of_tag}
|
||||
\label{Field_with_root_of_tag}
|
||||
|
||||
\ccDefinition
|
||||
Tag indicating that a type is a model of the \ccc{FieldWithRootOf} concept.
|
||||
|
||||
|
||||
\ccInheritsFrom
|
||||
\ccc{Field_with_kth_root_tag}
|
||||
|
||||
\ccIsModel
|
||||
\ccc{DefaultConstructible}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FieldWithRootOf} \\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
\begin{ccRefClass}{Field_with_sqrt_tag}
|
||||
\label{Field_with_sqrt_tag}
|
||||
|
||||
\ccDefinition
|
||||
Tag indicating that a type is a model of the \ccc{FieldWithSqrt} concept.
|
||||
|
||||
|
||||
\ccInheritsFrom
|
||||
\ccc{Field_tag}
|
||||
|
||||
\ccIsModel
|
||||
\ccc{DefaultConstructible}
|
||||
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FieldWithSqrt} \\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits}\\
|
||||
\end{ccRefClass}
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
\begin{ccRefConcept}{Fraction}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A type is considered as a \ccc{Fraction}, if there is a reasonable way to
|
||||
decompose it into a numerator and denominator. In this case the relevant
|
||||
functionality for decomposing and re-composing as well as the numerator and
|
||||
denominator type are provided by \ccc{CGAL::Fraction_traits}.
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefIdfierPage{FractionTraits}\\
|
||||
\ccRefIdfierPage{CGAL::Fraction_traits<T>}\\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
\begin{ccRefConcept}{FractionTraits}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
A model of \ccRefName\ is associated with a type \ccc{Type}.
|
||||
|
||||
In case the associated type is a \ccc{Fraction}, a model of \ccRefName\
|
||||
provides the relevant functionality for decomposing and re-composing as well
|
||||
as the numerator and denominator type.
|
||||
|
||||
\ccInclude{CGAL/Fraction_traits.h}
|
||||
|
||||
\ccTypes
|
||||
|
||||
\ccNestedType{Type}{the associated type}
|
||||
\ccNestedType{Is_fraction}{
|
||||
Tag indicating whether the associated type is a fraction and can be
|
||||
decomposed into a numerator and denominator. \\
|
||||
This is either \ccc{CGAL::Tag_true} or \ccc{CGAL::Tag_false}.}
|
||||
\ccNestedType{Numerator_type }{The type to represent the numerator.
|
||||
This is undefined in case the associated type is not a fraction. }
|
||||
\ccNestedType{Denominator_type}{The (simpler) type to represent the denominator.
|
||||
This is undefined in case the associated type is not a fraction. }
|
||||
|
||||
\ccHeading{Functors}
|
||||
|
||||
In case \ccc{Type} is not a \ccc{Fraction} all functors are \ccc{Null_functor}.
|
||||
|
||||
\ccNestedType{Decompose}{A model of \ccc{FractionTraits::Decompose}.}
|
||||
\ccNestedType{Compose}{A model of \ccc{FractionTraits::Compose}.}
|
||||
\ccNestedType{Common_factor}{A model of \ccc{FractionTraits::CommonFactor}.}
|
||||
|
||||
\ccHasModels
|
||||
|
||||
\ccRefIdfierPage{CGAL::Fraction_traits<T>}\\
|
||||
|
||||
\ccSeeAlso
|
||||
\ccRefConceptPage{FractionTraits::Decompose}\\
|
||||
\ccRefConceptPage{FractionTraits::Compose}\\
|
||||
\ccRefConceptPage{FractionTraits::CommonFactor}\\
|
||||
|
||||
\end{ccRefConcept}
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
\begin{ccRefFunctionObjectConcept}{FractionTraits::CommonFactor}
|
||||
|
||||
\ccDefinition
|
||||
|
||||
\ccc{AdaptableBinaryFunction}, finds great common factor of denominators.
|
||||
|
||||
This can be considered as a relaxed version of \ccc{AlgebraicStructureTraits::Gcd},
|
||||
this is needed because it is not guaranteed that \ccc{FractionTraits::Denominator_type} is a model of
|
||||
\ccc{UniqueFactorizationDomain}.
|
||||
|
||||
|
||||
\ccRefines
|
||||
|
||||
\ccc{AdaptableBinaryFunction}
|
||||
|
||||
\ccTypes
|
||||
%SetThreeColumns{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}{xxxxxxxxxxxxxxxxxxxxxxx}{}
|
||||
|
||||
\ccTypedef{typedef FractionTraits::Denominator_type result_type;}{}
|
||||
\ccTypedef{typedef FractionTraits::Denominator_type first_argument_type;}{}
|
||||
\ccTypedef{typedef FractionTraits::Denominator_type second_argument_type;}{}
|
||||
|
||||
\ccOperations
|
||||
%SetThreeColumns{xxxxxxxxxx}{xxxxx}{}
|
||||
\ccCreationVariable{common_factor}
|
||||
\ccMethod{result_type operator()(first_argument_type d1, second_argument_type d2);}
|
||||
{return a great common factor of $d1$ and $d2$.\\
|
||||
Note: {\tt operator()(0,0) = 0} }
|
||||
|
||||
%\ccHasModels
|
||||
|
||||
\ccSeeAlso
|
||||
|
||||
\ccRefConceptPage{Fraction}\\
|
||||
\ccRefConceptPage{FractionTraits}\\
|
||||
\ccRefConceptPage{FractionTraits::Decompose}\\
|
||||
\ccRefConceptPage{FractionTraits::Compose}\\
|
||||
%\ccRefConceptPage{FractionTraits::CommonFactor}\\
|
||||
\ccRefConceptPage{AlgebraicStructureTraits::Gcd}\\
|
||||
|
||||
\end{ccRefFunctionObjectConcept}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue