removed old files

.gitattributes

@@ -561,60 +561,6 @@ Kernel_23/doc_tex/Kernel_23_ref/fig/compare_x_at_y.pdf -text svneol=unset#unset
 Kernel_23/doc_tex/Kernel_23_ref/fig/transvecthree.gif -text svneol=unset#unset
 Kernel_23/doc_tex/Kernel_23_ref/fig/transvectwo.gif -text svneol=unset#unset
 Kinetic_data_structures/demo/Kinetic_data_structures/makefile -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/adding_certificate.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/architecture.odg -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/architecture_pct.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/architecture_pct.gif -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/architecture_pct.pdf -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_0.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_0.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_0.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_0.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_1.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_1.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_1.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_1.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_2.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_2.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_2.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_2.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_3.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_3.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_3.pdf -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_3.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_4.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_4.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_4.pdf -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_4.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_5.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_5.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_5.pdf -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_5.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_6.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_6.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_6.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_6.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_7.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_7.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_7.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_7.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_8.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_8.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_8.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_8.png -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/overview.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/qt_widget_marked_pct.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/qt_widget_marked_pct.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/qt_widget_marked_pct.pdf -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_example.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_usage_pct.eps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_usage_pct.gif -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_usage_pct.pdf -text svneol=unset#unset
-Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_usage_pct.ps -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Certificate.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/ConstructFunction.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Function.tex -text
-Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Time.tex -text
 Kinetic_data_structures/examples/Kinetic_data_structures/adding_a_certificate.C -text
 Kinetic_data_structures/include/CGAL/Kinetic/Certificate_generator.h -text
 Kinetic_data_structures/include/CGAL/Polynomial/CORE_kernel.h -text

Kinetic_data_structures/doc_tex/Kinetic_data_structures/PkgDescription.tex

@@ -1,17 +0,0 @@
-
-\begin{ccPkgDescription}{Kinetic Data Structures\label{Pkg:Kds}}
-\ccPkgSummary{
-Kinetic data structures allow combinatorial structures to be
-maintained as the primitives move. The package provides
-implementations of kinetic data structures for Delaunay triangulations
-in two and three dimensions, sorting of points in one dimension and
-regular triangulations in three dimensions. In addition, the package
-provides a framework to ease implementing and debugging kinetic data
-structures. The package supports exact or inexact operations on
-primitives which move along polynomial trajectories.  }
-
-\ccPkgDependsOn{Two dimensional visualization depends on \ccThirdPartyQt, three dimensional visualization depends on \ccThirdPartyCoin. }
-\ccPkgMaturity{Introduced in \cgal\ 3.2}
-\ccPkgLicense{\ccLicenseLGPL}
-
-\end{ccPkgDescription}

Kinetic_data_structures/doc_tex/Kinetic_data_structures/adding_certificate.tex

@@ -1,87 +0,0 @@
-\subsection{Adding a new certificate type}
-\label{sec:add_cert}
-
-The following example shows how to add a new type of certificate to a simulation. 
-
-First we code the actual certificate function generator. It must take
-some sort (or sorts) of kinetic primitives, compute some function from
-their coordinates.
-
-\begin{ccExampleCode}
-template <class KineticKernel>
-struct Positive_x_f_2 {
-  typedef typename KineticKernel::Certificate_function result_type;
-  typedef typename KineticKernel::Point_2 argument_type;
-  result_type operator()(const argument_type &p){
-    return result_type(p.x()- result_type(0));
-  }
-};
-\end{ccExampleCode}
-
-Then we define a kinetic kernel which includes this predicate. To do
-this we wrap the function generator generator in a
-\ccc{Kinetic::Certificate_generator<Kernel, Generator>}.
-This wrapper uses the generator to create the certificate function and
-then the \ccc{Kinetic::FunctionKernel} to solve the certificate
-function. The result is wrapped in a \ccc{Kinetic::Certificate}
-object.
-
-\begin{ccExampleCode}
-template <class FunctionKernel> 
-class My_kinetic_kernel:
-  public CGAL::Kinetic::Cartesian_kinetic_kernel<FunctionKernel> {
-  typedef CGAL::Kinetic::Cartesian_kinetic_kernel<FunctionKernel> P;
-  typedef My_kinetic_kernel<FunctionKernel> This;
-public:
-  typedef CGAL::Kinetic::internal::Certificate_generator<This, Positive_x_f_2<This> > Positive_x_2;
-  Positive_x_2 positive_x_2_object() const
-  {
-    return Positive_x_2(P::function_kernel_object());
-  }
-};
-\end{ccExampleCode}
-
-Now we have the unfortunately rather messy part of assembling a new
-\ccc{Kinetic::SimulationTraits} model. This is done in two steps for convenience.
-
-\begin{ccExampleCode}
-struct My_st_types: public CGAL::Kinetic::Suggested_exact_simulation_traits_types {
-  typedef CGAL::Kinetic::Suggested_exact_simulation_traits_types P;
-  typedef My_kinetic_kernel<P::Function_kernel>::Point_2 Active_object;
-  typedef CGAL::Kinetic::Active_objects_vector<Active_object> Active_objects_table;
-  typedef CGAL::Kinetic::Cartesian_instantaneous_kernel< Active_objects_table,
-							 Static_kernel> Instantaneous_kernel;
-};
-
-struct My_simulation_traits:
-  public  CGAL::Kinetic::Simulation_traits<My_st_types::Static_kernel,
-			    My_st_types::Kinetic_kernel,
-			    My_st_types::Simulator>
-{
-  typedef  CGAL::Kinetic::Simulation_traits<My_st_types::Static_kernel,
-					    My_st_types::Kinetic_kernel,
-					    My_st_types::Simulator> P;
-  My_simulation_traits(const P::Time &lb= P::Time(0),
-		       const P::Time &ub=std::numeric_limits<P::Time>::infinity()): 
-    P(lb,ub), 
-    ap_(new Active_points_2_table()) {}
-
-  typedef My_st_types::Active_objects_table Active_points_2_table;
-  Active_points_2_table* active_points_2_table_handle() {
-    return ap_.get();
-  }
-  const Active_points_2_table* active_points_2_table_handle() const {
-    return ap_.get();
-  }
-
-  typedef My_st_types::Instantaneous_kernel Instantaneous_kernel;
-  Instantaneous_kernel instantaneous_kernel_object() const
-  {
-    return Instantaneous_kernel(ap_, static_kernel_object());
-  }
-protected:
-  Active_points_2_table::Handle ap_;
-};
-\end{ccExampleCode}
-
-Now the simulation traits can be used by a kinetic data structure.

Kinetic_data_structures/doc_tex/Kinetic_data_structures/architecture.tex

@@ -1,364 +0,0 @@
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Architecture}
-\label{sec:architecture}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-As we have already mentioned, one of the major goals of our package is
-to support the development of new kinetic data structures. Below we
-discuss in detail each one of the first four major concepts which help
-in implementing kinetic data structures: the \ccc{Kinetic::Simulator},
-the Kinetic::Kernel, the \ccc{Kinetic::ActiveObjectsTable} and the
-\ccc{Kinetic::InstantaneousKernel}.  The \ccc{Kinetic::FunctionKernel}
-concept is discussed separately in Section \ref{algebraic_kernel}.
-
-\subsection{The Kinetic::Simulator}
-\label{simulator}
-
-The \ccc{Kinetic::Simulator} is the central repository of all active events.
-It maintains the event queue and can use its knowledge of the events
-in the queue to find times for the kinetic data structures to easily
-check their own correctness (this will be discussed in more detail
-later in this section). Kinetic data structures call methods of the
-\ccc{Kinetic::Simulator} to schedule new events, deschedule old ones and
-access and change data contained in already scheduled events (the
-operations on existing events are performed using a key which was
-returned when the event was scheduled).  For controlling the
-simulation, methods in the \ccc{Kinetic::Simulator} allow stepping through
-events, advancing time and even running the simulation backwards (that
-is we run the simulation with the time running in the opposite
-direction).
-
-The kinetic sorting example in Figure~\ref{sec:sort_example} shows the
-basic usage of the \ccc{Kinetic::Simulator}. First, the \ccc{Simulator}
-is created by the \ccc{Kinetic::SimulatorTraits}. The kinetic data structure
-gets a handle to the simulator from the traits class and uses the
-handle to add its events to the simulation. The \ccc{Kinetic::Simulator} is
-then told to advance time up until the end of the simulation,
-processing all events along the way.
-
-Each event is represented by a \ccc{Kinetic::Simulator::Time} and an instance of a
-model of the \ccc{Kinetic::Simulator::Event} concept.  Models of the \ccc{Kinetic::Simulator::Event}
-concept are responsible for taking the appropriate action in order to
-handle the kinetic event they represent.  Specifically, the
-\ccc{Kinetic::Simulator::Event} concept specifies one method,
-\ccc{Kinetic::Simulator::Event::process()}, that is called when the event occurs.
-The body of the \ccc{Kinetic::Simulator::Event::process()} method typically
-simply calls a method of the kinetic data structure that created the
-event; for example in our kinetic sorting example, processing an event
-means calling the \ccc{Kinetic::Sort<Traits, Visitor>::swap(Iterator)}
-method of the kinetic sorting data structure.
-
-In the model of the \ccc{Kinetic::Simulator} concept that we provide, any
-model of the \ccc{Kinetic::Simulator::Event} concept can be inserted as an event. This
-ability implies that events can be mixed at run time, which is
-essential when we want to support multiple kinetic data structures
-operating on the same set of moving geometric primitives.
-
-The \ccc{Kinetic::Simulator::Time} concept is defined by the simulator, typically to be
-some representation of a root of a polynomial, taken from the
-\ccc{Kinetic::FunctionKernel} (details of the algebraic side of the package
-will be discussed in Section~\ref{algebraic_kernel}). For most
-kinetic data structures \ccc{Kinetic::Simulator::Time} only needs to support
-comparisons (we need to compare events, in order to process them in
-the correct order) and a few other non-arithmetic operations.
-
-When the failure times of certificates are sorted exactly (as opposed
-to when we numerically approximate the roots of the certificate
-polynomials) the correctness of kinetic data structures can be easily
-verified.  Let $I$ be an open interval between the last event
-processed and the next event to be processed.  As was mentioned in the
-introduction kinetic data structures do not change combinatorially in
-$I$. In addition, although the static data structures can be
-degenerate at the roots defining the two ends of the interval, they
-are not, in general, degenerate in the interior. An independent check
-of the integrity of kinetic data structures can be provided by, for
-example, using an \ccc{Kinetic::InstantaneousKernel} (cf. Subsection
-\ref{instantaneous_kernel}) to rebuild the static version of the
-structure from scratch at some time interior to $I$ and compare it to
-the kinetic version. This auditing can typically catch algorithmic or
-programming errors much closer to the time they arise in the
-simulation than, for example, using visual inspection.  Such easy
-auditing is one of the powerful advantages of having an exact
-computational framework since, as with static data structures, when
-using inexact computations differentiating between errors of
-implementation and numeric errors is quite tricky.
-
-Kinetic data structures receive alerts of appropriate times to audit
-themselves using a notification framework. The same framework is also
-used by the \ccc{Kinetic::ActiveObjectsTable} to alert kinetic data
-structures when the set of primitives changes (see
-Subsection~\ref{active_objects_table}). To use the notification
-framework, the kinetic data structure creates a proxy object which
-implements a standard \ccc{Listener} interface. It then registers this
-proxy with the \ccc{Kinetic::Simulator}. When the
-\ccc{Kinetic::Simulator} finds an appropriate time for the kinetic
-data structures to audit themselves it calls the function
-\ccc{Listener::new_notification(Type)} on each of the registered proxy
-objects.  A helper for creating such proxy objects, called
-\ccc{Kinetic::Simulator_kds_listener<Listener, KDS>}, is provided by the
-framework. It translates the notification into a function call
-(\ccc{audit()}) on the kinetic data structure.  Pointers in the
-notification framework are reference counted appropriately to avoid
-issues caused by the creation and destruction order of kinetic data
-structures and the simulator. See Section~\ref{listener} for a more
-complete discussion of this part of the framework.
-
-Internally the \ccc{Kinetic::Simulator} maintains a priority queue
-containing the scheduled events. The type of the priority queue is a
-template argument to our \ccc{Kinetic::Simulator} model and, as such, it can
-be replaced by the user.  In our package, we provide two different
-types of priority queues, a heap and a two-list priority queue.  A
-two-list queue is a queue in which there is a sorted front list,
-containing all events before some time and an unsorted back list. The
-queue tries to maintain a small number of elements in the front list,
-leaving most of them in the unsorted main pool. The two-list queue,
-although an unconventional choice, is our default queue when using
-exact computation because it minimizes comparisons involving events
-that are far in the future.  These events are likely to be deleted
-before they are processed, so extra work done structuring them is
-wasted.  Our experiments have shown that, for example, the two-list
-queue causes a 20\% reduction in running time relative to a binary
-heap for Delaunay triangulations with degree 3 polynomial motions and
-20 points.
-
-
-
-\subsection{The Kinetic::Kernel}
-
-The \ccc{Kinetic::Kernel} is structured very much like static CGAL
-kernels. It defines a number of primitives, which in the model
-provided are \ccc{Kinetic::Kernel::Point_1},
-\ccc{Kinetic::Kernel::Point_2}, \ccc{Kinetic::Kernel::Point_3} and
-\ccc{Kinetic::Kernel::Weighted_point_3}. The primitives are defined by
-a set of Cartesian coordinates each of which is a function of time, a
-\ccc{Kernel::MotionFunction}. In addition it defines constructions
-and certificate generators which act on the primitives.  The
-certificate generators are the direct analog of the non-kinetic
-predicates. Each certificate generator take a number of primitives as
-arguments, but instead of producing an element from a discrete set
-they produce a set of discrete failure times for the certificate.
-These failure times are wrapped in a model of \ccc{Kinetic::Certificate}.
-
-A \ccc{Kinetic::Certificate} is a simple object whose primary function is to
-produce a \ccc{Kinetic::Simulator::Time} object representing the failure time of the
-certificate.  Since, the handling of most certificate failures
-involves creating a new certificate whose certificate function is the
-negation of the old certificate function, a \ccc{Kinetic::Certificate}
-object caches any work that could be useful to isolate future roots of
-the certificate function (such as the Sturm sequence of the
-certificate function). To illustrate this further, if you have two
-one-dimensional points with coordinate functions $p_0(t)$ and
-$p_1(t)$, the certificate that the first moving point is after the
-second corresponds to the inequality $p_0(t) - p_1(t) > 0$.  When the
-certificate fails and the two points cross, the new certificate is
-$p_1(t)- p_0(t) > 0$, which is the negated version of the certificate
-just processed and which has the same roots.
-
-The model of \ccc{Kinetic::Kernel} provided includes the certificate
-generators necessary for Delaunay triangulations (in one, two and
-three dimensions) and regular triangulations (in 3D).  New
-certificates can be fairly easily added. An example is included in the
-distributed code.
-
-
-
-\subsection{The Kinetic::ActiveObjectsTable}
-\label{active_objects_table}
-
-The \ccc{Kinetic::ActiveObjectsTable} stores a set of kinetic primitives.
-Its purpose is to notify kinetic data structures when new primitives
-are added, when primitives are removed or when a trajectories change.
-Each primitive is uniquely identified by a Key, assigned by
-the table when the primitive is added, that can be used to change or
-remove it.  We provide one model of the
-\ccc{Kinetic::ActiveObjectsTable} concept, called
-\ccc{Kinetic::Active_objects_vector<MovingObject>} which stores all the moving
-primitives in an \ccc{std::vector<D>}.
-
-Notifications of changes to the set of active objects are handled
-using a setup similar to the \ccc{Kinetic::Simulator} audit time
-notification. We provide a helper class,
-\ccc{Kinetic::Active_objects_listener_helper<ActiveObjectsTable,
-KDS>}, which translates the notifications into \ccc{insert(Key)},
-\ccc{erase(Key)} or \ccc{set(Key)} function calls on the kinetic data
-structure.
-
-
-
-\subsection{The Kinetic::InstantaneousKernel}
-\label{instantaneous_kernel}
-
-The \ccc{Kinetic::InstantaneousKernel} allows existing CGAL data structures
-to be used on moving data as it appears at some instant of time.
-Models of this concept are, by definition, models of a CGAL
-Kernel or a traits class, and, therefore, can then be used as
-the traits class of CGAL's algorithms and data structures.
-
-Consider for example the kinetic Delaunay data structure in either two
-or three dimensions.  Internally, it uses a
-\ccc{Delaunay_triangulation_2<Traits, Tds>} or
-\ccc{Delaunay_triangulation_3<Traits, Tds>} to represent the
-triangulation, instantiated with a model of the
-\ccc{Kinetic::InstantaneousKernel} concept as its traits class.  At
-initialization, as well as at times during the simulation when we want
-to insert a point to the kinetic Delaunay triangulation, a static
-version of the Delaunay triangulation is conceptually instantiated.
-More precisely, the time for the copy of the model of the
-\ccc{Kinetic::InstantaneousKernel} stored in the CGAL triangulation is set
-to be the current time (or rather, as discussed in the introduction, a
-more convenient time determined by the \ccc{Kinetic::Simulator}
-combinatorially equivalent to the current time).  The kinetic data
-structure then calls the
-\ccc{Delaunay_triangulation_3<Traits, Tds>::insert(Point)} insert
-method to insert the point.  The static insert method called uses
-various predicate functors on the moving points which evaluate to the
-values that the predicates have at that instant in time. Removal is
-handled in an analogous manner. Auditing of the geometric structure is
-easily handled in a similar manner (in the case of Delaunay
-triangulations by simply calling the \ccc{verify()} method after
-setting the time).
-
-Internally, in order to evaluate a static predicate, our model of the
-\ccc{Kinetic::InstantaneousKernel} computes the current instantaneous
-coordinates of the involved primitives and then passes them to a
-static predicate. The static primitive coordinates are cached since
-they are likely to be involved in other static predicates evaluated at
-the same time.
-
-
-Note that the time used in the \ccc{Kinetic::InstantaneousKernel} must
-be an arithmetic type that fully supports ring and possibly field
-operations.  These are much more stringent requirements than for
-\ccc{Kinetic::Simulator::Time} objects in the simulator, where we only require
-comparisons. These requirements currently rule out our algebraic
-kernels' \ccc{Root} objects (see Section \ref{algebraic_kernel}),
-since they only support comparisons and some limited arithmetic
-operations. In practice this is not a strong limitation since we can
-almost always find a time that is representable by a rational number
-type (such as \ccc{Gmpq}) which is close to the current time and such
-that the combinatorial structure has not changed. Alternatively, if a
-real number type such as \ccc{CORE::Expr} is used for time, then
-computation can, of course, be performed at any time, although
-computations will be significantly slower.  It is the job of the
-\ccc{Kinetic::Simulator} to determine an appropriate time to perform
-operations.
-
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsection{Miscellaneous: notification and reference management.}
-\label{sec:misc}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-We describe some coding conventions used, graphical display,
-notification and reference management support in the framework in the
-following sections.
-
-
-\subsubsection{Reference management}
-
-A number of objects need to maintain pointers to other independent
-objects. For example, each kinetic data structure must have access to
-the \ccc{Kinetic::Simulator} so that it can schedule and deschedule
-events. These pointers are all reference counted in order to guarantee
-that they are always valid. We provide a standard reference counting
-pointer and object base to facilitate this, namely
-\ccc{Ref_counted<Object>}.
-
-Each shared object in the framework defines a type \ccc{Handle} which is the
-type for a reference counter pointer pointing to it. These should be
-used for storing pointers to the objects in order to avoid dangling
-pointers. In addition, many of the objects expect such pointers as
-arguments.
-
-\subsubsection{Runtime event passing}
-\label{listener}
-
-Runtime events must be passed from \textit{notifiers}, namely the
-\ccc{Kinetic::ActiveObjectsTable} and the \ccc{Kinetic::Simulator} to
-\textit{listeners}, typically the kinetic data structures. For
-example, kinetic data structures are notified when new primitives are
-added to the \ccc{Kinetic::ActiveObjectsTable}. On reciving the
-notification, it will add the new primitive to the combinatorial
-structure it is maintaining. The events are passed using a simple,
-standardized notification interface. To receive notifications, the
-listener first defines a small proxy class which inherits from a
-\ccc{Listener} base type provided by the notifier. On creation, the
-\ccc{Listener} base class registers itself with the notifier on
-construction (and unregisters itself on destruction).
-
-When the some state of the notifier changes, it calls the
-\ccc{new_notification} method on the listener proxy object provided
-and passes it a label corresponding to the name of the field that
-changed. The proxy object can then call an appropriate method on the
-kinetic data structure or whetever the listening class is.
-
-In order to unregister on destruction, the \ccc{Listener} must store a
-(reference counted) pointer to the object providing notifications.
-This pointer can be accessed through the \ccc{notifier()} field. The
-\ccc{Listener} object stores a reference counted pointer to the
-notifying object, while the notifying object stores a plain pointer to
-the \ccc{Listener}. It can do this since the \ccc{Listener} is
-guaranteed to unregister itself when it is destroyed. This avoids
-circular reference counted pointers as well as dangling pointers.
-
-\section{Algebraic Kernel}
-\label{algebraic_kernel}
-
-The interface between the algebraic kernel and the kinetic data
-structures package was kept quite minimal in order to ease the
-implementation of various underlying computation models. The interface
-is detailed in the reference page (\ccc{Kinetic::FunctionKernel}).
-
-We provide models of the algebraic kernel that handle polynomial
-\ccc{Kinetic::Function} objects. The provided models perform
-\begin{itemize}
-\item exact computations using Sturm sequences to isolate roots
-\item exact computations using Descartes rule of sign in order to
-  isolate roots (Sturm sequences are also used in order to properly
-  handle even multiplicity roots)
-\item filtered exact computations using Descartes rule of sign
-\item numeric (inexact) root approximations
-\item numeric root approximations which take advantage of certain
-  assumptions that can be made about the types of polynomials solved
-  in the process of evaluating kinetic data structures
-\item a wrapper for CORE::Expr which implements the required
-  concepts.
-\end{itemize}
-The exact models, which we implement the numerics for, handle
-non-square-free polynomials and polynomials with arbitrary field
-number type coefficients and are quite robust.
-
-
-\subsection{Kinetic::FunctionKernel customized for kinetic data structures}
-
-There are several modifications we can make to how the roots are
-handled to optimize for the case of kinetic data structures.  The
-first are motivated by the question of how to handle degeneracies
-(certificate functions which have roots at the same time).  Naively,
-there is no way to differentiate between a certificate which fails
-immediately when it is created and one whose function is momentarily
-0, but will be valid immediately in the future. In order to handle
-such degeneracies we ensure that all the certificate function
-generators produce certificate functions which are positive when the
-corresponding certificates are valid.  Then, if we have a degeneracy
-we can differentiate between a certificate which fails immediately and
-one which is simply degenerate by looking at the sign of the
-certificate function immediately following the root (equivalently, by
-looking at the derivative). In addition, this allows us, under the
-assumption that computations are performed exactly, to check that all
-certificates are not invalid upon creation.
-
-The assumption that certificates are positive when valid is particular
-useful when using numeric solvers.  Without it there is no reliable
-way to tell whether a root near the current time is the certificate
-having become valid just before the current time, or failing shortly
-in the future. Testing the sign of the function immediately after the
-root reliably disambiguates the two cases.
-
-In addition, we have to specially handle even roots of functions. For
-the most part these can just be discarded as dropping an even root is
-equivalent to perturbing the simulation to remove the degeneracy.
-However, when we are using the \ccc{Kinetic::Simulator} to audit the
-kinetic data structures, they most be broken up in to two, equal,
-roots to avoid auditing at the degeneracy.

