mirror of https://github.com/CGAL/cgal
244 lines
13 KiB
TeX
244 lines
13 KiB
TeX
\chapter{Kernel Representations}
|
|
Our object of study is the $d$-dimensional affine Euclidean space.
|
|
Here we are mainly concerned with cases $d=2$ and $d=3$.
|
|
Objects in that space are sets of points. A common way to represent
|
|
the points is the use of \ccHtmlNoLinksFrom{Cartesian} coordinates,
|
|
which assumes a reference frame (an origin and $d$ orthogonal axes).
|
|
In that framework, a point is represented by a $d$-tuple
|
|
\ccTexHtml{$(c_0,c_1,\ldots,c_{d-1})$}{<MATH>(c<SUB>0</SUB>,c<SUB>1</SUB>,...,c<SUB>d-1</SUB>)</MATH>},
|
|
and so are vectors in the underlying linear space. Each point is
|
|
represented uniquely by such \ccHtmlNoLinksFrom{Cartesian} coordinates.
|
|
%An object can then be represented by an equation, that is, it is the
|
|
%set of
|
|
%points whose coordinates satisfy the equation. For example, the
|
|
%equation of a
|
|
%line is usually given as $ax + by +c = 0$.
|
|
%The line can then be represented by three numbers $a$, $b$, $c$.
|
|
Another way to represent points is by homogeneous coordinates. In that
|
|
framework, a point is represented by a $(d+1)$-tuple
|
|
\ccTexHtml{$(h_0,h_1,\ldots,h_d)$}{<MATH>(h<SUB>0</SUB>,h<SUB>1</SUB>,...,h<SUB>d</SUB>)</MATH>}.
|
|
Via the formulae
|
|
\ccTexHtml{$c_i = h_i/h_d$}{<MATH>c<SUB>i</SUB>=h<SUB>i</SUB>/h<SUB>d</SUB></MATH>},
|
|
the corresponding point with \ccHtmlNoLinksFrom{Cartesian} coordinates
|
|
\ccTexHtml{$(c_0,c_1,\ldots,c_{d-1})$}{<MATH>(c<SUB>0</SUB>,c<SUB>1</SUB>,...,c<SUB>d-1</SUB>)</MATH>}
|
|
can be computed. Note that homogeneous coordinates are not unique.
|
|
For \ccTexHtml{$\lambda\ne 0$}{<MATH>lambda != 0</MATH>},
|
|
the tuples
|
|
\ccTexHtml{$(h_0,h_1,\ldots,h_d)$}{<MATH>(h<SUB>0</SUB>,h<SUB>1</SUB>
|
|
,...,h<SUB>d</SUB>)</MATH>}
|
|
and
|
|
\ccTexHtml{$(\lambda\cdot h_0,\lambda\cdot h_1,\ldots,\lambda\cdot
|
|
h_d)$}{<MATH>(lambda h<SUB>0</SUB>,lambda h<SUB>1</SUB>,...,lambda
|
|
h<SUB>d</SUB>)</MATH>} represent the
|
|
same point.
|
|
For a point with \ccHtmlNoLinksFrom{Cartesian} coordinates \ccTexHtml{$(c_0,c_1,\ldots,c_{
|
|
d-1})$}{<MATH>(c<SUB>0</SUB>,c<SUB>1</SUB>,...,c<SUB>d-1</SUB>)</MATH>} a
|
|
possible homogeneous representation is
|
|
\ccTexHtml{$(c_0,c_1,\ldots,c_{d-1},1)$}{<MATH>(c<SUB>0</SUB>,c<SUB>1</SUB>,...,c<SUB>d-1</SUB>,1)</MATH>}.
|
|
\ccHtmlNoLinksFrom{Homogeneous} coordinates in fact allow to represent
|
|
objects in a more general space, the projective space
|
|
\ccTexHtml{$\P_d$}{<MATH>P<SUB>d</SUB></MATH>}.
|
|
In \cgal, we do not compute in projective geometry. Rather, we use
|
|
homogeneous coordinates to avoid division operations,
|
|
since the additional coordinate can serve as a common denominator.
|
|
|
|
\section{Genericity through Parameterization}
|
|
Almost all the kernel objects (and the corresponding functions) are
|
|
templates with a parameter that allows the user to choose the
|
|
representation of the kernel objects. A type that is used as an
|
|
argument for this parameter must fulfill certain requirements on
|
|
syntax and semantics. The list of requirements defines an abstract
|
|
kernel concept. In \cgal\ such a kernel concept is often also called
|
|
a \emph{representation class} and denoted by \ccc{R}. A representation
|
|
class provides the actual implementations of the kernel objects.
|
|
For all kernel objects \ccc{Kernel_object}, the types
|
|
\ccc{CGAL::Kernel_object<R>} and \ccc{R::Kernel_object} are identical.
|
|
|
|
CGAL offers three families of concrete models for the concept
|
|
representation class, two based on the \ccHtmlNoLinksFrom{Cartesian} representation of points
|
|
and one based on the homogeneous representation of points.
|
|
The interface of the kernel objects is designed such that it works well
|
|
with both \ccHtmlNoLinksFrom{Cartesian} and homogeneous representation, for example, points
|
|
in 2D have a constructor with three arguments as well
|
|
(the three homogeneous coordinates of the point).
|
|
The common interfaces parameterized with a representation class allow
|
|
one to develop code independent of the chosen representation.
|
|
We said ``families'' of models, because both families are parameterized too.
|
|
A user can choose the number type used to represent the coordinates.
|
|
|
|
For reasons that will become evident later,
|
|
a representation class provides two typenames for number types,
|
|
namely \ccc{R::FT} and \ccc{R::RT}.%
|
|
\ccTexHtml{\footnote{The double colon :: is the \CC\ scope operator.}}{}
|
|
The type \ccStyle{R::FT} must fulfill the requirements on what is
|
|
called a {\em field type} in \cgal. This roughly means that \ccStyle{R::FT}
|
|
is a type for which operations $+$, $-$, $*$ and $/$ are defined
|
|
with semantics (approximately) corresponding to those of a field in
|
|
a mathematical sense. Note that, strictly speaking, the built-in type
|
|
\ccc{int} does not fullfil the requirements on a field type, since \ccc{int}s
|
|
correspond to elements of a ring rather than a field, especially
|
|
operation $/$ is not the inverse of $*$.
|
|
The requirements on the type \ccStyle{R::RT} are weaker.
|
|
This type must fulfill the requirements on what is called a {\em ring type}
|
|
in \cgal. This roughly means that \ccStyle{R::RT}
|
|
is a type for which operations $+$, $-$, $*$ are defined with semantics
|
|
(approximately) corresponding to those of a ring in a mathematical sense.
|
|
A very limited division operation $/$ must be available as well.
|
|
It must work for exact (i.e., no remainder) integer divisions only.
|
|
Furthermore, both number types should fulfill \cgal's requirements on a
|
|
number type. %see
|
|
Note that a ring type is always a field type but not the other way
|
|
round.
|
|
|
|
\section{Cartesian Kernels}
|
|
With \ccc{Cartesian<FieldNumberType>} you can choose \ccHtmlNoLinksFrom{Cartesian} representation
|
|
of coordinates. When you choose \ccHtmlNoLinksFrom{Cartesian} representation you
|
|
have to declare at the same time the type of the coordinates.
|
|
A number type used with the \ccc{Cartesian} representation class
|
|
should be a {\em field type} as described above.
|
|
As mentioned above, the built-in type \ccc{int} is not a field type.
|
|
However, for some computations with \ccHtmlNoLinksFrom{Cartesian} representation, no
|
|
division operation is needed, i.e.,
|
|
a {\em ring type} is sufficient in this case.
|
|
With \ccc{Cartesian<FieldNumberType>}, both \ccc{Cartesian<FieldNumberType>::FT}
|
|
and \ccc{Cartesian<FieldNumberType>::RT} are mapped to number type \ccc{FieldNumberType}.
|
|
|
|
\ccc{Cartesian<FieldNumberType>} uses reference counting internally to save copying
|
|
costs. CGAL also provides \ccc{Simple_cartesian<FieldNumberType>}, a kernel
|
|
that uses \ccHtmlNoLinksFrom{Cartesian} representation but no reference counting.
|
|
Debugging is easier with \ccc{Simple_cartesian<FieldNumberType>}, since the coordinates
|
|
are stored within the class and hence direct access to the coordinates is
|
|
possible. Depending on the algorithm, it can also be slightly more or less
|
|
efficient than \ccc{Cartesian<FieldNumberType>}.
|
|
With \ccc{Simple_cartesian<FieldNumberType>}, both \ccc{Simple_cartesian<FieldNumberType>::FT}
|
|
and \ccc{Simple_cartesian<FieldNumberType>::RT} are mapped to number type \ccc{FieldNumberType}.
|
|
|
|
\section{Homogeneous Kernel}
|
|
As we mentioned before, homogeneous coordinates permit to avoid
|
|
division operations in numerical computations, since the additional
|
|
coordinate can serve as a common denominator.
|
|
Avoiding divisions can be useful for exact geometric computation.
|
|
With \ccc{Homogeneous<RingNumberType>} you can choose homogeneous representation
|
|
of coordinates with the kernel objects. As for \ccHtmlNoLinksFrom{Cartesian} representation you
|
|
have to declare at the same time the type used to store the homogeneous
|
|
coordinates. Since the homogeneous representation allows one to avoid the
|
|
divisions, the number type associated with a homogeneous representation class
|
|
must be a model for the weaker concept ring type only. However,
|
|
some operations provided by this kernel involve division operations, for
|
|
example computing squared distances or returning a \ccHtmlNoLinksFrom{Cartesian} coordinate.
|
|
To keep the requirements on the number type parameter of \ccc{Homogeneous}
|
|
low, the number type \ccStyle{Quotient<RingNumberType>} is used instead.
|
|
This number type turns a ring type into a field type. It maintains
|
|
numbers as quotients, i.e. a numerator and a denominator.
|
|
Thereby, divisions are circumvented.
|
|
With \ccc{Homogeneous<RingNumberType>}, \ccc{Homogeneous<RingNumberType>::FT} is
|
|
equal to \ccStyle{Quotient<RingNumberType>} while
|
|
\ccc{Homogeneous<RingNumberType>::RT} is equal to \ccc{RingNumberType}.
|
|
|
|
\ccc{Homogeneous<RingNumberType>} uses reference counting internally to save
|
|
copying costs. CGAL also provides \ccc{Simple_homogeneous<RingNumberType>}, a
|
|
kernel that uses \ccHtmlNoLinksFrom{homogeneous} representation but no reference
|
|
counting. Debugging is easier with \ccc{Simple_homogeneous<RingNumberType>},
|
|
since the coordinates are stored within the class and hence direct access to
|
|
the coordinates is possible. Depending on the algorithm, it can also be
|
|
slightly more or less efficient than \ccc{Homogeneous<RingNumberType>}.
|
|
With \ccc{Simple_homogeneous<RingNumberType>},
|
|
\ccc{Simple_homogeneous<RingNumberType>::FT} is equal to
|
|
\ccStyle{Quotient<RingNumberType>} while
|
|
\ccc{Simple_homogeneous<RingNumberType>::RT} is equal to \ccc{RingNumberType}.
|
|
|
|
\section{Naming conventions}
|
|
|
|
The use of representation classes not only avoids problems, it
|
|
also makes all \cgal\ classes very uniform. They {\bf always} consist of:
|
|
\begin{enumerate}
|
|
\begin{ccTexOnly}
|
|
\itemsep0pt\topsep0pt\partopsep0pt\parskip0pt\parsep0pt
|
|
\end{ccTexOnly}
|
|
|
|
%\item The {\em name space prefix} \ccStyle{}. This avoids name
|
|
% clashes. It will be dropped as soon as \CC\ compilers support the
|
|
% concept of name spaces as a feature of the programming language.
|
|
|
|
\item The {\em capitalized base name} of the geometric object, such as
|
|
\ccStyle{Point}, \ccStyle{Segment}, \ccStyle{Triangle}.
|
|
|
|
\item An {\em underscore} followed by the {\em dimension} of the object,
|
|
for example $\_2$, $\_3$ or $\_d$.
|
|
|
|
\item A {\em representation class} as parameter, which itself is
|
|
parameterized with a number type, such as \ccStyle{Cartesian<double>}
|
|
or \ccStyle{Homogeneous<leda_integer>}.
|
|
\end{enumerate}
|
|
|
|
\section{Kernel as a Traits Class}
|
|
Algorithms and data structures in the basic library of CGAL are parameterized
|
|
by a traits class that subsumes the objects on which the algorithm or data
|
|
structure operates as well as the operations to do so. For most of the
|
|
algorithms and data structures in the basic library you can use a kernel
|
|
as a traits class. For some algorithms you even do not have to specify
|
|
the kernel; it is detected automatically using the types of the geometric
|
|
objects passed to the algorithm. In some other cases, the algorithms
|
|
or data structures needs more than is provided by a kernel. In these
|
|
cases, a kernel can not be used as a traits class.
|
|
|
|
\section{Choosing a Kernel}
|
|
If you start with integral \ccHtmlNoLinksFrom{Cartesian} coordinates, many geometric computations
|
|
will involve integral numerical values only. Especially, this is true for
|
|
geometric computations that evaluate only predicates, which are tantamount to
|
|
determinant computations. Examples are triangulation of point sets and
|
|
convex hull computation.
|
|
In this case, the \ccHtmlNoLinksFrom{Cartesian} representation is probably the first choice, even
|
|
with a ring type. You might use limited precision integer types like
|
|
\ccc{int} or \ccc{long}, use \ccc{double} to present your integers (they
|
|
have more bits in their mantissa than an \ccc{int} and overflow nicely), or an
|
|
arbitrary precision integer type like the wrapper \ccc{Gmpz} for the
|
|
GMP integers or \ccc{leda_integer}. Note, that unless you use an
|
|
arbitrary precision integer type, incorrect results might arise due to
|
|
overflow.
|
|
|
|
If new points are to be constructed, for example
|
|
the \ccHtmlNoLinksFrom{intersection} point of two lines, computation of
|
|
\ccHtmlNoLinksFrom{Cartesian} coordinates usually involves divisions, so
|
|
you need to use a field type with \ccHtmlNoLinksFrom{Cartesian} representation
|
|
or have to switch to homogeneous representation.
|
|
\ccc{double} is a possible, but imprecise field type.
|
|
You can also put any ring type into \ccc{Quotient} to get a
|
|
field type and put it into \ccc{Cartesian}, but you better put
|
|
the ring type into \ccc{Homogeneous}.
|
|
\ccc{leda_rational} and \ccc{leda_real} are valid field types, too.
|
|
|
|
If it is crucial for you that the computation is reliable,
|
|
the right choice are probably number types that guarantee
|
|
exact computation. The number type \ccc{leda_real} guarantees
|
|
that all decisions and hence all branchings in a computation
|
|
are correct. They also allow you to compute approximations to whatever
|
|
precision you need. Furthermore computation with
|
|
\ccc{leda_real} is faster than computation with arbitrary precision
|
|
arithmetic. So if you would like to avoid surprises caused by imprecise
|
|
computation, this is a good choice. In fact, it is a good choice with
|
|
both representations, since divisions slow down the computation of
|
|
the reals and hence it might pay-off to avoid them.
|
|
|
|
Still other people will prefer the built-in
|
|
type {\tt double}, because they need speed and can live with
|
|
approximate results, or even algorithms that, from time to time,
|
|
crash or compute incorrect results due to accumulated rounding errors.
|
|
|
|
\section{Inclusion Order}
|
|
You need to include a representation class first before you include any of
|
|
the geometric objects of the kernel that you would like to use with
|
|
the representation class, i.e., one or several of
|
|
\ccc{CGAL/Cartesian.h}, \ccc{CGAL/Homogeneous.h}, \ccc{CGAL/Simple_cartesian.h},
|
|
and \ccc{CGAL/Simple_homogeneous.h}
|
|
before \ccc{CGAL/..._2.h} and \ccc{CGAL/..._3.h}.
|
|
|
|
\ccExample
|
|
\begin{cprog}
|
|
#include <CGAL/Cartesian.h>
|
|
#include <CGAL/Homogeneous.h>
|
|
#include <CGAL/Point_2.h>
|
|
/* ... */
|
|
\end{cprog}
|
|
|