ACS Prototype implementation of the algebraic kernel

Download PDF
0 downloads 0 Views 239KB Size Report
Comment
A number type of this concept represents elements of an integral domain, i.e. a ring ..... intersection still contains both roots, it might be the case that the algebraic .... Moreover NiX::Coercion traits provides access to a common super type if a ...
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 C GAL 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 originally in Maple and later on within the S YNAPS 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 implementation 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 C GAL package Algebraic kernel for circles 2 2 aimed at providing the necessary algebraic functionality required for treating circular arcs. 2. Our experience in implementing algebraic numbers in environments like Maple and the S YNAPS 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 polynomials. 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 C GAL package, to be included in the next public release of C GAL. 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 S YNAPS 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 S YNAPS 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 S YNAPS and our current specifications of the algebraic kernel. In Section 4 we present N UMERI X, the library of the E XACUS 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 C GAL.

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 C GAL 2D Circular Kernel package (cf. Technical Report ACS-TR-123203-01 [30]). It follows the interface 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 C GAL manual corresponding to the models of the main algebraic concepts presented in [30]. In the spirit of the C GAL 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

Algebraic kernel for circles 2 2

Class

#include Is Model for the Concept AlgebraicKernelForCircles

4

Polynomial 1 2

Class

#include Is Model for the Concept AlgebraicKernelForCircles::Polynomial 1 2

5

Polynomial for circles 2 2

Is Model for the Concept AlgebraicKernelForCircles::PolynomialForCircles 2 2

6

Class

#include

Root of 2

Class

#include Is Model for the Concept AlgebraicKernelForCircles::RootOf 2

7

Root for circles 2 2

Class

#include 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 S YNAPS 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::result_t typedef typename RationalOf::result_t typedef typename ApproximationOf::result_t typedef typename IntervalOf::result_t typedef typename IntervalOf::result_t

RT; FT; XT; FIT; XIT;

// // // // //

Ring Field Aproximate Field interval Approximate interval

typedef typename HasFunction::gcd typedef typename HasFunction::isqrt typedef typename HasFunction::sqrt

Has_gcd; Has_isqrt; Has_sqrt;

typedef typename HasProperty::exact typedef typename HasProperty::ring typedef typename HasProperty::field

Is_exact; Is_Ring_type; Is_Field_type;