Kinetic_data_structures/doc_tex/Kinetic_data_structures/comments.tex

@@ -1,173 +0,0 @@
-\section{Comments}
-
-
-The package is rather complex,
-
-
-\subsection{User Manual}
-
-
-define_exact_kds and define_numeric_kds are more than strange.
-\textit{I agree. On the other hand, due to the complexity of things, I
-think something along those lines is needed (otherwise there are 9
-#includes and 10 typedefs which need to be added to every
-file). Perhaps a header which defines a "Exact_simulator" or
-"Numeric_simulation" class which simply defines the types as defined
-in the headers.}
-
-
-
-
-
-
-Section 1.3.1
-
-The two ways to use KDS  "as fast as possible", and "Alternatively"
-are hard to grasp. You might have two examples  insteas of the #ifdefs
-If I understand it right they are very different in nature. The one
-with GUI has a notion of a a regular beat of time, where snapshots
-are taken and the snapshot gets visualized. Events can even happen
-between the beats. The other mode of usage is only interested in
-events.
-\textit{Separate it into two examples, one explicitly showing the GUI}.
-
-
-Also the example should do more than start the event loop  or
-set current time to infinity.
-\textit{Maybe}
-
-
-
-
-
-The #include section could be shorter.
-There is no need to include Delaunay_triangulation_{vertex,face}_base_2.h
-\textit{I should remove some of the includes.}
-
-You could regroup
-#include <CGAL/Kinetic/Moving_object_table.h>
-#include <CGAL/Kinetic/Moving_object_inserter.h>
-in <CGAL/Kinetic/basic.h> and this one could
-be included by Cartesain_kinetic_kernel.h
-\textit{They aren't really conceptually related and can be used without one another, so I would rather not. Perhaps they can go into the ``Helper headers''. I could also use default arguments for \ccc{Kinetic::Delaunay}_triangulation and skip many of the headers. I had wanted to avoid that, but it could make it less intimidating.}
-
-
-Are "Simulator", "Time", "FunctionKernel" defined in the
-magic header file? Obscure.
-And what about Cartesian_instantaneous_kernel? If it comes
-from CGAL/Kinetic/Cartesian_kinetic_kernel.h, then this
-header file might be called CGAL/Kinetic/Cartesian.h
-with the two types in there.
-\textit{It doesn't come from there, but maybe it could. Strictly speaking it is more of an adaptor, but I could simplify things. }
-
-
-The template arguments of \ccc{Kinetic::Delaunay}_triangulation_2
-do not correspond to the reference manual.
-\textit{Indeed. This should be fixed.}
-
-Would it be possible to have default template arguments which
-make the example shorter?
-\textit{I could, I was trying to avoid default arguments in the example in order to show everything, but I could change that.}
-
-Concerning the trajectories, would it be possible to have CGAL::Vectors
-where the direction of the vector is the direction and its length
-the speed? This would be intuitive.
-\textit{Hmmm, I could write constructors from a point and a vector.}
-
-Also get rid of the random. It saves you one #include ==:>-
-Instead take four points
-p0(0,1) with Vector(0,1)
-p1(1,0) with Vector(0,0) (does not move)
-p2(1,3) with Vector(0,0)
-p3(2,2) with Vector(-1,0)
-\textit{Sure}
-
-Then you can even make screenshots of all events.
-
-Also I would start with a static setting. Why inserting them
-one after the other. Set the stage, switch on the clock
-to keep it simple.
-
-
-p8: "five new events" why five?
-
-p9: Simulator<..,Exact,..>  but the reference manual has no Exact
-
-p11, paragraph3: MovingObjectTable -> Moving_object_table bwecause it is a model.
-
-
-Reference Management  Don't we have that in the support library Handle/Rep
-
-p12: "or other listening class" -> "or other listening objects"
-
-
-p13: POLYNOMIAL -> Polynomial
-
-p14: KDSMoving_object_table -> \ccc{Kinetic::Moving}_object_table
-p14: passingh -> passing, possition -> position, being processs in order -> being processed in order
-
-More Typos
-simplist -> simplest
-classeds -> classes
-reference through -> referenced through
-each of these is created -> each of these are created
-
-
-I skipped the rest of the user manual for the next round of review ==:>-
-
-
-__________________________
-Reference Manual
-
-The same example all over the place ??
-
-_____
-Listener<Interface>
-
-you make define -> you ??? define
-"inherits from the Listener interface??? Do you mean inherits from the template argument
-\ccc{Interface> ?
-
-listner -> listener
-poxy -> proxy
-An notifier -> A notifier
-ref counted -> rfeference counted
-
-
-_____
-Moving_object_table<Object>
-
-Object can easily be confused with CGAL::Obejct
-true -> \ccc{true}
-Object mot[Key key]   Do you return a copy or a reference
-
-mot.editing() -> mot.is_editing()
-
-I suggest to get rid of "_object" in the member function names.
-STL container do not have that either.
-
-_____
-Multi_listener
-
-Is this class obsolete? The fact that it is not in the right namespace
-and not in the right directory seems to indicate that.
-
-
-_____
-Pointer_queue
-
-Why is class Time in a comment?
-
-
-_____
-RootEnumerator
-
-It looks very much like an iterator
-
-\textit{But it is not quite an iterator. It is basically a container
-or stack. We decided not to go for the iterator model since it is
-comparatively heavy. In addition, allowing iterators into the
-RootEnumerator disallows a number of optimizations. We have
-RootContainers if you want iterators.
-
-It is now called RootStack and has appropraitely named methods.}

Kinetic_data_structures/doc_tex/Kinetic_data_structures/delaunay_2_example.tex

@@ -1,130 +0,0 @@
-
-
-\subsection{Visualization of Kinetic Data Structures}
-\label{sec:delaunay_2_example}
-
-The framework includes Qt widgets for displaying kinetic data
-structures in two and three dimensions. The following example shows
-using the two dimensional widget with a Delaunay triangulation:
-
-\begin{ccExampleCode}
-#include <CGAL/Kinetic/Exact_simulation_traits_2.h>
-#include <CGAL/Kinetic/Delaunay_triangulation_2.h>
-#include <CGAL/Kinetic/Enclosing_box_2.h>
-#include <CGAL/Kinetic/IO/Qt_moving_points_2.h>
-#include <CGAL/Kinetic/IO/Qt_triangulation_2.h>
-#include <CGAL/Kinetic/IO/Qt_widget_2.h>
-
-int main(int argc, char *argv[]) {
-    using namespace CGAL::Kinetic;
-    typedef Exact_simulation_traits_2 Traits;
-    typedef Delaunay_triangulation_2<Traits> Del_2;
-    typedef Enclosing_box_2<Traits> Box_2;
-    typedef Qt_widget_2<Traits::Simulator> Qt_widget;
-    typedef Qt_moving_points_2<Traits, Qt_gui> Qt_mps;
-    typedef Qt_triangulation_2<Del_2, Qt_widget, Qt_mps> Qt_dt2;
-    
-    // create a simulation traits and add two KDSs:
-    // a kinetic Delaunay triangulation and an enclosing box;
-    // the moving points bounce against the walls of the enclosing box
-    Traits tr;
-    Box_2::Handle box = new Box_2(tr);
-    Del_2::Handle kdel = new Del_2(tr);
-
-    // register the simulator, set of moving points and
-    // Delaunay triangulation with the kinetic Qt widget
-    Qt_widget::Handle qt_w = new Qt_widget(argc, argv, tr.simulator_handle());
-    Qt_mps::Handle qt_mps = new Qt_mps(qt_w, tr);
-    Qt_dt2::Handle qt_dt2 = new Qt_dt2(kdel, qt_w, qt_mps);
-
-    // read the trajectories of the moving points
-    //  the simulation traits automatically inserts them in the two KDSs
-    // and schedules the appropriate kinetic events; as in the kinetic
-    // sorting example this is done with appropriate notifications
-    std::ifstream in("data/points_2");    
-    in  >> *tr.active_points_2_table_handle();
-
-    // run the interactive kinetic simulation
-    return qt_w->begin_event_loop();
-};
-\end{ccExampleCode}
-
-The example shows how to use a number of additional features of the
-framework. First, it shows that two kinetic data structures
-(\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation>} and
-\ccc{Kinetic::Enclosing_box_2<Traits>}) can coexist on the same set of
-points without any extra effort. Both interact with the moving points
-through the active objects table, and never need to directly interact
-with one another. Second, objects (like
-\texttt{qt\_w}, \texttt{qt\_mps} and \texttt{qt\_dt2}) are all stored
-by using reference counted handles (\texttt{Object::Handle}). This
-allows them to share references to one another without the user having
-to worry about memory management and order of deletion.  For example,
-the \ccc{Kinetic::Qt_triangulation_2<KineticDelaunay_2, QtWidget_2,
-Qt_moving_points_2>} object needs a handle to the kinetic
-triangulation, in order to get the structure to display, and a handle
-to the \ccc{Active_points_1_table} to get the coordinates of the
-points.
-
-
-Finally, the example shows how to use the graphical interface elements
-provided, see Figure~\ref{qtwidget_capture}. Our package includes
-\texttt{Qt} widgets for displaying kinetic geometry in two and three
-dimensions. In addition to being able to play and pause the
-simulation, the user can step through events one at a time and reverse
-the simulation to retrace what had happened. The three-dimensional
-visualization support is based on the Coin library http://www.coin3d.org.
-
-\begin{figure*}[htb]
-\begin{ccTexOnly}
-\begin{center}
-1.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_0} 
-2.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_1}
-3.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_2}\\
-4.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_3}
-5.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_4}
-6.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_5}\\
-7.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_6}
-8.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_7}
-9.\includegraphics[ scale=.2]{Kinetic_data_structures/delaunay_8}
-\end{center}
-\end{ccTexOnly}
-%width=300 height=300
-\begin{ccHtmlOnly}
-
-<img border=1 src="./delaunay_0.gif" align=center alt="Frame 0" >
-<img border=1 src="./delaunay_1.gif" align=center alt="Frame 1" >
-<img border=1 src="./delaunay_2.gif" align=center alt="Frame 2" >
-<img border=1 src="./delaunay_3.gif" align=center alt="Frame 3" >
-<img border=1 src="./delaunay_4.gif" align=center alt="Frame 4" >
-<img border=1 src="./delaunay_5.gif" align=center alt="Frame 5" >
-<img border=1 src="./delaunay_6.gif" align=center alt="Frame 6" >
-<img border=1 src="./delaunay_7.gif" align=center alt="Frame 7" >
-<img border=1 src="./delaunay_8.gif" align=center alt="Frame 8" >
-<br>
-\end{ccHtmlOnly}
-\caption{ \label{fig:delaunay_events} 
-{\em Some events from a Delaunay triangulation kinetic data
-structure:} The state of the two dimensional Delaunay triangulation
-immediately following the first events is shown. Green edges are ones
-which were just created. The pictures are screen shots from
-demo/Kinetic\_data\_structures/Delaunay\_triangulation\_2.C. }
-%\end{minipage}
-%\end{center}
-\end{figure*}
-
-
-\begin{figure}
-\begin{ccTexOnly}
-\begin{center}
-\includegraphics[scale=.5]{Kinetic_data_structures/qt_widget_marked_pct}
-\end{center}
-\end{ccTexOnly}
-\begin{ccHtmlOnly}
-<img src="./qt_widget_marked_pct.gif" align=center alt="Qt widget"> <br>
-\end{ccHtmlOnly}
-\caption{\label{qtwidget_capture} The figure shows the graphical user interface for
-  controlling two-dimensional kinetic data structures. It is built on
-  top of the \ccc{Qt_widget} and adds buttons to play, pause, step
-  through and run the simulation backwards.}
-\end{figure}

