\chapter{Kernel Representations}

Our object of study is the $d$-dimensional affine Euclidean space,
where $d$ is a parameter of our geometry.  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.

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 two families of concrete models for the concept
representation class, one 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 have a constructor with a range of coordinates plus a
common denominator (the $d+1$ 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
and the linear algebra module used to calculate the result of
predicates and constructions.

For reasons that will become evident later, a representation class
provides two typenames for number types,
namely \ccc{R::FT} and \ccc{R::RT} and one typename for the linear
algebra module \ccc{R::LA}.%
\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 an
{\em Euclidean 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.  

\section{Cartesian Kernel}
With \ccc{Cartesian_d<FieldNumberType,LinearAlgebra>} you can choose
\ccHtmlNoLinksFrom{Cartesian} representation of coordinates. The type
\ccc{LinearAlgebra} must me a linear algebra module working on numbers
of type \ccc{FieldNumberType}. The second parameter defaults to module
delivered with the kernel so for short a user can just write
\ccc{Cartesian_d<FieldNumberType>} when not providing her own linear
algebra.

When you choose \ccHtmlNoLinksFrom{Cartesian} representation you have
to declare at least the type of the coordinates.  A number type used
with the \ccc{Cartesian_d} representation class should be a {\em field
  type} as described above.  Both \ccc{Cartesian<FieldNumberType>::FT}
and \ccc{Cartesian<FieldNumberType>::RT} are mapped to number type
\ccc{FieldNumberType}.
\ccc{Cartesian_d<FieldNumberType,LinearAlgebra>::LA} is mapped to the
type \ccc{LinearAlgebra}. \ccc{Cartesian<FieldNumberType>} uses
reference counting internally to save copying costs.

\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_d<RingNumberType,LinearAlgebra>} 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 Euclidean
ring type only. 

The type \ccc{LinearAlgebra} must me a linear algebra module working
on numbers of type \ccc{RingNumberType}. Again the second parameter
defaults to module delivered with the kernel so for short one can just
write \ccc{Homogeneous_d<RingNumberType>} when replacing the default
is no issue.

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_d<RingNumberType>},
\ccc{Homogeneous_d<RingNumberType>::FT} is equal to
\ccStyle{Quotient<RingNumberType>} while
\ccc{Homogeneous_d<RingNumberType>::RT} is equal to
\ccc{RingNumberType}.
\ccc{Homogeneous_d<RingNumberType,LinearAlgebra>::LA} is mapped to the
type \ccc{LinearAlgebra}.

\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 capitalized base name} of the geometric object, such as
  \ccStyle{Point}, \ccStyle{Segment}, \ccStyle{Triangle}.

\item Followed by \ccc{_d}.
  
\item A {\em representation class} as parameter, which itself is
  parameterized with a number type, such as
  \ccStyle{Cartesian_d<double>} or \ccStyle{Homogeneous_d<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.  

The dimension $d$ of our affine space determines the dimension of the
matrix computions in the mathematical evaluation of predicates.  As
rounding errors accumulate fast the homogeneous represenation used
with multi-precision integers is the kernel of choice for well-behaved
algorithms.  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.

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 of Header Files}

You need just to include a representation class to obtain the the
geometric objects of the kernel that you would like to use with the
representation class, i.e., \ccc{CGAL/Cartesian_d.h} or
\ccc{CGAL/Homogeneous_d.h}


