/*!

\page chapintro Introduction

\author Susan Hert
\author Menelaos Karavelas (<TT>mkaravel@tem.uoc.gr</TT>)
\author Stefan Schirra

<CENTER>
\image html cgal_small.gif 
</CENTER>
<CENTER><span class="textsc">Computational Geometry Algorithms Library</span></CENTER>

<BLOCKQUOTE>
<I>The goal of the \cgal Open Source Project is to provide easy access to efficient and reliable geometric algorithms in the form of a \cpp library.
\cgal is used in various areas needing geometric computation, such
as: computer graphics, scientific visualization, computer aided design
and modeling, geographic information systems, molecular biology,
medical imaging, robotics and motion planning, mesh generation,
numerical methods...
</I>
</BLOCKQUOTE>

Work on \cgal has been supported in the past by <span class="textsc">esprit iv</span>
projects 21957 (CGAL) and 28155 (GALIA).

\section secdesign_goals Primary design goals 

The primary design goals of \cgal are described in \cite fgkss-dccga-00:

## Correctness ##

A library component is correct if it behaves according to its
specification. 
Basically, correctness is therefore a matter of 
verification that documentation and implementation coincide.
In a modularized program the correctness of a module is determined 
by its own correctness and the correctness of all the modules it depends on.  
Clearly, in order to get correct results, correct algorithms and data 
structures must be used.

Exactness should not be confused with correctness in the sense of
reliability. There is nothing wrong with algorithms computing approximate 
solutions instead of exact solutions, as long as their 
behavior is clearly documented and they do behave as specified.
Also, an algorithm handling only non-degenerate cases can be
correct with respect to its specification, although in \cgal we would
like to provide algorithms handling degeneracies.

## Robustness ##

A design goal particularly relevant for the implementation of
geometric algorithms is robustness.  Many implementations of geometric
algorithms lack robustness because of precision problems; see 
Chapter  \ref chaprobustness  for a discussion of robustness issues within 
\cgal.

## Flexibility ##

The different needs of the potential application areas demand 
flexibility in the library. Four sub-issues of flexibility can be identified.

<B>Modularity.</B>

A clear structuring of \cgal into modules with as few dependencies as
possible helps a user in learning and using \cgal, since the overall
structure can be grasped more easily and the focus can be narrowed to
those modules that are actually of interest.

<B>Adaptability.</B>

\cgal might be used in an already established environment with
geometric classes and algorithms in which case the modules will 
most probably need adaptation before they can be used.

<B>Extensibility.</B>

Not all wishes can be fulfilled with \cgal. Users may want to
extend the library. It should be possible, and in fact desirable, to
integrate new classes and algorithms into \cgal.

<B>Openness.</B>

\cgal should be open to coexist with other libraries, or better, to
work together with other libraries and programs. The \cpp 
Standard \cite cgal:ansi-is14882-98

defines with the \cpp Standard Library a common
foundation for all \cpp platforms. 
So it is easy and natural to gain openness by following this standard.
There are important libraries outside the standard, and \cgal should be easily adaptable to them as well.

## Ease of Use ##

Many different qualities can contribute to the ease of use of a
library. Which qualities are most important differs according to 
the experience of the user.
The above-mentioned correctness and robustness issues are among
these qualities. Of general importance is the length of time required
before the library becomes useful. Another issue is the number of 
new concepts and
exceptions to general rules that must be learned and remembered.

Ease of use tends to conflict with flexibility, but in many
situations a solution can be found.
The flexibility of \cgal should not distract a novice who takes the 
first steps with \cgal.

<B>Uniformity.</B>

A uniform look and feel of the design in \cgal will help in learning
and memorizing. A concept once learned should be applicable in all
places where one would wish to apply it. 
A function name once learned for a specific
class should not be named differently for another class.

  \cgal is
based in many places on concepts borrowed from \stl (Standard
Template Library) or the other parts of the \cpp Standard Library. An
example is the use of streams and stream operators in \cgal. Another
example is the use of container classes and algorithms from the
\stl. So these concepts should be used uniformly.

  During the past few years,
\cgal has moved towards using on concepts and ideas from the boost
libraries, as well as providing interfaces towards boost
libraries. These include the boost graph library and the boost property
maps library.

<B>Complete and Minimal Interfaces.</B>

A goal with similar implications as uniformity is a design
with complete and minimal interfaces, see for example Item 18 
in Ref. \cite cgal:m-ec-97.
An object or module should be complete in its 
functionality, but should
not provide additional decorating functionality. Even if a certain
function might look like it contributes to the ease of use for a certain 
class, in a more global picture it might hinder the understanding of 
similarities and differences among classes, and make it harder to learn 
and memorize.

<B>Rich and Complete Functionality.</B>

We aim for a useful and rich collection of geometric classes, data
structures and algorithms. \cgal is supposed to be a foundation for
algorithmic research in computational geometry and therefore needs a
certain breadth and depth. The standard techniques in the field are
supposed to appear in \cgal.

Completeness is also related to robustness.

We aim for general-purpose
solutions that are, for example, not restricted by assumptions on
general positions. Algorithms in \cgal should be able to handle
special cases and degeneracies. 

In those cases where handling of degeneracies turns out to be
inefficient, special variants that are more efficient but less general
should be provided in the library in addition to the general 
algorithms handling all degeneracies. Of course, it needs to be
clearly documented which degeneracies are handled and which are not.

## Efficiency ##

For most geometric algorithms theoretical results for the time and space
complexity are known. Also, the theoretic interest in efficiency for
realistic inputs, as opposed to worst-case situations, is
growing \cite v-ffrim-97.
For practical purposes, insight into the constant factors hidden in the
\f$ O\f$-notation is necessary, especially if there are several competing
algorithms.

Therefore, different implementations should be supplied if there is 
not one best solution, as, for example, when there is a tradeoff between 
time and space or a more efficient implementation when there are no or few 
degeneracies. 

\section secoverall_design The overall design 

The design goals, especially flexibility and efficient robust 
computation, have led us to opt for the generic programming paradigm using 
templates in \cpp.\footnote{In appropriate places, however, \cgal does  and should make use of object-oriented solutions and design patterns, as well.}
In the overall design of \cgal three major layers can be identified, the
layer of algorithms and data structures, the kernel layer and the
arithmetic and algebra layer.
(Figure  \ref figgenericCGAL ).

\anchor figgenericCGAL
\image html generic_cgal.gif 
<center><b>The generic design of \cgal.</b></center>

Algorithms and data structures in \cgal are parameterized by the 
types of objects and operations they use. They work with any concrete 
template arguments that fulfill certain syntactical as well as semantic
requirements. In order to avoid long parameter lists,
the parameter types are collected into a single class, called the
traits class in \cgal
(Chapter  \ref chaptraits_classes ).
A <I>concept</I> is an abstraction of a type 
defined by a set of requirements.
Any concrete type is called a <I>model</I> for a 
concept if it fulfills
the set of requirements corresponding to the concept. Using this terminology,
we can say a \cgal algorithm or data structure comes with a traits 
concept and can be used with any concrete traits model for this concept.
Further contributions to \cgal should continue the current high
level of genericity.

\cgal defines the concept of a geometry kernel.
Ideally, any
model for this concept can be used with any \cgal algorithm. This holds, 
of course, only if the requirements of an algorithm or data structure on its
traits class are subsumed by the kernel concepts, <I>i.e.</I>, if an
algorithm or data structure has no special requirements 
not covered in the definition of the kernel concept. Currently, \cgal offers a concept for a fundamental geometry kernel, that defines
various geometric objects such as points, line segments, lines,
circles, and operations on them, as well as two additional concepts,
the circular and the spherical kernel. The goal of the last two
kernels is to specify a large set of functionalities on circles and
circular arcs on the plane (circular kernel), and analogous
functionalities for circles, circular arcs living on a 3D sphere
(spherical kernel).

\cgal currently provides several models for the \cgal 2D and 3D kernel
concept, and one model for the 2D circular and the 3D spherical kernel
concepts.. Those are again parameterized and differ in their 
representation of the geometric objects and the exchangeability of
the types involved. 
In the first four cases the kernels are parameterized by a number type, which
is used to store coordinates and which determines the basic arithmetic
of the kernel primitives.

In the last two cases, the circular and spherical kernel are also
parametrized by Algebraic Kernels, which, along with Algebraic
Foundations, is the third distinct high level of genericity in
\cgal. The algebraic foundations in \cgal is a collection of concepts
representing algebraic structures, and are motivated by well-known
counterparts in traditional algebra. The algebraic foundations
determine the operations per algebraic structure, their properties
(e.g., whether they are supposed to be exact or approximate), as well
as interoperability between them.
An algebraic kernel is responsible for providing an abstraction
for the algebraic operations required by either geometry kernels or
traits classes used in \cgal algorithms. The goal is to be able to
construct, compare and perform operations on real roots of polynomial
equations. There are different concepts depending on the number of
variables of the polynomials used to determine the roots (currently
there are concepts for univariate and bivariate algebraic kernel), as
well as specialized concepts targeted towards specific geometric
higher level layers of the library (such as the circular and spherical
kernels). These concepts are accompanied by at least one model per
concept.

There are further complementary layers in \cgal. The most basic layer is 
the configuration layer.
This layer takes care of setting configuration flags according to the outcome
of tests run during installation.  The <I>support library</I> layer
 is documented in
the <A HREF="http://www.cgal.org/Manual/latest/doc_html/cgal_manual/contents.html#part_XVII">Support Library Manual</A> and contains packages
that deal with things such as visualization, number types, streams, and
\stl extensions in \cgal.

*/