Kinetic_data_structures/doc_tex/Kinetic_data_structures/main.tex

@@ -1,175 +0,0 @@
-
-\ccUserChapter{Kinetic Data Structures}
-\label{chapter-kds}
-\ccChapterAuthor{Daniel Russel}
-
-\input{Kinetic_data_structures/PkgDescription}
-
-\minitoc
-
-
-\ccDefGlobalScope{CGAL::}
-
-\def\note#1{$\langle\langle${\bf #1}$\rangle\rangle$}
-%\message{Remove note before final version!}
-%\def{\th}{^{\rm th}}
-
-% space tweaks
-%\addtolength{\parskip}{-1pt}
-
-%\input{Kinetic_data_structures/todo.tex}
-
-Lets say you want to maintain a sorted list of items (each item is
-associate with a real number key). You can imagine placing each of the
-items on the point on the real line corresponding to its key. Now, let
-the key for each item change continuously (i.e. no jumps are allowed).
-As long as no to (consecutive) items cross, the sorted order is
-intact. When two cross, they need to be exchanged in the list and then
-the sorted order is once again correct. This is a trivial example of a
-kinetic data structure. The key observation is that the combinatorial
-structure which is maintained changes at discrete times (events) even
-though the basic building blocks are changing continuously.
-
-This chapter describes a framework for implementing kinetic data
-structures and sweepline algorithms as well as several kinetic data
-structures implemented on top of this framework. The framework was
-first presented at ALENEX~\cite{cgal:gkr-cfhm-04}. We first, in
-Section~\ref{sec:kds_intro} introduce kinetic data structures and
-sweepline algorithms. This section can be skipped if the reader is
-already familiar with the area. The next sections,
-Section~\ref{sec:kds_terms} and Section~\ref{sec:overview} introduces
-the terms and gives an overview of the framework. They are recommended
-reading for all readers. We then present kinetic data structures for
-Delaunay triangulations in two and three dimensions in
-Section~\ref{sec:provided_kdss}. Following that, in
-Section~\ref{sec:architecture} we discuss the architecture of the
-framework and finally we give several examples of using the framework
-to implement a kinetic data structure in
-Section~\ref{sec:examples}. The framework makes heavy use of our
-\ccc{Polynomial_kernel} package to provide models of the
-\ccc{Kinetic::FunctionKernel} concept.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Kinetic Data Structures and Sweep Algorithms}
-\label{sec:kds_intro}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-
-\subsection{Kinetic Data Structures}
-Kinetic data structures were first introduced in by Basch et.\ al.\ in
-1997~\cite{cgal:bgh-dsmd-97}.  The idea stems from the observation that
-most, if not all, computational geometry structures are built using
-{\em predicates} --- functions on quantities defining the geometric
-input (e.g.\ point coordinates), which return a discrete set of
-values. Many predicates reduce to determining the sign of a polynomial
-on the defining parameters of the primitive objects. For example, to
-test whether a point lies above or below a plane we compute the dot
-product of the point with the normal of the plane and subtract the
-plane's offset along the normal. If the result is positive, the point
-is above the plane, zero on the plane, negative below. The validity of
-many combinatorial structures built on top of geometric primitives can
-be verified by checking a finite number of predicates of the geometric
-primitives.  These predicates, which collectively certify the
-correctness of the structure, are called {\em certificates}.  For a
-Delaunay triangulation in three dimensions, for example, the
-certificates are one \ccc{InCircle} test per facet of the
-triangulation, plus a point plane orientation test for each facet or
-edge of the convex hull.
-
-The kinetic data structures approach is built on top of this view of
-computational geometry. Let the geometric primitives move by replacing
-each of their defining quantities with a function of time (generally a
-polynomial). As time advances, the primitives trace out paths in
-space called {\em trajectories}. The values of the polynomial
-functions of the defining quantities used to evaluate the predicates now
-also become functions of time. We call these functions
-{\em certificate functions}. Typically, a geometric structure is valid when
-all predicates have a specific non-zero sign. In the kinetic setting,
-as long as the certificate functions maintain the correct sign as time varies,
-the corresponding predicates do not change values,
-and the original data structure remains correct. However, if
-one of the certificate functions changes sign, the original structure
-must be updated, as well as the set of certificate functions that
-verify it.  We call such occurrences {\em events}.
-
-Maintaining a kinetic data structure is then a matter of determining
-which certificate function changes sign next, i.e.\ determining which
-certificate function has the first real root that is greater than the
-current time, and then updating the structure and the set of
-certificate functions. In addition, the trajectories of primitives are
-allowed to change at any time, although $C^0$-continuity of the
-trajectories must be maintained.  When a trajectory update occurs for
-a geometric primitive, all certificates involving that primitive must
-be updated.  We call the collection of kinetic data structures,
-primitives, event queue and other support structures a
-{\em simulation}.
-
-Sweepline algorithms for computing arrangements in $d$ dimensions
-easily map on to kinetic data structures by taking one of the
-coordinates of the ambient space as the time variable. The kinetic
-data structure then maintains the arrangement of a set of objects
-defined by the intersection of a hyperplane of dimension $d-1$ with
-the objects whose arrangement is being computed. 
-
-
-Time is one of the central concepts in a kinetic simulation.  Just as
-static geometric data structures divide the continuous space of all
-possible inputs (as defined by sets of coordinates) into a discrete
-set of combinatorial structures, kinetic data structures divide the
-continuous time domain into a set of disjoint intervals. In each
-interval the combinatorial structure does not change, so, in terms of
-the combinatorial structure, all times in the interval are equivalent.
-We capitalize on this equivalence in the framework in order to
-simplify computations. If the primitives move on polynomial
-trajectories and the certificates are polynomials in the coordinates,
-then events occur at real roots of polynomials of time. Real numbers,
-which define the endpoints of the interval, are more expensive to
-compute with than rational numbers, so performing computations at a
-rational number inside the interval is preferable whenever
-possible. See Section~\ref{instantaneous_kernel} for an example of
-where this equivalence is exploited.
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Terms Used}
-\label{sec:kds_terms}
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{description}
-\item[primitive] The basic geometric types--i.e.\ the points of a
-  triangulation. A primitive has a set of {\em coordinates}.
-\item[combinatorial structure] A structure built on top of the
-  primitives. The structure does not depend directly on the
-  coordinates of the primitives, only on relationships between them.
-\item[trajectory] The path traced out by a primitive as time passes.
-  In other words how the coordinates of a primitive change with time.
-\item[snapshot] The position of all the primitives at a particular
-  moment in time.
-\item[static] Having to do with geometric data structures on
-  non-moving primitives.
-\item[predicate] A function which takes the coordinates of several
-  primitives from a snapshot as input and produces one of a discrete
-  set of outputs.
-\item[certificate] One of a set of predicates which, when all having
-  the correct values, ensure that the combinatorial structure is
-  correct.
-\item[certificate function] A function of time which is positive when
-  the corresponding certificate has the correct value. When the
-  certificate function changes sign, the combinatorial structure needs
-  to be updated.
-\item[event] When a certificate function changes sign and the
-  combinatorial structure needs to be updated.
-\end{description}
-
-
-\input{Kinetic_data_structures/overview.tex}
-
-\input{Kinetic_data_structures/provided_kdss.tex}
-
-\input{Kinetic_data_structures/architecture.tex}
-
-\input{Kinetic_data_structures/examples.tex}
-
-
-
-% LocalWords:  Guibas Menelaos CGAL templated Expr KDSs deschedule
-% LocalWords:  Karavelas

Kinetic_data_structures/doc_tex/Kinetic_data_structures/overview.tex

@@ -1,88 +0,0 @@
-\subsection{Overview}
-\label{sec:overview}
-The package is structured around five main concepts. See
-Figure~\ref{uml_usage} for a schematic of how a kinetic data
-structure interacts with the various parts. The main concepts are
- 
-% MK:: why is there a + before less_x_1_object() ?
-% Another thing is that I am not really sure that we really want this
-% figure to appear here. I prefer to have it at the end as it was before.
-% I leave it up to you to decide this.
-\begin{figure}
-\begin{ccTexOnly}
-\begin{center}
-\includegraphics[scale=.8,viewport=0 18 470 250, clip]{Kinetic_data_structures/sort_usage_pct}
-\end{center}
-\end{ccTexOnly}
-\begin{ccHtmlOnly}
-<img src="./sort_usage_pct.gif" align=center alt="Sort Usage"><br>
-\end{ccHtmlOnly}
-\caption{\label{uml_usage} The figure shows the interaction between
-  the \ccc{Kinetic::Sort<Traits, Visitor>} kinetic data structure and
-  the various pieces of our package.  Other, more complicated, kinetic
-  data structures will also use the \ccc{Kinetic::InstantaneousKernel} in order
-  to insert/remove geometric primitives and audit
-  themselves. \ccc{Kinetic::Sort<Traits, Visitor>} uses the sorting
-  functionality in STL instead.}
-\end{figure}
-
-\begin{itemize}
-
-\item the \ccc{Kinetic::Simulator}. Models of this concept process events in
-  the correct order and audit kinetic data structures. There should be
-  one instance of a model of this concept per simulation.
-\item the \ccc{Kinetic::Kernel}. The structure of a
-  \ccc{Kinetic::Kernel} is analogous to the static CGAL (i.e.,
-  non-kinetic) kernels in that it defines a set of primitives and
-  functors which generate certificates from the primitives.
-\item the \ccc{Kinetic::ActiveObjectsTable}. Models of this concept hold a
-  collection of kinetic primitives in a centralized manner. This
-  structure centralizes management of the primitives in order to
-  properly disseminate notifications when trajectories change, new
-  primitives are added or primitives are deleted.
-  There is generally one instance of a model of this concept per simulation.
-\item the \ccc{Kinetic::InstantaneousKernel}. Models of this concept allow
-  existing non-kinetic CGAL data structures to be used on a snapshot
-  of kinetic data. As a result, pre-existing static structures can be
-  used to initialize and audit kinetic data structures.
-\item the \ccc{Kinetic::FunctionKernel}. This concept is the computational
-  kernel of our framework.  Models of this concept are responsible for
-  representing, generating and manipulating the motional and
-  certificate functions and their roots. It is this concept that
-  provides the kinetic data structures framework with the necessary
-  algebraic operations for manipulating event times. The
-  \ccc{Kinetic::FunctionKernel} is discussed in detail in Section
-  \ref{algebraic_kernel}.
-\end{itemize}
-
-For simplicity, we added an additional concept, that of
-\ccc{Kinetic::SimulationTraits}, which wraps together a particular set of
-choices for the above concepts and is responsible for creating
-instances of each of the models. The addition of this concept reduces
-the choices the user has to make to picking the dimension of the
-ambient space and choosing between exact and inexact computations. The
-model of \ccc{Kinetic::SimulationTraits} creates an instance each of the
-\ccc{Kinetic::Simulator} and \ccc{Kinetic::ActiveObjectsTable}. Handles for
-these instances as well as instances of the \ccc{Kinetic::Kernel}
-and \ccc{Kinetic::InstantaneousKernel} can be requested from the simulation
-traits class. Both the \ccc{Kinetic::Kernel} and the
-\ccc{Kinetic::Simulator} use the \ccc{Kinetic::FunctionKernel}, the former to find
-certificate failure times and the later to operate on them. For
-technical reasons, each supplied model of \ccc{Kinetic::SimulationTraits} also
-picks out a particular type of kinetic primitive which will be used by
-the kinetic data structures.
-
-
-% Both the \object{KineticKernel}
-%and the \object{Simulator} query the \object{FunctionKernel} for
-%constructing certificate functions, as well as getting their failure
-%times.
-
-Surrounding these central set of concepts, there are a large number of
-smaller concepts, the models of which act either as glue between
-objects or as helper classes.  The key smaller concepts will be described along
-with the appropriate central concepts in the corresponding subsections
-of Section \ref{sec:architecture}.
-
-
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures/provided_kdss.tex

