ACS. Algorithms for Complex Shapes with Certified Numerics and Topology. Evaluation of results to different approaches in the 2D curved kernel. Ioannis Z.
ACS Algorithms for Complex Shapes with Certified Numerics and Topology
Evaluation of results to different approaches in the 2D curved kernel
Ioannis Z. Emiris Menelaos Karavelas
Athanasios Kakargias Constantinos Per. Tsirogiannis
ACS Technical Report No.: ACS-TR-123104-02 Part of deliverable: WP-III/D1 Site: NUA Month: 24
Project co-funded by the European Commission within FP6 (2002–2006) under contract nr. IST-006413
Evaluation of results to different approaches in the 2D curved kernel Ioannis Z. Emiris, Athanasios Kakargias, Menelaos Karavelas, Constantinos Per. Tsirogiannis Abstract We measure the efficiency of the recently extended Circular kernel 2 cgal package in relation with the 2D Apollonius graph application. We provide results of benchmarking for both of the new and the stand-alone version of the code. This allows us to quantify the performance of the new version of the kernel, based on a concrete application. The proposed version seems to accelerate the construction of the Apollonius graph when using exact number types, while the opposite happens if algebraic filtering with inexact number types is included. We plan to further investigate this discrepancy.
1
Introduction
The Apollonius graph 2 package constitutes the CGAL implementation of the algorithm for the construction of the 2D Apollonius diagram and the Apollonius graph (the Voronoi diagram of weighted points and its dual graph respectively). The geometric traits of this package were at first introduced with a stand-alone structure as they were dependent of a simple linear kernel from which imported basic geometric object types and operations. The essential for the algorithm representations of weighted points (Apollonius site 2 ) and of conics remained outside of the existing CGAL kernels. In the same way, the fundamental primitives of the application appeared only inside an internal namespace that was utilised only from the specific algorithm. The Circular kernel 2 package was created in order to offer an organised platform for CGAL applications that deal with objects of circular nature ( [EKP+ 04], [PT06]). Its first version consists of primitives and object types that are used by the Arrangement of 2D circular arcs, yet without being application specific. On the other hand, the Apollonius graph 2 package was introduced in CGAL before the first appearance of the 2D circular kernel in a public release. Hence, its main bulk of primitives and its basic Apollonius site 2 type were not included into any kind of the existing linear kernels.
2
What is measured
We take advantage of the Circular kernel 2 and extend it by importing 9 primtives from the area of Apollonius graph 2 plus the Apollonius site 2 definition renamed as Circular disk 2. These primtives have new (more general) semantics as they now depict operations on circular disks (further description in [EKKT07a]). 1
The proposed structure of the code is evindently more organised than the former one. The question is whether this reorganisation could affect the efficiency of the Apollonius graph application, decelerating its execution. We attempt to provide a justified answer by simulating experiments equivalent to the ones described in [EK04]. This task of evaluation was ”pending” in the first year of the ACS program.
3
The variants of the experiments
The code remains in C++ and is based on the CGAL internal releases that follow the 3.2 public version. The benchmarking took place on a Pentium-M processor of 1.70 GHz . The compiler used is GNU g++ version 4.1.2 and the compilation flags are : -O2, -march=pentium-m, -mtune=pentium-m and -DNDEBUG. The latter is used in all the cases except the ones that handle double arithmetic. The number types that we included in our experiments are: ◦ C++ bult-in double ◦ CGAL’s multi-precision floating point number type known as MP_Float ◦ The GNU multi-precision quotient Gmpq ◦ Quotients with numerators and denominators of the MP_Float type Most of the main predicates that appear in the Apollonius graph application are written in 2 versions. The first version ensures exact computations of signs with a number type that simulates a ring, which means is sufficient for the operators {+, −, ×}. The second version certifies computations of signs √ for expressions that include the operators {+, −, ×, /, }. These versions are denoted as POLYNOMIAL and SQRT respectively on the becnhmarking tables. An exact number type on SQRT is also exact on POLYNOMIAL. None of the aforementioned types is exact on SQRT, yet we use double arithmetic with SQRT as a point of reference. We attempted to conduct the experiments also with the Expr type of CORE but it proved be extremely slow for degenerate cases of large bitsize. The experiments were executed with the use of the Apollonius graph hierarchy 2 class that succeeds to construct the Apollonius graph in O(nlogn) rather than the Apollonius graph 2 class which completes the construction with quadratic complexity. With the exception of double arithmetic, for the rest of the number types we use filtering with intervals of doubles. At first, each predicate is executed with interval approximations of its arguments and, in cases of uncertainty, the version of the predicate with the exact number type is utilised [BBP01]. The input data is of 2 different categories:
2
• The centers of the Apollonius sites are random integers of bit size B = {10, 20, 30, 40, 50} and the radii are random non-negative integers of bit size b = {5, 10, 20, 30, 40}, always chosen so that b < B. We use the name INSQUARE for such data sets. • The centers of Apollonius sites lie on the parabola y = x2 and their radii are equal to the y-coordinate. The bit sizes used for the (integer) xcoordinate of their centers are b = {5, 10, 15, 20, 25} while the y-coordinate and the radius have bit size 2b. For such data sets, which are highly degenerate, we use the name ONPARABOLA. For each bit size and number type (filtered and non-filtered) we apply input sets of 104 , 105 and 106 sites . Because in almost every case there have to be hidden sites, we consider the presented running times as functions of the form T (n, h) where n is the actual number of input sites and h is the number of NON-hidden sites.
Figure 1: A possible data set of the INSQUARE category
3
4
Evaluating the overall algorithm
4.1 4.1.1
The INSQUARE input sets The kernelised version
n
Method
SQRT 104
POLYN.
INSQUARE
SQRT 105
POLYN.
SQRT 106
POLYN.
bmax Number type h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q
10 5720 0.16 0.18 19.02 8.88 36.27 0.55 0.62 0.56 27468 1.38 1.33 136.42 74.46 317.42 5.06 5.40 5.31 133457 17.12 17.18 1081.59 535.68 2714.32 60.86 59.91 60.03
20
30 40 T (n, h)[seconds] 9992 9992 9992 0.44 0.44 0.45 0.44 0.44 0.44 26.18 26.62 28.05 16.41 19.40 22.73 51.64 56.79 61.45 1.30 1.30 1.30 1.30 1.30 1.30 1.29 1.29 1.30 99346 99384 99414 4.73 4.33 4.38 4.90 3.92 5.29 274.68 281.79 293.32 168.85 200.24 236.46 541.20 595.46 652.35 14.02 13.76 13.78 13.23 13.26 13.77 12.56 14.07 13.49 938702 937712 939675 39.37 39.13 39.26 38.87 37.83 49.44 2958.85 3047.66 3075.72 1855.09 2169.58 2469.53 6216.24 6730.16 7859.23 128.61 122.16 124.23 131.94 124.66 130.58 123.95 120.88 123.04
Table 1: Benchmarks for the INSQUARE input sets using the proposed (kernelised) version of the code. The running times are portrayed as T (n, h), a function of the number of input sites n and the number of visible sites h. The blue colour indicates the cases of faster executions with the kernelised version, while the red colour indicates the cases where the stand-alone version constructs the diagram first. The “n/a” symbol denotes inability of termination due to assertion failures or invalid state of the final diagram, both being the outcome of inexact computations.
4
50 9992 0.45 0.44 30.06 22.87 61.69 1.29 1.30 1.30 99375 4.17 4.52 333.80 238.87 655.18 13.28 13.60 13.44 938866 38.42 41.02 3641.44 2542.99 7725.49 123.33 131.24 123.77
4.1.2
The stand-alone version
n
INSQUARE
104
105
106
bmax Number type h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q
10
Method
5720 0.14 0.12 19.56 9.50 39.42 0.35 0.39 0.36 27468 1.17 0.88 145.54 82.28 301.23 3.06 3.05 3.07 63 13.25 10.07 1051.35 632.33 2490.23 34.30 33.31 31.977
20
30 40 T (n, h)[seconds] 9992 9992 9992 0.33 0.34 0.34 0.30 0.29 0.30 26.25 26.70 28.11 17.64 20.68 24.12 54.22 59.37 64.23 0.88 0.87 0.88 0.88 0.88 0.88 0.88 0.88 0.88 99346 99384 99414 3.29 2.95 3.77 2.66 3.12 2.92 277.00 283.36 295.39 182.30 212.74 248.63 568.68 618.53 676.99 8.88 9.44 9.14 9.59 8.98 9.31 8.57 9.11 9.18 133457 938702 939675 25.04 27.49 25.23 22.10 25.85 23.53 2891.448 2951.15 3042.67 1935.28 2321.31 2631.13 6343.07 7053.36 7943.90 74.20 73.05 73.98 75.32 73.98 73.90 72.52 75.71 72.43
Table 2: Benchmarks for the INSQUARE input sets of the stand-alone approach of the code. The running times are portrayed as T (n, h), a function of the number of input sites n and the number of visible sites h. The “n/a” symbol denotes inability of termination due to assertion failures or invalid state of the final diagram, both being the outcome of inexact computations. Commenting on the running times of each version alone, (as also stated in [EK04]) there seem to be almost similar performances for bit sizes b > 10 for the INSQUARE category. This is due to the fact that the number of hidden sites remains more or less the same for those cases. It is also evident that the performance of the filters with the intervals is more than satisfactory. Comparisons between the 2 versions show that we have better results in the new version for “heavy” number types such as MP_Float and Quotient with MP_Float> but worse running times for double arithmetic and the filtered 5
50 9992 0.32 0.31 30.10 24.16 64.42 0.88 0.88 0.89 99375 2.96 2.62 341.18 250.77 674.54 9.26 8.36 9.16 938866 25.30 23.42 3772.59 2668.35 7733.42 74.40 77.04 71.16
versions. We attempt to provide an explanation for this strange phenomenon in the last section of the current report.
4.2 4.2.1
The ONPARABOLA input sets The kernelised version
n
Method
SQRT 104
POLYN.
ONParabola
SQRT 105
POLYN.
SQRT 106
POLYN.
bmax Number type h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q h double double gmpq mpfloat Q filter + gmpq filter + mpfloat filter + Q
10 63 0.05 0.05 2.77 1.52 6.00 0.18 0.18 0.18 63 0.48 0.48 27.40 15.01 59.59 1.73 1.76 1.75 63 4.72 4.77 272.16 150.26 593.33 17.52 17.42 17.55
20
30 40 T (n, h)[seconds] 2028 9269 9980 n/a n/a 8.22 15.78 16.40 5.02 10.19 11.90 18.6 35.70 38.66 0.53 5.83 10.55 0.52 4.30 9.05 0.56 9.29 18.43 2047 51262 97636 n/a n/a 76.74 157.23 207.38 47.34 101.97 150.29 178.56 363.28 496.07 4.60 30.68 155.71 4.62 24.16 139.10 4.62 45.33 275.74 2047 65535 795149 n/a n/a 757.97 1538.43 2630.67 472.28 1025.95 1933.65 1779.59 3708.46 6428.56 44.99 127.64 2286.68 44.87 119.00 2113.93 45.16 144.32 3900.01
Table 3: Benchmarks for the ONPARABOLA input sets using the proposed (kernelised) version of the code. The running times are portrayed as T (n, h), a function of the number of input sites n and the number of visible sites h. The blue colour indicates the cases of faster executions with the kernelised version, while the red colour indicates the cases where the stand-alone version constructs the diagram first. The “n/a” symbol denotes inability of termination due to assertion failures or invalid state of the final diagram, both being the outcome of inexact computations.
6
50 10000
16.84 13.36 41.10 28.61 28.16 54.42 99939
214.80 170.14 531.09 331.51 326.03 626.44 992546
2880.76 2289.91 7125.17 4991.48 4774.18 8849.10
4.2.2
The stand-alone version
n
ONParabola
104
105
106
bmax Number type h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q h SQRT double double gmpq mpfloat Q POLYN. filter + gmpq filter + mpfloat filter + Q
10
Method
63 0.04 0.03 2.80 1.62 6.22 0.10 0.10 0.10 63 0.40 0.33 27.70 16.01 61.59 0.98 1.00 1.01 63 4.02 3.27 276.50 160.03 614.93 9.76 10.04 10.06
20
30 40 T (n, h)[seconds] 2028 9269 9980 n/a n/a 8.28 15.90 16.56 5.30 10.74 12.48 19.15 36.69 39.65 0.33 5.56 9.73 0.32 4.17 8.78 0.38 9.26 18.35 2047 51262 97636 n/a n/a 77.37 157.96 209.06 49.55 107.14 157.27 183.56 372.90 508.65 2.59 27.37 142.32 2.63 21.20 136.18 2.70 42.70 276.46 2047 65535 795149 n/a n/a 768.14 1550.89 2662.13 496.63 1070.61 2009.23 1830.07 3799.93 6589.14 25.15 83.34 1979.64 25.84 76.87 1942.98 25.86 102.81 3851.78
Table 4: Benchmarks for the ONPARABOLA input sets of the stand-alone approach of the code. The running times are portrayed as T (n, h), a function of the number of input sites n and the number of visible sites h. The “n/a” symbol denotes inability of termination due to assertion failures or invalid state of the final diagram, both being the outcome of inexact computations. For both of the versions, unlike the previous data category, the running times rise evidently with the increase of the bit size . Moreover, the filters work much better than the simple traits classes for bit sizes 10-30, quite better in most of the cases of bit size 40 and evidently worse when then bit size equals to 50. Again, the kernelised version runs faster than the stand-alone version for exact yet slow number types but is less efficient when it comes for filtered versions and doubles. This is profitable only for the largest bit sizes since for 7
50 10000
16.98 13.96 42.04 25.33 27.60 54.13 99939
216.30 177.46 543.18 290.92 317.98 622.06 992546
2908.95 2386.75 7382.14 4202.35 4574.80 8951.42
such degenerate input the filters are not effective at all. Yet, the difference in the running times of the filtered cases is quite small except when the input sites are n = 1000000 and the bit sizes in the range 10-30.
5
Conclusion
As it was mentioned before, the proposed kernelised structure for the code of the 2D Apollonius graph application is more efficient in matters of speed than the stand-alone structure for exact, thus time-worthy number types. On the other hand it is slower than the stand-alone approach when using filtered traits and double arithmetic. Actually, this decrease in speed in the filtered cases is a result of the utilisation of a kernel that uses interval approximations. So, why the new approach is faster when it uses exclusively kernels of exact NTs and slower when it also includes instantiations of kernels with inexact number types? The answer is strongly related to the change of the type of kernel to which the traits class is templated. In the stand-alone version the traits classes are templated to a linear kernel and in our kernelisation we switch to a model of the Circular kernel 2. One may justify that in a simple step; In every benchmarking programm of the stand-alone version, free of any changes that we propose, a substitution of the kernel included from : CGAL::Simple_cartesian
Kernel;
to : CGAL::Simple_cartesian CGAL::Algebraic_kernel_for_circles_2_2 CGAL::Circular_kernel_2
L_kernel; Al_kernel; Kernel;
will cause the running time of the application to change towards the direction that we desrcibed above. The 2D circular kernel is a superset of the linear kernel to which it is templated, so every application that is executed with the latter may as well be executed with the former. (except when there are technical problems of instantiation of the circular kernel e.g. the Root of 2 traits are not defined for a number type such as GmpZ). Eventually, the proposed approach certainly offers a gain by means of genericity of the code structure while the advantages in matters of execution times are rather controversial. There is an obvious improvement in speed when an exact number type is used, whereas there is also a decrease when the filtered versions are chosen. The differences in speed are evident only when we combine large bit sizes (>30) with large numbers of input sites (≤ 105 ) and there is the special case when the filters fail in the degenerate ONPARABOLA case for max bit size b=50 and input sites n = 106 . We intend in the near future to fill the gap for the filtered cases by offering additional geometric filtering with bounding boxes ([EKKT07b]).
8
References [BBP01]
H. Bronnimann, C. Burnikel, and S. Pion. Interval arithmetic yields efficient dynamic filters for computational geometry. Discrete Applied Mathematics, 109:25–47, 2001.
[EK04]
Ioannis Emiris and Menelaos Karavelas. The predicates of the apollonius diagram: algorithmic analysis and implementation. Computational Geometry: Theory and Applications, July 2004.
[EKKT07a] Ioannis Z. Emiris, Athanasios Kakargias, Menelaos Karavelas, and Constantinos Per. Tsirogiannis. Cgal package for 2d curved kernel. Technical Report ACS-TR-123203-03, National University of Athens, 2007. [EKKT07b] Ioannis Z. Emiris, Athanasios Kakargias, Menelaos Karavelas, and Constantinos Per. Tsirogiannis. Cgal package for 2d filtered curved kernel. Technical Report ACS-TR-243404-01, National University of Athens, 2007. [EKP+ 04]
Ioannis Z. Emiris, Athanasios Kakargias, Sylvain Pion, Monique Teillaud, and Elias P. Tsigaridas. Towards an open curved kernel. In Proceedings of the 20th Symposium of Computational Geometry., pages 438–446, 2004.
[PT06]
Sylvain Pion and Monique Teillaud. Cgal package for 2d curved kernel. Technical Report ACS-TR-123203-01, INRIA, 2006.
9