typedef NumberTraits };

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 2ck , 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 S YNAPS, however the implementation choices are independent of the S YNAPS. 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 S YNAPS there are several solver classes, their interface is as follows template < class T > struct SOLVER { typedef NumberTraits::RT RT; typedef NumberTraits::FT FT; typedef NumberTraits::FIT FIT; typedef UPolDse typedef root_of ... };

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 struct root_of { NumberTraits::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 interval 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 (precomputed) Sturm sequences. Sturm solver is a solver for arbitrary degree polynomial based on an implementation of various algorithms about Sturm sequences.

11

4

N UMERI X towards an Algebraic Tool Box

For the goal of propagating design experiments learned in E XACUS [15] towards the planned AlgebraicKernel and AlgebraicToolBox within C GAL, this part of the report will concentrate on the N UMERI X library. 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 E XACUS project, as well as the general context and motivation behind the N UMERI X 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 N UMERI X, we therefore provide a rich interface layer of number type concepts. Our interface extends the interface in C GAL [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 C GAL.

4.1.1

Algebraic Number Type Concepts

Figure 1 shows the refinement relationship of the main number type concepts in N UMERI X. 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 domains, 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. Each concrete number type NT knows the (most refined) concept it fulfills, this is encoded in NT traits::Algebra type. The usual arithmetic and comparison operators are required to be realized via C++ operator overloading for ease of use. The division operator is reserved for division in fields. All other unary STL Assignable STL DefaultConstructible

IntegralDomainWithoutDiv

STL EqualityComparable

IntegralDomain

UFDomain

EuclideanRing

Field

FieldWithSqrt

Figure 1: The number type concepts in E XACUS. The arcs show the refinement relationship among number types. In particular, each number type is a refinement from three classical S TL concepts. 12

(e.g. sqrt) and binary functions (e.g. gcd, div) must be models of the well known S TL-concepts AdaptableUnaryFunction or AdaptableBinaryFunction concept and local to a traits class (e.g., NT traits::Sqrt ()(x)). This allows us to profit maximally from all parts in the S TL 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 S TL concepts Assignable, DefaultConstructible, EqualityComparable. It thus offers a default and a copy constructor, assignment =, and (in)equality ==, !=, with S TL-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 traits::NT • NT traits::Algebra type, indicates the most refined algebraic number type concept, NT fulfills Required functors in NiX::NT traits: • 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 operation. We intend to reserve the operator / for use with a Field. Nevertheless, some non-field models of IntegralDomain have one. NiX::NT traits 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 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 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 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 S TL concepts EqualityComparable and LessThanComparable. It thus offers operator ==, !=, , = with S TL-compatible semantics. If a number type is a model of both concepts IntegralDomainWithoutDiv and RealComparable then the number represented by an object of this type is the same for both arithmetic and com1 FieldWithSqrt 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 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 containing x

4.2 Main Types in N UMERI X We next discuss the main types provided by the N UMERI X 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 represents polynomials with coefficients of type NT. Depending on the capabilities of NT, the polynomial class adapts and picks the best implementation for certain 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. The table to the right shows the resulting 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-

NT IntegralDomainWithoutDiv IntegralDomain UFDomain, EuclideanRing Field, FieldWithSqrt

15

⇒ ⇒ ⇒ ⇒

Polynomial IntegralDomainWithoutDiv IntegralDomain UFDomain EuclideanRing

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 multivariate). 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 metaprogramming 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 B´ezout matrix [17, 1]. Evaluating a B´ezout determinant with the method of Berkowitz [31] can be faster than the Subresultant PRS for bivariate polynomials of small degrees over the integers. The B´ezout determinant can also express subresultants, see e.g. [18, 24, 1].

4.2.2

Root Isolators

An important design rational of N UMERI X 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 2 This 3 see

form of constructing multivariate polynomials is justified for low degrees. 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 N UMERI X library. All listed isolators are template classes, e.g. possible coefficient types of the Descartes isolator are the integers, rationals or even a NiX::Sqrt extension4 type. Models of the RootIsolator concept provided by N UMERI X: • NiX::Descartes Implements the Descartes Method [9, 32, 2] which is known to be the best method for squarefree 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 IntegralDomainWithoutDiv and 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 4 For 5 In

NiX::Sqrt extension see section 4.2.5 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 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 expensive 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 particular 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. 6 Other

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

7 NTX

18

4.2.4

NiX::Real roots

An instance of the class NiX::Real roots< AlgebraicReal, RootIsolator >9 provides operators 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 polynomials 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 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 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 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 constructible from Root. The number type NT must be at least a model of the IntegralDomainWithoutDiv concept. For all operations involving division, the IntegralDomain concept is required. The table to the right shows the re- NT Sqrt extension sulting algebraic type with respect to IntegralDomainWithoutDiv ⇒ IntegralDomainWithoutDiv ⇒ IntegralDomain the algebraic type of NT. Both NT and IntegralDomain UFDomain, EuclideanRing ⇒ IntegralDomain Root can themselves be an instance Field, FieldWithSqrt ⇒ Field of NiX::Sqrt extension, yielding RealComparable ⇒ RealComparable a nested extension. Note that the extension 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 9 The

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

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 extension 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 provides standard functionality on matrices and vectors. Beside the determinants, the linear algebra does not play an important role within E XACUS, hence we only touch it briefly here. An instance of the class NiX::Linear algebra 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. determinant, 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 is useful to add the two infinite values to a comparable number 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 requirement that NT has to represent the reals. NiX::Compactified is in particular used to represent unbounded arcs within S WEEP X in a convenient way. For more details see [6]. 12 It

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

20

• Tendency The class NiX::Tendency 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, NiX::Tendency 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, N UMERI X 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 number 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 this is indicated by: • Fraction traits::Is decomposable, either LiS::True tag or LiS::False tag If it is the case NiX::Fraction traits 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 N U MERI X, 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 this is indicated by: • Modular traits::Is convertible, either LiS::True tag or LiS::False tag If it is the case NiX::Modular traits provides: • Modular traits::Modular NT, the result type with respect to the number type NT • Modular traits::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 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. 13 just

think of NiX::Polynomial

22

It provides: • NiX::Coercion traits::RET, the result type of the type coercion of A and B • NiX::Coercion traits::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::RET ≡ A • Coercion traits::RET ≡ Coercion traits::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::RET ≡ double • Coercion traits::RET ≡ Integer14 Moreover NiX::Coercion traits provides access to a common super type if a direct cast is not possible, e.g.: • Coercion traits ::RET ≡ Polynomial • Coercion traits ::RET ≡ Sqrt extension • Coercion traits ::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 class, allowing the evaluation of a NiX::Polynomial by some type NTX. > > > > > > > > > > > >

template typename Coercion traits::RET evaluate(const NTX& x) const { typedef Coercion traits 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; } 14 For

the respective types of the L EDA, C ORE , G MP and other libraries. 15 Real represents some model of the FieldWithSqrt and RealComparable

23

concepts i.e. leda::real or CORE::Expr.

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 ArithmeticTraits concept provides a well-formed collection of all scalar number types needed in the higher E XACUS libraries (C ONI X, Q UADRI X, etc.). All basic 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 N UMERI X library. It is guaranteed that: • Arithmetic traits::Rational, explicit constructible from Integer • Arithmetic traits::FieldWithSqrt, explicit constructible from Integer and Rational N UMERI X currently provides two models of the ArithmeticTraits concept: • NiX::LEDA Arithmetic traits, defined if L EDA is available, using leda::integer, leda::rational and leda::real • NiX::CORE Arithmetic traits, defined if C ORE is available, using CORE::BigInt, CORE::BigRat and CORE::Expr

4.5 Lessons Learned and Further Work We consider N UMERI X 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 N U MERI X 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 N UMERI X library is currently organized within the namespace NiX. Therefore all template classes and functions within N UMERI X 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 N UMERI X. 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, providing access to the respective model of ArithmeticTraits. We currently see this as the preferable solution for the N UMERI X library since it is organized in a namespace. The second option is to collect most of the functionality of NiX within 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.

16 In

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 polynomials. 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 C GAL. However, the existing C GAL 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 C GAL are a first step towards providing more structure in C GAL 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 E XACUS 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 described in Section 4.1.1. For the reasons we have implemented temporarily a few helper classes listed below: • The CGAL::Number type category 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 integral domain number type, a field number type or a Euclidean ring number type. • The CGAL::Arithmetic traits Class, which provides the connection between an integral 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 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 C GAL 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. 17 The CGAL::Arithmetic traits class has similar semantics to the ArithmeticTraits concept of Section 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 C GAL : The bottom-most layer uses the existing C GAL 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 appropriate 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 algebraic 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 selfcontained 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

Polynomial Toolbox

Number Type Layer

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 Toolbox operates, as well as the Polynomial Toolbox itself. Polynomials are required to come with standard operations (not shown in this report), such as addition, subtraction 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 0 (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 polynomial 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 Polynomial_toolbox { protected: typedef Polynomial_toolbox typedef Number_type_category

Self; category_type;

public: typedef typename P::template Rebind::Other Polynomial; typedef typedef typedef typedef typedef typedef typedef typedef typedef typedef typedef

Shift Negate Invert Derivative Translate Quotient_remainder PQuotient Remainder Pseudo_quotient Pseudo_remainder Pseudo_quotient_remainder

Shift; Negate; Invert; Derivative; Translate; Quotient_remainder; Quotient; Remainder; Pseudo_quotient; Pseudo_remainder; Pseudo_quotient_remainder;

typedef typedef typedef typedef typedef typedef typedef typedef typedef typedef

Sturm_sequence Sturm_sequence_q Euclidean_Sturm_sequence Euclidean_Sturm_sequence_q Subresultant_Sturm_sequence Monic_Sturm_sequence Reduced_Sturm_sequence Primitive_part_Sturm_sequence Primitive_part_Sturm_sequence_q Sign_at

Sturm_sequence; Sturm_sequence_q; Euclidean_Sturm_sequence; Euclidean_Sturm_sequence_q; Subresultant_Sturm_sequence; Monic_Sturm_sequence; Reduced_Sturm_sequence; Primitive_part_Sturm_sequence; Primitive_part_Sturm_sequence_q; Sign_at;

// rebind mechanism for the toolbox; this way I can get toolboxes // with other number types and polynomials template struct Rebind { typedef Polynomial_toolbox Other; }; template T get() const { return T(); } template T get(const A1& a1) const { return T(a1); } template 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 successive 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 discussion 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 polynomial. 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 Algebraic_toolbox : public Polynomial_toolbox { private: typedef typename ArithmeticTraits::Integral_domain_number_type IDNT; typedef typename ArithmeticTraits::Field_number_type FNT; typedef Polynomial_toolbox Base; public: typedef ArithmeticTraits typedef IDNT typedef FNT

Arithmetic_traits; Integral_domain_number_type; Field_number_type;

typedef typename P::template Rebind::Other typedef Polynomial_toolbox

Polynomial; Polynomial_toolbox;

private: typedef Solver_traits 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 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 0 (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 defining polynomial. These operations should include addition, subtraction, multiplication and possibly division (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 interval 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 parameterization 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 Computation 22, pages 565–578, 1968. [4] E. Berberich, A. Eigenwillig, M. Hemmer, S. Hert, K. Mehlhorn, and E. Sch¨omer. 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. Sch¨omer, 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 Sch¨omer, 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. Interface specification of algebraic kernel. Technical Report ACS-TR-123101-01, INRIA, NUA, MPI, 2006. [8] H. Br¨onnimann, 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, Saarbr¨ucken, Germany, 2003. [12] A. Eigenwillig, L. Kettner, W. Krandick, K. Mehlhorn, S. Schmitt, and N. Wolpert. A Descartes algorithm for polynomials 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 Sch¨omer, 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 S YNAPS). Technical Report ACSTR-123203-02, NUA, 2006. [15] The E XACUS project. www.mpi-sb.mpg.de/projects/EXACUS/. [16] A. Fabri, G.-J. Giezeman, L. Kettner, S. Schirra, and S. Sch¨onherr. 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. Birkh¨auser, 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 u¨ ber Zahlentheorie. Springer, 2nd edition, 1964. [22] M. Hemmer, L. Kettner, and E. Sch¨omer. Effects of a modular filter on geometric applications. Technical Report ECG-TR-363111-01, MPI Saarbr¨ucken, 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. SpringerVerlag. [24] X. Hou and D. Wang. Subresultants with the B´ezout 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. N¨aher. 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. N¨aher. 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