@@ -1,31 +0,0 @@
-\section{Provided Kinetic Data Structures}
-\label{sec:provided_kdss}
-
-Along with the framework, we provide several already implemented kinetic data structures. They currently are 
-\begin{description}
-\item[\ccc{Kinetic::Sort<Traits, Visitor>}] maintain a list of points
-sorted by x-coordinate.
-\item[\ccc{Kinetic::Delaunay_triangulation_2<Traits, Visitor,
-    Triangulation>}] maintain the Delaunay triangulation of a set of
-  two dimensional points
-\item[\ccc{Kinetic::Delaunay_triangulation_3<Traits,Visitor,
-    Triangulation>}] maintain the Delaunay triangulation of a set of
-  three dimensional points.
-\item[\ccc{Kinetic::Regular_triangulation_3<Traits, Visitor,
-Triangulation>}] maintain the regular triangulation of a set of waiting
-three dimensional points.
-\item[\ccc{Kinetic::Enclosing_box_2<Traits>},
-  \ccc{Kinetic::Enclosing_box_3<Traits>}] restrict points to stay
-  within a box by bouncing them off the walls.
-\end{description}
-
-
-\input{Kinetic_data_structures/sort_example.tex}
-
-\input{Kinetic_data_structures/delaunay_2_example.tex}
-
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: t
-%%% End: 

Kinetic_data_structures/doc_tex/Kinetic_data_structures/sort_example.tex

@@ -1,42 +0,0 @@
-\subsection{Using a provided kinetic data structure}
-\label{sec:sort_example}
-
-Using a kinetic data structure can be as simple as the following:
-\label{fig:sort_program}
-\ccIncludeExampleCode{Kinetic_data_structures/sort.C}
-
-In the example, first the \ccc{Kinetic::SimulationTraits} object is chosen
-(in this case one that supports exact computations). Then the kinetic
-data structure is defined using the chosen traits object and a
-visitor class which logs changes to the sorted list.  Next, instances
-of the two are created and a set of points is read from a file. Then,
-the simulator is instructed to process all the events until the end of
-the simulation.  Finally, a record of what happened is printed to the
-terminal.
-
-Several important things happen behind the scenes in this example.
-First, the \ccc{Kinetic::ActiveObjectsTable} which holds the moving
-points notifies the kinetic data structure that new points have been
-added to the simulation. Second, the
-\ccc{Kinetic::Sort<Traits,Visitor>} kinetic data structure registers
-its events with the \ccc{Kinetic::Simulator} by providing a time and a
-proxy object for each event. When a particular event occurs, the
-\ccc{Kinetic::Simulator} calls a function on the proxy object which in turn
-updates the kinetic data structure.
-
-The example illustrates how to monitor the supplied data structures as
-they evolve by using a \ccc{Kinetic::SortVisitor} object---a small class whose
-methods are called whenever the kinetic data structure changes. Hooks
-for such visitor concepts are provided for all of the shipped kinetic
-data structures. In the case of kinetic sorting, the visitor's
-methods are called every time a new point is inserted in the sorted
-list, when one is removed, or when two points are swapped in the
-sorted order. 
-
-
-The visitor concept is quite powerful, allowing us, for example, to
-implement a data structure for computing and storing two-dimensional
-arrangements of $x$-monotone curves on top of the
-\ccc{Kinetic::Sort<Traits, Visitor>} data structure using about 60
-lines of code. This sweepline code is presented in
-Section~\ref{sec:sweepline_example}.

Kinetic_data_structures/doc_tex/Kinetic_data_structures/sweepline_usage_example.tex

@@ -1,117 +0,0 @@
-
-
-\subsection{A Sweepline Algorithm}
-\label{sec:sweepline_example}
-
-Here we present a simple example that uses the kinetic data structures
-framework to implement a sweepline to compute the arrangement of
-x-monotone algebraic curves in the plane. The example builds on top of
-the \ccc{Kinetic::Sort<Traits, Visitor>} kinetic data structure, using a visitor
-to keep track of changes to the sorted order and newly inserted
-points. To see an example using this kinetic data structure read the
-example at examples/Kinetic\_data\_structures/sweepline.C.
-
-First we define the visitor class. An object of this type is passed to
-the \ccc{Kinetic::Sort} data structure and turns events into calls on
-the arrangement structure. This class has to be handled externally
-since the arrangement will inherit from the sorting structure.
-
-\begin{ccExampleCode}
-template <class Arrangement>
-struct Arrangement_visitor: public Kinetic::Sort_visitor_base
-{
-  Arrangement_visitor(Arrangement *a):p_(a){}
-  template <class Vertex_handle>
-  void remove_vertex(Vertex_handle a) {
-    p_->erase(a);
-  }
-  template <class Vertex_handle>
-  void create_vertex(Vertex_handle a) {
-    p_->insert(a);
-  }
-  template <class Vertex_handle>
-  void after_swap(Vertex_handle a, Vertex_handle b) {
-    p_->swap(a, b);
-  }
-  Arrangement *p_;
-};
-
-\end{ccExampleCode}
-
-Now we define the actual kinetic data structure. 
-
-\begin{ccExampleCode}
-
-template <class TraitsT> 
-class Planar_arrangement: 
-  public Kinetic::Sort<TraitsT, 
-		       Arrangement_visitor<Planar_arrangement<TraitsT> > > {
-  typedef TraitsT Traits;
-  typedef Planar_arrangement<TraitsT> This;
-  typedef typename Kinetic::Sort<TraitsT,
-				 Arrangement_visitor<This> > Sort;
-  typedef Arrangement_visitor<This> Visitor;
-  typedef typename Traits::Active_objects_table::Key Key;
-
-public:
-  typedef CGAL::Exact_predicates_inexact_constructions_kernel::Point_2 Approximate_point;
-  typedef std::pair<int,int> Edge;
-  typedef typename Sort::Vertex_handle Vertex_handle; 
-
-  // Register this KDS with the MovingObjectTable and the Simulator
-  Planar_arrangement(Traits tr): Sort(tr, Visitor(this)) {}
-
-  Approximate_point vertex(int i) const
-  {
-    return approx_coords_[i];
-  }
-
-  size_t vertices_size() const
-  {
-    return approx_coords_.size();
-  }
-
-  typedef std::vector<Edge >::const_iterator Edges_iterator;
-  Edges_iterator edges_begin() const
-  {
-    return edges_.begin();
-  }
-  Edges_iterator edges_end() const
-  {
-    return edges_.end();
-  }
-
-  void insert(Vertex_handle k) {
-    last_points_[*k]=new_point(*k);
-  }
-
-  void swap(Vertex_handle a, Vertex_handle b) {
-    int swap_point= new_point(*a);
-    edges_.push_back(Edge(swap_point, last_points_[*a]));
-    edges_.push_back(Edge(swap_point, last_points_[*b]));
-    last_points_[*a]= swap_point;
-    last_points_[*b]= swap_point;
-  }
-
-  void erase(Vertex_handle a) {
-    edges_.push_back(Edge(last_points_[*a], new_point(*a)));
-  }
-
-  int new_point(typename Traits::Active_objects_table::Key k) {
-    double tv= CGAL::to_double(Sort::traits().simulator_handle()->current_time());
-    double dv= CGAL::to_double(Sort::traits().active_objects_table_handle()->at(k).x()(tv));
-    approx_coords_.push_back(Approximate_point(tv, dv));
-    return approx_coords_.size()-1;
-  }
-
-  std::vector<Approximate_point > approx_coords_;
-  std::map<Key, int> last_points_;
-  std::vector<Edge> edges_;
-
-};
-\end{ccExampleCode}
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: t
-%%% End: 

Kinetic_data_structures/doc_tex/Kinetic_data_structures/todo.tex

