ACS

Algorithms for Complex Shapes

with Certified Numerics and Topology

Prototype implementation of the algebraic kernel

Eric Berberich Michael Hemmer Menelaos Karavelas

Sylvain Pion Monique Teillaud Elias Tsigaridas

ACS Technical Report No.: ACS-TR-121202-01

Part of deliverable: WP-I/D2

Sites: INRIA, MPI, NUA

Month: 12

Project co-funded by the European Commission within FP6 (2002–2006)

under contract nr. IST-006413

Abstract

In this report we describe the current progress with respect to prototype implementations of

algebraic kernels within the ACS project. More specifically, we report on: (1) the CGAL package

Algebraic kernel for circles 2 2 aimed at providing the necessary algebraic functionality

required for treating circular arcs; (2) our experience on implementing algebraic numbers orig-

inally in Maple and later on within the SYNAPS library; (3) the NumeriX library (part of the

EXACUS project) which is a prototype implementation of a set of algebraic tools on univariate

polynomials, needed to built an algebraic kernel and (4) a rough CGAL-like prototype implemen-

tation of a set of algebraic tools on univariate polynomials.

1 Introduction

In this report we report on four parallel approaches towards the implementation of an algebraic kernel:

1. The CGAL package Algebraic kernel for circles 2 2 aimed at providing the necessary alge-

braic functionality required for treating circular arcs.

2. Our experience in implementing algebraic numbers in environments like Maple and the SYNAPS

library.

3. The NumeriX library (part of the EXACUS project) which is a prototype implementation of a

set of algebraic tools on univariate polynomials, needed to built an algebraic kernel.

4. A rough CGAL-like prototype implementation of a set of algebraic tools on univariate polyno-

mials.

The work presented in this report follows semantically the discussions about the specifications for the

interface of the algebraic kernel, presented in Technical Report ACS-TR-123101-01 [7].

Among the four parallel approaches, one has reached the level of maturity of becoming a CGAL pack-

age, to be included in the next public release of CGAL. It deals, however, with a very limited category

of polynomials, namely bivariate polynomials of degree up to two, representing lines or circles. On

the other hand, it is one of two instances of a concrete algebraic kernel (along the guidelines presented

in ACS-TR-123101-01 [7]), dealing with polynomials not only in one variable but two. The other is

discussed in ACS-TR-123203-02 [14].

In the second approach we experimented with existing software, such as Maple or the SYNAPS library,

which has allowed for testing different possible directions. The current implementation on which we

report is in C++ as an independent module of the SYNAPS library, and is directly related to the work

reported in Technical Report ACS-TR-123203-02 [14].

The remaining two approaches have focused on providing tools of general interest and great variety

that can serve as a basis for the construction of a general (with respect to the type of algebraic objects

handled) Algebraic Kernel. It should be noted at this point that the specifications of what should be

underneath an Algebraic Kernel (called an Algebraic ToolBox in ACS-TR-123101-01 [7]) are still

1

ongoing discussions. As a result, concepts, names and semantics may differ in the last two sections of

this report.

The remainder of this report is organized as follows. In Section 2 we present the manual pages of

the Algebraic kernel for circles 2 2. In Section 3 we report on the interface between SYNAPS and

our current specifications of the algebraic kernel. In Section 4 we present NUMERIX, the library

of the EXACUS project providing the algebraic and numerical foundations required for performing

computations on curved objects. Finally, in Section 5 we report on a rough prototype of an algebraic

toolbox, designed and implemented in the spirit of CGAL.

2

2 The Algebraic kernel for circles 2 2

The work in this section has been carried out at INRIA as part of the development of the CGAL

2D Circular Kernel package (cf. Technical Report ACS-TR-123203-01 [30]). It follows the inter-

face specification of the algebraic kernel presented in Technical Report ACS-TR-123101-01 [7]. The

implementation of the Root of 2 class follows the analysis in [10].

Here we present the pages of the CGAL manual corresponding to the models of the main algebraic

concepts presented in [30]. In the spirit of the CGAL manual these pages are minimal, since all the

relevant information about the API of the models presented can be found in the manual pages of

corresponding concepts (see Technical Report ACS-TR-123101-01 [30]).

3

Cla

ss

Algebraic kernel for circles 2 2<RT>

#include <CGAL/Algebraic kernel 2 2.h>

Is Model for the Concept

AlgebraicKernelForCircles

4

Cla

ss

Polynomial 1 2<RT>

#include <CGAL/Polynomials 1 2.h>

Is Model for the Concept

AlgebraicKernelForCircles::Polynomial 1 2

5

Cla

ss

Polynomial for circles 2 2<FT>

#include <CGAL/Polynomials 2 2.h>

Is Model for the Concept

AlgebraicKernelForCircles::PolynomialForCircles 2 2

6

Cla

ss

Root of 2<RT>

#include <CGAL/Root of 2.h>

Is Model for the Concept

AlgebraicKernelForCircles::RootOf 2

7

Cla

ss

Root for circles 2 2<FT>

#include <CGAL/Root for circles 2 2.h>

Is Model for the Concept

AlgebraicKernelForCircles::RootForCircles 2 2

8

3 Implementation experiences on algebraic algorithms

In this section we report on several implementation issues in the development of various algebraic

algorithms, concerning real solving of univariate and (small) polynomial systems, and operations

with real algebraic numbers. These operations can eventually support several geometric predicates on

complex shapes, see e.g. [14]. A preliminary implementation of the algorithms was made in Maple,

which allowed us to test different directions. The current implementation is in C++, as an independent

module of the SYNAPS library.

The bottom, and perhaps the most important layer, concerns the number types. Typically, there is a

need for a ring number type (imagine Z), a field number type (imagine Q), an approximate number

type (imagine R, but in the implementation we use doubles, because they are fast), a number type

for intervals with endpoints a field number type and operations on all theses number types.

There are many implementation choices for the realization of the number types, but the choice of

a specific one is not clear. It depends on the problem and ultimate goal of the library that contains

them. We choose to have a NumberTraits class that is parametrized by a ring number type (Z) and

to access all the number types from this class.

template < typename RT_ >

struct NumberTraits {

typedef typename RingOf<RT_>::result_t RT; // Ring

typedef typename RationalOf<RT>::result_t FT; // Field

typedef typename ApproximationOf<RT>::result_t XT; // Aproximate

typedef typename IntervalOf<FT>::result_t FIT; // Field interval

typedef typename IntervalOf<XT>::result_t XIT; // Approximate interval

typedef typename HasFunction<RT>::gcd Has_gcd;

typedef typename HasFunction<RT>::isqrt Has_isqrt;

typedef typename HasFunction<RT>::sqrt Has_sqrt;

typedef typename HasProperty<RT>::exact Is_exact;

typedef typename HasProperty<RT>::ring Is_Ring_type;

typedef typename HasProperty<RT>::field Is_Field_type;

typedef NumberTraits<RT> self_t;

};

However we have to mention that these number types are no enough for efficient implementations.

Additionally we use dyadic numbers, that is rationals numbers of the form c2k , where c and k are ring

number types, but will not report on them since the concepts of these numbers are not standard yet.

Now, naturally arises the question about operations on the number types. We choose to collect all the

possible operations that we need and to specialize them on all possible number types.

The basic number type that a algebraic toolbox would provide is a type for real algebraic numbers, i.e

real root of univariate integer polynomials, and the basic operation on this number type is construction,

9

i.e real root isolation of univariate integer polynomials.

It is not clear whether a universal fast univariate real solver exists. Thus we choose to implement

different real solver so as to give the user the opportunity to choose the appropriate solver for her

application, or in other words to choose the optimal construction for real algebraic numbers.

We describe a package for algebraic numbers available in the library SYNAPS, however the imple-

mentation choices are independent of the SYNAPS. The purpose of this package is to provide a set of

tools, for the manipulation of algebraic numbers, needed in applications such as Geometric modeling.

In SYNAPS there are several solver classes, their interface is as follows

template < class T > struct SOLVER {

typedef NumberTraits<T>::RT RT;

typedef NumberTraits<T>::FT FT;

typedef NumberTraits<T>::FIT FIT;

typedef UPolDse<T> Poly;

typedef root_of<T, Poly> RO_t;

... };

