ANEXOS

The Exact Geometric Computation paradigm has been been widely successful because it allows to implement algorithms as described in theory and leads to robust implementations. Other approaches to the robustness problem are less attractive as they require to re-invent algorithms or compute only approximate solutions. But, as

in the case of vroni, they may still lead to very efficient implementations which are reliable in practice. Provable guarantees on robustness and output quality remain an issue.

Libraries for Exact Geometric Computation. Many geometric algorithms have been implemented successfully following the Exact Geometric Computation paradigm and are now available to the scientific community, industry, and the general public. Among the many approaches, the libraries leda [53, 58] and cgal [16] stand out. Most of the techniques discussed in this chapter are part of one or both libraries. Both leda and cgal can be considered a product of Algorithm Engineering in Computational Geometry.

leda is the first library to follow the Exact Geometric Computation paradigm rigorously. The decision for Exact Geometric Computation was made following disappointing results with floating-point based implementations and the finding that problem dependent approaches to robustness are unsuitable in a library, which should be open to many applications. leda contains an extensive collection of geometric algorithms and data-structures both in two and three dimensions. Tools for Exact Geometric Computation are provided, too. leda contains exact number types and interval arithmetic, as well as exact geometric kernels. Besides geometry, leda also provides an extensive set of combinatorial algorithms.

cgal concentrates exclusively on geometry. It is the product of more than 15 years of work by the computational geometry community and now contains a much larger body of geometric algorithms than leda. cgal is a more recent development, too, and could therefore take advantage of

C++

’s template feature which was not available when the development of leda started. By means of templates, cgal very nicely separates the arithmetic layer, the layer of geometric primitives and the combinatorial layer. The three layers can be combined easily and quite independently. cgal is not only the product of Algorithm Engineering but, due to its generic design, makes further Algorithm Engineering much easier and thereby possible. This thesis has profited immensely from cgal, almost all experiments use kernels and geometric algorithms from cgal.

Cost of Exact Geometric Computation. Despite the apparent advantages of Exact Geometric Computation, practitioners still complain about its lack of efficiency. Often, they compare the efficiency to the speed of floating-point based implementa- tions, but this comparison is not quite fair, since floating-point based implementations are not robust. Nearly all papers presenting new techniques for Exact Geometric Computation compare their new approach experimentally to other methods for per- formance. They often include straightforward floating-point based implementations too, since they provide some sort of lower bound. But, not surprisingly, as soon as problems are more challenging, the times for the floating-point based implementation are missing because of robustness problems. We now summarize some experimental results comparing Exact Geometric Computation approaches to each other and to other robust and non-robust approaches.

The input size of geometric algorithms, basis for asymptotic performance analysis, is usually the number of basic geometric input objects. The input size affects the number of predicate calls, not the time taken by a single predicate. Thus, exchanging predicate implementations in a geometric algorithm alters the running time roughly by a constant factor, independently of the input size. Assuming all predicates in an algorithm are sped up by a factor s, the algorithm will be sped up by a constant factor somewhat smaller than s, regardless of the input size. In case of adaptive predicates, the average speed up factor for a predicate depends on the number of nearly degenerate predicate evaluations. Hence, experiments are usually run for several inputs with varying number of degenerate configurations, but not so much for inputs of varying input size.

Predicates with Integer and Rational Numbers. Michael Karasick, Derek Lieber and Lee Nackman [49] are among the first to report on the use of exact arithmetic in geometric algorithms. They implement an algorithm for the computation of the 2D Delaunay triangulation of input points with floating-point coordinates. They report a slowdown factor of 10 000 when naïvely using rational arithmetic, compared to a floating-point based implementation. Clearly, with such a performance hit, one would abandon Exact Geometric Computation despite all problems with different approaches. Karasick et al. manage to improve the slowdown to a factor of 5, by using first filtering techniques in an adaptive scheme, and modifying the algorithm to use less arithmetic.

Several authors report on the efficiency of their predicate implementations for the computation of 2D and 3D Delaunay triangulations. Fortune and van Wyk[29] compute the 2D Delaunay triangulation of integer points. Compared to a floating- point based implementation, their predicates achieve a slight decrease in running time for input sets without degeneracies, for nearly co-circular points they report an increase in running time by 65%. Shewchuk[104] computes 2D and 3D Delaunay triangulation of points with floating-point coordinates. In the two dimensional case, the overhead for exactness is 8% to 30% for input sets with varying amounts of degenerate configurations, in the three dimensional case the overhead is between 30% for uniformly distributed points and a factor of 11 for co-spherical points. Devillers and Pion [23] compute the 3D Delaunay triangulation of points with floating-point coordinates for some uniformly at random and real world input data sets. For Shewchuk’s predicates they report an increase in running time of 40% compared to floating-point predicates. Their own best exact predicates achieve an overhead of 8% to 25% only. Devillers and Pion include expression dag based number types