@@ -1,46 +0,0 @@
-\section{Todo}
-
-\subsection{General thoughts}
-
-\begin{itemize}
-
-\item add reference pages for traits
-
-\item implemented a shared version of polynomials-- copying them all around for the roots is quite expensive
-
-\item current\_time\_nt() instead of rational
-
-\item add motion vector arrows to \ccc{moving_points_2}
-
-\item reread manual
-
-\item restructure examples to illustrate separate parts (listener for example).
-
-\item there might be a bug in Simple\_interval\_root due to its use of
-  \ccc{approximate_interval_width} (which uses doubles and so might never
-
-\item there might be a bug in \ccc{Simple_interval_root} due to its use of
-  \ccc{approximate_interval_width} (which uses doubles and so might never
-  get small enough).
-
-\item The other trajectory modification events need to be documented
-  (Set\_moving\_point). 
-
-\item There is no 2d regular triangulation. This is not too much work,
-  but a bit (since I will need to refactor my 2d delaunay)
-
-\item the FunctionKernel is not documented much (the options are never
-  explained)
-
-\item The FunctionKernel numeric solver I implemented is not as good
-  as the one provided by GSL which is shipped on most linux boxes. It
-  is GPL, so the user does have to make a decision about using it.
-  Currently, there is a traits class that the user can select if they
-  want to use it (at the cost of reassembling the SimulationTraits).
-
-\end{itemize}
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: t
-%%% End: 

Kinetic_data_structures/doc_tex/Kinetic_data_structures/trivial_kds_example.tex

@@ -1,250 +0,0 @@
-
-\subsection{Implementing a Trivial Kinetic Data Structure}
-\label{sec:trivial_kds_example}
-
-
-We will first explain in detail how a typical kinetic data structure
-uses the various pieces of the framework, then move on to showing the
-actual code for a simpler data structure.
-
-\subsection{Using the Pieces of the Package}
-
-Here we will explain how the kinetic sorting data structure uses the
-various pieces of the package. A schematic of its relationship to the
-various components is shown in the UML diagram in
-Figure~\ref{uml_usage}. In this subsection we abuse, for reasons of
-simplicity of presentation, the concept/model semantics: when we refer
-to concepts we actually refer to an instance of a model of them.
-
-As with most kinetic data structures, \ccc{Kinetic::Sort<Traits,
-  Visitor>} maintains some sort of combinatorial structure (in this
-case a sorted doubly linked list), each element of which has a
-corresponding certificate in the event queue maintained by the
-simulator. In the case of sorting, there is one certificate maintained
-for each ``edge'' between two consecutive elements in the list.
-
-On creation, the data structure is passed a copy of the
-\ccc{Kinetic::SimulationTraits} for this simulation, which it saves for
-future use. It gets a handle to to the
-\ccc{Kinetic::ActiveObjectsTable} by calling the
-\ccc{Kinetic::SimulationTraits::active_points_1_table_handle()}
-method and registers a proxy with the table in order to receive
-notifications of changes to the point set.  The
-\ccc{Kinetic::SimulationTraits} method returns a handle to, rather
-than a copy of, the \ccc{Kinetic::ActiveObjectsTable}, since the table must
-be shared between all the kinetic data structures using these points.
-The handles are reference counted pointers, thus saving the user from
-worrying about cleaning things up properly.
-
-When new points are added to the model of the
-\ccc{Kinetic::ActiveObjectsTable}, the table calls the
-\ccc{new_notification()} method on the proxy of the kinetic data
-structure, which in turn calls the \ccc{insert(Point_key)} method of
-the kinetic data structure. The \ccc{Point_key} here is the key which
-uniquely identifies the newly inserted point in the table. The data
-structure then requests an instance of a model of the
-\ccc{Kinetic::InstantaneousKernel} from the
-\ccc{Kinetic::SimulationTraits}.  It sets the time on the
-instantaneous kernel to the time value gotten from the
-\ccc{Kinetic::Simulator::current_time_nt()} method. This method
-returns a field number type that is between the previous and next
-event, as discussed in the introduction. An instance of the
-\ccc{Kinetic::InstantaneousKernel::Less_x_1} predicate and the STL
-function \ccc{std::upper_bound()} are then used to insert the new
-point in the sorted list. For each inserted object, the kinetic data
-structure removes the no longer relevant certificate from the event
-queue by calling the \ccc{Kinetic::Simulator::delete_event(Key)}
-function and creates two new certificates using a
-\ccc{Kinetic::Kernel::Is_less_x_1} certificate functor. The new
-certificates are inserted in the event queue by calling the
-\ccc{Kinetic::Simulator::new_event(Time, Event)} method where
-\ccc{Kinetic::Simulator::Event} is a proxy object which instructs the sort
-kinetic data structure to swap two points when its \ccc{process()}
-method is called.
-
-Now that the kinetic data structure has been initialized, the
-simulator is instructed to process all events. Each time an event
-occurs, the simulator calls the \ccc{process()} method on the
-corresponding proxy object. The proxy, in turn, tells the sort kinetic
-data structure to swap the two points whose order has changed.
-
-The \ccc{Kinetic::Simulator} can periodically instruct the kinetic data
-structures to audit themselves.  As is explained in
-Section~\ref{simulator}, a proxy object maps the notification on to an
-\ccc{audit()} function call in the kinetic data structure. To audit
-itself the kinetic data structure builds a list of all the current
-points and uses \ccc{std::sort} to sort this list using a
-comparison function gotten from the \ccc{Kinetic::InstantaneousKernel}.
-This sorted list is compared to the maintained one to verify
-correctness. This auditing could also have been done by evaluating the
-\ccc{Kinetic::InstantaneousKernel} predicate for each sorted pair.  Since
-auditing a kinetic data structure typically requires at least linear
-time in the size of the combinatorial structure, the auditing
-procedure in between events is deactivated by default.  The user can
-however easily switch it on by defining the
-\ccc{CGAL_CHECK_EXACTNESS} and \ccc{CGAL_CHECK_EXPENSIVE} CGAL
-macros.
-
-This general structure of the interaction between the kinetic data
-structure and the framework is shared by all of the provided kinetic
-data structures and has proved itself to go quite far.
-
-\subsection{The trivial kinetic data structure}
-
-To show how to implement such things, instead of presenting a full
-kinetic data structure, we present a trivial one which maintains one
-event in the queue which maintains one event in the queue, scheduled
-to occur one time unit after the last change was made to the set of
-active primitives.  Two classes are defined, the \ccc{Trivial_event},
-and the \ccc{Trivial_kds}. The event classes must be declared outside
-of the kinetic data structure so that the \ccc{operator<<} can be
-defined for them.
-
-The kinetic data structure maintains the invariant that it was one
-event in the queue at all times. This event ccurs one time unit after
-the last event or change in the set of objects occurs. As a result,
-the kinetic data structure has the main parts of a real one--it
-responds to changes in trajectories of the objects and certificate
-failures (when the event expires).
-
- The public methods can be grouped into three sets which are shared
- with almost all other kinetic data structures:
-\begin{itemize}
-\item \ccc{has_certificates} and \ccc{set_has_certificates} which
-  checks/sets whether the kinetic data structure is currently
-  maintaining certificates.
-\item \ccc{insert}, \ccc{set}, \ccc{erase} which are called by the
-  \ccc{Kinetic::Active_objects_listener_helper} in response to the
-  addition, modification, or deletion of an object to, in or from the
-  simulation.
-\item \ccc{audit} which is called periodically by the
-  \ccc{Kinetic::Simulator_kds_listener} when kinetic data structures can
-  easily audit themselves.
-\end{itemize} 
-
-In addition, it has one method which is called when a certificate
-fails. The name/existence of such methods depend on the nature of the
-kinetic data structure in question.
-
-Like many kinetic data structures, it takes a \ccc{Kinetic::SimulationTraits}
-as a template argument. This traits class defines the types needed for
-the simulation and is responsible for instantiating them.
-
- \label{fig:trivial_usage_program}
-
-\begin{ccExampleCode}
-#include <CGAL/Kinetic/Ref_counted.h>
-#include <CGAL/Kinetic/Exact_simulation_traits_1.h>
-#include <CGAL/Kinetic/Active_objects_listener_helper.h>
-#include <CGAL/Kinetic/Simulator_kds_listener.h>
-...
-
-// This must be external since operator<< has to be defined
-template <class KDS>
-struct Trivial_event
-{
-  Trivial_event(){}
-  Trivial_event(KDS* kds): kds_(kds) {
-  }
-  void process() const
-  {
-    kds_->process();
-  }
-  KDS* kds_;
-};
-
-template <class KDS>
-std::ostream &operator<<(std::ostream &out,
-			 const Trivial_event<KDS> &) {
-  out << "\"An event\"";
-  return out;
-}
-
-
-template <class Traits>
-struct Trivial_kds: CGAL::Kinetic::Ref_counted<Trivial_kds<Traits> >
-{
-  typedef Trivial_kds<Traits> This;
-  typedef typename Traits::Active_points_1_table::Data Point;
-  typedef typename Traits::Simulator::Time Time;
-  typedef typename Traits::Active_objects_table::Key Point_key;
-  typedef typename Traits::Simulator::Event_key Event_key;
-  typedef CGAL::Kinetic::Active_objects_listener_helper<
-    typename Traits::Active_points_1_table::Listener, This> Active_objects_helper;
-  typedef CGAL::Kinetic::Simulator_kds_listener<
-    typename Traits::Simulator::Listener, This> Simulator_helper;
-
-  typedef Trivial_event<This> Event;
-
-  Trivial_kds(Traits tr): has_certificates_(true),
-			  tr_(tr),
-			  nth_(tr.active_points_1_table_handle(), this),
-			  sh_(tr.simulator_handle(), this){}
-
-  // this method is called with the value true when the event is processed
-  void process(bool tf) {
-     event_= Event_key();
-     set_has_certificates(false);
-     set_has_certificates(true);
-  }
-
-  void audit() const
-  {
-     ...
-  }
-
-  void set_has_certificates(bool tf) {
-    typename Traits::Simulator::Handle sp= tr_.simulator_handle();
-    if (has_certificates_ != tf) {
-      has_certificates_=tf;
-      if (has_certificates_) {
-	bool ev= event_;
-	CGAL_assertion(!ev);
-	Time t= CGAL::to_interval(sp->current_time()).second+1;
-	event_= sp->new_event(t, Event(this));
-      } else if (event_) {
-	sp->delete_event(event_);
-	event_=Event_key();
-      }
-    }
-  }
-
-  bool has_certificates() const {
-    return has_certificates_;
-  }
-
-  void insert(Point_key k) {
-    if (has_certificates_) {
-      set_has_certificates(false);
-      set_has_certificates(true);
-    }
-  }
-
-  void set(Point_key k) {
-    if (has_certificates_) {
-      set_has_certificates(false);
-      set_has_certificates(true);
-    }
-  }
-
-  void erase(Point_key k) {
-    if (has_certificates_) {
-      set_has_certificates(false);
-      set_has_certificates(true);
-    }
-  }
-
-  ~Trivial_kds(){
-     set_has_certificates(false);
-  }
-
-protected:
-  bool has_certificates_;
-  Event_key event_;
-  Traits tr_;
-  Active_objects_helper nth_;
-  Simulator_helper sh_;
-};
-
-\end{ccExampleCode}
-%../../examples/Kinetic_data_structures/ % LocalWords: CGAL

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/ActiveObjectsTable.tex

@@ -1,112 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Moving_object_table.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSMovingobjecttableRev}{$Id$}
-\RCSdefDate{\RCSMovingobjecttableDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::ActiveObjectsTable}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-
-This container holds a set of objects of a particular type. It creates
-notifications using the standard \ccc{Multi_listener<Interface>}
-interface when a primitive changes or is added or deleted. Objects
-which are listening for events can then ask which primitives changed.
-
-For speed, modifications to the \ccRefName\ can be grouped into
-editing sessions. A session is begun by calling
-\ccc{set_is_editing(true)} and ended by calling \ccc{set_is_editing(false)}.
-There is one type of notification, namely, \ccc{Listener::IS_EDITING}
-which occurs when the editing mode is set to false, signaling that a
-batch of changes is completed.
-
-As an convenience, the change methods can be called without setting
-the editing state to true, this acts as if it were set to true for
-that one function call.
-
-\ccTypes
-
-\ccNestedType{Key}{A key identifying an object in the table.}
-
-\ccNestedType{Data}{The type being stored in the table.}
-
-\ccNestedType{Listener}{The base class to derive from for listening for runtime events.}
-
-The following types are iterators. Each type, \ccc{Foo_iterator} has
-two corresponding methods \ccc{foo_begin} and \ccc{foo_end} which
-allow you to iterate through the objects in the set \ccc{Foo}.
-
-\ccNestedType{Keys_iterator}{An iterator through all the valid keys in the table.}
-
-\ccNestedType{Set_iterator}{An iterator through all the objects which have been changed in the last editing session.}
-
-\ccNestedType{Inserted_iterator}{An iterator through all the objects which were added in the last editing session.}
-
-\ccNestedType{Erased_iterator}{An iterator through all the objects which were deleted in the last editing session.}
-
-\ccCreation
-\ccCreationVariable{mot}  %% choose variable name
-
-\ccOperations
-
-\ccMethod{Data operator[](Key key) const;}{Access the object referenced by the key.}
-
-\ccMethod{Data at(Key key) const;}{Access the object referenced by the key.}
-
-\ccMethod{void set_is_editing(bool is_editing);}{Set the editing state of
-  the object. A notification is sent when the editing state is set to
-  false after it has been true, i.e. the editing session is finished.
-  This allows changes to be batched together.}
-
-\ccMethod{bool is_editing() const;}{Access the editing state.}
-
-\ccMethod{void set(Key key, Data object);}{This method changes
-  the motion of one moving object.  The position at the current time
-  should not be different from the previous current position. However,
-  at the moment I do not check this as there is no reference to time
-  in the \ccRefName.  If \ccc{is_editing()} is not true, then it is as
-  if the calls \ccc{set_is_editing(true)}, \ccc{set(key, value)} and
-  finally \ccc{set_is_editing(false)} were made. If it is true, then
-  no notifications are created.}
-
-  \ccMethod{Key insert_object(Data ob);}{Insert a new object into the
-    table and return a \ccc{Key} which can be used to refer to it. See
-    \ccc{set(Key, Data)} for a description of editing modes.}
-
-
- \ccMethod{void erase(Key key);}{ Delete an object from the table. The
-   object with Key key must already be in the table. This does not
-   necessarily decrease the amount of storage used at all. In fact, it
-   is unlikely to do so.  See \ccc{set(Key,Data)} for an explainating
-   of how the editing modes are used.  }
-
-\ccMethod{void clear();}{Remove all objects from the table and free all storage.}
-
-\ccHasModels
-
-\ccc{Kinetic::Active_objects_vector<MovingObject>}
-
-\ccSeeAlso
-
-\ccc{Multi_listener<Interface>},
-\ccc{Kinetic::Active_objects_listener_helper<ActiveObjectsTable, KDS>}
-
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Active_objects_listener_helper.tex

@@ -1,42 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Moving_object_table_listener_helper.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSMovingobjecttablelistenerhelperRev}{$Id$}
-\RCSdefDate{\RCSMovingobjecttablelistenerhelperDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Active_objects_listener_helper<ActiveObjectsTable, KDS>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ acts as an intermediate between a moving object
-table and a KDS. It translates the
-\ccc{ActiveObjectsTable::Listener::IS_EDITING} notification events into
-appropriate calls to \ccc{Kinetic::insert}, \ccc{Kinetic::set},
-\ccc{Kinetic::erase}.
-
-\ccInclude{CGAL/Kinetic/Active_objects_listener_helper.h}
-
-
-\ccSeeAlso
-
-\ccc{Kinetic::Active_objects_vector<MovingObject>},
-\ccc{Kinetic::ActiveObjectsTable}.
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Active_objects_vector.tex

@@ -1,42 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Moving_object_table.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSMovingobjecttableRev}{$Id$}
-\RCSdefDate{\RCSMovingobjecttableDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Active_objects_vector<MovingObject>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-
-MovingObjects are stored in a vector. This means that access is constant
-time, but storage is not generally freed. The only way to be sure is
-to remove all reference counts for the table or to call \ccc{clear()}.
-
-
-\ccInclude{CGAL/Kinetic/Active_objects_vector.h}
-
-\ccIsModel
-
-\ccc{Kinetic::ActiveObjectsTable}
-
-
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Cartesian_instantaneous_kernel.tex

@@ -1,44 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Cartesian_instantaneous_kernel.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSCartesianinstantaneouskernelRev}{$Id$}
-\RCSdefDate{\RCSCartesianinstantaneouskernelDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Cartesian_instantaneous_kernel<ActiveObjectsTable, StaticKernel>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This class provides a model of the \ccc{Kinetic::InstantaneousKernel} for
-use with general Cartesian Geometry. It provides all the predicates
-needed for Delaunay triangulations and regular triangulations.
-
-For technical reasons, the user must pick out one particular type of
-primitive to use when instantiating a model. For example, if the user
-passes a model of \ccc{Kinetic::Active_objects_vector<Data, Object>} with a
-\ccc{Kinetic::Kernel::Point_2} as the kinetic primitive, then the type
-\ccc{Point_2} will be properly defined and the predicates on it will
-work properly, but the other predicates will not work.
-
-\ccInclude{CGAL/Kinetic/Cartesian_instantaneous_kernel.h}
-
-\ccIsModel
-
-\ccc{Kinetic::InstantaneousKernel}
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Cartesian_kinetic_kernel.tex

@@ -1,76 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Cartesian_kinetic_kernel.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSCartesiankinetickernelRev}{$Id$}
-\RCSdefDate{\RCSCartesiankinetickernelDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Cartesian_kinetic_kernel<FunctionKernel>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This class provides a model of \ccc{Kinetic::Kernel} for use with general Cartesian geometry.
-
-\ccInclude{CGAL/Kinetic/Cartesian_kinetic_kernel.h}
-
-\ccTypes
-
-\ccNestedType{Certificate}{This is a model of \ccc{Kinetic::Certificate}.}
-
-\ccNestedType{Point_1}{}
-
-\ccNestedType{Point_2}{}
-
-\ccNestedType{Point_3}{}
-
-\ccNestedType{Weighted_point_3}{}
-
-The following are functors which generate \ccc{Certificate} objects. Each has a corresponding \ccc{_object} method which creates the functor.
-
-\ccNestedType{Positive_orientation_2}{}
-
-\ccNestedType{Positive_orientation_3}{}
-
-\ccNestedType{Positive_side_of_oriented_circle_2}{}
-
-\ccNestedType{Positive_side_of_oriented_sphere_3}{}
-
-\ccNestedType{Power_test_3}{}
-
-\ccNestedType{Weighted_positive_orientation_3}{}
-
-\ccNestedType{Is_less_x_1}{}
-
-\ccNestedType{Is_less_x_2}{}
-
-\ccNestedType{Is_less_y_2}{}
-
-\ccNestedType{Is_less_x_3}{}
-
-\ccNestedType{Is_less_y_3}{}
-
-\ccNestedType{Is_less_z_3}{}
-
-
-
-\ccIsModel
-
-\ccc{Kinetic::Kernel}.
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Certificate.tex

@@ -1,45 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id: Event.tex 28517 2006-02-14 23:14:42Z drussel $}
-\RCSdefDate{\RCSEventDate}{$Date: 2006-02-14 15:14:42 -0800 (Tue, 14 Feb 2006) $}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::Certificate}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccClassName\ represents certificate. Its main purpose is
-to provide a way of creating \ccc{Time} objects corresponding to when
-the certificate fails and to cache any useful work done in find the
-\ccc{Time} for later.
-
-\ccOperations
-
-\ccCreationVariable{c}
-
-\ccMethod{Time failure_time();}{Returns the next failure time.}
-
-\ccMethod{void pop_failure_time();}{Advances to the next failure time (the next root of the certificate functions).}
-
-
-\ccSeeAlso
-
-\ccc{Kinetic::Kernel}.
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/ConstructFunction.tex

@@ -1,55 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id: Event.tex 28517 2006-02-14 23:14:42Z drussel $}
-\RCSdefDate{\RCSEventDate}{$Date: 2006-02-14 15:14:42 -0800 (Tue, 14 Feb 2006) $}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-\ccDefGlobalScope{CGAL::}
-\begin{ccRefConcept}[Kinetic::FunctionKernel::]{ConstructFunction}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccClassName\ is used to construct functions. 
-
-\ccCreationVariable{a}  %% choose variable name
-
-\ccOperations
-
-\ccMethod{Function operator()(NT a, ...);} {This family of methods
-  takes a list of coefficients and returns a function. There can be
-  any number of coeffients passed as arguments (up to about 25 in the
-  current implementations).}
-
-\ccSeeAlso
-
-\ccc{FunctionKernel}
-
-\ccExample
-
-\begin{ccExampleCode}
-Function_kernel fk;
-Function_kernel::Construct_function cf= fk.construct_function_object();
-Function_kernel::Function f= cf(0,1,2,3,4,5);
-\end{ccExampleCode}
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: t
-%%% End: 

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/DelaunayTriangulationVisitor_2.tex

