From b3af96caa1cad9c3bd4483537bf3dcba48e68c80 Mon Sep 17 00:00:00 2001 From: albert-github Date: Tue, 4 Jul 2023 16:23:14 +0200 Subject: [PATCH] issue #7454 Consistency of BigO notations Create `cgalBigO` marco and used it. (`The macro `cgalBigOLarge` is for special situations where we need bigger round brackets) --- AABB_tree/include/CGAL/AABB_tree.h | 2 +- .../doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h | 2 +- .../doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h | 2 +- .../Arrangement_on_surface_2.txt | 18 ++--- .../CGAL/Arr_trapezoid_ric_point_location.h | 4 +- .../CGAL/Arr_polycurve_basic_traits_2.h | 2 +- .../Barycentric_coordinates_2.txt | 22 +++--- .../CGAL/Approximate_min_ellipsoid_d.h | 2 +- .../CGAL/Min_sphere_of_spheres_d.h | 2 +- .../CGAL/rectangular_p_center_2.h | 2 +- .../Concepts/MinSphereOfSpheresTraits.h | 2 +- .../Box_intersection_d/Box_intersection_d.txt | 8 +- .../CGAL/box_intersection_d.h | 12 +-- .../Combinatorial_map/Combinatorial_map.txt | 2 +- .../include/CGAL/Combinatorial_map.h | 2 +- .../doc/Cone_spanners_2/Cone_spanners_2.txt | 6 +- .../Convex_decomposition_3.txt | 4 +- .../PackageDescription.txt | 2 +- .../include/CGAL/convex_decomposition_3.h | 4 +- .../doc/Convex_hull_2/CGAL/ch_akl_toussaint.h | 2 +- .../doc/Convex_hull_2/CGAL/ch_bykat.h | 2 +- .../doc/Convex_hull_2/CGAL/ch_eddy.h | 2 +- .../doc/Convex_hull_2/CGAL/ch_graham_andrew.h | 4 +- .../doc/Convex_hull_2/CGAL/ch_jarvis.h | 4 +- .../doc/Convex_hull_2/CGAL/convex_hull_2.h | 8 +- .../Convex_hull_2/CGAL/convexity_check_2.h | 4 +- .../doc/Convex_hull_2/Convex_hull_2.txt | 12 +-- .../Convex_hull_3/CGAL/convexity_check_3.h | 2 +- .../doc/Convex_hull_d/CGAL/Convex_hull_d.h | 2 +- .../Developer_manual/Chapter_intro.txt | 2 +- .../Developer_manual/Chapter_kernels.txt | 2 +- .../doc/resources/1.8.13/BaseDoxyfile.in | 4 +- .../doc/resources/1.9.6/BaseDoxyfile.in | 4 +- .../doc/Generalized_map/Generalized_map.txt | 2 +- .../include/CGAL/Generalized_map.h | 2 +- .../CGAL/random_convex_hull_in_disc_2.h | 4 +- .../doc/Generator/CGAL/random_convex_set_2.h | 4 +- .../doc/Generator/CGAL/random_polygon_2.h | 4 +- .../doc/HalfedgeDS/CGAL/HalfedgeDS_default.h | 2 +- .../doc/HalfedgeDS/CGAL/HalfedgeDS_list.h | 2 +- .../doc/Heat_method_3/Heat_method_3.txt | 4 +- .../CGAL/Largest_empty_iso_rectangle_2.h | 4 +- .../Inscribed_areas/CGAL/extremal_polygon_2.h | 12 +-- .../CGAL/Largest_empty_iso_rectangle_2.h | 2 +- .../CGAL/Interval_skip_list.h | 6 +- .../CGAL/Kernel_d/Aff_transformation_d.h | 4 +- .../doc/Kernel_d/CGAL/Kernel_d/Direction_d.h | 4 +- .../doc/Kernel_d/CGAL/Kernel_d/Hyperplane_d.h | 4 +- Kernel_d/doc/Kernel_d/CGAL/Kernel_d/Line_d.h | 6 +- Kernel_d/doc/Kernel_d/CGAL/Kernel_d/Point_d.h | 4 +- Kernel_d/doc/Kernel_d/CGAL/Kernel_d/Ray_d.h | 4 +- .../doc/Kernel_d/CGAL/Kernel_d/Segment_d.h | 6 +- .../doc/Kernel_d/CGAL/Kernel_d/Sphere_d.h | 8 +- .../doc/Kernel_d/CGAL/Kernel_d/Vector_d.h | 4 +- .../Matrix_search/CGAL/sorted_matrix_search.h | 2 +- .../CGAL/Polygon_convex_decomposition_2.h | 8 +- .../CGAL/Polygon_vertical_decomposition_2.h | 4 +- ...mall_side_angle_bisector_decomposition_2.h | 2 +- .../doc/Minkowski_sum_2/Minkowski_sum_2.txt | 10 +-- .../Minkowski_sum_2/AABB_tree_with_join.h | 2 +- .../CGAL/Polygon_convex_decomposition_2.h | 6 +- .../doc/Minkowski_sum_3/Minkowski_sum_3.txt | 2 +- .../include/CGAL/minkowski_sum_3.h | 2 +- Miscellany/doc/Miscellany/CGAL/Union_find.h | 2 +- .../doc/Miscellany/CGAL/Unique_hash_map.h | 2 +- Miscellany/doc/Miscellany/Miscellany.txt | 4 +- Nef_2/doc/Nef_2/CGAL/Nef_polyhedron_2.h | 6 +- Nef_S2/doc/Nef_S2/CGAL/Nef_polyhedron_S2.h | 2 +- Orthtree/doc/Orthtree/Orthtree.txt | 2 +- .../doc/Partition_2/CGAL/is_y_monotone_2.h | 2 +- .../doc/Partition_2/CGAL/partition_2.h | 10 +-- .../Partition_2/CGAL/partition_is_valid_2.h | 6 +- .../CGAL/polygon_function_objects.h | 6 +- .../doc/Partition_2/PackageDescription.txt | 10 +-- Partition_2/doc/Partition_2/Partition_2.txt | 8 +- .../Periodic_2_Delaunay_triangulation_2.h | 10 +-- .../CGAL/Periodic_2_triangulation_2.h | 2 +- Polygon/include/CGAL/Polygon_2_algorithms.h | 2 +- .../Polygon_mesh_processing.txt | 4 +- QP_solver/doc/QP_solver/QP_solver.txt | 2 +- .../STL_Extension/CGAL/Compact_container.h | 6 +- .../CGAL/Concurrent_compact_container.h | 6 +- .../doc/STL_Extension/CGAL/In_place_list.h | 2 +- .../doc/STL_Extension/CGAL/Multiset.h | 10 +-- STL_Extension/include/CGAL/Multiset.h | 74 +++++++++---------- .../doc/SearchStructures/CGAL/Range_tree_d.h | 6 +- .../SearchStructures/CGAL/Segment_tree_d.h | 6 +- .../doc/SearchStructures/SearchStructures.txt | 14 ++-- .../Segment_Delaunay_graph_2.txt | 4 +- .../Set_movable_separability_2.txt | 4 +- .../include/CGAL/Eigen_sparse_matrix.h | 4 +- .../internal/K_means_clustering.h | 4 +- .../Surface_mesh_shortest_path.txt | 4 +- .../Surface_mesh_shortest_path.h | 2 +- .../Surface_mesh_topology.txt | 4 +- .../doc/Surface_sweep_2/Surface_sweep_2.txt | 6 +- .../doc/Triangulation/Triangulation.txt | 8 +- .../CGAL/Delaunay_triangulation_2.h | 12 +-- .../Triangulation_2/CGAL/Triangulation_2.h | 8 +- .../doc/Triangulation_2/Triangulation_2.txt | 22 +++--- .../CGAL/Delaunay_triangulation_3.h | 4 +- .../doc/Triangulation_3/Triangulation_3.txt | 2 +- .../CGAL/Rotational_sweep_visibility_2.h | 4 +- .../CGAL/Simple_polygon_visibility_2.h | 4 +- .../CGAL/Triangular_expansion_visibility_2.h | 6 +- .../doc/Visibility_2/visibility_2.txt | 8 +- 106 files changed, 301 insertions(+), 297 deletions(-) diff --git a/AABB_tree/include/CGAL/AABB_tree.h b/AABB_tree/include/CGAL/AABB_tree.h index 0016d4ecc097..ca68663308b2 100644 --- a/AABB_tree/include/CGAL/AABB_tree.h +++ b/AABB_tree/include/CGAL/AABB_tree.h @@ -143,7 +143,7 @@ namespace CGAL { /// An explicit call to `build()` must be made to ensure that the next call to /// a query function will not trigger the construction of the data structure. /// A call to `AABBTraits::set_shared_data(t...)` is made using the internally stored traits. - /// This procedure has a complexity of \f$O(n log(n))\f$, where \f$n\f$ is the number of + /// This procedure has a complexity of \cgalBigO{n log(n)}, where \f$n\f$ is the number of /// primitives of the tree. template void build(T&& ...); diff --git a/Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h b/Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h index 98dedd0f75b6..832be2b8d29e 100644 --- a/Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h +++ b/Alpha_shapes_2/doc/Alpha_shapes_2/CGAL/Alpha_shape_2.h @@ -80,7 +80,7 @@ use binary search. `Alpha_shape_2::number_of_solid_components()` performs a graph traversal and takes time linear in the number of faces of the underlying triangulation. `Alpha_shape_2::find_optimal_alpha()` uses binary search and takes time -\f$ O(n \log n)\f$, where \f$ n\f$ is the number of points. +\cgalBigO{n \log n}, where \f$ n\f$ is the number of points. */ template< typename Dt, typename ExactAlphaComparisonTag > diff --git a/Alpha_shapes_3/doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h b/Alpha_shapes_3/doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h index 70f1bec2182b..7136eed539b1 100644 --- a/Alpha_shapes_3/doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h +++ b/Alpha_shapes_3/doc/Alpha_shapes_3/CGAL/Alpha_shape_3.h @@ -77,7 +77,7 @@ use binary search. `Alpha_shape_3::number_of_solid_components()` performs a graph traversal and takes time linear in the number of cells of the underlying triangulation. `Alpha_shape_3::find_optimal_alpha()` uses binary search and takes time -\f$ O(n \log n)\f$, where \f$ n\f$ is the number of points. +\cgalBigO{n \log n}, where \f$ n\f$ is the number of points. */ template< typename Dt, typename ExactAlphaComparisonTag > diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt index 431083db107b..62571bfdee9b 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/Arrangement_on_surface_2.txt @@ -1223,10 +1223,10 @@ halfedge \f$e_{\mathrm{pred}}\f$ directed toward \f$v\f$, such that \f$c\f$ is located between the curves associated with \f$e_{\mathrm{pred}}\f$ and the next halfedge in the clockwise order in the circular list of halfedges around \f$v\f$; see -\cgalFigureRef{aos_fig-insert}. This search may take \f$O(d)\f$ time, +\cgalFigureRef{aos_fig-insert}. This search may take \cgalBigO{d} time, where \f$d\f$ is the degree of the vertex \f$v\f$. \cgalFootnote{We can store the handles to the halfedges incident to \f$v\f$ in an efficient -search structure to obtain \f$O(\log d)\f$ access time. However, as +search structure to obtain \cgalBigO{\log d} access time. However, as \f$d\f$ is usually very small, this may lead to a waste of storage space without a meaningful improvement in running time in practice.} However, if the halfedge \f$e_{\mathrm{pred}}\f$ is known in advance, @@ -1488,9 +1488,9 @@ keep up-to-date as this arrangement changes. As mentioned above, the triangulation strategy is provided only for educational purposes, and thus we do not elaborate on this strategy. The data structure needed by the landmark and the trapezoidal map RIC -strategies can be constructed in \f$O(N \log N)\f$ time, where \f$N\f$ +strategies can be constructed in \cgalBigO{N \log N} time, where \f$N\f$ is the overall number of edges in the arrangement, but the constant -hidden in the \f$O()\f$ notation for the trapezoidal map RIC strategy +hidden in the \cgalBigO{ } notation for the trapezoidal map RIC strategy is much larger. Thus, construction needed by the landmark algorithm is in practice significantly faster than the construction needed by the trapezoidal map RIC strategy. In addition, although both resulting @@ -1647,7 +1647,7 @@ Section \ref arr_ssecpl. The output pairs are sorted in increasing \f$xy\f$-lexicographical order of the query point. The batched point-location operation is carried out by sweeping the -arrangement. Thus, it takes \f$O((m+N)\log{(m+N)})\f$ time, where +arrangement. Thus, it takes \cgalBigO{(m+N)\log{(m+N)}} time, where \f$N\f$ is the number of edges in the arrangement. Issuing separate queries exploiting a point-location strategy with logarithmic query time per query, such as the trapezoidal map RIC strategy (see Section @@ -2037,11 +2037,11 @@ so it must be construct from scratch. In the first case, we sweep over the input curves, compute their intersection points, and construct the \dcel that represents their -arrangement. This process is performed in \f$O\left((n + k)\log -n\right)\f$ time, where \f$k\f$ is the total number of intersection +arrangement. This process is performed in \cgalBigO{left((n + k)\log +n\right} time, where \f$k\f$ is the total number of intersection points. The running time is asymptotically better than the time needed for incremental insertion if the arrangement is relatively sparse -(when \f$k\f$ is \f$O(\frac{n^2}{\log n}\f$)), but it is recommended +(when \f$k\f$ is \cgalBigO{\frac{n^2}{\log n}}), but it is recommended that this aggregate construction process be used even for dense arrangements, since the plane-sweep algorithm performs fewer geometric operations compared to the incremental insertion algorithms, and hence @@ -4346,7 +4346,7 @@ a point with respect to an \f$x\f$-monotone polyline, we use binary search to locate the relevant segment that contains the point in its \f$x\f$-range. Then, we compute the position of the point with respect to this segment. Thus, operations on \f$x\f$-monotone polylines of -size \f$m\f$ typically take \f$O(\log m)\f$ time. +size \f$m\f$ typically take \cgalBigO{\log m} time. You are free to choose the underlying segment traits class. Your decision could be based, for example, on the number of expected diff --git a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h index 0027ec53409c..e662503bee43 100644 --- a/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h +++ b/Arrangement_on_surface_2/doc/Arrangement_on_surface_2/CGAL/Arr_trapezoid_ric_point_location.h @@ -12,9 +12,9 @@ Seidel \cgalCite{s-sfira-91} (see also [\cgalCite{bkos-cgaa-00} Chapter 6). It subdivides each arrangement face to pseudo-trapezoidal cells, each of constant complexity, and constructs and maintains a linear-size search structure on top of these cells, such that each query can be answered -in \f$ O(\log n)\f$ time, where \f$ n\f$ is the complexity of the arrangement. +in \cgalBigO{\log n} time, where \f$ n\f$ is the complexity of the arrangement. -Constructing the search structures takes \f$ O(n \log n)\f$ expected time +Constructing the search structures takes \cgalBigO{n \log n} expected time and may require a small number of rebuilds \cgalCite{hkh-iiplgtds-12}. Therefore attaching a trapezoidal point-location object to an existing arrangement may incur some overhead in running times. In addition, the point-location diff --git a/Arrangement_on_surface_2/include/CGAL/Arr_polycurve_basic_traits_2.h b/Arrangement_on_surface_2/include/CGAL/Arr_polycurve_basic_traits_2.h index 84c9cee01d97..c216a07bc9ca 100644 --- a/Arrangement_on_surface_2/include/CGAL/Arr_polycurve_basic_traits_2.h +++ b/Arrangement_on_surface_2/include/CGAL/Arr_polycurve_basic_traits_2.h @@ -2419,7 +2419,7 @@ class Arr_polycurve_basic_traits_2 { /*! Obtain the index of the subcurve in the polycurve that contains the * point q in its x-range. The function performs a binary search, so if the * point q is in the x-range of the polycurve with n subcurves, the subcurve - * containing it can be located in O(log n) operations. + * containing it can be located in \cgalBigO{log n} operations. * \param cv The polycurve curve. * \param q The point. * \return An index i such that q is in the x-range of cv[i]. diff --git a/Barycentric_coordinates_2/doc/Barycentric_coordinates_2/Barycentric_coordinates_2.txt b/Barycentric_coordinates_2/doc/Barycentric_coordinates_2/Barycentric_coordinates_2.txt index 72588aec4365..b3f13fcf8191 100644 --- a/Barycentric_coordinates_2/doc/Barycentric_coordinates_2/Barycentric_coordinates_2.txt +++ b/Barycentric_coordinates_2/doc/Barycentric_coordinates_2/Barycentric_coordinates_2.txt @@ -451,10 +451,10 @@ To fix the problem, we modify the weights \f$w_i\f$ as After the above normalization, this gives us the precise algorithm to compute Wachspress coordinates -but with \f$O(n^2)\f$ performance only. The max speed \f$O(n)\f$ algorithm uses the standard +but with \cgalBigO{n^2} performance only. The max speed \cgalBigO{n} algorithm uses the standard weights \f$w_i\f$. Note that mathematically this modification does not change the coordinates. One should be cautious when using the unnormalized Wachspress weights. In that case, you must choose the -\f$O(n)\f$ type. +\cgalBigO{n} type. It is known that for strictly convex polygons the denominator's zero set of the Wachspress coordinates (\f$W^{wp} = 0~\f$) is a curve, which (in many cases) lies quite @@ -507,10 +507,10 @@ To fix the problem, similarly to the previous subsection, we modify the weights After the above normalization, this yields the precise algorithm to compute discrete harmonic coordinates -but with \f$O(n^2)\f$ performance only. The max speed \f$O(n)\f$ algorithm uses the standard +but with \cgalBigO{n^2} performance only. The max speed \cgalBigO{n} algorithm uses the standard weights \f$w_i\f$. Again, mathematically this modification does not change the coordinates, one should be cautious when using the unnormalized discrete harmonic weights. In that case, -you must choose the \f$O(n)\f$ type. +you must choose the \cgalBigO{n} type. \b Warning: as for Wachspress coordinates, we do not recommend using discrete harmonic coordinates for exterior points, because the curve \f$W^{dh} = 0\f$ may have several components, @@ -563,7 +563,7 @@ After the normalization of these weights as before \f$b_i = \frac{w_i}{W^{mv}}\qquad\f$ with \f$\qquad W^{mv} = \sum_{j=1}^n w_j\f$ -we obtain the max precision \f$O(n^2)\f$ algorithm. The max speed \f$O(n)\f$ algorithm computes the +we obtain the max precision \cgalBigO{n^2} algorithm. The max speed \cgalBigO{n} algorithm computes the weights \f$w_i\f$ using the pseudocode from here. These weights @@ -575,7 +575,7 @@ with \f$\qquad t_i = \frac{\text{det}(d_i, d_{i+1})}{r_ir_{i+1} + d_id_{i+1}}\f$ are also normalized. Note that they are unstable if a query point is closer than \f$\approx 1.0e-10\f$ to the polygon boundary, similarly to Wachspress and discrete harmonic coordinates and one should be cautious when using the unnormalized mean value weights. In that case, you must choose the -\f$O(n)\f$ type. +\cgalBigO{n} type. \anchor compute_hm_coord @@ -654,17 +654,17 @@ The resulting timings for all closed-form coordinates can be found in the figure \cgalFigureBegin{analytic_timings, analytic_timings.png} Time in seconds to compute \f$n\f$ coordinate values for a polygon with \f$n\f$ vertices -at 1 million query points with the max speed \f$O(n)\f$ algorithms (dashed) and +at 1 million query points with the max speed \cgalBigO{n} algorithms (dashed) and the max precision \f$0(n^2)\f$ algorithms (solid) for Wachspress (blue), discrete harmonic (red), and mean value (green) coordinates. \cgalFigureEnd -From the figure above we observe that the \f$O(n^2)\f$ algorithm is as fast -as the \f$O(n)\f$ algorithm if we have a polygon with a small number of vertices. +From the figure above we observe that the \cgalBigO{n^2} algorithm is as fast +as the \cgalBigO{n} algorithm if we have a polygon with a small number of vertices. But as the number of vertices is increased, the linear algorithm outperforms the squared one, as expected. One of the reasons for this behavior is that for a small number of vertices -the multiplications of \f$n-2\f$ elements inside the \f$O(n^2)\f$ algorithm take almost the -same time as the corresponding divisions in the \f$O(n)\f$ algorithm. For a polygon with +the multiplications of \f$n-2\f$ elements inside the \cgalBigO{n^2} algorithm take almost the +same time as the corresponding divisions in the \cgalBigO{n} algorithm. For a polygon with many vertices, these multiplications are substantially slower. To benchmark harmonic coordinates, we used a MacBook Pro 2018 with 2.2 GHz Intel Core i7 processor (6 cores) diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h index 33d006577bfc..856d1a169296 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Approximate_min_ellipsoid_d.h @@ -119,7 +119,7 @@ We implement Khachyian's algorithm for rounding polytopes \cgalCite{cgal:k-rprnm-96}. Internally, we use `double`-arithmetic and (initially a single) Cholesky-decomposition. The algorithm's running time is -\f$ {\cal O}(nd^2(\epsilon^{-1}+\ln d + \ln\ln(n)))\f$, where \f$ n=|P|\f$ and +\cgalBigO{nd^2(\epsilon^{-1}+\ln d + \ln\ln(n))}, where \f$ n=|P|\f$ and \f$ 1+\epsilon\f$ is the desired approximation ratio. \cgalHeading{Example} diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h index 8d360443390e..fbcd5f02e2dc 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/Min_sphere_of_spheres_d.h @@ -76,7 +76,7 @@ We implement two algorithms, the LP-algorithm and a heuristic \cgalCite{msw-sblp-92}. As described in the documentation of concept `MinSphereOfSpheresTraits`, each has its advantages and disadvantages: Our implementation of the LP-algorithm has maximal -expected running time \f$ O(2^d n)\f$, while the heuristic comes without +expected running time \cgalBigO{2^d n}, while the heuristic comes without any complexity guarantee. In particular, the LP-algorithm runs in linear time for fixed dimension \f$ d\f$. (These running times hold for the arithmetic model, so they count the number of operations on diff --git a/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h b/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h index f3baaa625f13..519b3eeb24fa 100644 --- a/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h +++ b/Bounding_volumes/doc/Bounding_volumes/CGAL/rectangular_p_center_2.h @@ -245,7 +245,7 @@ must be a model for `RectangularPCenterTraits_2`. \cgalHeading{Implementation} The runtime is linear for \f$ p \in \{2,\,3\}\f$ and -\f$ \mathcal{O}(n \cdot \log n)\f$ for \f$ p = 4\f$ where \f$ n\f$ is the number of +\cgalBigO{n \cdot \log n} for \f$ p = 4\f$ where \f$ n\f$ is the number of input points. These runtimes are worst case optimal. The \f$ 3\f$-center algorithm uses a prune-and-search technique described in \cgalCite{cgal:h-slacr-99}. The \f$ 4\f$-center implementation uses sorted matrix diff --git a/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h b/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h index 49b32647f3c2..a1a0126cf9e8 100644 --- a/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h +++ b/Bounding_volumes/doc/Bounding_volumes/Concepts/MinSphereOfSpheresTraits.h @@ -79,7 +79,7 @@ The recommended choice is the first, which is a synonym to the one of the other two methods which we consider "the best in practice." In case of `CGAL::LP_algorithm`, the minsphere will be computed using the LP-algorithm \cgalCite{msw-sblp-92}, which in our -implementation has maximal expected running time \f$ O(2^d n)\f$ (in the +implementation has maximal expected running time \cgalBigO{2^d n} (in the number of operations on the number type `FT`). In case of `CGAL::Farthest_first_heuristic`, a simple heuristic will be used instead which seems to work fine in practice, but comes without diff --git a/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt b/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt index 64cead025327..2dcd2db8d30e 100644 --- a/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt +++ b/Box_intersection_d/doc/Box_intersection_d/Box_intersection_d.txt @@ -350,12 +350,12 @@ parameter the function switches from the streamed segment-tree algorithm to the two-way-scan algorithm, see \cgalCite{cgal:ze-fsbi-02} for the details. -The streamed segment-tree algorithm needs \f$ O(n \log^d (n) + k)\f$ -worst-case running time and \f$ O(n)\f$ space, where \f$ n\f$ is the number of +The streamed segment-tree algorithm needs \cgalBigO{n \log^d (n) + k} +worst-case running time and \cgalBigO{n} space, where \f$ n\f$ is the number of boxes in both input sequences, \f$ d\f$ the (constant) dimension of the boxes, and \f$ k\f$ the output complexity, i.e., the number of pairwise -intersections of the boxes. The two-way-scan algorithm needs \f$ O(n \log -(n) + l)\f$ worst-case running time and \f$ O(n)\f$ space, where \f$ l\f$ is the +intersections of the boxes. The two-way-scan algorithm needs \cgalBigO{n \log +(n) + l} worst-case running time and \cgalBigO{n} space, where \f$ l\f$ is the number of pairwise overlapping intervals in one dimensions (the dimension where the algorithm is used instead of the segment tree). Note that \f$ l\f$ is not necessarily related to \f$ k\f$ and using the diff --git a/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h b/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h index f9ec7ba1ae13..0f7fd9bccdd1 100644 --- a/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h +++ b/Box_intersection_d/doc/Box_intersection_d/CGAL/box_intersection_d.h @@ -77,7 +77,7 @@ namespace CGAL { \cgalHeading{Implementation} The algorithm is trivially testing all pairs and runs therefore in time - \f$ O(nm)\f$ where \f$ n\f$ is the size of the first sequence and \f$ m\f$ is the + \cgalBigO{nm} where \f$ n\f$ is the size of the first sequence and \f$ m\f$ is the size of the second sequence. */ @@ -219,12 +219,12 @@ void box_intersection_all_pairs_d( algorithm to the two-way-scan algorithm, see \cgalCite{cgal:ze-fsbi-02} for the details. - The streamed segment-tree algorithm needs \f$ O(n \log^d (n) + k)\f$ - worst-case running time and \f$ O(n)\f$ space, where \f$ n\f$ is the number of + The streamed segment-tree algorithm needs \cgalBigO{n \log^d (n) + k} + worst-case running time and \cgalBigO{n} space, where \f$ n\f$ is the number of boxes in both input sequences, \f$ d\f$ the (constant) dimension of the boxes, and \f$ k\f$ the output complexity, i.e., the number of pairwise - intersections of the boxes. The two-way-scan algorithm needs \f$ O(n \log - (n) + l)\f$ worst-case running time and \f$ O(n)\f$ space, where \f$ l\f$ is the + intersections of the boxes. The two-way-scan algorithm needs \cgalBigO{n \log + (n) + l} worst-case running time and \cgalBigO{n} space, where \f$ l\f$ is the number of pairwise overlapping intervals in one dimensions (the dimension where the algorithm is used instead of the segment tree). Note that \f$ l\f$ is not necessarily related to \f$ k\f$ and using the @@ -397,7 +397,7 @@ namespace CGAL { \cgalHeading{Implementation} The algorithm is trivially testing all pairs and runs therefore in time - \f$ O(n^2)\f$ where \f$ n\f$ is the size of the input sequence. This algorithm + \cgalBigO{n^2} where \f$ n\f$ is the size of the input sequence. This algorithm does not use the id-number of the boxes. */ diff --git a/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt b/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt index 2e36037ea231..5a17500431d8 100644 --- a/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt +++ b/Combinatorial_map/doc/Combinatorial_map/Combinatorial_map.txt @@ -297,7 +297,7 @@ Several functions allow to create specific configurations of darts into a combin \subsection ssecadvmarks Boolean Marks -It is often necessary to mark darts, for example to retrieve in O(1) if a given dart was already processed during a specific algorithm, for example, iteration over a given range. Users can also mark specific parts of a combinatorial map (for example mark all the darts belonging to objects having specific semantics). To answer these needs, a `GenericMap` has a certain number of Boolean marks (fixed by the constant \link GenericMap::NB_MARKS `NB_MARKS`\endlink). When one wants to use a Boolean mark, the following methods are available (with `cm` an instance of a combinatorial map): +It is often necessary to mark darts, for example to retrieve in \cgalBigO{1} if a given dart was already processed during a specific algorithm, for example, iteration over a given range. Users can also mark specific parts of a combinatorial map (for example mark all the darts belonging to objects having specific semantics). To answer these needs, a `GenericMap` has a certain number of Boolean marks (fixed by the constant \link GenericMap::NB_MARKS `NB_MARKS`\endlink). When one wants to use a Boolean mark, the following methods are available (with `cm` an instance of a combinatorial map): \htmlonly[block] \endhtmlonly " \ "cgalParamSectionBegin{1}=\cgalParamNBegin{\1}" \ "cgalParamSectionEnd=\cgalParamNEnd" \ - "cgalParamPrecondition{1}=
  • Precondition: \1
    • " + "cgalParamPrecondition{1}=
  • Precondition: \1
    • " \ + "cgalBigO{1}=\f$O(\1)\f$" \ + "cgalBigOLarge{1}=\f$O\left(\1\right)\f$" # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given diff --git a/Documentation/doc/resources/1.9.6/BaseDoxyfile.in b/Documentation/doc/resources/1.9.6/BaseDoxyfile.in index 1cfd0a6ffd9f..7cda561372e5 100644 --- a/Documentation/doc/resources/1.9.6/BaseDoxyfile.in +++ b/Documentation/doc/resources/1.9.6/BaseDoxyfile.in @@ -197,7 +197,9 @@ ALIASES = "cgal=%CGAL" \ "cgalParamNEnd= \htmlonly[block] \endhtmlonly " \ "cgalParamSectionBegin{1}=\cgalParamNBegin{\1}" \ "cgalParamSectionEnd=\cgalParamNEnd" \ - "cgalParamPrecondition{1}=
  • Precondition: \1
    • " + "cgalParamPrecondition{1}=
  • Precondition: \1
    • " \ + "cgalBigO{1}=\f$O(\1)\f$" \ + "cgalBigOLarge{1}=\f$O\left(\1\right)\f$" # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given diff --git a/Generalized_map/doc/Generalized_map/Generalized_map.txt b/Generalized_map/doc/Generalized_map/Generalized_map.txt index 491a8c9ed3d3..f2c811e33b6f 100644 --- a/Generalized_map/doc/Generalized_map/Generalized_map.txt +++ b/Generalized_map/doc/Generalized_map/Generalized_map.txt @@ -296,7 +296,7 @@ Several functions allow to create specific configurations of darts into a genera \subsection ssecadvmarksgmap Boolean Marks -It is often necessary to mark darts, for example to retrieve in O(1) if a given dart was already processed during a specific algorithm, for example, iteration over a given range. Users can also mark specific parts of a generalized map (for example mark all the darts belonging to objects having specific semantics). To answer these needs, a `GeneralizedMap` has a certain number of Boolean marks (fixed by the constant \link GenericMap::NB_MARKS `NB_MARKS`\endlink). When one wants to use a Boolean mark, the following methods are available (with `gm` an instance of a generalized map): +It is often necessary to mark darts, for example to retrieve in \cgalBigO{1} if a given dart was already processed during a specific algorithm, for example, iteration over a given range. Users can also mark specific parts of a generalized map (for example mark all the darts belonging to objects having specific semantics). To answer these needs, a `GeneralizedMap` has a certain number of Boolean marks (fixed by the constant \link GenericMap::NB_MARKS `NB_MARKS`\endlink). When one wants to use a Boolean mark, the following methods are available (with `gm` an instance of a generalized map):