CORE::Expr

,

leda::real

, and

Lazy_exact_nt

in their experiments too. For random input data,

CORE::Expr

is the fastest among the three, while for real world data

Lazy_exact_nt

wins. Comparing to Shewchuk’s adaptive predicates, the slowdown is at least a factor of 10 in any case.

The predicates for all problems mentioned so far consist of small polynomial expressions. Evidently, Exact Geometric Computation has been achieved for them

at an increased runtime cost well below a factor of two, except for cases with many degenerate input configurations. These are however the cases where Exact Geometric Computation is needed the most. This is a small price to pay for correct results and tolerable in all but the most runtime restricted applications. For these applications, expression dag based number types do not appear to be efficient.

Predicates with Algebraic Numbers. Christoph Burnikel, Rudolf Fleischer, Kurt Mehlhorn and Stefan Schirra[10] somewhat artificially design problems that require the power of expression dag based number types. For example, they first compute all intersection points induced by a set of lines or circles and then compute the convex hull of these intersection points. Here,

leda::real

outperforms both

CORE::Expr

and non-adaptive predicates based on exact number types. With respect

to a floating-point based implementation, the slowdown is a factor of 15 to 20 for circles, and 25 to 60 for lines.

For problems involving algebraic numbers comparing exact approaches to non- robust floating-point based approaches is meaningless, even when the input data are hardware numbers. The robustness problems become so severe that no straightfor- ward floating-point based implementation might work. Because exact approaches are still felt to be too slow though, it is very interesting to look for the most efficient exact approach.

Ioannis Emiris, Athanasios Kakargias, Sylvain Pion, Monique Teillaud, Elias Tsigaridas[26] present a new geometric kernel for the computation of arrangements of circles and circular arcs. To handle algebraic numbers occurring in this problem they either employ

CORE::Expr

or

leda::real

, or static algebraic predicates based on integer and rational number types[22, 27]. In their experiments, they compute arrangements for randomly generated input sets and structured input sets with many degeneracies. Among expression dag based number types,

leda::real

always outperforms

CORE::Expr

. However,

leda::real

is a factor of two to four slower than static algebraic predicates for an optimal choice of number type.

Menelaos Karavelas [50] reports on his implementation of segment Voronoi diagrams, another problem involving algebraic numbers. In his experiments he computes segment Voronoi diagrams for randomly generated data, structured data with many degeneracies and real world data. For predicates he uses

leda::real

, and alternatively static algebraic predicates based on rational numbers from gmp. Both variants are combined with a floating-point filter and achieve essentially the same running time. The reason might be, that the floating-point filter computes most of the signs.

More recent results involving expression dag based number types are presented by Martin Held and Willi Mann[43]. Among other problems, they examine the problem of computing the Voronoi diagram of segments, using robust and exact approaches. The first competitor is their own code vroni, based on floating-point numbers as well as bigfloat numbers from mpfr. The mpfr based variant uses fixed precision which is higher than that of hardware arithmetic. It is therefore more

likely to produce correct topology and computes more accurate numerical data. The second competitor is the implementation of segment Voronoi diagrams by Karavelas, combined with

CORE::Expr

as exact number type. As input data, Held and Mann use a data base of roughly 20 000 input sets. The results are, that both Karavelas implementation with

CORE::Expr

, and vroni based on mpfr are on average a factor of 50 – 80 slower than vroni with floating-point based predicates. Furthermore, for Karavelas implementation, the running times are much more scattered and some outliers did not even finish computing in the time limit set for the experiments. A slowdown by a factor of 50 seems to be a hard price to pay for exactness or more accuracy.

These results might disencourage an implementor to use expression dag based number types, despite other advantages. For linear problems, Exact Geometric Computation seems achievable at a slowdown of less than two, while the cost for using expression dag based number types is much higher. For problems involving algebraic numbers, where it is reasonable to spend more time, static algebraic predicates appear to be the better choice. In some cases, non-exact but much faster implementations like vroni may be used.

On the other hand, many of the experimental results given here are outdated. Linear problems rely on floating-point filters for speed. But floating-point filters are unlikely to have been improved since then or to be improved in the future. The reasons are, that they are quite simple and for easy predicates are so fast that there is just no room for improvement. Expression dag based number types however are internally quite complicated and it is reasonable to believe that progress can be made to narrow the gap.

The issue with floating-point filters for arithmetically more demanding problems is not lack of speed, but that floating-point filters fail more frequently and computation with software number types becomes necessary. But adaptivity beyond the limits of dynamic floating-point filters is only available in expression dag based number types. The running times achieved with static algebraic predicates are not so small, as to seem unreachable. The main goal of this thesis is, to improve expression dag based number types to close the performance gap to other, more specialized approaches.

In document PROYECTO EDUCATIVO INSTITUCIONAL (página 96-99)