@@ -1,49 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunayTriangulationVisitorRev}{$Id$}
-\RCSdefDate{\RCSDelaunayTriangulationVisitorDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-\begin{ccRefConcept}{Kinetic::DelaunayTriangulationVisitor2}
-
-\ccDefinition
-
-This concept is for proxy objects which get notified when a kinetic Delaunay triangulation changes.
-
-\ccCreationVariable{v}
-
-\ccOperations
-
-\ccMethod{void remove_vertex(Vertex_handle);}{The vertex is about to be deleted.}
-
-\ccMethod{void create_vertex(Vertex_handle);}{The vertex was just created.}
-
-\ccMethod{void modify_vertex(Vertex_handle);}{The trajectory of the point at the vertex changed.}
-
-\ccMethod{template <class It> void create_faces(It begin, It
-  end);}{New faces have just been made. The \ccc{value_type} of the
-  iterator is a \ccc{TriangulationDataStructure_2::Face_handle}.}
- 
-\ccMethod{template <class It> void remove_faces(It, It);}{The faces in
-  the range are about to be deleted.  The \ccc{value_type} of the
-  iterator is a \ccc{TriangulationDataStructure_2::Face_handle}.}
-
-\ccMethod{void before_flip(Edge);}{The edge is about to be flipped.}
-
-\ccMethod{void after_flip(Edge);}{The edge was just created with a flip.}
-
-
-\ccHasModels 
-
-\ccc{Kinetic::Delaunay_triangulation_visitor_base_2},
-\ccc{Kinetic::Delaunay_triangulation_recent_edges_visitor_2<Triangulation>},
-\ccc{Kinetic::Delaunay_triangulation_event_log_visitor_2}
-
-\end{ccRefConcept}
-
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/DelaunayTriangulationVisitor_3.tex

@@ -1,47 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunayTriangulationVisitorRev}{$Id$}
-\RCSdefDate{\RCSDelaunayTriangulationVisitorDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-\begin{ccRefConcept}{Kinetic::DelaunayTriangulationVisitor3}
-
-\ccDefinition
-
-This concept is for proxy objects which get notified when a kinetic Delaunay triangulation changes.
-
-\ccCreationVariable{v}
-
-\ccOperations
-
-\ccMethod{void remove_vertex(Vertex_handle);}{The vertex is about to be deleted.}
-
-\ccMethod{void create_vertex(Vertex_handle);}{The vertex was just created.}
-
-\ccMethod{void modify_vertex(Vertex_handle);}{The trajectory of the point at the vertex changed.}
-
-\ccMethod{template <class It>  void create_cells(It begin, It end);}{New faces have just been made. The iterator \ccc{value_type} is a \ccc{TriangulationDataStructure_3::Cell_handle}.}
- 
-\ccMethod{template <class It> void remove_cells(It, It);}{The faces in the range are about to be deleted.  The \ccc{value_type} of the iterator is a \ccc{TriangulationDataStructure_3::Cell_handle}.}
-
-\ccMethod{void before_edge_flip(Edge);}{The edge is about to be flipped.}
-
-\ccMethod{void after_edge_flip(Facet);}{The facet was just created with a flip.}
-
-\ccMethod{void before_facet_flip(Facet);}{The facet is about to be flipped.}
-
-\ccMethod{void after_facet_flip(Edge);}{The edge was just created with a flip.}
-
-
-\ccHasModels 
-
-\ccc{Kinetic::Delaunay_triangulation_visitor_base_3}, \ccc{Kinetic::Delaunay_triangulation_recent_edges_visitor_3<Triangulation>}, \ccc{Kinetic::Delaunay_triangulation_event_log_visitor_3}
-
-\end{ccRefConcept}
-
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_2.tex

@@ -1,84 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author Daniel Russel
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_2<Traits, Visitor, Triangulation>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ maintains a Delaunay triangulation on top of the
-points contained in a \ccc{Kinetic::ActiveObjectsTable}. It has one
-main method of interest, \ccc{triangulation()}, which returns the
-triangulation it is maintaining.
-
-The class \ccc{Kinetic::Qt_triangulation_2<KineticTriangulation_2,
-  QtWidget_2, QtMovingPoints_2>} displays a kinetic Delaunay
-triangulation using the Qt widget.
-
-This class is a good example of a simple, but non-trivial, kinetic
-data structure.
-
-The \ccc{Triangulation} template parameter must be a model of
-\ccc{CGAL::Delaunay_triangulation_2<Traits, Tds>} which uses
-\ccc{Traits::Instantaneous_kernel} as its geometric traits and a
-\ccc{Tds} whose face inherits from
-\ccc{Kinetic::Delaunay_triangulation_face_base_2<Traits, Base>}.
-
-The optional \ccc{Visitor} parameter takes a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor2}. Methods on this object will be called
-whenever the triangulation changes.
-
-\ccInclude{CGAL/Kinetic/Delaunay_triangulation_2.h}
-
-\ccIsModel
-
-\ccc{Ref_counted<T>}
-
-
-\ccTypes
-
-\ccNestedType{Triangulation}{The template argument triangulation.}
-
-\ccNestedType{Visitor}{The template argument for the visitor.}
-
-\ccCreation
-\ccCreationVariable{dt}  %% choose variable name
-
-\ccConstructor{Delaunay_triangulation_2(Traits tr);}{Maintain the
-  Delaunay triangulation of the points in
-  \ccc{tr.active_points_2_handle()}.}
-
-\ccOperations
-
-\ccMethod{const Triangulation& triangulation() const;}{Access the triangulation that is maintained. }
-
-\ccMethod{Visitor& visitor();}{Access the visitor. }
-
-\ccSeeAlso
-
-\ccc{Kinetic::DelaunayTriangulationVisitor2},
-\ccc{Kinetic::Delaunay_triangulation_default_visitor_2},
-\ccc{Kinetic::Delaunay_triangulation_recent_edges_visitor_2<Triangulation>},
-\ccc{Kinetic::Delaunay_triangulation_event_log_visitor_2},
-\ccc{Kinetic::Qt_Delaunay_triangulation_2}.
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_3.tex

@@ -1,81 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_3<Traits, Visitor, Triangulation>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ maintains a Delaunay triangulation on top of the
-points contained in a \ccc{Kinetic::ActiveObjectsTable}. It has one main method
-of interest. \ccc{triangulation()} which returns the triangulation it
-is maintaining. In addition, as an optimisation, you can turn on and
-off whether it is currently maintaining its certificates. This allows
-a large number of changes to the underlying points to be made at one
-time without recomputing the certificates each time a single point
-changes.
-
-The class \ccc{Kinetic::Qt_triangulation_3<Traits>}, included as part
-of the demo code, displays a kinetic Delaunay triangulation in three
-dimensions using the Coin library.
-
-The optional \ccc{Visitor} template argument is a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor3} and can be used to monitor
-changes in the kinetic data structure.
-
-The optional \ccc{Triangulation} template argument must be a model of
-a static Delaunay triangulation and have
-\ccc{Kinetic::Delaunay_triangulation_cell_base_3<Traits, Base>} a the cell
-type.
-
-\ccInclude{CGAL/Kinetic/Delaunay_triangulation_3.h}
-
-
-\ccTypes
-
-\ccNestedType{Triangulation}{The template argument.}
-
-\ccNestedType{Visitor}{The template argument.}
-
-\ccCreation
-\ccCreationVariable{dt}  %% choose variable name
-
-\ccConstructor{Delaunay_triangulation_3(Traits tr);}{Maintain the Delaunay triangulation of the points in \ccc{tr.active_points_3_handle()}.}
-
-\ccOperations
-
-\ccMethod{const Triangulation* triangulation();}{Access the triangulation that is maintained. }
-
-\ccMethod{bool has_certificates();}{This method returns true if the \ccRefName\ is currently maintaining certificates for a Delaunay triangulation. }
-
-\ccMethod{void set_has_certificates(bool tf);}{This method allows you to control whether the triangulation is maintaining certificates.}
-
-\ccMethod{Visitor& visitor();}{Access the visitor.}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Regular_triangulation_3<Traits, Triangulation, Visitor>},
-\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation, Visitor}, 
-\ccc{Kinetic::Delaunay_triangulation_visitor_base_3},
-\ccc{Kinetic::Delaunay_triangulation_event_log_visitor_3}.
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_cell_base_3.tex

@@ -1,32 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author Daniel Russel
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_cell_base_3<Traits, Base>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This is the base class for faces used by \ccc{Kinetic::Delaunay_triangulation_3<Traits, Triangulation, Visitor>::Triangulation}.
-
-\ccInclude{CGAL/Kinetic/Delaunay_triangulation_cell_base_3.h}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_event_log_visitor_2.tex

@@ -1,40 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_event_log_visitor_2}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor2} and \ccc{Kinetic::EventLogVisitor} which logs edge flip events.
-
-
-\ccIsModel
-
-\ccc{Kinetic::DelaunayTriangulationVisitor2}, \ccc{Kinetic::EventLogVisitor}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_event_log_visitor_3.tex

@@ -1,40 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_event_log_visitor_3}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor3} and
-\ccc{Kinetic::EventLogVisitor} which logs edge and facet flip events.
-
-\ccIsModel
-
-\ccc{Kinetic::DelaunayTriangulationVisitor3}, \ccc{Kinetic::EventLogVisitor}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Delaunay_triangulation_3<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_face_base_2.tex

@@ -1,37 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author Daniel Russel
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_face_base_2<Traits, Base>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This is the base class for faces used by the triangulation used in
-\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation,
-  Visitor>}.
-
-\ccInclude{CGAL/Kinetic/Delaunay_triangulation_face_base_2.h}
-
-\ccSeeAlso
-
-\ccc{Kinetic:Delaunay_triangulation_2<Traits, Triangulation, Visitor>}
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_recent_edges_visitor_2.tex

@@ -1,55 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_recent_edges_visitor_2<Triangulation>}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor2} which tracks which edges were created in
-the most recent change.
-
-\ccIsModel
-
-\ccc{Kinetic::DelaunayTriangulationVisitor2}
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Delaunay_triangulation_recent_edges_visitor_2();}{default constructor.}
-
-\ccNestedType{iterator}{The iterator through the recently created edges.}
-
-\ccOperations
-
-\ccMethod{iterator begin() const;}{Begin iteration through the recent edges.}
-
-\ccMethod{iterator end() const;}{End iteration through the recent edges.}
-
-\ccMethod{bool contains(Triangulation::Edge) const;}{Returns true if this edge exists in the set.}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_visitor_base_2.tex

@@ -1,45 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_visitor_base_2}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor2}. You can extend this class if you only
-want to implement a few methods from \ccc{Kinetic::DelaunayTriangulationVisitor2}.
-
-\ccIsModel
-
-\ccc{Kinetic::DelaunayTriangulationVisitor2}
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Delaunay_triangulation_visitor_base_2();}{default constructor.}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Delaunay_triangulation_2<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Delaunay_triangulation_visitor_base_3.tex

@@ -1,45 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Delaunay_triangulation_visitor_base_3}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::DelaunayTriangulationVisitor3}. You can extend this class if you only
-want to implement a few methods from \ccc{Kinetic::DelaunayTriangulationVisitor3}.
-
-\ccIsModel
-
-\ccc{Kinetic::DelaunayTriangulationVisitor3}
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Delaunay_triangulation_default_visitor_3();}{default constructor.}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Delaunay_triangulation_3<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Enclosing_box_2.tex

@@ -1,50 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Enclosing_box_2<Traits>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ keeps the points in the simulation inside of a
-box. Whenever the points come close to the wall of the box they bounce off of the wall.
-
-Note that, in general, points hit the wall of the box at times which
-are not easily represented by standard (rational) number types. The
-resulting trajectories would also have non-rational coefficients,
-complicating and slowing the simulation. In order to handle this, the
-\ccRefName\ bounces the points at the nearest easily representable
-time before the point would leave the box.
-
-\ccInclude{CGAL/Kinetic/Enclosing_box_2.h}
-
-\ccTypes
-
-\ccNestedType{NT}{The number type used to represent the walls of the box and perform calculations. Generally this is \ccc{Traits::NT}.}
-
-\ccCreation
-\ccCreationVariable{eb}  %% choose variable name
-
-\ccConstructor{Enclosing_box_2(Traits, NT xmin, NT xmax, NT ymin, NT ymax);}{This constructs a bounding box with the dimensions specified by the last 4 arguments. They are optional and will take the values $\pm$10 if omitted.}
-
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Enclosing_box_3.tex

@@ -1,52 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Enclosing_box_3<Traits>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ keeps the points in the simulation inside of a
-box. Whenever the points come close to the wall of the box they bounce
-off of the wall.
-
-
-Note that, in general, points hit the wall of the box at times which
-are not easily represented by standard (rational) number types. The
-resulting trajectories would also have non-rational coefficients,
-complicating and slowing the simulation. In order to handle this, the
-\ccRefName\ bounces the points at the nearest easily representable
-time before the point would leave the box.
-
-\ccInclude{CGAL/Kinetic/Enclosing_box_3.h}
-
-\ccTypes
-
-\ccNestedType{NT}{The number type used to represent the walls of the box and perform calculations. Generally this is \ccc{Traits::NT}.}
-
-\ccCreation
-\ccCreationVariable{eb}  %% choose variable name
-
-\ccConstructor{Enclosing_box_3(Traits, NT xmin, NT xmax, NT ymin, NT ymax, NT zmin, NT zmax);}{This constructs a bounding box with the dimensions specified by the last 6 arguments. They are optional and will take the values $\pm$10 if omitted.}
-
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Event.tex

@@ -1,75 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-\ccDefGlobalScope{CGAL::}
-\begin{ccRefConcept}[Kinetic::Simulator]{Event}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccClassName\ represents a single event. Models of
-\ccClassName\ should be passed to the \ccc{Kinetic::Simulator} when
-scheduling events which will in turn pass them to the
-\ccc{EventQueue}.
-
-\ccCreationVariable{a}  %% choose variable name
-
-\ccOperations
-
-\ccMethod{void process();}{This method is called when the event
-  occurs. This method will only be called once per time this event is
-  scheduled and the event will be removed from the queue immediately
-  afterwards.}
-
-\ccGlobalFunction{std::ostream& operator<<(std::ostream&, Event);}{Write a text description of the event to a standard stream.}
-
-\ccHasModels
-
-All over the place. 
-
-\ccSeeAlso
-
-\ccc{Kinetic::EventQueue}
-
-\ccExample
-
-All of the kinetic data structures provided have models of
-\ccRefName. Here is the code implementing a swap event from the
-sorting kinetic data structure.
-
-\begin{ccExampleCode}
-template <class Certificate, class Id, class Root_enumerator> 
-class Swap_event {
-public:
-  Swap_event(Id o, typename Sort::Handle sorter, 
-	     const Certificate &s): left_object_(o), 
-                                    sorter_(sorter), 
-                                    s_(s){}
-  void process(){
-    sorter_->swap(left_object_, s_);
-  }
-  Id left_object_; 
-  typename Sort::Handle sorter_; 
-  Certificate s_;
-};
-\end{ccExampleCode}
-
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/EventLogVisitor.tex

@@ -1,40 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunayTriangulationVisitorRev}{$Id$}
-\RCSdefDate{\RCSDelaunayTriangulationVisitorDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-\begin{ccRefConcept}{Kinetic::EventLogVisitor}
-
-\ccDefinition
-
-This concept is for visitors which maintain a text log of events. 
-
-\ccCreationVariable{v}
-
-\ccTypes
-
-\ccNestedType{Event_iterator}{An iterator through strings defining the events that occurred. Each event is represented by a \ccc{std::string}.}
-
-
-\ccOperations
-
-\ccMethod{Event_iterator events_begin();}{Begin iterating through the events.}
-
-\ccMethod{Event_iterator events_end();}{}
-
-
-
-
-\ccHasModels 
-
-\ccc{Kinetic::Delaunay_triangulation_event_log_visitor_3}, \ccc{Kinetic::Delaunay_triangulation_event_log_visitor_2}, \ccc{Kinetic::Regular_trianglation_event_log_visitor_3}, \ccc{Kinetic::Sort_event_log_visitor}
-
-\end{ccRefConcept}
-
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/EventQueue.tex

@@ -1,76 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: EventQueue.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventQueueRev}{$Id$}
-\RCSdefDate{\RCSEventQueueDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::EventQueue}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The for priority queues used by the \ccc{Simulator}. The concept
-basically defines a priority queue which supports deletions and
-changes of items in the queue (but not their priorities). Items in the
-queue must implement the \ccc{Event} concept.
-
-
-\ccTypes
-
-\ccNestedType{Key}{The type used to access items in the queue in order
-  to change or delete them.}
-
-\ccNestedType{Priority}{The priority type for items in the queue. This
-  is typically the same as \ccc{Kinetic::Simulator::Time}}.
-
-\ccCreation
-\ccCreationVariable{q}  %% choose variable name
-
-\ccConstructor{EventQueue(Priority start, Priority end, int
-  size_hint);}{Construct a queue which will start at time start and
-  run until time end.}
-
-\ccOperations
-
-\ccMethod{template <class Event> Key insert(Priority, Event);}{Insert
-  an event into the event queue. A \ccc{Key} which can be used to
-  manipulated the event is returned.}
-
-\ccMethod{void erase(Key);}{Erase an event from the queue.}
-
-\ccMethod{template <class Event> void set(Key, Event);}{Change the data in the event referred to by the key.}
-
-\ccMethod{template <class Event> Event& get(Key) const;}{Access the event referred to by the passed key.}
-
-\ccMethod{Priority priority(Key) const;}{Return the priority of the event.}
-
-\ccMethod{bool empty();}{Return true if the queue is empty.}
-
-\ccMethod{Priority next_priority() const;}{Return the priority of the next event in the queue.}
-
-\ccMethod{void process_next();}{Process the next \ccc{Event} by calling its process method with its \ccc{Priority}.}
-
-\ccMethod{void set_end_priority();}{Set the priority beyond which to ignore events.}
-
-\ccHasModels
-
-\ccc{Kinetic::Two_list_pointer_event_queue<FunctionKernel>},
-\ccc{Kinetic::Heap_pointer_event_queue<FunctionKernel>}.
-
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Function.tex