where RT is the ring number type (typically Z) FT is the field number type (typically Q) FIT is the

interval type, Poly is the univariate polynomial, RO t is the type for real algebraic numbers, etc.

Algebraic numbers are of the form:

template <class T, class UPOL=UPolDse<T> >

struct root_of {

NumberTraits<T>::Interval_t interval_;

UPOL polynomial_;

... };

parametrized by the type of coefficients and univariate polynomials.

In order to construct a real algebraic number the user may select from several different univariate

solvers. Thus the functionality that we provide is construction, comparison, bool compare(const

RO t& a, const RO t& b) and int signat(const Poly& P, const RO t& a), based on in-

terval evaluation and if necessary on the computation of Sturm-Habicht sequences. and the four

operations, i.e. {+,−,∗,/}, of RO t with RT’s and FT’s.

Bivariate problems are also treated in this package, but not reported here. Several subdivision solvers

have been tested for the construction of these algebraic numbers. We report here on the following

solvers:

In general the user can call the solver function like,

Solve( const Poly& f, SOLVER);

10

where SOLVER ∈ {Small degree, Sturm}.

Small degree solver is dedicated for real solving polynomials of degree up to 4 using static (pre-

computed) Sturm sequences. Sturm solver is a solver for arbitrary degree polynomial based on an

implementation of various algorithms about Sturm sequences.

11

4 NUMERIX towards an Algebraic Tool Box

For the goal of propagating design experiments learned in EXACUS [15] towards the planned AlgebraicKernel

and AlgebraicToolBox within CGAL, this part of the report will concentrate on the NUMERIX li-

brary. It will discuss the number type concepts, algebraic constructions to build types from types

such as polynomials (over a number type), vectors and matrices and the various available tools such

as determinants, resultants, gcds, root isolation on univariate polynomials and comparing algebraic

numbers. For an introduction and overview of the EXACUS project, as well as the general context and

motivation behind the NUMERIX library please refer to [6].

4.1 Number Type Concept

We aim for the Real RAM model of computation. An effective realization must exploit the trade-off

between expressiveness and efficiency of different number type implementations. In NUMERIX, we

therefore provide a rich interface layer of number type concepts. Our interface extends the interface in

CGAL [16, 8, 23, 26] which only distinguishes EuclideanRing, Field, and FieldWithSqrt. The

finer granularity is needed for the domain of curves and surfaces, in particular the algebraic numbers

and algorithms on polynomials.

We keep the arithmetic and comparison operators for ease of use. Their semantic is sufficiently

standard to presume their existence and compliance in existing number type libraries for C++. For

the other functions we prefer the trouble-free and extensible traits class solution; this was suggested

by the name-lookup and two-pass template compilation problems experienced in CGAL.

4.1.1 Algebraic Number Type Concepts

Figure 1 shows the refinement relationship of the main number type concepts in NUMERIX. IntegralDomain,

UFDomain, Field, and EuclideanRing correspond to the algebraic concepts with the same name.

FieldWithSqrt are fields with a square root operator, giving generic access to types as leda::real

or CORE::Expr. The concept IntegralDomainWithoutDiv also corresponds to integral domains

in the algebraic sense, the distinction results from the fact that some implementations of integral do-

mains, such as CGAL::MP Float, lack the (algebraically always well defined) integral division.

The main properties of a number type are collected in the class NiX::NT traits<NT>. Each concrete

number type NT knows the (most refined) concept it fulfills, this is encoded in NT traits<NT>::Algebra type.

The usual arithmetic and comparison operators are required to be realized via C++ operator over-

loading for ease of use. The division operator is reserved for division in fields. All other unary

Assignable

DefaultConstructible

EqualityComparableField

UFDomain

FieldWithSqrt

STL

STL

STL

IntegralDomainIntegralDomainWithoutDivEuclideanRing

Figure 1: The number type concepts in EXACUS. The arcs show the refinement relationship among

number types. In particular, each number type is a refinement from three classical STL concepts.

12

(e.g. sqrt) and binary functions (e.g. gcd, div) must be models of the well known STL-concepts

AdaptableUnaryFunction or AdaptableBinaryFunction concept and local to a traits class (e.g.,

NT traits<NT>::Sqrt ()(x)). This allows us to profit maximally from all parts in the STL and its

programming style.

The Algebraic Number Type Concepts in detail:

• IntegralDomainWithoutDiv: The most basic number type concept: A ring with 0, 1, + , *.

A number type of this concept represents elements of an integral domain, i.e. a ring that is

commutative under multiplication, has an identity element, and has no divisors of 0. It refines

the classical STL concepts Assignable, DefaultConstructible, EqualityComparable.

It thus offers a default and a copy constructor, assignment =, and (in)equality ==, !=, with

STL-compatible semantics. There are also unary and binary plus +, unary and binary minus -,

multiplication * and their compound forms +=, -=, *= implementing the ring operations.

Furthermore, an IntegralDomainWithoutDiv provides an explicit conversion constructor

from int that is guaranteed to work for small integers (-128 to 127) and is the restriction of

a homomorphism from the integers to the ring in question. In particular, 0 and 1 map to the

ring’s zero and one respectively.

Required typedefs in NiX::NT traits<NT>:

• NT traits::NT

• NT traits::Algebra type,

indicates the most refined algebraic number type concept, NT fulfills

Required functors in NiX::NT traits<NT>:

• NT traits::Simplify ()(x), an AdaptableUnaryFunction,

triggers an internal simplification of the representation of x, if applicable

• NT traits::Unit part ()(x), an AdaptableUnaryFunction,

returns the unit part of x

• IntegralDomain: refines IntegralDomainWithoutDiv.

This concept refines IntegralDomainWithoutDiv by providing an integral division opera-

tion. We intend to reserve the operator / for use with a Field. Nevertheless, some non-field

models of IntegralDomain have one.

NiX::NT traits<NT> is required to provide:

• NT traits::Integral div ()(x,y), an AdaptableBinaryFunction,

provides integral division of x by y

• UFDomain: refines IntegralDomain.

A model of UFDomain is an IntegralDomain with the additional property that the ring it

represents is a unique factorization domain (a.k.a. em UFD or factorial ring), meaning that

every non-zero non-unit element has a factorization into irreducible elements that is unique up

