mirror of https://github.com/CGAL/cgal
267 lines
12 KiB
Plaintext
267 lines
12 KiB
Plaintext
/*!
|
|
|
|
\page chapintro Introduction
|
|
|
|
\author Susan Hert
|
|
\author Menelaos Karavelas (<TT>mkaravel@tem.uoc.gr</TT>)
|
|
\author Stefan Schirra
|
|
|
|
<CENTER>
|
|
\image html cgal_small.png
|
|
\image latex cgal_small.png
|
|
</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:
|
|
|
|
\subsection Developer_manualCorrectness 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.
|
|
|
|
\subsection Developer_manualRobustness 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.
|
|
|
|
\subsection Developer_manualFlexibility 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.
|
|
|
|
\subsection Developer_manualEaseofUse 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.
|
|
|
|
\subsection Developer_manualEfficiency 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.\cgalFootnote{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.
|
|
(\cgalFigureRef{figgenericCGAL} ).
|
|
|
|
\cgalFigureBegin{figgenericCGAL,generic_cgal.png}
|
|
The generic design of \cgal.
|
|
\cgalFigureEnd
|
|
|
|
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.
|
|
|
|
*/
|
|
|