@@ -1,58 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id: Event.tex 28517 2006-02-14 23:14:42Z drussel $}
-\RCSdefDate{\RCSEventDate}{$Date: 2006-02-14 15:14:42 -0800 (Tue, 14 Feb 2006) $}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-\ccDefGlobalScope{CGAL::}
-\begin{ccRefConcept}[Kinetic::FunctionKernel::]{Function}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccClassName\ represents a function. 
-
-\ccCreationVariable{a}  %% choose variable name
-
-
-\ccTypes
-
-\ccNestedType{NT}{The number type used in describing the function;}
-
-\ccConstructor{Function(NT);}{Construct a constant function from a number.}
-
-
-\ccOperations
-
-\ccMethod{NT operator()(NT);} {Evaluate the function at an \ccc{NT}.}
-
-\ccSeeAlso
-
-\ccc{FunctionKernel},
-\ccc{FunctionKernel::ConstructFunction}
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: t
-%%% End: 
-
-%%% Local Variables: 
-%%% mode: latex
-%%% TeX-master: "ConstructFunction"
-%%% End: 

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/FunctionKernel.tex

@@ -1,184 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: FunctionKernel.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSFunctionKernelRev}{$Id$}
-\RCSdefDate{\RCSFunctionKernelDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::FunctionKernel}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ encapsulates all the methods for representing
-and handing functions. The set is kept deliberately small to easy use
-of new \ccRefName s, but together these operations are sufficient to
-allow the correct processing of events, handling of degeneracies,
-usage of static data structures, run-time error checking as well as
-run-time verification of the correctness of kinetic data structures.
-The computation of a polynomial with the variable negated is used for
-reversing time in kinetic data structures and can be omitted if that
-capability is not needed.
-
-
-\ccTypes
-
-\ccNestedType{Function}{The type of function being handled.}
-
-\ccNestedType{NT}{The basic representational number type.}
-
-\ccNestedType{Root}{A type representing the roots of a \ccc{Function}.}
-
-\ccNestedType{Root_stack}{A model of \ccc{RootStack}. These objects can be created by calling the \ccc{root_stack_object} method with a \ccc{Function} and two (optional) \ccc{Root} objects. The enumerator then enumerates all roots of the function in the open inverval defined by the two root arguments. They optional arguments default to positive and negative infinity. }
-
-\ccNestedType{Root_enumerator_traits}{The traits for the \ccc{Root_enumerator} class.}
-
-Each of the following types has a corresponding \ccc{type_object}
-method (not explicitly documented) which takes a \ccc{Function} as an
-argument.
-
-\ccNestedType{Sign_at}{A functor which returns the sign of a
-  \ccc{Function} at a \ccc{NT} or \ccc{Root}.}
-
-\ccNestedType{Multiplicity}{A functor which returns the multiplicity of roots.}
-
-\ccNestedType{Sign_above}{A functor which returns sign of a function
-  immediately above a root.}
-
-The following type is used to construct functions from a list of
-coefficients. To get an instance use the
-\ccc{construct_function_object()} method.
-
-\ccNestedType{Construct_function}{This functor can be used create
-  instances of \ccc{Function}. See its reference page
-  \ccc{FunctionKernel::ConstructFunction} for more details.}
-
-The following functor likewise have a \ccc{type_object} method, but
-these take arguments other than a \ccc{Function}. The arguments are
-given below.
-
-\ccNestedType{Sign_between_roots}{This functor, creation of which
-  requires two \ccc{Root}s, returns the sign of a passed function
-  between the pair of roots.}
-
-%\ccNestedType{Compare_isolated_roots_in_interval}{This functor, creation of which requires two functions, compares the roots of two functions in an isolating invterval. More specifically, it takes two \ccc{NT}s as an argument. These numbers must isolate a root for each of the functions the functor is constructed with. The functor then returns true if the isolated root of the first function is less than that of the second.}
-
-%\ccNestedType{Quotient}{Compute the quotient of two \ccc{Functions}s.}
-
-%\ccNestedType{Pseudo_quotient}{Compute the pseudo quotient of two \ccc{Functions}s.}
-
-%\ccNestedType{Remainder}{Compute the remainder of one \ccc{Functions} divided by another.}
-
-%\ccNestedType{Are_negations_object}{Return true of the two functions passed are negations of one another.}
-
-%\ccNestedType{Sturm_sequence}{This object evaluates the Sturm sequence of two \ccc{Function}s at a \ccc{NT} value. Construction requires two \ccc{Function}s.}
-
-\ccNestedType{Differentiate}{This functor computes the derivitive of a \ccc{Function}. Construction takes no arguments.}
-
-%\ccNestedType{Sign_Sturm_sequence}{This object evaluates the Sturm sequence of two \ccc{Function}s at a \ccc{NT} value. Construction requires two \ccc{Function}s.}
-
-The following methods do not require any arguments to get the functor and take one \ccc{Function} as a functor argument.
-
-%\ccNestedType{Root_bound_evaluator}{This functor computes a root bound on a passed \ccc{Function}. }
-
-%\ccNestedType{Invert_variable}{Map $f(x)$ to $x^d f(1/x)$.}
-
-\ccNestedType{Negate_variable}{Map $f(x)$ to $f(-x)$.}
-
-%\ccNestedType{Map_rational_interval_to_positive}{}
-
-%\ccNestedType{Rational_translate_zero}{}
-%\ccNestedType{Shift_power}{}
-
-%\ccCreation
-%\ccCreationVariable{fk}  %% choose variable name
-
-%\ccConstructor{FunctionKernel(Root_enumerator_traits tr);}{}
-
-%\ccOperations
-
-%\ccMethod{void foo();}{some member functions}
-
-\ccHasModels
-\ccc{POLYNOMIAL::Kernel<RootStack>}, \ccc{POLYNOMIAL::Filtered_kernel<RootStack>}.
-
-\ccSeeAlso
-
-\ccc{Kinetic::RootEnumerator}.
-
-\ccExample
-
-We provide several models of the concept, which are not documented
-separately. The models of \ccc{Kinetic::SimulationTraits} all choose
-appropriate models.  However, if
-more control is desired, we here provide examples of how to create the
-various supported \ccc{Kinetic::FunctionKernel}.
-
-A Sturm sequence based kernel which supports exact comparisons of roots of polynomials (certificate failure times):
-\begin{ccExampleCode}
-typedef CGAL::POLYNOMIAL::Polynomial<CGAL::Gmpq> Function;
-typedef CGAL::POLYNOMIAL::Sturm_root_stack_traits<Function> Root_stack_traits;
-typedef CGAL::POLYNOMIAL::Sturm_root_stack<Root_stack_traits> Root_stack;
-typedef CGAL::POLYNOMIAL::Kernel<Function, Root_stack> Function_kernel;
-\end{ccExampleCode}
-
-A wrapper for \ccc{CORE::Expr} which implements the necessary
-operations:
-\begin{ccExampleCode}
-typedef CGAL::POLYNOMIAL::CORE_kernel Function_kernel;
-\end{ccExampleCode}
-
-A function kernel which computes approximations to the roots of the polynomials:
-\begin{ccExampleCode}
-typedef CGAL::POLYNOMIAL::Polynomial<double> Function;
-typedef CGAL::POLYNOMIAL::Root_stack_default_traits<Function> Root_stack_traits;
-typedef CGAL::POLYNOMIAL::Numeric_root_stack<Root_stack_traits> Root_stack;
-typedef CGAL::POLYNOMIAL::Kernel<Function, Root_stack> Function_kernel;
-\end{ccExampleCode}
-
-When using the function kernel in kinetic data structures, especially
-one that is in exact, it is useful to wrap the root stack. The wrapper
-checks the sign of the certificate function being solved and uses that
-to handle degenacies. This is done by, for the inexact solvers 
-\begin{ccExampleCode}
-typedef \ccc{Kinetic::Derivitive}_filter_function_kernel<Function_kernel> KDS_function_kernel;
-\end{ccExampleCode}
-and for exact solvers
-\begin{ccExampleCode}
-typedef \ccc{Kinetic::Handle}_degeneracy_function_kernel<Function_kernel> KDS_function_kernel;
-\end{ccExampleCode}
-
-For exact computations, the primary representation for roots is the
-now standard choice of a polynomial with an associated isolating
-interval (and interval containing exactly one distinct root of a
-polynomial) along with whether the root has odd or even multiplicity
-and, if needed, the Sturm sequence of the polynomial. Two intervals
-can be compared by first seeing if the isolating intervals are
-disjoint. If they are, then we know the ordering of the respective
-roots. If not we can subdivide each of the intervals (using the
-endpoints of the other interval) and repeat. In order to avoid
-subdividing endlessly when comparing equal roots, once we subdivide a
-constant number of times, we use the Sturm sequence of $p$ and $p'q$
-(where $p$ and $q$ are the two polynomials and $p'$ is the derivative
-of $p$) to evaluate the sign of the second at the root of the first
-one directly (note that this Sturm sequence is applied to a common
-isolating interval of the roots of interest of both polynomials).
-
-
-
-\end{ccRefConcept}
-
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Insert_event.tex

@@ -1,71 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Moving_object_inserter.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSMovingobjectinserterRev}{$Id$}
-\RCSdefDate{\RCSMovingobjectinserterDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Insert_event<ActiveObjectsTable>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This event inserts a point into the \ccc{ActiveObjectsTable} when it
-is processed.
-
-\ccInclude{CGAL/Kinetic/Insert_event.h}
-
-\ccIsModel
-\ccc{Kinetic::Simulator::Event}
-
-\ccCreation
-\ccCreationVariable{i}  %% choose variable name
-
-\ccConstructor{Insert_event(ActiveObjectsTable::Data o,
-  ActiveObjectsTable::Handle t);}{Insert the object o, into the table
-  t when processed.}
-
-
-\ccSeeAlso
-
-\ccc{Kinetic::ActiveObjectsTable},
-\ccc{Kinetic::Active_objects_vector<MovingObject>}.
-
-\ccExample
-
-\begin{ccExampleCode}
-typedef CGAL::Kinetic::Exact_simulation_traits_2 Simulation_traits;
-typedef Simulation_traits::Kinetic_kernel::Point_2 Moving_point_2;
-typedef CGAL::Kinetic::Insert_event<Simulation_traits::Active_points_2_table> Insert_event;
-typedef CGAL::Kinetic::Delaunay_triangulation_2<Simulation_traits> KDel;
-
-Simulation_traits tr;
-
-KDel kdel(tr);
-
-Moving_point_2 mp(Moving_point_2::NT(0),
-                  Moving_point_2::NT(0));
-tr.simulator_handle()->new_event(Simulation_traits::Simulator::Time(3), 
-                                 Insert_event(mp,
-			                      tr.active_points_2_table_handle()));
-
-\end{ccExampleCode}
-
-
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/InstantaneousKernel.tex

@@ -1,57 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::InstantaneousKernel}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ covers models that act as adaptors allowing
-CGAL static data structures to act on snapshots of kinetic data. It
-typically only supports one type of moving object.
-
-Currently, each model is created for one particular type of kinetic
-primitive. The primitives are identified by
-\ccc{Kinetic::ActiveObjectsTable::Key} objects.
-
-\ccTypes 
-
-\ccNestedType{Time}{The type used to represent the current time. This must be a ring or field type.}
-
-\ccCreationVariable{a}  %% choose variable name
-
-\ccOperations
-
-\ccMethod{Time time();}{Return the current time.}
-
-\ccMethod{void set_time(Time);}{Set the current time to have a certain value. All existing predicates are updated automatically.}
-
-\ccMethod{Static_object to_static(Key);}{Return a static object corresponding to the kinetic object at this instant in time.}
-
-\ccHasModels
-
-\ccc{Kinetic::Cartesian_instantaneous_kernel}
-
-
-
-
-
-\end{ccRefConcept}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Key.tex

@@ -1,50 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Key}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ is a unique identifier for something in some
-sort of table. In general, they can be only created by the table and
-are returned when a appropriate \ccc{new_foo()} method is called on
-the table. There are two classes of values for a \ccRefName, valid and
-invalid. The latter cannot refer to something in a table and must
-evaluate to \ccc{false} when cast to a bool.
-
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Key()}{The default constructor is guaranteed to construct an invalid key (i.e.\ one which is false when cast to a bool.}
-
-\ccOperations
-
-\ccMethod{operator bool() const;}{Casting a \ccRefName\ to a bool returns \ccc{true} if \ccRefName\ is a valid key value.}
-
-\ccGlobalFunction{std::ostream& operator<<(std::ostream&, Event);}{Write a text description of the key to a standard stream.}
-
-\ccHasModels
-
-\ccc{Kinetic::Simulator::Event_key}, \ccc{Kinetic::Active_objects_vector<Object>::Key}.
-
-
-\end{ccRefConcept}
-
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/KineticKernel.tex

@@ -1,62 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: KineticKernel.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSKineticKernelRev}{$Id$}
-\RCSdefDate{\RCSKineticKernelDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefConcept}{Kinetic::Kernel}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ acts as the kinetic analog of a CGAL
-kernel. It provides some set of primitives and predicats acting on
-them.
-
-
-\ccCreationVariable{kk}
-\ccTypes
-
-\ccNestedType{Motion_function}{The type which is used to represent
-  coordinates of moving primitives. It is a model of the concept
-  \ccc{FunctionKernel::Function}. This is the analog of the CGAL
-  kernel \ccc{RT}.}
-
-\ccNestedType{Certificate}{The type representing the results of
-  predicates. See \ccc{Kinetic::Certificate}.}
-
-\ccNestedType{Function_kernel}{The type of the function kernel used.
-  See \ccc{Kinetic::FunctionKernel}.}
-
-\ccOperations
-
-\ccMethod{Function_kernel function_kernel_object() const;}{Gets a copy
-  of the function kernel.}
-
-\ccCreationVariable{a}  %% choose variable name
-
-
-\ccHasModels
-
-\ccc{Kinetic::Cartesian_kinetic_kernel<FunctionKernel>}.
-
-
-
-
-\end{ccRefConcept}
-
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Listener.tex