to order and up to multiplication by invertible elements (units). (An irreducible element is a

non-unit ring element that cannot be factored further into two non-unit elements. In an UFD,

the irreducible elements are precisely the prime elements. Moreover any two elements, not both

zero, possess a greatest common divisor (gcd).

NiX::NT traits<NT> is required to provide:

13

• NT traits::Gcd ()(x,y), an AdaptableBinaryFunction,

computes the greatest common divisor of x and y

• EuclideanRing: refines UFDomain.

The ring affords a suitable notion of minimality of remainders such that given x and y 6= 0, we

obtain an (almost) unique solution to x = qy + r by demanding that a solution (q,r) is chosen

to minimize r. In particular, r is chosen to be 0 if possible. The most prominent example of

an Euclidean ring are the integers. Whenever both x and y are positive, then it is conventional

to choose the smallest positive remainder r. In other cases, there seems to be no universally

observed convention on how to choose the sign. (In particular, the ISO C++ Standard fixes

none for the modulo operation % on the built-in integral types.) Another important example

of an Euclidean ring are univariate polynomials over a field. Here the degree of r is to be

minimized.

NiX::NT traits<NT> is required to provide:

• NT traits::Div mod ()(x,y,q,r), a function object,

divides x by y into quotient q and remainder r

• NT traits::Div ()(x,y), an AdaptableBinaryFunction

• NT traits::Mod ()(x,y), an AdaptableBinaryFunction

• Field: refines IntegralDomain.

A model of the concept Field is an IntegralDomain in which every non-zero element has a

multiplicative inverse. As a consequence for any divisor 6= 0 NT traits::Integral div is

defined. For a Field, we require this division operation to be available also through operators

/ and /=.

• FieldWithSqrt:1 refines Field.

A model of FieldWithSqrt represents the field of algebraic expressions (FAE) limited to real

square root expressions.

NiX::NT traits<NT> is required to provide:

• NT traits::Sqrt ()(x), an AdaptableUnaryFunction,

computes the square root of x

4.1.2 Concept: RealComparable

Note that an order on the number type isn’t required by any of the concepts yet, i.e. the fields Q

and Z/pZ are ordered and not ordered respectively. The additional concept RealComparable is thus

orthogonal to the algebraic number type concepts.

• RealComparable:

A model of this concept is comparable according to the total order of the real numbers. RealComparable

refines the STL concepts EqualityComparable and LessThanComparable. It thus offers

operator ==, !=, <, >, <= and >= with STL-compatible semantics.

If a number type is a model of both concepts IntegralDomainWithoutDivand RealComparable

then the number represented by an object of this type is the same for both arithmetic and com-

1FieldWithSqrt will be replaced or refined by the FieldWithRootOf concept supporting in particular the diamond

operator of leda::real and the respective counterpart of CORE::Expr.

14

parison. It follows that the ring represented by this type is a sub ring of the real numbers and

hence has characteristic zero.

RealComparable is indicated by:

• NT traits::Is real comparable,

either LiS::True tag or LiS::False tag

If it is the case NiX::NT traits<NT> is required to provide:

• NT traits::Abs ()(x), an AdaptableUnaryFunction,

computes the absolute value of x

• NT traits::Sign ()(x), an AdaptableUnaryFunction,

computes the three-valued sign of x

• NT traits::Compare ()(x,y), an AdaptableBinaryFunction,

computes the three-valued comparison result of x and y

• NT traits::To double ()(x), an AdaptableUnaryFunction,

computes a double approximation of x

• NT traits::To Interval ()(x), an AdaptableUnaryFunction,

computes a boost::interval<double> containing x

4.2 Main Types in NUMERIX

We next discuss the main types provided by the NUMERIX library. The most important ones are

polynomials (section 4.2.1), several classes for real root isolation based on a common concept (section

4.2.2), real algebraic numbers (section 4.2.3) and square root extensions (section 4.2.5). The class

NiX::Linear algebra (a tool box for the most common methods in linear algebra) and other types

are discussed just briefly, see sections 4.2.6 and 4.2.7 respectively.

4.2.1 NiX::Polynomial

The class NiX::Polynomial<NT> represents polynomials with coefficients of type NT. Depending

on the capabilities of NT, the polynomial class adapts and picks the best implementation for cer-

tain functions (see below for an example). The number type NT must be at least a model of the

IntegralDomainWithoutDiv concept. For all operations involving division, the IntegralDomain

concept is required. Some functions need more than the IntegralDomain concept, for example, the

gcd-function based on polynomial remainder sequences requires NT to be of the Field or UFDomain

concept. In general, the generic implementation of the polynomial class encapsulates the distinction

between different variants of a function at an early level and allows the reuse of generic higher-level

functions.

NT Polynomial<NT>

IntegralDomainWithoutDiv ⇒ IntegralDomainWithoutDiv

IntegralDomain ⇒ IntegralDomain

UFDomain, EuclideanRing ⇒ UFDomain

Field, FieldWithSqrt ⇒ EuclideanRing

The table to the right shows the re-

sulting algebraic type with respect to

the algebraic type of NT. The number

type NT can itself be an instance of

NiX::Polynomial, yielding a recur-

15

sive form of multivariate polynomials2 . Some convenience functions hide the recursive construction

in the bivariate and trivariate case.

We use polynomial remainder sequences (PRS) to compute the gcd of two polynomials (uni- or mul-

tivariate). Template meta-programming is used to select the kind of PRS: Euclidean PRS over a field

and Subresultant PRS (see [28] for exposition and history) over a UFD. However, an additional meta-

programming wrapper makes the coefficients fraction-free via Fraction traits3 if possible, so that

gcd computation over the field of rational numbers is actually performed with integer coefficients and

the Subresultant PRS.

We offer several alternatives for computing the resultant of two polynomials: Via the Subresultant

PRS or as determinant of the Sylvester or Bezout matrix [17, 1]. Evaluating a Bezout determinant

with the method of Berkowitz [31] can be faster than the Subresultant PRS for bivariate polynomials

of small degrees over the integers. The Bezout determinant can also express subresultants, see e.g.

[18, 24, 1].

4.2.2 Root Isolators

An important design rational of NUMERIX is to provide a large collection of interchangeable tools

towards higher level approaches. A key tool is the isolation of real roots of univariate polynomials.

We therefore introduced the RootIsolator concept allowing a generic access to miscellaneous root

isolation approaches.

A model of the RootIsolator concept is a default constructible class providing the following public

typedefs:

• RootIsolator::Polynomial,

the polynomial type the isolator supports

• RootIsolator::Boundary type,

the boundary type of the isolating intervals the isolator supports

Moreover a model of this concept can be constructed from a univariate square-free polynomial of the

supported type.

The concept requires these member functions:

• Polynomial polynomial(),

returns the defining polynomial

• int number of real roots(),

returns the number of real roots

• bool is exact root(int i),

returns true if the respective isolating interval is degenerated to a single point

• Boundary type left boundary(int i),

returns the left boundary of the i-th root

2This form of constructing multivariate polynomials is justified for low degrees.3see also section 4.3.1

16

• Boundary type right boundary(int i),

returns the right boundary of the i-th root

We next list all models of the RootIsolator concept provided by the NUMERIX library. All listed

isolators are template classes, e.g. possible coefficient types of the Descartes isolator are the inte-

gers, rationals or even a NiX::Sqrt extension4 type. Models of the RootIsolator concept provided

by NUMERIX:

• NiX::Descartes

Implements the Descartes Method [9, 32, 2] which is known to be the best method for square-

free polynomials [9].

• NiX::Bernstein descartes approx

Coefficients are converted to (potentially infinite) bit-streams and the monomial polynomial is

converted to a Bernstein polynomial. Then a variant of Descartes algorithm is used to determine

the isolating intervals for the roots. Details can be found in [12].

• NiX::Smith filtered descartes

A filtered Descartes using double arithmetic, based on [27, 33].

The introduction of the new isolation methods NiX::Bernstein descartes approx and

NiX::Smith filtered descartes showed, that the concept provides an easy and comfortable way

to experiment with new tools. We thus emphasize the concept of a RootIsolator as an example for

an algebraic tool with respect to the coming specification of an AlgebraicToolBox.

4.2.3 NiX::Algebraic real

The type NiX::Algebraic real has been designed to represent coordinates of event points within

the sweep-line algorithm of the arrangement computation. Each instance of NiX::Algebraic real

is a model of the concept RealComparable, arithmetic operations are not supported.

The class NiX::Algebraic real itself is a handle class pointing to an internal representation class.

The representation class stores a univariate square-free polynomial and an open interval isolating

exactly on root, the represented algebraic real. It is guaranteed that the polynomial is not zero at the

endpoints of the interval.

The representation class has two template parameters:

• CoefficientType,

the coefficient type of the polynomial, model of IntegralDomainWithoutDivand RealComparable

• BoundaryType,

represents the endpoints of the isolating interval, it is a model of Field 5 and RealComparable

CoefficientType and BoundaryType must have a common super type provided by

NiX::Coercion traits, see section 4.3.4, to allow sign evaluation of the polynomial at the

boundary

4For NiX::Sqrt extension see section 4.2.55In fact any number type covering Z[1/2] is possible, i.e. exact float numbers.

17

A central operation is the refinement of an algebraic real. An algebraic real represented by the

square free polynomial P and the isolating interval I := (l,r) is refined at a given point m ∈ Q∩ I, by

evaluating the sign of P(m). If P(m) = 0, we set I := (m,m). If not, we set I := (l,m) if sign(P(l)) 6=sign(P(m)) and I := (m,r) otherwise.

We expose the refinement by the following member functions:

• refine(),

bisects the isolating interval 6

• template <class NTX7 > strong refine(NTX m),

refines the isolating interval until m is outside the closed interval

• refine to(BoundaryType l, BoundaryType u),

intersects the current interval with the isolating interval (l,u)

We next discuss the comparing of two algebraic reals. If the isolating intervals overlap, an immediate

comparison is not possible. In the latter case we compute the intersection of the intervals. If this

intersection still contains both roots, it might be the case that the algebraic numbers are equal. We thus

have to compute the gcd of both polynomials. If this gcd also contains a root within the intersection,

the numbers are equal. Otherwise the numbers are not equal and we refine both algebraic reals until

the isolating intervals fall apart.

We now discuss two central optimizations of the approach discussed above. Each trying to avoid the

often very expensive gcd-computation within the comparison step. Let P and Q be the two defining

polynomials involved and G their common factor.

• Modular filter: In most cases the two compared algebraic reals are not equal and moreover

P and Q don’t have a common factor at all. In these cases it is essential to avoid this expen-

sive computation at all. We therefore compute the resultant of both polynomials with modular

arithmetic. If the result is not equal zero, we can guarantee that P and Q don’t have a common

factor. This is done using the Modular traits, see section 4.3.2 and for more details [22].

• Common factor propagation: In some cases the gcd-computation can not be avoided, in par-

ticular if the two algebraic reals are equal. In case G is nontrivial, we use G to reduce the

degree of the defining polynomials P and Q. If the numbers are equal, we replace the defining

polynomials by G, otherwise we replace them by P/G and Q/G respectively. Moreover we

keep a list8 of all algebraic reals defined by the same polynomial. We are thus able to propagate

a discovered factor to all of them avoiding the computation of the same GCD over and over

again. And in addition this improves the representation of the involved algebraic reals. This is

in particular useful for algebraic reals used within the arrangement computation since all real

roots of a resultant are needed, see also [4, 13, 5] for more details.

6Other methods with a better convergence like interval Newton [19] are not implemented yet.7NTX and Coefficient must have a common super type via NiX::Coercion traits, see also section 4.3.4.8The initialization of this list is encapsulated within the Real roots functor, see section 4.2.4.

18

4.2.4 NiX::Real roots

An instance of the class NiX::Real roots< AlgebraicReal, RootIsolator >9 provides opera-

tors for a comfortable construction of AlgebraicReal from polynomials using a specific RootIsolator.

It has been introduced for three reasons. First, it encapsulates the handling of non-square-free poly-

nomials in a comfortable way. Second, it links all algebraic reals defined by the same polynomial

together, see also common factor propagation in section 4.2.3. Third, it allows maximal flexibility

with respect to the root isolators used, in particular it allows an improvement of the concept towards

root isolators handling non-square-free polynomials without effecting higher-level code.

The following operators are provided:

• template<class OI AR10>

int operator() (const Polynomial& P, OI oi root),

computes all roots of the square free polynomial in ascending order and returns the number of

real roots

• template<class OI AR, class OI int>

int operator()

(const Polynomial &poly, OI AR oi root, OI int oi mult),

computes all roots and their multiplicity of the polynomial in ascending order and returns the

number of real roots

4.2.5 NiX::Sqrt extension

An instance of the class template NiX::Sqrt extension<NT,Root> represents an extension of the

type NT by a square root of the type Root. In case NT and Root do not coincide, NT must be con-

structible from Root. The number type NTmust be at least a model of the IntegralDomainWithoutDiv

concept. For all operations involving division, the IntegralDomain concept is required.

NT Sqrt extension<NT,Root>

IntegralDomainWithoutDiv ⇒ IntegralDomainWithoutDiv

IntegralDomain ⇒ IntegralDomain

UFDomain, EuclideanRing ⇒ IntegralDomain

Field, FieldWithSqrt ⇒ Field

RealComparable ⇒ RealComparable

The table to the right shows the re-

sulting algebraic type with respect to

the algebraic type of NT. Both NT and

Root can themselves be an instance

of NiX::Sqrt extension, yielding

a nested extension. Note that the ex-

tension of an UFDomain or EuclideanRing is just an IntegralDomain, since the extension in gen-

eral destroys the unique factorization property. For example take Z[√

10] as indicated by [11] referring

to [20, 21]: For the fact that 2, 5, and√

10 are irreducible elements of Z[√

10]. It follows immediately

that Z[√

10] is not a UFD, because 10 =√

10 ·√

10 = 2 ·5 factors in two essentially different ways.

The type NiX::Sqrt extension is motivated due to the fact that number types such as leda::real

or CORE::Expr 11 being a model of the superior FieldWithSqrt concept should not be use as

9The polynomial and boundary type of AlgebraicReal and RootIsolator must coincide.10An Output Iterator for algebraic reals11For a details discussion on these types see [29, 25]

19

the coefficient type of polynomials since e.g. an polynomial gcd operation would cause large and

thus slow expression trees. In contrast, an object of NiX::Sqrt extension represents an exten-

sion by one square root only, which is defined at construction time. As a consequence two objects

of this type are interoperable if and only if they are defined within the same extension12 . The type

NiX::Sqrt extension is thus predestined to be used as the coefficient type of polynomials defined

over a algebraic extension of degree 2 or nested forms, in particular it is possible to use it as the

coefficient type of an NiX::Algebraic real.

4.2.6 NiX::Linear algebra

The class template NiX::Linear algebra<NT> provides standard functionality on matrices and vec-

tors. Beside the determinants, the linear algebra does not play an important role within EXACUS,

hence we only touch it briefly here.

An instance of the class NiX::Linear algebra<NT> provides:

• NiX::Linear algebra::Matrix,

matrix of arbitrary dimension supported by NiX::Linear algebra

• NiX::Linear algebra::Vector,

vector of arbitrary dimension supported by NiX::Linear algebra

On top it provides a collection of related function objects for the most common operations, i.e. de-

terminant, inverse, kernel, rank of a matrix and solving linear systems (Gauss-Jordan elimination).

Template meta-programming is used to select the best algorithm for each function with respect to the

used number type NT. For example the determinant picks one of the following functions:

• NiX::det bareiss,

Gaussian elimination according to the method proposed by Bareiss [3]

• NiX::det berkowitz,

a division free method as presented in Rote [31]

4.2.7 Further Types in NiX

Due to lack of space we just mention the following types briefly.

• Compactified

The class Compactified<NT> is useful to add the two infinite values to a comparable num-

ber type NT representing the real numbers (or subsets thereof). Mathematically, this is called

the two-point compactification of the real numbers, hence the name. However, it is not a re-

quirement that NT has to represent the reals. NiX::Compactified<NT> is in particular used to

represent unbounded arcs within SWEEPX in a convenient way. For more details see [6].

12It is also possible to leave the extension undefined i.e. NiX::Sqrt extension is constructible from int

20

• Tendency

The class NiX::Tendency<NT> allows to assign a slight tending to each representable value of

the comparable number type NT. The tending represents the (in fact infinitesimal small) amount

to which the number is shifted.

As Compactified<NT>, NiX::Tendency<NT> is used to handle unbounded arcs, in particular

it is used to represent the behavior of vertical lines or curves that approach a pole. For more

details see [6].

4.3 Traits Classes

Beside the main traits class NiX::NT traits, NUMERIX provides a rich framework of several other

traits classes. We next define and motivate these traits classes.

4.3.1 NiX::Fraction traits

Beyond the need for performing algebraic operations on objects as a whole, there are also num-

ber types which one would like to decompose into numerator and denominator. This does not only

hold for rational numbers, but also compound objects like polynomials or NiX::Sqrt extensions

which may decompose into a (scalar) denominator and a compound numerator with a simpler and

thus faster coefficient type (e.g. integer instead of rational). For example the gcd computation of

two polynomials is internally performed ’denominator-free’ if supported by the coefficient type via

NiX::Fraction traits.

In case NT is decomposable via NiX::Fraction traits<NT> this is indicated by:

• Fraction traits::Is decomposable,

either LiS::True tag or LiS::False tag

If it is the case NiX::Fraction traits<NT> provides:

• Fraction traits::Numerator type,

type to represent the numerator

• Fraction traits::Denominator type,

type to represent the denominator

• Fraction traits::Decompose ()(x,n,d), a function object,

decomposes x = n/d into (n,d)• Fraction traits::Compose ()(n,d), an AdaptableBinaryFunction,

composes (n,d) to n/d

21

4.3.2 NiX::Modular traits

NiX::Modular traits has been introduced to support one of the strongest filters used within NU-

MERIX, the modular filter discussed in [22]. It comes along with the type NiX::Modular. This

number type is based on double arithmetic and represents a value in Z/pZ, p prim in Z. It is thus

a model of the Field concept. NiX::Modular traits is defined for scalar number types such as

integers or rationals but also for compound types as NiX::Polynomial or NiX::Sqrt extension.

In case NT is supported by NiX::Modular traits<NT> this is indicated by:

• Modular traits<NT>::Is convertible,

either LiS::True tag or LiS::False tag

If it is the case NiX::Modular traits<NT> provides:

• Modular traits<NT>::Modular NT,

the result type with respect to the number type NT

• Modular traits<NT>::Modular image, an AdaptableUnaryFunction,

computing the image of the canonical homomorphism from NT to Modular NT

4.3.3 NiX::Scalar factor traits

A recurring problem in handling compound algebraic objects like polynomials defining curves is how

to simplify them by extracting a scalar factor out of them such that the remaining polynomial has

coefficients as small as possible. This scalar factor is in general not the gcd of all coefficients since

the gcd might not be defined at all13. We thus introduced NiX::Scalar factor traits providing

a generic mechanism for scalar factor extraction.

NiX::Scalar factor traits<NT> provides:

• Scalar factor traits::Scalar,

the inner scalar type with respect to NT

• Scalar factor traits::Scalar factor ()(x),

an AdaptableUnaryFunction, computes the inner scalar factor of x

• Scalar factor traits::Scalar div ()(x,s),

an AdaptableBinaryFunction, divides x by the scalar factor s

4.3.4 NiX::Coercion traits

A frequent problem in generic programming is how to handle operations involving type coercion, in

particular it is important to know what is the resulting type of an operation. We therefore introduced

NiX::Coercion traits giving access to this result type in a generic way.

13just think of NiX::Polynomial<NiX::Sqrt extension<Integer,Integer> >

22

It provides:

• NiX::Coercion traits<A,B>::RET,

the result type of the type coercion of A and B

• NiX::Coercion traits<A,B>::Cast, a function object,

providing a cast of A and/or B to RET

It is idempotent and symmetric in its template parameters, i.e.:

• Coercion traits<A,A>::RET ≡ A

• Coercion traits<A,B>::RET ≡ Coercion traits<B,A>::RET

NiX::Coercion traits is defined if and only if the cast is an exact cast. If one of the types is

constructible from the other, then NiX::Coercion traits provides this cast, e.g.:

• Coercion traits<double,int>::RET ≡ double

• Coercion traits<Rational,Integer>::RET ≡ Integer14

Moreover NiX::Coercion traits provides access to a common super type if a direct cast is not

possible, e.g.:

• Coercion traits<Rational,Polynomial<Integer> >

::RET ≡ Polynomial<Rational>

• Coercion traits<Rational,Sqrt extension<Integer,Integer> >

::RET ≡ Sqrt extension<Rational,Integer>

• Coercion traits<Real,Sqrt extension<Integer,Integer> >

::RET ≡ Real15

A very illustrative example for the use of the NiX::Coercion traits within generic code is the

member function evaluate of the NiX::Polynomial<NT> class, allowing the evaluation of a

NiX::Polynomial<NT> by some type NTX.

> template <class NTX>

> typename Coercion traits<NTX,NT>::RET

> evaluate(const NTX& x) const {> typedef Coercion traits<NTX,NT> CT;

> typename CT::Cast cast;

> int d = degree();

>

> typename CT::RET y=cast(this->ptr()->coeff[d]);

> while (--d >= 0)

> y = y*cast(x) + cast(this->ptr()->coeff[d]);

> return y;

> }

14For the respective types of the LEDA, CORE, GMP and other libraries.15Real represents some model of the FieldWithSqrt and RealComparable concepts i.e. leda::real or CORE::Expr.

23

4.4 Concept: ArithmeticTraits

The concept of an ArithmeticTraits can be considered as the first step towards a concept we call an

AlgebraicToolBox, see [7]. Currently an instance of the ArithmeticTraitsconcept provides a well-formed

collection of all scalar number types needed in the higher EXACUS libraries (CONIX, QUADRIX, etc.). All ba-

sic classes within these libraries are instantiated by a model of the ArithmeticTraits or a refinement of the

concept.

A model of the concept provides:

• Arithmetic traits::Integer,

a model of EuclideanRing and RealComparable representing Z

• Arithmetic traits::Rational,

a model of Field and RealComparable representing Q

• Arithmetic traits::FieldWithSqrt,

a model of FieldWithSqrt and RealComparable

The collection is well-formed in the sense that the given types are interoperable. As a consequence NiX::Coercion traits

provides type coercion for these types and all reasonable compound types provided by the NUMERIX library.

It is guaranteed that:

• Arithmetic traits::Rational,

explicit constructible from Integer

• Arithmetic traits::FieldWithSqrt,

explicit constructible from Integer and Rational

NUMERIX currently provides two models of the ArithmeticTraits concept:

• NiX::LEDA Arithmetic traits,

defined if LEDA is available, using leda::integer, leda::rational and leda::real

• NiX::CORE Arithmetic traits,

defined if CORE is available, using CORE::BigInt, CORE::BigRat and CORE::Expr

4.5 Lessons Learned and Further Work

We consider NUMERIX as work in progress and thus as work in progress. We next motivate and discuss our

main objectives for the near future.

4.5.1 Floating Point Numbers

Except for NiX::NT traits::To double and NiX::NT traits::To Interval functors, up to now NU-

MERIX has not fully taken advantage of floating point numbers , in particular those with variable precision such

as leda::bigfloat. For the next iteration a direct and thus more sophisticated use of multi-precision floating

point arithmetic is expected to lead to significant runtime improvements. We intend to introduce the according

concepts for floating point number types and interval arithmetic on these types, in particular we want to enrich

the ArithmeticTraits by the respective types.

24

4.5.2 Namespace vs. Kernel

The NUMERIX library is currently organized within the namespace NiX. Therefore all template classes and

functions within NUMERIX do have an immediate access to their template parameter types only. In general

this is compensated due to the rich frame work of traits classes provided by NUMERIX. But there are cases, in

particular when it comes to filtering, in which one would like to have a more comfortable way to access types

that do not directly depend on the given template parameters. It is thus preferable to have a direct access to the

most basic types16 such as Integer, Rational and multi-precision floats.

We currently see two feasible options to reach this goal:

The first option is to introduce a class, let’s say NiX::Get arithmetic traits<NT>, providing access to the

respective model of ArithmeticTraits. We currently see this as the preferable solution for the NUMERIX

library since it is organized in a namespace.

The second option is to collect most of the functionality of NiXwithin a Kernel receiving an ArithmeticTraits

as template parameter. In this way each class and function within this Kernel has direct access to all number

types provided by this ArithmeticTraits. We emphasis this approach to be taken into account within the

design of the AlgebraicToolBox.

16In addition to the built-in types.

25

5 A rough CGAL-like prototype implementation of a set of algebraic

tools on univariate polynomials

In this section we report on a rough prototype implementation of a set of algebraic tools on univariate poly-

nomials. The work has been carried out at NUA and aims at providing the AlgebraicToolBox functionality

presented in Technical Report ACS-TR-123101-01 [7], as well as in Section 4 in this report. For convenience

we will refer to our prototype as the Algebraic Toolbox package, although it is my no means a fully designed

and implemented package.

The Algebraic Toolbox has a three-layer structure (cf. Figure 2). The bottom most layer is the Number Type

Layer. This layer is responsible for providing all the functionality related to number types. This level currently

corresponds to the number type concepts in CGAL. However, the existing CGAL concepts seem to be quite

limited and are not really capable of providing information about the relationships between the different number

types. The discussions held at INRIA on October 2005 (reported in ACS-TR-123101-01 [7]) and the decisions

taken with respect to the re-design of the number type hierarchy in CGAL are a first step towards providing more

structure in CGAL at the number type level and introducing more concretely the afore-mentioned relationships

between number types (see also the related discussion about number types in Section 4.1). The Number Type

Layer introduced here seems to have the same semantics as the ArithmeticTraits concept in Section 4.4.

This is not the case however. The ArithmeticTraits corresponds to a collection of all scalar types needed in

the hierarchy of the EXACUS libraries, whereas in this section’s context it refers to the specifications of what is

a number type and what functionality is expected from it, or supported by it. In that sense it plays the same role

as the NiX::NT Traits<NT> described in Section 4.1.1.

For the reasons we have implemented temporarily a few helper classes listed below:

• The CGAL::Number type category<NT> class, which provides the additional information that we

need. This class provides a tag that indicates whether the number type that we are using is an inte-

gral domain number type, a field number type or a Euclidean ring number type.

• The CGAL::Arithmetic traits<IDNT,FNT> Class, which provides the connection between an inte-

gral domain number type and a matching field number type. It is assumed here that the integral domain

number type is convertible to the field number type and that operations between the two number types

are properly defined. The restrictions that we impose here on the cooperability of the two number types

defined in the CGAL::Arithmetic traits<IDNT,FNT> class seem quite restrictive; we have decided

yet as to whether these restrictions are going to be enforced in later versions of our package or whether

we are going to use other mechanisms, such as the Coercion traits presented in Section 4.3.417

We are not going to focus on this layer since it refers to concepts and models already existing in CGAL or going

through a revision.

The middle layer is the Polynomial Toolbox layer. This layer is responsible for providing a polynomial class,

defined over a number type, as well as various operations on the polynomial provided. We will describe this

layer in detail in Subsection 5.1.

The top-most layer of our hierarchy is the Algebraic Toolbox. This layer extends the Polynomial Toolbox layer.

In addition to the functionality of the Polynomial Toolbox, it is responsible for providing a Sturm sequence

based solver for isolating the real roots of a polynomial, as well as a type Root, which represents the real

roots of the polynomial solved. The type Root essentially represents algebraic numbers, but with very limited

functionality, and it basically a typedef to the Root type provided by the solver. We will discuss this layer in

detail in Subsection 5.2.

17The CGAL::Arithmetic traits<IDNT,FNT> class has similar semantics to the ArithmeticTraits concept of Sec-

tion 4.4. It represents a collection of number types to be used for computations at higher levels or our hierarchy.

26

Our package has been designed using this three-layer structure for the following reasons:

• Cooperability with CGAL : The bottom-most layer uses the existing CGAL infrastructure on number type

concepts. Of course, there are some unresolved issues, mentioned above, but these issues are well under

way towards resolution.

• Genericity: We would like our implementation to be as generic as possible; more precisely the user

should be able to plug-in different number types and polynomial classes (which should follow the ap-

propriate concepts of course), and use our Polynomial and Algebraic Toolboxes without any additional

programming effort. One major design decision we made in order to achieve this goal is to use the

rebind mechanism for associating polynomials with number types, and polynomial toolboxes with alge-

braic toolboxes.

• Modularity: Our three-layer design is really related to the type of the objects we handle/introduce at

each layer: the bottom-most layer is related to number types, the middle layer is related to polynomials

defined over the number types of the layer below and provides operations on polynomials; the top-most

layer goes one step further and introduces algebraic numbers. Moreover, we wanted each layer to be self-

contained and independently useful to the user, instead of hiding the three layers under the same roof.

The major outcome of this choice is a toolbox of operations on polynomials that could be of independent

interest for some of our geometric applications.

• Flexibility: One of our aims when designing our package was the ability to experiment with different

solver for root isolation. This is achieved by keeping the top-most level very thin, and providing a

wide variety of algorithms for computing Sturm sequences at the middle layer. If the user wants to

use a different Sturm sequence than the default choice we have in our current implementation of the

Algebraic Toolbox, it suffices to change one line of code in our Algebraic toolbox class. In future

we are planning on making this choice even more flexible via the introduction of appropriate template

parameters.

Algebraic Toolbox

Number Type Layer

Polynomial Toolbox

Figure 2: The three-layer of the Algebraic Toolbox package.

27

5.1 The Polynomial Toolbox

The Polynomial Toolbox is parametrized by a number type and a polynomial. All operations offered by the

Polynomial Toolbox apply to one or two polynomials defined over the same number type, hence we have no

need for the Arithmetic Traits discussed in the section above. Since we want to allow the flexibility to

1. guide the definition of the polynomial using the number type, and

2. define polynomials with different number types using the same toolbox (this is essential for the solver

provided by the Algebraic Toolbox),

we have decided to use the rebind mechanism for both defining the polynomial on which the Polynomial Tool-

box operates, as well as the Polynomial Toolbox itself.

Polynomials are required to come with standard operations (not shown in this report), such as addition, sub-

traction and multiplication, as well as addition, subtraction and multiplication with an instance of the number

type over which they are defined. When the number type supports division (i.e., if it is a field number type), it

is also possible to divide a polynomial with an instance of such a number type. All remaining operations are

performed through the Polynomial Toolbox. These operations, as it can be seen from the public interface of the

CGAL::Polynomial toolbox class in Figure 3, include:

• Given a polynomial f (x) and an integer k, compute the polynomial xk f (x); this is the Shift functor.

• Given a polynomial f (x), return (− f )(x); this is the Negate functor.

• Given a polynomial f (x), of degree d, compute the polynomial xd f (1/x); this is the Invert functor.

• Given a polynomial f (x), compute its first derivative polynomial f ′(x); given in addition an integer k,

compute its k-th derivative polynomial f (k)(x); this is the Derivative functor.

• Given a polynomial f (x) and a number α , compute the polynomial f (x + α); this is the Translate

functor.

• Given two polynomials f (x) and g(x), compute the quotient of the division of f (x) by g(x); this is the

Quotient functor. This functor can be used if the number type over which the polynomial is defined

supports division.

• Given two polynomials f (x) and g(x), compute the remainder of the division of f (x) by g(x); this is the

Remainder functor. This functor can be used if the number type over which the polynomial is defined

supports division.

• Given two polynomials f (x) and g(x), compute the quotient and the remainder of the division of f (x) by

g(x); this is the Quotient remainder functor. This functor is more efficient than using the Quotient

and Remainder functors separately. This functor can be used if the number type over which the polyno-

mial is defined supports division.

• Given two polynomials f (x) and g(x), compute the pseudo-quotient of the division of f (x) by g(x); this

is the Pseudo quotient functor.

• Given two polynomials f (x) and g(x), compute the pseudo-remainder of the division of f (x) by g(x);this is the Pseudo remainder functor.

• Given two polynomials f (x) and g(x), compute the quotient and the remainder of the division of f (x)by g(x); this is the Pseudo quotient remainder functor. This functor is more efficient than using the

Pseudo quotient and Pseudo remainder functors separately.

28

template<class NT_t, class P>

class Polynomial_toolbox

{

protected:

typedef Polynomial_toolbox<NT_t,P> Self;

typedef Number_type_category<NT_t> category_type;

public:

typedef typename P::template Rebind<NT_t>::Other Polynomial;

typedef Shift<Polynomial> Shift;

typedef Negate<Polynomial> Negate;

typedef Invert<Polynomial> Invert;

typedef Derivative<Polynomial> Derivative;

typedef Translate<Polynomial> Translate;

typedef Quotient_remainder<Polynomial> Quotient_remainder;

typedef PQuotient<Polynomial> Quotient;

typedef Remainder<Polynomial> Remainder;

typedef Pseudo_quotient<Polynomial> Pseudo_quotient;

typedef Pseudo_remainder<Polynomial> Pseudo_remainder;

typedef Pseudo_quotient_remainder<Polynomial> Pseudo_quotient_remainder;

typedef Sturm_sequence<Self> Sturm_sequence;

typedef Sturm_sequence_q<Self> Sturm_sequence_q;

typedef Euclidean_Sturm_sequence<Self> Euclidean_Sturm_sequence;

typedef Euclidean_Sturm_sequence_q<Self> Euclidean_Sturm_sequence_q;

typedef Subresultant_Sturm_sequence<Self> Subresultant_Sturm_sequence;

typedef Monic_Sturm_sequence<Self> Monic_Sturm_sequence;

typedef Reduced_Sturm_sequence<Self> Reduced_Sturm_sequence;

typedef Primitive_part_Sturm_sequence<Self> Primitive_part_Sturm_sequence;

typedef Primitive_part_Sturm_sequence_q<Self> Primitive_part_Sturm_sequence_q;

typedef Sign_at<Polynomial> Sign_at;

// rebind mechanism for the toolbox; this way I can get toolboxes

// with other number types and polynomials

template<class NTT, class P_t>

struct Rebind { typedef Polynomial_toolbox<NTT,P_t> Other; };

template<class T>

T get() const { return T(); }

template<class T, typename A1>

T get(const A1& a1) const { return T(a1); }

template<class T, typename A1, typename A2>

T get(const A1& a1, const A2& a2) const { return T(a1, a2); }

};

Figure 3: The CGAL::Polynomial toolbox class.

29

• Given two polynomial f (x) and g(x), compute their Sturm sequence. There are several different Sturm

sequences that can be computed, such as the Sturm sequence that uses the standard division algorithm,

the Euclidean Sturm sequence, the Subresultant Sturm sequence, the Monic Sturm sequence, the Reduced

Sturm sequence and the Primitive part Sturm Sequence. The corresponding functors are, respectively,

Sturm sequence, Euclidean Sturm sequence, Subresultant Sturm sequence, Monic Sturm sequence,

Reduced Sturm sequence and Primitive part Sturm Sequence.

• In addition to the afore-mentioned Sturm sequences, we can compute, for some of them, variations that

not only keep the remainder polynomials, but also the quotient polynomials of the division of two suc-

cessive terms in the sequence. The underlying idea and motivation is to use these quotient polynomials,

when computing sign variations during the root isolation. The Sturm sequences for which this idea has

been implemented are the normal Sturm sequence, the Euclidean Sturm sequence and the Primitive part

Sturm sequence. The corresponding functors are Sturm sequence q, Euclidean Sturm sequence q

and Primitive part Sturm sequence q. Note that not all Sturm sequence algorithms work on the

same type of numbers. For example the normal Sturm sequence needs a field number type, the Euclidean

Sturm sequence requires an integral domain number type, whereas the Primitive part Sturm sequence

needs a Euclidean ring number type.

• Given a polynomial f (x) and a number α , compute the sign of the quantity f (α); this is the Sign at

functor.

The functor in the Polynomial Toolbox can be accessed via template get methods, which take zero, one or

two arguments, that are passed as arguments to the functor at construction time. The number or arguments

depends on the nature of the functor requested; for example the Shift or Derivative functors take zero

arguments. On the contrary, all Sturm sequence functors take two arguments, since all these functors maintain

a state by caching the results of the computation (the Sturm sequence computed); it is thus necessary to pass

them at construction time the objects on which they operate. We currently have no functors in the Polynomial

Toolbox that take one argument at construction time; the corresponding get method has been added for future

compatibility.

Our package also provides a default implementation of a model of the polynomial concept (not presented in this

report), along with an accompanying traits class for accessing its functionality, and is reference-counted.

5.2 The Algebraic Toolbox

The Algebraic Toolbox is parametrized by a polynomial class and an Arithmetic Traits class. The Arithmetic

traits provide an integral domain number type and a field number type then work well together (see the dis-

cussion at the beginning of this section about the Arithmetic Traits). Based on these number types and the

polynomial class provided, the Algebraic Toolbox defines the polynomial type exported to the user. It also

exports a solver object that is responsible for performing root isolation, and providing the real roots of a poly-

nomial. The solver that the Algebraic Toolbox provides, i.e., the Solver functor, is generic in the sense that

it works with any Sturm sequence provided by the Polynomial Toolbox. Clearly Sturm sequences are not the

only algebraic tool for root isolation; although our Algebraic Toolbox is modeled around Sturm sequences so

far, the interface is generic enough to accomodate other types of solvers. The Solver also defines a Root type

that represents the real roots of the polynomial passed to it, which is also exported to the user.

The Solver object is operating on a polynomial which is passed to it at construction time. It behaves as a

container of numbers, namely the real roots of the polynomial solved. As mentioned above, all our models of

a Solver are Sturm sequence based. They have the ability to give back the Sturm sequence used for the root

isolation, and so far for square-free polynomials only. As a result the root multiplicity related issues have not

been fully addressed yet.

30

template<class P, class ArithmeticTraits>

class Algebraic_toolbox

: public Polynomial_toolbox

<typename ArithmeticTraits::Integral_domain_number_type,P>

{

private:

typedef typename ArithmeticTraits::Integral_domain_number_type IDNT;

typedef typename ArithmeticTraits::Field_number_type FNT;

typedef Polynomial_toolbox<IDNT,P> Base;

public:

typedef ArithmeticTraits Arithmetic_traits;

typedef IDNT Integral_domain_number_type;

typedef FNT Field_number_type;

typedef typename P::template Rebind<IDNT>::Other Polynomial;

typedef Polynomial_toolbox<IDNT,Polynomial> Polynomial_toolbox;

private:

typedef Solver_traits<IDNT,FNT,Polynomial_toolbox,Polynomial> Solver_traits;

// change this typedef to use another Sturm sequence for the solver

typedef typename Polynomial_toolbox::Primitive_part_Sturm_sequence_q

Sturm_sequence;

public:

typedef Sturm_sequence_solver<Sturm_sequence,Solver_traits> Solver;

typedef typename Solver::Root Root;

// access to solver; solver should be reference counted

Solver get_solver_object(const Polynomial& f) const {

return Solver(f);

}

Solver solve(const Polynomial& f) const {

return Solver(f);

}

};

Figure 4: The CGAL::Algberaic toolbox class.

31

The Root object is currently an isolating interval of real root represented and the polynomial of which the

object represented is a real root. Our current interface of the Root object is quite limited: the user can ask

for the isolating interval and the defining polynomial, and can compare two roots. The comparison is perform

by successive subdivision of the isolating intervals until they are either disjoint, in which case the order of

the two roots can be deduced from the relative order of their isolating intervals, or until the share the same

isolating interval. In the later case, the sign of the quantity g(γ) is computed, where f (x) and g(x) are the

defining polynomials of the two algebraic numbers being compared and γ is the real root of interest of f (x)(i.e., f (γ) = 0). This sign is computed via the Sturm sequence of the polynomials f (x) and f ′(x)g(x) (cf. [34]).

5.3 Future Work

As mentioned in the beginning of this section, the work presented here is at a quite preliminary stage and

constitutes a rough prototype of an Algebraic Toolbox in the sense of ACS-TR-123101-01 [7]. The goal is to

have a flexible, modular and generic implementation of such a toolbox, to be used for implementing generic

algebraic kernels.

The is a lot of functionality to be added to the current implementation. Below we list the most important items;

some are very specific, others are of broader interest. This difference in the level of detail represents the current

status of our development process: detailed view for the items closer to implementation, a coarse view for the

items further ahead in the future.

• Support for basic operations between the Root type and the number type of the coefficients of the defin-

ing polynomial. These operations should include addition, subtraction, multiplication and possibly divi-

sion (depending on the type of the coefficients).

• Support the computation of the square root of the k-th root of a Root; similarly support the computation

of the square of a Root.

• Support approximation of the Root type by either a double or to whatever precision is required.

• Implement Sturm sequence solvers that not only take the polynomial to be solved, but also an inter-

val which delimits the real roots we are interested in. The endpoints of the intervals should be Roots

themselves.

• Extend the Sign at functor to work not only for a polynomial and a number of the same type as the

coefficients of the polynomial, but also for a polynomial and a Root (this is the generalization of the

Sign at functor from the context of the Polynomial Toolbox to that of the Algebraic Toolbox.

• Implements efficient methods for isolating and comparing real roots for polynomials of small degree

based on static Sturm Sequences (cf. []).

• Implement a Lazy Algebraic Toolbox; in a Lazy Algebraic Toolbox, objects have a dual representation:

one based on an interval number type akin to interval arithmetic, and one based on an exact number type.

The various operations are represented using an operation tree, while at the same time computing the

interval representation. Evaluations are performed as much as possible with the interval representation,

and whenever this representation is not sufficient to answer the predicate of interest, we automatically

switch to the exact representation, by means of a bottom-up evaluation of the operation tree. We have so

far implemented lazy polynomials and basic operations on them; the next step is to generalize the lazy

approach to functors on polynomials, such as those in the Polynomials Toolbox, and eventually to the

Algebraic Toolbox.

32

References

[1] J. Abdeljaoued, G. M. Diaz-Toca, and L. Gonzalez-Vega. Minors of Bezout matrices, subresultants and the parame-

terization of the degree of the polynomial greatest common divisor. Internat. J. of Computer Math., 81:1223–1238,

2004.

[2] Alkiviadis G. Akritis. There is no “Uspensky’s method.”. In SYMSAC ’86: Proceedings of the fifth ACM symposium

on Symbolic and algebraic computation, pages 88–90, New York, NY, USA, 1986. ACM Press.

[3] BAREISS. E.h. sylvester’s identity and multlstep integer-preserving gaussian elimination. In Mathematics of Compu-

tation 22, pages 565–578, 1968.

[4] E. Berberich, A. Eigenwillig, M. Hemmer, S. Hert, K. Mehlhorn, and E. Schomer. A computational basis for conic

arcs and boolean operations on conic polygons. In ESA 2002, LNCS 2461, pages 174–186, 2002.

[5] E. Berberich, M. Hemmer, L. Kettner, E. Schomer, and N. Wolpert. An exact, complete and efficient implementation

for computing planar maps of quadric intersection curves. In Proc. 21th Annu. Sympos. Comput. Geom., pages 99–106,

2005.

[6] Eric Berberich, Arno Eigenwillig, Michael Hemmer, Susan Hert, Lutz Kettner, Kurt Mehlhorn, Joachim Reichel,

Susanne Schmitt, Elmar Schomer, and Nicola Wolpert. EXACUS: Efficient and exact algorithms for curves and

surfaces. In Gerth S. Brodal and Stefano Leonardi, editors, 13th Annual European Symposium on Algorithms (ESA

2005), volume 3669 of Lecture Notes in Computer Science, pages 155–166, Palma de Mallorca, Spain, October 2005.

European Association for Theoretical Computer Science (EATCS), Springer.

[7] Eric Berberich, Michael Hemmer, Menelaos Karavelas, Sylvain Pion, Monique Teillaud, and Elias Tsigaridas. Inter-

face specification of algebraic kernel. Technical Report ACS-TR-123101-01, INRIA, NUA, MPI, 2006.

[8] H. Bronnimann, L. Kettner, S. Schirra, and R. Veltkamp. Applications of the generic programming paradigm in the

design of CGAL. In M. Jazayeri, R. Loos, and D. Musser, editors, Generic Programming—Proceedings of a Dagstuhl

Seminar, LNCS 1766, pages 206–217. Springer-Verlag, 2000.

[9] G. E. Collins and A.-G. Akritas. Polynomial real root isolation using Descartes’ rule of sign. In SYMSAC, pages

272–275, 1976.

[10] Olivier Devillers, Alexandra Fronville, Bernard Mourrain, and Monique Teillaud. Algebraic methods and arithmetic

filtering for exact predicates on circle arcs. Comput. Geom. Theory Appl., 22:119–142, 2002.

[11] A. Eigenwillig. Exact arrangement computation for cubic curves. Master’s thesis, Saarland University, Saarbrucken,

Germany, 2003.

[12] A. Eigenwillig, L. Kettner, W. Krandick, K. Mehlhorn, S. Schmitt, and N. Wolpert. A Descartes algorithm for poly-

nomials with bit-stream coefficients. In Proc. 8th Int. Workshop on Computer Algebra in Scient. Comput. (CASC),

LNCS. Springer, 2005. to appear.

[13] Arno Eigenwillig, Lutz Kettner, Elmar Schomer, and Nicola Wolpert. Exact, efficient, and complete arrangement

computation for cubic curves. Computational Geometry, 2006. In press.

[14] I. Emiris and E. Tsigaridas. CGAL package for 2D curved kernel (a wrapper for SYNAPS). Technical Report ACS-

TR-123203-02, NUA, 2006.

[15] The EXACUS project.

www.mpi-sb.mpg.de/projects/EXACUS/.

[16] A. Fabri, G.-J. Giezeman, L. Kettner, S. Schirra, and S. Schonherr. On the design of CGAL, the computational

geometry algorithms library. Softw. – Pract. and Exp., 30(11):1167–1202, 2000.

[17] I. M. Gelfand, M. M. Kapranov, and A. V. Zelevinsky. Discriminants, Resultants and Multidimensional Determinants.

Birkhauser, Boston, 1994.

[18] R. N. Goldman, T. W. Sederberg, and D. C. Anderson. Vector elimination: A technique for the implicitization,

inversion, and intersection of planar parametric rational polynomial curves. CAGD, 1:327–356, 1984.

[19] R. Hammer, M. Hocks, U. Kulisch, and D. Ratz. C++ Toolbox for Verified Computing. Springer, 1995.

[20] G. H. Hardy and E. M. Wright. An Introduction to the Theory of Numbers. Oxford University Press, 5th edition, 1979.

[21] H. Hasse. Vorlesungen uber Zahlentheorie. Springer, 2nd edition, 1964.

[22] M. Hemmer, L. Kettner, and E. Schomer. Effects of a modular filter on geometric applications. Technical Report

ECG-TR-363111-01, MPI Saarbrucken, 2004.

33

[23] S. Hert, M. Hoffmann, L. Kettner, S. Pion, and M. Seel. An adaptable and extensible geometry kernel. In Proc. 5th

Workshop on Algorithm Engineering (WAE’01), LNCS 2141, pages 76–91, Arhus, Denmark, August 2001. Springer-

Verlag.

[24] X. Hou and D. Wang. Subresultants with the Bezout matrix. In Proc. Fourth Asian Symp. on Computer Math. (ASCM

2000), pages 19–28. World Scientific, Singapore New Jersey, 2000.

[25] V. Karamcheti, C. Li, I. Pechtchanski, and C. Yap. A core library for robust numeric and geometric computation. In

Proc. 15th Annu. Sympos. Comput. Geom., pages 351–359, 1999.

[26] L. Kettner and S. Naher. Two computational geometry libraries: LEDA and CGAL. In J. E. Goodman and J. O’Rourke,

editors, Handbook of Disc. and Comput. Geom., pages 1435–1463. CRC Press, second edition, 2004.

[27] J. Keyser, S. Krishnan, and D. Manocha. Efficient and accurate B-rep generation of low degree sculptured solids using

exact arithmetic. In Proceedings of ACM Solid Modeling, 1997. To appear.

[28] R. Loos. Generalized polynomial remainder sequences. In B. Buchberger, G. E. Collins, and R. Loos, editors,

Computer Algebra: Symbolic and Algebraic Computation, pages 115–137. Springer, 2nd edition, 1983.

[29] K. Mehlhorn and S. Naher. LEDA: A Platform for Combinatorial and Geometric Computing. Cambridge University

Press, Cambridge, UK, 2000.

[30] Sylvain Pion and Monique Teillaud. CGAL package for 2D curved kernel. Technical Report ACS-TR-123203-01,

INRIA, 2006.

[31] G. Rote. Division-free algorithms for the determinant and the pfaffian: algebraic and combinatorial approaches. In

H. Alt, editor, Computational Discrete Mathematics, pages 119–135. Springer-Verlag, 2001. LNCS 2122.

[32] F. Rouillier and P. Zimmermann. Efficient isolation of polynomial’s real roots. J. Comput. Applied Math., 162:33–50,

2004.

[33] Brian T. Smith. Error bounds for zeros of a polynomial based upon gerschgorin’s theorems. J. ACM, 17(4):661–674,

1970.

[34] C. K. Yap. Fundamental Problems in Algorithmic Algebra. Princeton University Press, 1993.

34