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

@@ -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<typename ... T>
     void build(T&& ...);

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 >

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 >

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

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

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].

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
 </center>
 
 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
 </center>
 
 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$
 </center>
 
-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 <a href="https://www.inf.usi.ch/hormann/nsfworkshop/presentations/Hormann.pdf">here</a>.
 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)

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}

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

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

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

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

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.
 
 */

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 <I>O(1)</I> 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):
 <ul>
 <li> get a new free mark: `size_type m = cm.`\link GenericMap::get_new_mark `get_new_mark()`\endlink (throws the exception Exception_no_more_available_mark if no mark is available);
 <li> set mark `m` for a given dart `d0`: `cm.`\link GenericMap::mark `mark(d0,m)`\endlink;

Combinatorial_map/include/CGAL/Combinatorial_map.h

@@ -1154,7 +1154,7 @@ namespace CGAL {
     }
 
     /** Unmark all the darts of the map for a given mark.
-     * If all the darts are marked or unmarked, this operation takes O(1)
+     * If all the darts are marked or unmarked, this operation takes \cgalBigO{1}
      * operations, otherwise it traverses all the darts of the map.
      * @param amark the given mark.
      */

Cone_spanners_2/doc/Cone_spanners_2/Cone_spanners_2.txt

@@ -160,7 +160,7 @@ In constructing Theta graphs, this functor uses the algorithm from
 Chapter 4 of the book by Narasimhan and Smid \cgalCite{cgal:ns-gsn-07}.
 Basically, it is a sweep line algorithm and uses a
 balanced search tree to store the vertices that have already been scanned.
-It has the complexity of \f$O(n \log n)\f$, where \f$n\f$ is the number of vertices in the plane.
+It has the complexity of \cgalBigO{n \log n}, where \f$n\f$ is the number of vertices in the plane.
 This complexity has been proved to be optimal.
 
 For more details on how to use this `Construct_theta_graph_2` functor to write an application to build Theta graphs,
@@ -178,13 +178,13 @@ The functor `Construct_yao_graph_2` has a similar definition as `Construct_theta
 
 The way of using these two template parameters is the same as that of `Construct_theta_graph_2`,
 so please refer to the previous subsection for the details. We note here that construction algorithm for Yao graph
-is a slight adaptation of the algorithm for constructing Theta graph, having a complexity of \f$O(n^2)\f$.
+is a slight adaptation of the algorithm for constructing Theta graph, having a complexity of \cgalBigO{n^2}.
 The increase of complexity in this adaptation is because in constructing Theta graph,
 the searching of the 'closest' node by projection distance can be done by a balanced search tree,
 but in constructing Yao graph, the searching of the 'closest' node by Euclidean distance cannot be
 done by a balanced search tree.
 
-Note that an optimal algorithm for constructing Yao graph with a complexity of \f$O(n \log n)\f$ is
+Note that an optimal algorithm for constructing Yao graph with a complexity of \cgalBigO{n \log n} is
 described in \cgalCite{cgal:cht-oacov-90}. However, this algorithm is much more complex to implement than
 the current algorithm implemented, and it can hardly reuse the codes for constructing Theta graphs,
 so it is not implemented in this package right now.