@@ -1,154 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Listener.tex
-% +------------------------------------------------------------------------+
-% | 21.03.2005   Author
-% | Package: Support
-% | 
-\RCSdef{\RCSListenerRev}{$Id$}
-\RCSdefDate{\RCSListenerDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Listener<Interface>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
- 
-The \ccRefName\ class provides the core of the run time notification
-system used by the kinetic data structures package. In short,
-notifications are handled through proxy objects called listeners. In
-order to listen for notifications from an object, called the notifier,
-you make define a small class called a listener proxy, which inherits
-from the Listener interface defined by the notifier. When constructing
-your listner poxy, you pass a reference counted pointer to the
-notifier, which is used to register the proxy for notifications. When
-a notification occurs, the notifier calls the \ccc{new_notification}
-method on the proxy, passing the type of the notification. The proxy
-stores a reference counted pointer to the notifier, ensuring that
-there are never any dangling pointers in the system.
-
-The class \ccRefName\ provides base class for listener proxy objects.
-A notifier should provide a class which inherits from this base. To
-use this base class, implement a class, here called \ccc{Interface},
-which defines a type \ccc{Interface::Notification_type} and a type
-\ccc{Interface::Notifier_handle}.
-
-The \ccc{Notification_type} is generally an enum with one value for
-each type of notification which can be used.
-
-The \ccc{Notifier_handle} is the type of a (ref counted) pointer to
-the object providing the notifications. The ref counter pointer must
-provide a nested type \ccc{Pointer} which is the type of a raw
-pointer.
-
-The \ccRefName\ maintains a ref counted pointer to the object
-performing notifications. It is registered for notifications on
-construction and unregistered on destruction using the function
-\ccc{set_listener(Listener<Interface>*)} on the object providing the
-notifications. The use of ref counted pointers means that as long as
-the notification object exists, the object providing the notifications
-must exist, ensuring that the object providing the notifications is
-not prematurely destroyed.
-
-These objects cannot be copied since the notifier only support one
-listener. If copying and more than one listener are desired, the
-\ccc{Multi_listener<Interface>} base class should be used instead.
-
-As a side note, Boost provides a similar functionality in the Boost.Signal
-package. However, it is quite a bit more complex (and flexible). This
-complexity add significantly to compile time and (although I did not
-test this directly), I suspect it is much slower at runtime due to the
-overhead of worrying about signal orders and not supporting single
-signals. In addition, it does not get on well with Qt due to
-collisions with the Qt moc keywords.
-
-There is also the TinyTL library which implements signals. As of
-writing it did not have any easy support for making sure all pointers
-are valid, so it did not seem to offer significant code saving over
-writing my own.
-
-\ccInclude{CGAL/Kinetic/Listener.h}
-
-\ccTypes
-
-\ccNestedType{Notifier_handle}{This type is inherited from the \ccc{Interface} template argument. It is a reference counted pointer type for the object providing notifications.}
-
-\ccNestedType{Notification_type}{The type (usually an enum) used to distinguish different types of notifications. This is inherited from the \ccc{Interface} template argument.}
-
-\ccCreation
-\ccCreationVariable{l}  %% choose variable name
-
-\ccConstructor{Listener(Notifier_handle np);}{The \ccRefName\ subscribes to events coming from the notifier and stores a pointer to the notifier.}
-
-\ccOperations
-
-\ccMethod{Notifier_handle notifier();}{Return a pointer to the notifier.}
-
-\ccMethod{virtual void new_notification(Notification_type);}{This method is pure virtual. A class which wishes to receive events must inherit from this class and implement this method. The method will then be called whenever there is a notification.}
-
-\ccSeeAlso
-
-\ccc{Multi_listener<Interface>}.
-
-\ccExample
-
-Here is a simplier class that provides notifications:
-\begin{ccExampleCode}
-struct Notifier: public CGAL::Kinetic::Ref_counted<Notifier>
-{
-public:
-  Notifier(): data_(0), listener_(NULL){}
-
-  struct Listener_interface
-  {
-  public:
-    typedef enum Notification_type {DATA_CHANGED} Notification_type;
-    typedef Notifier::Handle Notifier_handle;
-  };
-
-  typedef CGAL::Kinetic::Listener<Listener_interface> Listener;
-  friend class CGAL::Kinetic::Listener<Listener_interface>;
-  
-  void set_data(int d) {
-    data_=d;
-    if (listener_ != NULL) listener_->new_notification(Listener_interface::DATA_CHANGED);
-  }
-
-protected:
-  void set_listener(Listener *l) {
-    listener_= l;
-  }
-  Listener* listener() const {return listener_;}
-
-  int data_;
-  Listener *listener_;
-};
-\end{ccExampleCode}
-
-Now the listener:
-\begin{ccExampleCode}
-
-struct My_listener: public Notifier::Listener, public CGAL::Kinetic::Ref_counted<My_listener>
-{
-  typedef Notifier::Listener::Notifier_handle PP;
-  My_listener(PP p): P(p){}
-
-  void new_notification(P::Notification_type nt) {
-    ...
-  }
-};
-
-\end{ccExampleCode}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Multi_listener.tex

@@ -1,39 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Multi_listener.tex
-% +------------------------------------------------------------------------+
-% | 21.03.2005   Author
-% | Package: Support
-% | 
-\RCSdef{\RCSMultilistenerRev}{$Id$}
-\RCSdefDate{\RCSMultilistenerDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Multi_listener<Interface>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ implements a base class for listeners where more
-than one listener is allowed to subscribe to a notifier. See
-\ccc{Listener} for full documentation. This uses the function calls
-\ccc{new_listener()} and \ccc{delete_listener()} to register and
-unrester the listener (instead of \ccc{set_listener()}).
-
-\ccInclude{CGAL/Kinetic/Multi_listener.h}
-
-\ccSeeAlso
-
-\ccc{Listener<Interface>}.
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Qt_moving_points_2.tex

@@ -1,46 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Qt_moving_points_2.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSQtmovingpointsRev}{$Id$}
-\RCSdefDate{\RCSQtmovingpointsDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Qt_moving_points_2<Traits, QtWidget_2>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ displays a set of moving points in 2D.
-
-See Section~\ref{sec:delaunay_2_example} for an example using this class. 
-
-\ccInclude{CGAL/Kinetic/IO/Qt_moving_points_2.h}
-
-
-
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Qt_moving_points_2(QtGui::Handle,Traits::Active_points_2_table::Handle);}{default constructor.}
-
-
-\ccSeeAlso
-
-\ccc{Kinetic::Qt_widget_2<Simulator>}.
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Qt_triangulation_2.tex

@@ -1,44 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Qt_gui_2.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSQtguiRev}{$Id$}
-\RCSdefDate{\RCSQtguiDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Qt_triangulation_2<KineticTriangulation_2, QtWidget_2, QtMovingPoints_2>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class draws a triangulation into a \ccc{CGAL::Qt_widget_2}. This class is
-very simple and a good one to look at if you want to see how to draw
-your own two dimensional kinetic data structure.
-
-See Section~\ref{sec:delaunay_2_example} for an example using this class. 
-
-\ccInclude{CGAL/Kinetic/IO/Qt_triangulation_2.h}
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Qt_widget_2(KineticTriangulation_2::Handle,QtWidget_2::Handle,QtMovingPoints_2::Handle);}{Construct the object and make all the connections with the appropriate other objects.}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Qt_widget_2<Simulator>}
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Qt_widget_2.tex

@@ -1,41 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Qt_gui_2.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSQtguiRev}{$Id$}
-\RCSdefDate{\RCSQtguiDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Qt_widget_2<Simulator>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ implements a graphical interface for 2D kinetic data structures.
-
-\ccInclude{CGAL/Kinetic/IO/Qt_widget_2.h}
-
-\ccTypes
-
-\ccNestedType{Listener}{The listener base to listen for when to update the picture. This class includes an extra method \ccc{Qt_widget widget()} which returns the \ccc{Qt_widget} object which can be used for drawing.}
-
-\ccCreation
-\ccCreationVariable{a}  %% choose variable name
-
-\ccConstructor{Qt_widget_2(int argc, char *argv[], Simulator::Handle);}{default constructor.}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Ref_counted.tex

@@ -1,50 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Ref_counted.tex
-% +------------------------------------------------------------------------+
-% | 21.03.2005   Author
-% | Package: Support
-% | 
-\RCSdef{\RCSRefcountedRev}{$Id$}
-\RCSdefDate{\RCSRefcountedDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Ref_counted<T>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ implements a base class for objects which are
-reference counted. To use it simply inherit from \ccRefName\ (passing
-the type to be reference counted as the template argument) and then
-access the object through \ccc{Handle} objects rather than bare C++
-pointers.
-
-\ccInclude{CGAL/Kinetic/Ref_counted.h}
-
-
-\ccTypes
-
-\ccNestedType{Handle}{A reference counted pointer to an Object. }
-\ccNestedType{Const_handle}{A const reference counted pointer to an Object. }
-
-\ccCreation
-\ccCreationVariable{rc}  %% choose variable name
-
-\ccConstructor{Ref_counted();}{default constructor.}
-
-\ccOperations
-
-There are no methods which should be called by users of this class.
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/RegularTriangulationVisitor_3.tex

@@ -1,60 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunayTriangulationVisitorRev}{$Id$}
-\RCSdefDate{\RCSDelaunayTriangulationVisitorDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-\begin{ccRefConcept}{Kinetic::RegularTriangulationVisitor3}
-
-\ccDefinition
-
-This concept is for proxy objects which get notified when a kinetic regular triangulation changes.
-
-\ccCreationVariable{v}
-
-\ccOperations
-
-\ccMethod{void remove_vertex(Vertex_handle);}{The vertex is about to be deleted.}
-
-\ccMethod{void create_vertex(Vertex_handle);}{The vertex was just created.}
-
-\ccMethod{void modify_vertex(Vertex_handle);}{The trajectory of the vertex just changed.}
-
-\ccMethod{template <class It>  void create_cells(It begin, It end);}{New faces have just been made. The iterator \ccc{value_type} is a \ccc{TriangulationDataStructure_3::Cell_handle}.}
- 
-\ccMethod{template <class It> void remove_cells(It, It);}{The faces in the range are about to be deleted.  The \ccc{value_type} of the iterator is a \ccc{TriangulationDataStructure_3::Cell_handle}.}
-
-\ccMethod{void before_edge_flip(Edge);}{The edge is about to be flipped.}
-
-\ccMethod{void after_edge_flip(Facet);}{The facet was just created with a flip.}
-
-\ccMethod{void before_facet_flip(Facet);}{The facet is about to be flipped.}
-
-\ccMethod{void after_facet_flip(Edge);}{The edge was just created with a flip.}
-
-\ccMethod{void pre_move(Key, Cell);}{The point defined by \ccc{Key} is about to move from the cell.}
-
-\ccMethod{void post_move(Key, Cell);}{The point defined by \ccc{Key} just moved to the cell.}
-
-\ccMethod{void pre_push(Key, Cell);}{The point defined by the key is about to be inserted into the cell.}
-
-\ccMethod{void post_push(Vertex_handle);}{The point referred to by the vertex handle was just added to the triangulation, it previously was redundant.}
-
-\ccMethod{void pre_pop(Vertex_handle);}{The vertex is about to be removed from the triangulation since its weight is too small.}
-
-\ccMethod{void post_pop(Key, Cell);}{The point was just removed from the triangulation.}
-
-
-\ccHasModels 
-
-\ccc{Kinetic::Regular_triangulation_visitor_base_3}, 
-\ccc{Kinetic::Regular_triangulation_event_log_visitor_3}
-
-\end{ccRefConcept}
-
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Regular_triangulation_3.tex

@@ -1,49 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Regular_trianglation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSRegulartrianglationRev}{$Id$}
-\RCSdefDate{\RCSRegulartrianglationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Regular_triangulation_3<Traits, Visitor, Triangulation>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ maintains a triangulation of set of moving
-weighted points. Its interface is the same as
-\ccc{Kinetic::Delaunay_triangulation_3<Traits, Visitor, Triangulation>}.
-
-The optional \ccc{Triangulation} template argument must be a model of
-\ccc{CGAL::RegularTriangulation_3} which has
-\ccc{Kinetic::Regular_triangulation_cell_base_3<Traits, Base>} as a
-cell base and
-\ccc{Kinetic::Regular_triangulation_vertex_base_3<Traits, Base>} as a
-vertex base.
-
-\ccInclude{CGAL/Kinetic/Regular_triangulation_3.h}
-
-
-\ccSeeAlso
-\ccc{Kinetic::Delaunay_triangulation_3<Traits, Visitor, Triangulation>}.
-\ccc{Kinetic::RegularTriangulationVisitor3}.
-
-\ccExample
-
-\ccIncludeExampleCode{Kinetic_data_structures/regular_triangulation_3.C}
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Regular_triangulation_cell_base_3.tex

@@ -1,32 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Delaunay_triangulation_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author Daniel Russel
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSDelaunaytriangulationRev}{$Id$}
-\RCSdefDate{\RCSDelaunaytriangulationDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Regular_triangulation_cell_base_3<Traits, Base>}  %% add template arg's if necessary
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-This is the base class for faces used by \ccc{Kinetic::Regular_triangulation_3<Traits, Triangulation, Visitor>}.
-
-\ccInclude{CGAL/Kinetic/Regular_triangulation_cell_base_3.h}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Regular_triangulation_event_log_visitor_3.tex

@@ -1,40 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Event.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSEventRev}{$Id$}
-\RCSdefDate{\RCSEventDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Regular_triangulation_event_log_visitor_3}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[concept]{} %% add further index entries
-
-\ccDefinition
-  
-The concept \ccRefName\ provides a model of
-\ccc{Kinetic::RegularTriangulationVisitor3} and \ccc{EventLogVisitor} which logs edge flip events.
-
-
-\ccIsModel
-
-\ccc{Kinetic::RegularTriangulationVisitor3}, \ccc{Kinetic::EventLogVisitor}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Regular_triangulation_3<Traits, Triangulation, Visitor>}
-
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-

Kinetic_data_structures/doc_tex/Kinetic_data_structures_ref/Regular_triangulation_instantaneous_traits_3.tex

@@ -1,43 +0,0 @@
-% +------------------------------------------------------------------------+
-% | Reference manual page: Regular_trianglation_instantaneous_traits_3.tex
-% +------------------------------------------------------------------------+
-% | 20.03.2005   Author
-% | Package: Kinetic_data_structures
-% | 
-\RCSdef{\RCSRegulartrianglationinstantaneoustraitsRev}{$Id$}
-\RCSdefDate{\RCSRegulartrianglationinstantaneoustraitsDate}{$Date$}
-% |
-%%RefPage: end of header, begin of main body
-% +------------------------------------------------------------------------+
-
-
-\begin{ccRefClass}{Kinetic::Regular_triangulation_instantaneous_traits_3<ActiveObjectsTable, StaticKernel>}
-
-%% \ccHtmlCrossLink{}     %% add further rules for cross referencing links
-%% \ccHtmlIndexC[class]{} %% add further index entries
-
-\ccDefinition
-  
-The class \ccRefName\ is an instantaneous kernel for use with a
-regular triangulation data structure. There is not currently a reason
-for the user to call this directly unless the user wants created their
-own simulation traits as it is included as part of the
-\ccc{Kinetic::Regular_triangulation_exact_simulation_traits_3}.
-
-\ccInclude{CGAL/Kinetic/Regular_triangulation_instantaneous_traits_3.h}
-
-\ccIsModel
-
-\ccc{CGAL::RegularTriangulationTraits\_3}, \ccc{Kinetic::InstantaneousKernel}
-
-\ccSeeAlso
-
-\ccc{Kinetic::Regular_triangulation_3<Traits, Visitor, Triangulation>}.
-
-\end{ccRefClass}
-
-% +------------------------------------------------------------------------+
-%%RefPage: end of main body, begin of footer
-% EOF
-% +------------------------------------------------------------------------+
-