Doc for CMap, GMap and LCC ok after review 2

This commit is contained in:
Guillaume Damiand 2016-10-05 10:35:06 -04:00
parent 4ed3d3318f
commit d0539bbd5b
20 changed files with 301 additions and 297 deletions

View File

@ -22,7 +22,7 @@ The complexity of \link GenericMap::sew `sew`\endlink and \link GenericMap::unse
The complexity of \link GenericMap::set_attribute `set_attribute`\endlink is in <I>O</I>( \f$ | \f$ <I>c</I> \f$ | \f$ ), <I>c</I> being the <I>i</I>-cell containing the considered dart.
The complexity of \link GenericMap::is_without_boundary(unsigned int i) const `is_without_boundary(unsigned int i)`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ ), <I>D</I> being the set of darts of the combinatorial map, and the complexity of \link GenericMap::is_without_boundary() const `is_without_boundary()`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times\f$ <I>d</I> ).
The complexity of \link GenericMap::is_without_boundary(unsigned int i) const `is_without_boundary(i)`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ ), <I>D</I> being the set of darts of the combinatorial map, and the complexity of \link GenericMap::is_without_boundary() const `is_without_boundary()`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times\f$ <I>d</I> ).
The complexity of \link GenericMap::unmark_all `unmark_all`\endlink and \link GenericMap::free_mark `free_mark`\endlink is in <I>O</I>( 1 ) if all the darts of the combinatorial map have the same mark, and in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ ) otherwise.

9
Generalized_map/TODO.txt Normal file
View File

@ -0,0 +1,9 @@
* modif de la doc ref manual de gmap (en suivant ce qui est fait dans CMap)
* ajouter les concepts Basic
* faire le code des insertions; et vérifier que le brin retourné est le bon
* faire la testsuite
* renommer (both cmap and gmap)
get_next_dart_in_face -> next
get_opposite_dart -> opposite
* ajouter function previous (both cmap and gmap)
* voir si besoin de documenter les fonctions is_exist_previous is_exist_next et is_exist_opposite

View File

@ -12,26 +12,24 @@ Darts and non void attributes are stored in memory using `Compact_container`, us
\tparam d the dimension of the map.
\tparam Items a model of the `GenericMapItems` concept.
\tparam Items a model of the `GenericMapItems` concept. Equal to `Generalized_map_min_items<d>` by default.
\tparam Alloc has to match the standard allocator requirements. The `rebind` mechanism `Alloc` will be used to create appropriate allocators internally with value type `Dart`.
There are two default template arguments: `Generalized_map_min_items<d>` for `Items` and `CGAL_ALLOCATOR(int)` from the `<CGAL/memory.h>` header file for `Alloc`.
\tparam Alloc has to match the standard allocator requirements. The `rebind` mechanism `Alloc` will be used to create appropriate allocators internally with value type `Dart`. Equal to `CGAL_ALLOCATOR(int)` from `<CGAL/memory.h>` by default.
\cgalHeading{Complexity}
The complexity of `sew` and `unsew` is in <I>O</I>(\f$ | \f$ <I>S</I> \f$ | \f$ \f$ \times \f$ \f$ | \f$ <I>c</I> \f$ | \f$), <I>S</I> being the set of darts of the orbit \f$ \langle{}\f$\f$ \alpha_0\f$,\f$ \ldots\f$,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,\f$ \ldots\f$,\f$ \alpha_d\f$\f$ \rangle{}\f$ for the considered dart, and <I>c</I> the biggest <I>j</I>-cell merged or split during the sew such that <I>j</I>-attributes are non void.
The complexity of `is_sewable` is in <I>O</I>(\f$ | \f$ <I>S</I> \f$ | \f$).
The complexity of \link GenericMap::sew `sew`\endlink and \link GenericMap::unsew `unsew`\endlink is in <I>O</I>( \f$ | \f$ <I>S</I> \f$ | \f$ \f$ \times \f$ \f$ | \f$ <I>c</I> \f$ | \f$ ), <I>S</I> being the set of darts of the orbit \f$ \langle{}\f$\f$ \alpha_0\f$,\f$ \ldots\f$,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,\f$ \ldots\f$,\f$ \alpha_d\f$\f$ \rangle{}\f$ for the considered dart, and <I>c</I> the biggest <I>j</I>-cell merged or split during the sew such that <I>j</I>-attributes are non void.
The complexity of \link GenericMap::is_sewable `is_sewable`\endlink is in <I>O</I>( \f$ | \f$ <I>S</I> \f$ | \f$ ).
The complexity of `set_attribute` is in <I>O</I>(\f$ | \f$ <I>c</I> \f$ | \f$), <I>c</I> being the <I>i</I>-cell containing the considered dart.
The complexity of \link GenericMap::set_attribute `set_attribute`\endlink is in <I>O</I>( \f$ | \f$ <I>c</I> \f$ | \f$ ), <I>c</I> being the <I>i</I>-cell containing the considered dart.
The complexity of `is_without_boundary(unsigned int i)` is in <I>O</I>(\f$ | \f$ <I>D</I> \f$ | \f$), <I>D</I> being the set of darts of the generalized map, and the complexity of `is_without_boundary()` is in <I>O</I>(\f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I>).
The complexity of \link GenericMap::is_without_boundary(unsigned int i) const `is_without_boundary(i)`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ ), <I>D</I> being the set of darts of the generalized map, and the complexity of \link GenericMap::is_without_boundary() const `is_without_boundary()`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I> ).
The complexity of `unmark_all` and `free_mark` is in <I>O</I>(1) if all the darts of the generalized map have the same mark, and in <I>O</I>(\f$ | \f$ <I>D</I> \f$ | \f$) otherwise.
The complexity of \link GenericMap::unmark_all `unmark_all`\endlink and \link GenericMap::free_mark `free_mark`\endlink is in <I>O</I>( 1 ) if all the darts of the generalized map have the same mark, and in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ ) otherwise.
The complexity of `is_valid` is in <I>O</I>(\f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I>\f$ ^2\f$).
The complexity of \link GenericMap::is_valid `is_valid`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I>\f$ ^2\f$ ).
The complexity of `clear` is in <I>O</I>(\f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I>).
The complexity of \link GenericMap::clear `clear`\endlink is in <I>O</I>( \f$ | \f$ <I>D</I> \f$ | \f$ \f$ \times \f$ <I>d</I> ).
Other methods have all a constant time complexity.

View File

@ -25,7 +25,8 @@ and <I>i</I>+2 \f$ \leq \f$ <I>j</I> \f$ \leq \f$ \link GenericMap::dimension `d
- \f$ \forall \f$ <I>i</I>, 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ \link GenericMap::dimension `dimension`\endlink such that <I>i</I>-attributes are non void:
+ \f$ \forall \f$ <I>d2</I> in the same <I>i</I>-cell than <I>d</I>: <I>d</I> and <I>d2</I> have the same <I>i</I>-attribute;
+ \f$ \forall \f$ <I>d2</I> in a different <I>i</I>-cell than <I>d</I>: <I>d</I> and <I>d2</I> have different <I>i</I>-attributes.
.
\cgalHeading{Sew and Unsew}
The function \link GenericMap::is_sewable `is_sewable(dh1,dh2)`\endlink returns true iff `*dh1` can be <I>i</I>-sewn with `*dh2` by keeping the generalized map valid.

View File

@ -64,10 +64,10 @@ In this section, we describe <I>d</I>D generalized maps in terms of data structu
\subsection ssecgenmapanddarts Generalized Map and Darts
A <I>d</I>D generalized map is a set of darts <I>D</I>. A dart <I>d0</I> is an element that can be <I>linked</I> with <I>d</I>+1 darts by pointers called \f$ \alpha_i\f$, with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>. %Dart <I>d0</I> is said <I>i-free</I> when \f$ \alpha_i\f$(<I>d0</I>)=<I>d0</I>. Each \f$ \alpha_i\f$ is its own inverse, i.e. \f$ \alpha_i\f$(\f$
A <I>d</I>D generalized map is a set of darts <I>D</I>. A dart <I>d0</I> is an element that can be <I>linked</I> with <I>d</I>+1 darts by pointers called \f$ \alpha_i\f$, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>. %Dart <I>d0</I> is said <I>i-free</I> when \f$ \alpha_i\f$(<I>d0</I>)=<I>d0</I>. Each \f$ \alpha_i\f$ is its own inverse, i.e. \f$ \alpha_i\f$(\f$
\alpha_i\f$(<I>d0</I>))=<I>d0</I>.
A generalized map is <I>without i-boundary</I> if there is no <I>i</I>-free dart, and it is <I>without boundary</I> if it is without <I>i</I>-boundary for all dimensions 1\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>.
A generalized map is <I>without i-boundary</I> if there is no <I>i</I>-free dart, and it is <I>without boundary</I> if it is without <I>i</I>-boundary for all dimensions 1 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>.
We show in \cgalFigureRef{fig_gmap_detailed_example} a 3D object and the corresponding 3D generalized map. This map has \tred{80} darts, some darts being numbered. In this generalized map, we have for example \f$ \alpha_0\f$(1)=2, \f$ \alpha_1\f$(1)=8, \f$ \alpha_2\f$(1)=24, and \f$ \alpha_3\f$(1)=9. This generalized map is without \tred{0-boundary}, without 1-boundary and 2-boundary, but has some 3-boundary, because some darts are 3-free, for example \f$ \alpha_3\f$(17)=17.
@ -79,17 +79,17 @@ Example of a 3D generalized map. Left: A 3D object made of two volumes adjacent
A cell in a <I>d</I>D generalized map is implicitly represented by a subset of darts. In this section, we will see how to retrieve all cells containing a given dart, how to retrieve all darts belonging to a cell containing a given dart, and how incidence and adjacency relations are defined in terms of darts.
The first important property of a generalized map is that each dart belongs to an <I>i</I>-cell, \f$ \forall\f$<I>i</I>, 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>. For example in 3D, a dart belongs to a vertex, an edge, a facet, and a volume. This means that a 3D generalized map containing an isolated dart contains exactly one vertex, one edge, one facet and one volume.
The first important property of a generalized map is that each dart belongs to an <I>i</I>-cell, \f$ \forall \f$ <I>i</I>, 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>. For example in 3D, a dart belongs to a vertex, an edge, a facet, and a volume. This means that a 3D generalized map containing an isolated dart contains exactly one vertex, one edge, one facet and one volume.
The second important property is that cells of a generalized map correspond to specific <I>orbits</I>. Given a set <I>S</I>\f$ \subseteq\f${\f$ \alpha_1\f$,...,\f$ \alpha_d\f$} and a dart <I>d0</I>, the <I>orbit</I> \f$ \langle{}\f$ <I>S</I>\f$ \rangle{}\f$(<I>d0</I>) is the set of darts that can be reached from <I>d0</I> by following any combination of any \f$ \alpha_i\f$'s in <I>S</I> (to simplify notations, we can use for example \f$ \langle{}\f$\f$ \alpha_1\f$,\f$ \alpha_4\f$\f$\rangle{}\f$(<I>d0</I>) to denote \f$ \langle{}\f$ <I>S</I>\f$ \rangle{}\f$(<I>d0</I>) with <I>S</I>={\f$ \alpha_1\f$,\f$ \alpha_4\f$}).
Given a dart <I>d0</I>, in general, \f$ \alpha_i\f$(<I>d0</I>) (with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$d) belongs to the same cells as <I>d0</I>, only the <I>i</I>-cell is different. There are two exceptions:
Given a dart <I>d0</I>, in general, \f$ \alpha_i\f$(<I>d0</I>) (with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>) belongs to the same cells as <I>d0</I>, only the <I>i</I>-cell is different. There are two exceptions:
<ol type="1">
<li>if <I>d0</I> is <I>i</I>-free, then \f$ \alpha_i\f$(<I>d0</I>)=<I>d0</I>, the <I>i</I>-cell is not different;</li>
<li>if \f$ \alpha_i\f$(<I>d0</I>) belongs to the same <I>i</I>-cell as <I>d0</I> (case of multi-incidence). For example if an edge is an isolated loop, it is incident twice to the same vertex, then given a dart <I>d0</I> belonging to this edge, \f$ \alpha_1\f$(<I>d0</I>) goes to the next edge, which is in fact the same edge.</li>
</ol>
Since \f$ \alpha_i\f$(<I>d0</I>) (with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>) allows to change the current <I>i</I>-cell, all the darts that can be reached from <I>d0</I> by using any combination of \f$ \alpha_j\f$'s, \f$ \forall\f$<I>j</I>, 0\f$ \leq\f$<I>j</I>\f$ \leq\f$<I>d</I> and <I>j</I>\f$ \neq\f$<I>i</I> are contained in the same <I>i</I>-cell as <I>d0</I>. The <I>i</I>-cell containing <I>d0</I> is defined in terms of orbit by \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d0</I>).
Since \f$ \alpha_i\f$(<I>d0</I>) (with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>) allows to change the current <I>i</I>-cell, all the darts that can be reached from <I>d0</I> by using any combination of \f$ \alpha_j\f$'s, \f$ \forall \f$ <I>j</I>, 0 \f$ \leq \f$ <I>j</I> \f$ \leq \f$ <I>d</I> and <I>j</I> \f$ \neq \f$ <I>i</I> are contained in the same <I>i</I>-cell as <I>d0</I>. The <I>i</I>-cell containing <I>d0</I> is defined in terms of orbit by \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d0</I>).
Orbit \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d0</I>) is the <I>connected component</I> containing dart <I>d0</I>. A generalized map is <I>connected</I> if this set is equal to the set of all the darts of the generalized map.
@ -103,11 +103,11 @@ Let us give some examples of cells in 3D, for the 3D generalized map of \cgalFig
<LI>All the darts belonging to the same volume can be obtained by any combination of \f$ \alpha_0\f$, \f$ \alpha_1\f$ and \f$ \alpha_2\f$: for example volume <I>vol1</I> corresponds in the generalized map to the set of the \tred{48} darts belonging to the cube. In terms of orbits, <I>vol1</I> corresponds to \f$ \langle{}\f$\f$ \alpha_0\f$,\f$ \alpha_1\f$,\f$ \alpha_2\f$\f$ \rangle{}\f$(1).
</UL>
Using this definition of cells as sets of darts, we can retrieve all the incidence and adjacency relations between the cells of the subdivision in a generalized map. Two cells are <I>incident</I> if the intersection of their two sets of darts is non empty (whatever the dimension of the two cells). Two <I>i</I>-cells <I>c1</I> and <I>c2</I>, 1\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>, are <I>adjacent</I> if there is <I>d1</I>\f$ \in\f$<I>c1</I> and <I>d2</I>\f$ \in\f$<I>c2</I> such that <I>d1</I> and <I>d2</I> belong to the same <I>(i-1)</I>-cell.
Using this definition of cells as sets of darts, we can retrieve all the incidence and adjacency relations between the cells of the subdivision in a generalized map. Two cells are <I>incident</I> if the intersection of their two sets of darts is non empty (whatever the dimension of the two cells). Two <I>i</I>-cells <I>c1</I> and <I>c2</I>, 1 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>, are <I>adjacent</I> if there is <I>d1</I> \f$ \in \f$ <I>c1</I> and <I>d2</I> \f$ \in \f$ <I>c2</I> such that <I>d1</I> and <I>d2</I> belong to the same <I>(i-1)</I>-cell.
In the example of \cgalFigureRef{fig_gmap_detailed_example}, vertex <I>v</I> and edge <I>e</I> are incident since the intersection of the two corresponding sets of darts is {\tred{1,9,24,25}}\f$ \neq\f$\f$ \emptyset\f$. Vertex <I>v</I> is incident to facet <I>f2</I> since the intersection of the two corresponding sets of darts is {\tred{1,8,9,16]}\f$ \neq\f$\f$ \emptyset\f$. Edge <I>e</I> and facet <I>f1</I> are incident since the intersection of the two corresponding sets of darts is {\tred{23,24}}\f$ \neq\f$\f$ \emptyset\f$. Finally, facets <I>f1</I> and <I>f2</I> are adjacent because 1\f$ \in\f$<I>f1</I>, \tred{24}\f$ \in\f$<I>f2</I> and 1 and \tred{24} belong to the same edge.
In the example of \cgalFigureRef{fig_gmap_detailed_example}, vertex <I>v</I> and edge <I>e</I> are incident since the intersection of the two corresponding sets of darts is {\tred{1,9,24,25}} \f$ \neq \f$ \f$ \emptyset\f$. Vertex <I>v</I> is incident to facet <I>f2</I> since the intersection of the two corresponding sets of darts is {\tred{1,8,9,16}} \f$ \neq \f$ \f$ \emptyset\f$. Edge <I>e</I> and facet <I>f1</I> are incident since the intersection of the two corresponding sets of darts is {\tred{23,24}} \f$ \neq \f$ \f$ \emptyset\f$. Finally, facets <I>f1</I> and <I>f2</I> are adjacent because 1 \f$ \in \f$ <I>f1</I>, \tred{24} \f$ \in \f$ <I>f2</I> and 1 and \tred{24} belong to the same edge.
We can consider <I>i</I>-cells in a dimension <I>d'</I> with <I>i</I>\f$ \leq\f$<I>d'</I>\f$ \leq\f$ <I>d</I>. The idea is to consider the <I>i</I>-cells as if the generalized map was in <I>d'</I> dimension. For that, we only take into account the \f$ \alpha_j \f$s for <I>j</I>\f$ \leq\f$<I>d'</I>. The <I>i</I>-cell containing <I>d0</I> in dimension <I>d'</I> is the orbit \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_{d'}\f$\f$ \rangle{}\f$(<I>d0</I>). By default, <I>i</I>-cells are considered in dimension <I>d</I>, the dimension of the generalized map.
We can consider <I>i</I>-cells in a dimension <I>d'</I> with <I>i</I> \f$ \leq \f$ <I>d'</I> \f$ \leq \f$ <I>d</I>. The idea is to consider the <I>i</I>-cells as if the generalized map was in <I>d'</I> dimension. For that, we only take into account the \f$ \alpha_j \f$s for <I>j</I> \f$ \leq \f$ <I>d'</I>. The <I>i</I>-cell containing <I>d0</I> in dimension <I>d'</I> is the orbit \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_{d'}\f$\f$ \rangle{}\f$(<I>d0</I>). By default, <I>i</I>-cells are considered in dimension <I>d</I>, the dimension of the generalized map.
In the example of \cgalFigureRef{fig_gmap_detailed_example}, the 2-cell containing dart 1 is facet <I>f2</I> which is the set of darts {\tred{1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16}}. If we consider the same 2-cell in dimension 2, we obtain the set of darts {\tred{1,2,3,4,5,6,7,8}}. Intuitively we <em>forget</em> \f$ \alpha_3\f$ and we obtain the set of darts of the facet containing dart 1 restricted to the volume containing this dart.
@ -139,13 +139,13 @@ There is an additional condition related to the type of represented objects, whi
Example of a 3D quasi-manifold which is not a manifold. The object to the right is made of the four pyramids (shown to the left) glued together along facets, thus it is a quasi-manifold.
\cgalFigureEnd
Generalized maps can only represent quasi-manifolds due to the definition of \f$ \alpha\f$ pointers. As we have seen in Section \ref sseccellsingmap "Cells as Sets of Darts", \f$ \alpha_i\f$(<I>d0</I>) (with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>) belongs to the same cells as <I>d0</I>, only the <I>i</I>-cell is different. In other words, \f$ \alpha_i\f$ links two <I>i</I>-cells that share a common <I>(i-1)</I>-cell: it is not possible to link more than two <I>i</I>-cells along a same <I>(i-1)</I>-cell. For this reason, it is not possible to describe non quasi-manifold objects as those shown in \cgalFigureRef{fig_gmap_non_manifolds} by generalized maps.
Generalized maps can only represent quasi-manifolds due to the definition of \f$ \alpha\f$ pointers. As we have seen in Section \ref sseccellsingmap "Cells as Sets of Darts", \f$ \alpha_i\f$(<I>d0</I>) (with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>) belongs to the same cells as <I>d0</I>, only the <I>i</I>-cell is different. In other words, \f$ \alpha_i\f$ links two <I>i</I>-cells that share a common <I>(i-1)</I>-cell: it is not possible to link more than two <I>i</I>-cells along a same <I>(i-1)</I>-cell. For this reason, it is not possible to describe non quasi-manifold objects as those shown in \cgalFigureRef{fig_gmap_non_manifolds} by generalized maps.
\cgalFigureBegin{fig_gmap_non_manifolds,gmap_non_manifolds.svg}
Three examples of non quasi-manifold objects. Left: A 2D object which is not a quasi-manifold since the two 2-cells share a common vertex but no common 1-cell. Middle: A 3D object which is not a quasi-manifold since is it not only composed by 3D cells glued together (there is an isolated 2-cell in dark gray). Right: A 3D object which is not a quasi-manifold since the two 3-cells share a common edge but no common 2-cell.
\cgalFigureEnd
Due to this additional condition, any objects can not be represented by a generalized map but only quasi-manifolds. We need to study now the inverse relation. Does any set of darts linked together by \f$ \alpha_i\f$'s, with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I> correspond to a quasi-manifold? As we can see in \cgalFigureRef{fig_gmap_non_valid}, the answer is no.
Due to this additional condition, any objects can not be represented by a generalized map but only quasi-manifolds. We need to study now the inverse relation. Does any set of darts linked together by \f$ \alpha_i\f$'s, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I> correspond to a quasi-manifold? As we can see in \cgalFigureRef{fig_gmap_non_valid}, the answer is no.
\cgalFigureBegin{fig_gmap_non_valid,gmap_non_valid.svg}
Two examples of darts linked together by some \f$ \alpha_0\f$, \f$ \alpha_1\f$, \f$ \alpha_2\f$ and \f$ \alpha_3\f$ which does not represent a 3D quasi-manifold, and thus which are not 3D generalized map. Left: In this example, all the darts are 3-free except \tred{\f$ \alpha_3\f$(1)=a, \f$ \alpha_3\f$(2)=b, \f$ \alpha_3\f$(7)=g and \f$ \alpha_3\f$(8)=h (and vice-versa)}. Right: In this example, darts \tred{1 to 8 and a to h} linked by \f$ \alpha_3\f$ are not in the same order in both 3-cells.
@ -155,7 +155,7 @@ In the first example (Left), there are two 3-cells (one to the left for the cube
But as we can see in the second example (Right), the condition that all the darts of the cell are linked in not sufficient. Indeed, in this example, all the darts of the 2-cell between the cube and the pyramid are linked together by \f$ \alpha_3\f$. However, this configuration does not correspond to a 3D quasi-manifold. Indeed, the operation of gluing two <I>d</I>-cells along one <I>(d-1)</I>-cell must preserve the structure of the initial <I>(d-1)</I>-cell.
To avoid these two kinds of configurations, conditions are added on \f$ \alpha\f$ pointers compositions (see Section \ref sec_definition_gmap "Mathematical Definitions", condition (4) of the definition of generalized maps). Intuitively these conditions say that if two darts are linked by \f$ \alpha_i\f$, then all the required darts are linked by \f$ \alpha_i\f$ two by two in such a way that neighborhood relations are preserved.
To avoid these two kinds of configurations, conditions are added on \f$ \alpha\f$ pointers compositions (see Section \ref sec_definition_gmap "Mathematical Definitions", condition (3) of the definition of generalized maps). Intuitively these conditions say that if two darts are linked by \f$ \alpha_i\f$, then all the required darts are linked by \f$ \alpha_i\f$ two by two in such a way that neighborhood relations are preserved.
We say that a generalized map is <I>valid</I> if it satisfies all the conditions on \f$ \alpha\f$ pointers and on association between darts and attributes. High level operations provided on generalized maps ensure that these conditions are always satisfied. Sometimes, it can be useful to use low level operations in a specific algorithm, for example to modify locally a generalized map in a really fast way. In such a case, additional operations may be needed to restore these validity conditions.
@ -193,9 +193,9 @@ All information associated to darts \tred{(\f$ \alpha\f$ links and attributes)}
\subsection ssecitemgmap Generalized Map Items
\tred{The `GenericMapItems` concept defines dart and attribute types of a generalized map. It contains one inner class named \link GenericMapItems::Dart_wrapper `Dart_wrapper`\endlink, having one template parameter, `BMap`, a model of `GenericMap` concept. The \link GenericMapItems::Dart_wrapper `Dart_wrapper<GMap>`\endlink class provides two local types: `%Dart` which must be a model of the `Dart` concept, and `%Attributes` which defines the attributes and their types.}
\tred{The `GenericMapItems` concept defines dart and attribute types of a generalized map. It contains one inner class named \link GenericMapItems::Dart_wrapper `Dart_wrapper`\endlink, having one template parameter, `Map`, a model of `GenericMap` concept. The \link GenericMapItems::Dart_wrapper `Dart_wrapper<Map>`\endlink class provides two local types: `%Dart` which must be a model of the `Dart` concept, and `%Attributes` which defines the attributes and their types.}
The `%Attributes` tuple must contain at most <I>d</I>+1 types (one for each possible cell dimension of the generalized map). Each type of the tuple must be either a model of the `CellAttribute` concept or `void`. The first type corresponds to 0-attributes, the second to 1-attributes and so on. If the <i>i <sup>th</sup></i> type in the tuple is `void`, <I>(i-1)</I>-attributes are disabled: we say that <I>(i-1)</I>-attributes are <I>void</I>. Otherwise, <I>(i-1)</I>-attributes are enabled and have the given type: we say <I>(i-1)</I>-attributes are <I>non void</I>. If the size of the tuple is <I>k</I>, with <I>k</I>\f$ <\f$<I>dimension+1</I>, \f$ \forall\f$<I>i</I>: <I>k</I>\f$ \leq\f$<I>i</I>\f$ \leq\f$dimension, <I>i</I>-attributes are void.
The `%Attributes` tuple must contain at most <I>d</I>+1 types (one for each possible cell dimension of the generalized map). Each type of the tuple must be either a model of the `CellAttribute` concept or `void`. The first type corresponds to 0-attributes, the second to 1-attributes and so on. If the <i>i <sup>th</sup></i> type in the tuple is `void`, <I>(i-1)</I>-attributes are disabled: we say that <I>(i-1)</I>-attributes are <I>void</I>. Otherwise, <I>(i-1)</I>-attributes are enabled and have the given type: we say <I>(i-1)</I>-attributes are <I>non void</I>. If the size of the tuple is <I>k</I>, with <I>k</I> \f$ < \f$ \link GenericMap::dimension `dimension`\endlink +1, \f$ \forall \f$ <I>i</I>: <I>k</I> \f$ \leq \f$ <I>i</I> \f$ \leq \f$ \link GenericMap::dimension `dimension\endlink, <I>i</I>-attributes are void.
The class `Generalized_map_min_items<d>` is a model of the `GenericMapItems` concept which can be used for default behaviors. It defines \tred{`Generalized_map_dart<d,GMap>`} as type of dart, and `Attributes` as empty tuple.
@ -256,16 +256,16 @@ There are three different categories of dart range classes:
<LI>\link GenericMap::Dart_range `Dart_range`\endlink: range of all the darts of a generalized map;
<LI>\link GenericMap::Dart_of_orbit_range `Dart_of_orbit_range<Alpha...>`\endlink: range of all the darts of the orbit \f$ \langle{}\f$`Alpha...`\f$ \rangle{}\f$(<I>d0</I>) for a given <I>d0</I>. `Alpha...` is a sequence of integers \f$ i_1\f$,..., \f$ i_k\f$, each \f$ i_j\f$\f$ \in\f${0, ..., <I>d</I>}. These integers must satisfy: \f$ i_1\f$\f$ <\f$\f$ i_2\f$\f$ <\f$...\f$ <\f$\f$ i_k\f$, and (\f$ i_1\f$\f$ \neq\f$ 0 or \f$ i_2\f$\f$ \neq\f$1) (for example \link GenericMap::Dart_of_orbit_range `Dart_of_orbit_range<1,2>`\endlink for the orbit \f$ \langle{}\f$\f$ \alpha_1\f$,\f$ \alpha_2\f$\f$ \rangle{}\f$(<I>d0</I>));
<LI>\link GenericMap::Dart_of_orbit_range `Dart_of_orbit_range<Alpha...>`\endlink: range of all the darts of the orbit \f$ \langle{}\f$`Alpha...`\f$ \rangle{}\f$(<I>d0</I>) for a given <I>d0</I>. `Alpha...` is a sequence of integers \f$ i_1\f$,..., \f$ i_k\f$, each \f$ i_j\f$ \f$ \in \f$ {0, ..., <I>d</I>}. These integers must satisfy: \f$ i_1\f$ \f$ < \f$\f$ i_2\f$\f$ < \f$...\f$ < \f$\f$ i_k\f$ (for example \link GenericMap::Dart_of_orbit_range `Dart_of_orbit_range<1,2>`\endlink for the orbit \f$ \langle{}\f$\f$ \alpha_1\f$,\f$ \alpha_2\f$\f$ \rangle{}\f$(<I>d0</I>));
<LI>\link GenericMap::Dart_of_cell_range `Dart_of_cell_range<i,dim>`\endlink: range of all the darts of the <I>i</I>-cell containing a given dart. The <I>i</I>-cell is considered in dimension `dim` (with 0\f$ \leq\f$<I>dim</I>\f$ \leq\f$<I>d</I>, <I>dim</I>=<I>d</I> by default), with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>dim+1</I>. If <I>i</I>=<I>dim+1</I>, \link GenericMap::Dart_of_cell_range `Dart_of_cell_range<i,dim>`\endlink is the range of all the darts of the connected component containing a given dart.
<LI>\link GenericMap::Dart_of_cell_range `Dart_of_cell_range<i,dim>`\endlink: range of all the darts of the <I>i</I>-cell containing a given dart. The <I>i</I>-cell is considered in dimension `dim` (with 0 \f$ \leq \f$ <I>dim</I> \f$ \leq \f$ <I>d</I>, <I>dim</I>=<I>d</I> by default), with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>dim+1</I>. If <I>i</I>=<I>dim+1</I>, \link GenericMap::Dart_of_cell_range `Dart_of_cell_range<i,dim>`\endlink is the range of all the darts of the connected component containing a given dart.
</UL>
There are also two different classes of ranges containing one dart per <I>i</I>-cell. Note that in these classes, the dart of each <I>i</I>-cell can be any dart of the cell. Moreover, each <I>i</I>-cell (and <I>j</I>-cell in the second case) is considered in dimension `dim` (with 0\f$ \leq\f$<I>dim</I>\f$ \leq\f$<I>d</I>, <I>dim=d</I> by default).
There are also two different classes of ranges containing one dart per <I>i</I>-cell. Note that in these classes, the dart of each <I>i</I>-cell can be any dart of the cell. Moreover, each <I>i</I>-cell (and <I>j</I>-cell in the second case) is considered in dimension `dim` (with 0 \f$ \leq \f$ <I>dim</I> \f$ \leq \f$ <I>d</I>, <I>dim=d</I> by default).
<UL>
<LI>\link GenericMap::One_dart_per_cell_range `One_dart_per_cell_range<i,dim>`\endlink: range containing one dart of each <I>i</I>-cell of the generalized map, 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>dim+1</I> (for example \link GenericMap::One_dart_per_cell_range `One_dart_per_cell_range<2>`\endlink for the range of one dart per 2-cell of the generalized map);
<LI>\link GenericMap::One_dart_per_cell_range `One_dart_per_cell_range<i,dim>`\endlink: range containing one dart of each <I>i</I>-cell of the generalized map, 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>dim+1</I> (for example \link GenericMap::One_dart_per_cell_range `One_dart_per_cell_range<2>`\endlink for the range of one dart per 2-cell of the generalized map);
<LI>\link GenericMap::One_dart_per_incident_cell_range `One_dart_per_incident_cell_range<i,j,dim>`\endlink: range containing one dart of each <I>i</I>-cell incident to the <I>j</I>-cell containing a given dart, with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>dim+1</I> and 0\f$ \leq\f$<I>j</I>\f$ \leq\f$<I>dim+1</I> (for example \link GenericMap::One_dart_per_incident_cell_range `One_dart_per_incident_cell_range<0,3>`\endlink for the range of one dart per vertex of the volume incident to the starting dart). If <I>i</I>=<I>j</I>, the range contains only the given dart.
<LI>\link GenericMap::One_dart_per_incident_cell_range `One_dart_per_incident_cell_range<i,j,dim>`\endlink: range containing one dart of each <I>i</I>-cell incident to the <I>j</I>-cell containing a given dart, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>dim+1</I> and 0 \f$ \leq \f$ <I>j</I> \f$ \leq \f$ <I>dim+1</I> (for example \link GenericMap::One_dart_per_incident_cell_range `One_dart_per_incident_cell_range<0,3>`\endlink for the range of one dart per vertex of the volume incident to the starting dart). If <I>i</I>=<I>j</I>, the range contains only the given dart.
</UL>
The iterators of the \link GenericMap::Dart_range `Dart_range`\endlink are bidirectional iterators, while the iterators of the other four ranges are forward iterators. The value type of all these iterators is `Dart` thus all these iterators can be directly used as \link GenericMap::Dart_handle `Dart_handle`\endlink.
@ -323,15 +323,15 @@ The \link GeneralizedMap::link_alpha `link_alpha`\endlink and \link GeneralizedM
\cgalAdvancedEnd
Linking two darts <I>d1</I> and <I>d2</I> by \f$ \alpha_i\f$, with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I> and <I>d1</I>\f$ \neq\f$<I>d2</I>, consists in modifying two \f$ \alpha_i\f$ pointers such that \f$ \alpha_i\f$(<I>d1</I>)=<I>d2</I> and \f$ \alpha_i\f$(<I>d2</I>)=<I>d1</I>.
Linking two darts <I>d1</I> and <I>d2</I> by \f$ \alpha_i\f$, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I> and <I>d1</I> \f$ \neq \f$ <I>d2</I>, consists in modifying two \f$ \alpha_i\f$ pointers such that \f$ \alpha_i\f$(<I>d1</I>)=<I>d2</I> and \f$ \alpha_i\f$(<I>d2</I>)=<I>d1</I>.
Reciprocally, unlinking a given dart <I>d0</I> by \f$ \alpha_i\f$, with 0\f$ \leq\f$ <I>i</I>\f$ \leq\f$<I>d</I>, consists in modifying two \f$ \alpha_i\f$ pointers such that \f$ \alpha_i\f$(\f$ \alpha_i\f$(<I>d0</I>))=\f$ \alpha_i\f$(<I>d0</I>) and \f$ \alpha_i\f$(<I>d0</I>)=<I>d0</I>. Note that is it possible to unlink a given dart for \f$ \alpha_i\f$ only if it is not <I>i</I>-free.
Reciprocally, unlinking a given dart <I>d0</I> by \f$ \alpha_i\f$, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>, consists in modifying two \f$ \alpha_i\f$ pointers such that \f$ \alpha_i\f$(\f$ \alpha_i\f$(<I>d0</I>))=\f$ \alpha_i\f$(<I>d0</I>) and \f$ \alpha_i\f$(<I>d0</I>)=<I>d0</I>. Note that is it possible to unlink a given dart for \f$ \alpha_i\f$ only if it is not <I>i</I>-free.
\cgalFigureBegin{fig_gmap_example_3d_sew,gmap_example_3d_sew.svg}
Example of 3-sew operation. Left: A 3D generalized map containing two volumes that are not connected, with 2-attributes. Each attribute contains a color in RGB format, and there are four 2-cells associated with attributes. Associations between darts and attributes are drawn with red segments. Right: The 3D generalized map obtained as result of \tred{\link GenericMap::sew `sew<3>(1,a)`\endlink (or \link GenericMap::sew `sew<3>(2,b)`\endlink ... or \link GenericMap::sew `sew<3>(8,h)`\endlink). Darts (1,a), ..., (8,h)} are linked together by \f$ \alpha_3\f$. The two 2-cells \tred{<I>c1</I>={1,...,8} and <I>c2</I>={a,...,h}} are merged after the sew into the 2-cell \tred{{1,...,8,a,...,h}}. We are in the case where the two attributes are non NULL, thus the first one is kept, and all the darts of <I>c2</I> are associated with the first attribute.
\cgalFigureEnd
The \link GenericMap::sew `sew<i>(dh1,dh2)`\endlink method consists mainly to link two by two several darts by \f$ \alpha_i\f$. This operation is possible only if there is a bijection <I>f</I> between all the darts of the orbit <I>D1</I>=\f$ \langle{}\f$\f$ \alpha_1\f$,...,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d1</I>) and <I>D2</I>=\f$ \langle{}\f$\f$ \alpha_1\f$,...,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,..., \f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d2</I>) satisfying: <I>f</I>(<I>d1</I>)=<I>d2</I>, and for all <I>e</I>\f$ \in\f$<I>D1</I>, for all <I>j</I>\f$ \in\f${1,..., i-2,i+2,...,<I>d</I>}, <I>f</I>(\f$ \alpha_j\f$(<I>e</I>))=\f$ \alpha_j^{-1}\f$(<I>f</I>(<I>e</I>)). Intuitively, this condition ensures the validity of the generalized map by verifying that condition discussed in Section \ref ssecgenmapvalidity "Generalized Map Properties" will be satisfied after the operation. This condition can be tested by using the method \link GenericMap::is_sewable `is_sewable<i>(dh1,dh2)`\endlink. For example, the function \link GenericMap::is_sewable `is_sewable<3>`\endlink would return `false` if we tried to 3-sew a triangular facet with a quad facet. Note that given two darts <I>d1</I> and <I>d2</I>, if there is such a bijection, it is uniquely defined. So giving the two darts as arguments of the \link GenericMap::sew `sew<i>`\endlink is enough to retrieve all the pairs of darts to link. If such a bijection exists, the \link GenericMap::sew `sew<i>(dh1,dh2)`\endlink operation consists only in linking by \f$ \alpha_i\f$ each couple of darts <I>d3</I> and <I>d4</I> such that <I>d3</I>=<I>f</I>(<I>d4</I>).
The \link GenericMap::sew `sew<i>(dh1,dh2)`\endlink method consists mainly to link two by two several darts by \f$ \alpha_i\f$. This operation is possible only if there is a bijection <I>f</I> between all the darts of the orbit <I>D1</I>=\f$ \langle{}\f$\f$ \alpha_1\f$,...,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d1</I>) and <I>D2</I>=\f$ \langle{}\f$\f$ \alpha_1\f$,...,\f$ \alpha_{i-2}\f$,\f$ \alpha_{i+2}\f$,..., \f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d2</I>) satisfying: <I>f</I>(<I>d1</I>)=<I>d2</I>, and for all <I>e</I> \f$ \in \f$ <I>D1</I>, for all <I>j</I> \f$ \in \f$ {1,..., i-2,i+2,...,<I>d</I>}, <I>f</I>(\f$ \alpha_j\f$(<I>e</I>))=\f$ \alpha_j^{-1}\f$(<I>f</I>(<I>e</I>)). Intuitively, this condition ensures the validity of the generalized map by verifying that condition discussed in Section \ref ssecgenmapvalidity "Generalized Map Properties" will be satisfied after the operation. This condition can be tested by using the method \link GenericMap::is_sewable `is_sewable<i>(dh1,dh2)`\endlink. For example, the function \link GenericMap::is_sewable `is_sewable<3>`\endlink would return `false` if we tried to 3-sew a triangular facet with a quad facet. Note that given two darts <I>d1</I> and <I>d2</I>, if there is such a bijection, it is uniquely defined. So giving the two darts as arguments of the \link GenericMap::sew `sew<i>`\endlink is enough to retrieve all the pairs of darts to link. If such a bijection exists, the \link GenericMap::sew `sew<i>(dh1,dh2)`\endlink operation consists only in linking by \f$ \alpha_i\f$ each couple of darts <I>d3</I> and <I>d4</I> such that <I>d3</I>=<I>f</I>(<I>d4</I>).
In addition, the sew operation updates the associations between darts and non void attributes in order to guarantee that all the darts belonging to a given cell are associated with the same attribute (which is a condition of generalized map validity). For each couple of <I>j</I>-cells <I>c1</I> and <I>c2</I> that are merged into one <I>j</I>-cell during the sew, we have to update the two associated attributes <I>attr1</I> and <I>attr2</I>. If both are NULL, there is nothing to do. If one is NULL and the other not, we only associate the non NULL attribute to all the darts of the resulting cell. When the two attributes are non NULL, we first apply functor \link CellAttribute::On_merge `On_merge`\endlink on the two attributes <I>attr1</I> and <I>attr2</I> (see Section \ref ssecattributesgmap "Cell Attributes"). Then, we associate the attribute <I>attr1</I> to all darts of the resulting <I>j</I>-cell. Finally, attribute <I>attr2</I> is removed from the generalized map.
@ -368,30 +368,30 @@ Illustration of the use of the 2-sew operation to construct a non-orientable gen
The following high level operations are defined. All these methods ensure that given a valid generalized map and a possible operation, the modified generalized map is also valid.
The first one is `gm`.\link GenericMap::remove_cell `remove_cell<i>(dh0)`\endlink which modifies the generalized map to remove the <I>i</I>-cell containing dart `d0`, with 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>. This operation is possible if <I>i</I>=<I>d</I> or if the given <I>i</I>-cell is incident to at most two <I>(i+1)</I>-cells which can be tested thanks to `gm.`\link GenericMap::is_removable `is_removable<i>(dh0)`\endlink. If the removed <I>i</I>-cell was incident to two different <I>(i+1)</I>-cells, these two cells are merged into one <I>(i+1)</I>-cell. In this case, the \link CellAttribute::On_merge `On_merge`\endlink functor is called if two <I>(i+1)</I>-attributes are associated to the two <I>(i+1)</I>-cells. If the <I>i</I>-cell is associated with a non void attribute, it is removed from the generalized map (see three examples on \cgalFigureRef{fig_gmap_insert_vertex}, \cgalFigureRef{fig_gmap_insert_edge} and \cgalFigureRef{fig_gmap_insert_facet}).
The first one is `gm`.\link GenericMap::remove_cell `remove_cell<i>(dh0)`\endlink which modifies the generalized map to remove the <I>i</I>-cell containing dart `d0`, with 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>. This operation is possible if <I>i</I>=<I>d</I> or if the given <I>i</I>-cell is incident to at most two <I>(i+1)</I>-cells which can be tested thanks to `gm.`\link GenericMap::is_removable `is_removable<i>(dh0)`\endlink. If the removed <I>i</I>-cell was incident to two different <I>(i+1)</I>-cells, these two cells are merged into one <I>(i+1)</I>-cell. In this case, the \link CellAttribute::On_merge `On_merge`\endlink functor is called if two <I>(i+1)</I>-attributes are associated to the two <I>(i+1)</I>-cells. If the <I>i</I>-cell is associated with a non void attribute, it is removed from the generalized map (see three examples on \cgalFigureRef{fig_gmap_insert_vertex}, \cgalFigureRef{fig_gmap_insert_edge} and \cgalFigureRef{fig_gmap_insert_facet}).
\cgalFigureBegin{fig_gmap_insert_vertex,gmap_insert_vertex.svg}
Example of \link GenericMap::insert_cell_0_in_cell_1 `insert_cell_0_in_cell_1`\endlink and \link GenericMap::remove_cell `remove_cell<0>`\endlink operations. Left: Initial generalized map. Right: After the insertion of a 0-cell in the 1-cell containing dart `d1`. Now if we remove the 0-cell containing dart `d2`, we obtain the initial generalized map.
\cgalFigureEnd
The inverse operation of the removal is the insertion operation. Several versions exist, sharing a common principle. They consist in adding a new <I>i</I>-cell <em>inside</em> an existing <I>j</I>-cell, <I>i</I>\f$ <\f$<I>j</I>, by splitting the <I>j</I>-cell into several <I>j</I>-cells. Contrary to `remove_cell<i>`, is it not possible to define a unique `insert_cell_i_in_cell_j<i,j>` function because parameters are different depending on `i` and `j`.
The inverse operation of the removal is the insertion operation. Several versions exist, sharing a common principle. They consist in adding a new <I>i</I>-cell <em>inside</em> an existing <I>j</I>-cell, <I>i</I> \f$ < \f$<I>j</I>, by splitting the <I>j</I>-cell into several <I>j</I>-cells. Contrary to `remove_cell<i>`, is it not possible to define a unique `insert_cell_i_in_cell_j<i,j>` function because parameters are different depending on `i` and `j`.
`gm.`\link GenericMap::insert_cell_0_in_cell_1 `insert_cell_0_in_cell_1(dh0)`\endlink adds a 0-cell in the 1-cell containing dart `d0`. The 1-cell is split in two. This operation is possible if `d0`\f$ \in\f$\link GenericMap::darts `gm.darts()`\endlink (see example on \cgalFigureRef{fig_gmap_insert_vertex}).
`gm.`\link GenericMap::insert_cell_0_in_cell_1 `insert_cell_0_in_cell_1(dh0)`\endlink adds a 0-cell in the 1-cell containing dart `d0`. The 1-cell is split in two. This operation is possible if `d0` \f$ \in \f$ \link GenericMap::darts `gm.darts()`\endlink (see example on \cgalFigureRef{fig_gmap_insert_vertex}).
`gm.`\link GenericMap::insert_cell_0_in_cell_2 `insert_cell_0_in_cell_2(dh0)`\endlink adds a 0-cell in the 2-cell containing dart `d0`. The 2-cell is split in triangles, one for each initial edge of the facet. This operation is possible if `d0`\f$ \in\f$\link GenericMap::darts `gm.darts()`\endlink (see example on \cgalFigureRef{fig_gmap_triangulation}).
`gm.`\link GenericMap::insert_cell_0_in_cell_2 `insert_cell_0_in_cell_2(dh0)`\endlink adds a 0-cell in the 2-cell containing dart `d0`. The 2-cell is split in triangles, one for each initial edge of the facet. This operation is possible if `d0` \f$ \in \f$ \link GenericMap::darts `gm.darts()`\endlink (see example on \cgalFigureRef{fig_gmap_triangulation}).
\cgalFigureBegin{fig_gmap_triangulation,gmap_triangulation.svg}
Example of \link GenericMap::insert_cell_0_in_cell_2 `insert_cell_0_in_cell_2`\endlink operation.
\cgalFigureEnd
`gm.`\link GenericMap::insert_cell_1_in_cell_2 `insert_cell_1_in_cell_2(dh1,dh2)`\endlink adds a 1-cell in the 2-cell containing darts `d1` and `d2`, between the two 0-cells containing darts `d1` and `d2`. The 2-cell is split in two. This operation is possible \tred{if <I>d1</I>\f$ \in\f$\f$ \langle{}\f$\f$ \alpha_0, \alpha_1\f$\f$ \rangle{}\f$(<I>d2</I>)} which can be tested thanks to `gm.`\link GenericMap::is_insertable_cell_1_in_cell_2 `is_insertable_cell_1_in_cell_2(dh1,dh2)`\endlink. In the example on \cgalFigureRef{fig_gmap_insert_edge}, it is possible to insert an edge between darts <I>d2</I> and <I>d3</I>, but it is not possible to insert an edge between <I>d1</I> and <I>d3</I>.
`gm.`\link GenericMap::insert_cell_1_in_cell_2 `insert_cell_1_in_cell_2(dh1,dh2)`\endlink adds a 1-cell in the 2-cell containing darts `d1` and `d2`, between the two 0-cells containing darts `d1` and `d2`. The 2-cell is split in two. This operation is possible \tred{if <I>d1</I> \f$ \in \f$ \f$ \langle{}\f$\f$ \alpha_0, \alpha_1\f$\f$ \rangle{}\f$(<I>d2</I>)} which can be tested thanks to `gm.`\link GenericMap::is_insertable_cell_1_in_cell_2 `is_insertable_cell_1_in_cell_2(dh1,dh2)`\endlink. In the example on \cgalFigureRef{fig_gmap_insert_edge}, it is possible to insert an edge between darts <I>d2</I> and <I>d3</I>, but it is not possible to insert an edge between <I>d1</I> and <I>d3</I>.
\cgalFigureBegin{fig_gmap_insert_edge,gmap_insert_edge.svg}
Example of \link GenericMap::insert_cell_1_in_cell_2 `insert_cell_1_in_cell_2`\endlink and \link GenericMap::remove_cell `remove_cell<1>`\endlink operations. Left: Initial generalized map. Right: After the insertion of two 1-cells: a first one between the two 0-cells containing darts `d2` and `d3`, and a second one incident to the 0-cell containing dart `d1`. Now if we remove the two 1-cells containing darts `d4` and `d5`, we obtain the initial generalized map.
\cgalFigureEnd
`gm.`\link GenericMap::insert_dangling_cell_1_in_cell_2 `insert_dangling_cell_1_in_cell_2(dh0)`\endlink adds a 1-cell in the 2-cell containing dart `d0`, the 1-cell being attached by only one of its vertex to the 0-cell containing dart `d0`. This operation is possible if `d0`\f$ \in\f$\link GenericMap::darts `gm.darts()`\endlink.
`gm.`\link GenericMap::insert_dangling_cell_1_in_cell_2 `insert_dangling_cell_1_in_cell_2(dh0)`\endlink adds a 1-cell in the 2-cell containing dart `d0`, the 1-cell being attached by only one of its vertex to the 0-cell containing dart `d0`. This operation is possible if `d0` \f$ \in \f$ \link GenericMap::darts `gm.darts()`\endlink.
`gm.`\link GenericMap::insert_cell_2_in_cell_3 `insert_cell_2_in_cell_3(itbegin,itend)`\endlink adds a 2-cell in the 3-cell containing all the darts between `itbegin` and `itend`, along the path of 1-cells containing darts in [`itbegin`,`itend`). The 3-cell is split in two. This operation is possible if all the darts in [`itbegin`,`itend`) form a closed path inside a same 3-cell which can be tested thanks to `gm.`\link GenericMap::is_insertable_cell_2_in_cell_3 `is_insertable_cell_2_in_cell_3(itbegin,itend)`\endlink (see example on \cgalFigureRef{fig_gmap_insert_facet}).
@ -514,24 +514,24 @@ Lastly we remove the dynamic onmerge functor (step 7). This is done by initializ
The definition of generalized map in any dimension is given in \cgalCite{cgal:l-tmbrc-91}, \cgalCite{l-ndgcm-94}. See also the book \cgalCite{cgal:dl-cmeds-14} which regroups many definitions, operations and algorithms about combinatorial and generalized maps.
An <I>involution</I> on a finite set <I>E</I> is a mapping <I>f</I> from <I>E</I> to <I>E</I> which is bijective and equal to its inverse. Thus \f$ \forall\f$<I>e</I>\f$ \in\f$<I>E</I>, we have <I>f</I>(<I>e</I>) = \f$ f^{-1}\f$(<I>e</I>) and <I>f</I>(<I>f</I>(<I>e</I>))=<I>e</I>.
An <I>involution</I> on a finite set <I>E</I> is a mapping <I>f</I> from <I>E</I> to <I>E</I> which is bijective and equal to its inverse. Thus \f$ \forall \f$ <I>e</I> \f$ \in \f$ <I>E</I>, we have <I>f</I>(<I>e</I>) = \f$ f^{-1}\f$(<I>e</I>) and <I>f</I>(<I>f</I>(<I>e</I>))=<I>e</I>.
Let <I>d</I>\f$ \geq\f$ 0. A <I>d</I>-dimensional generalized map (or <I>d</I>-Gmap) is a (d+1)-tuple <I>G</I>=(<I>D</I>,\f$ \alpha_0\f$,...,\f$ \alpha_d\f$) where:
<OL>
<LI><I>D</I> is a finite set of darts;
<LI>\f$ \forall\f$<I>i</I>, 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>, \f$ \alpha_i\f$ is an involution on <I>D</I>;
<LI>\anchor gmapcondcomposition \f$ \forall\f$<I>i</I>: 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>-2, \f$ \forall\f$<I>j</I>: 2\f$ \leq\f$<I>j</I>\f$ \leq\f$<I>d</I>, <I>i</I>+2\f$ \leq\f$<I>j</I>, \f$ \alpha_i\f$\f$ \circ\f$\f$ \alpha_j\f$ is an involution.
<LI>\f$ \forall \f$ <I>i</I>, 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>, \f$ \alpha_i \f$ is an involution on <I>D</I>;
<LI>\anchor gmapcondcomposition \f$ \forall \f$ <I>i</I>: 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>-2, \f$ \forall \f$ <I>j</I>: 2 \f$ \leq \f$ <I>j</I> \f$ \leq \f$ <I>d</I>, <I>i</I>+2 \f$ \leq \f$ <I>j</I>, \f$ \alpha_i \f$ \f$ \circ \f$ \f$ \alpha_j\f$ is an involution.
</OL>
A <I>d</I>-dimensional generalized map represents a subdivision of an orientable or non-orientable <I>d</I>-dimensional quasi-manifold. A dart is an abstract element which is only required to define involutions. The last line of the definition fixes constraints which guarantee the topological validity of the represented object, i.e., the fact that it is a quasi-manifold. This definition allows us to verify the validity of a given generalized map by checking if each item of the definition is satisfied.
\cgalModifEnd
Given a set of \tred{involutions} <I>S</I>=\f$\{f_1\f$,..., \f$ f_k\}\f$, we denote by \f$ \langle{}\f$ <I>S</I> \f$ \rangle{}\f$ the <I>permutation group</I> generated by \f$\{f_1\f$,..., \f$ f_k\}\f$ and whose group operation is the composition of involutions. The orbit \f$ \langle{}\f$\f$ f_1\f$,..., \f$ f_k\f$\f$ \rangle{}\f$(<I>a</I>) is the set of darts which can be obtained from <I>a</I> by elements of \f$ \langle{}\f$ <I>S</I> \f$ \rangle{}\f$: \f$ \langle{}\f$\f$ f_1\f$,..., \f$ f_k\f$\f$ \rangle{}\f$(<I>a</I>)=\f$\{ \phi\f$(<I>a</I>)\f$ |\f$\f$ \phi\f$\f$ \in\f$\f$ \langle{}\f$<I>S</I>\f$ \rangle{}\}\f$.
Given a set of \tred{involutions} <I>S</I>=\f$\{f_1\f$,..., \f$ f_k\}\f$, we denote by \f$ \langle{}\f$ <I>S</I> \f$ \rangle{}\f$ the <I>permutation group</I> generated by \f$\{f_1\f$,..., \f$ f_k\}\f$ and whose group operation is the composition of involutions. The orbit \f$ \langle{}\f$\f$ f_1\f$,..., \f$ f_k\f$\f$ \rangle{}\f$(<I>a</I>) is the set of darts which can be obtained from <I>a</I> by elements of \f$ \langle{}\f$ <I>S</I> \f$ \rangle{}\f$: \f$ \langle{}\f$\f$ f_1\f$,..., \f$ f_k\f$\f$ \rangle{}\f$(<I>a</I>)=\f$\{ \phi\f$(<I>a</I>)\f$ |\f$\f$ \phi\f$\f$ \in \f$ \f$ \langle{}\f$<I>S</I>\f$ \rangle{}\}\f$.
\cgalModifBegin
Let <I>d0</I>\f$ \in\f$<I>D</I> be a dart. Given <I>i</I>, 0\f$ \leq\f$<I>i</I>\f$ \leq\f$<I>d</I>, the <I>i</I>-cell containing <I>d0</I> is \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d0</I>).
Let <I>d0</I> \f$ \in \f$ <I>D</I> be a dart. Given <I>i</I>, 0 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ <I>d</I>, the <I>i</I>-cell containing <I>d0</I> is \f$ \langle{}\f$\f$ \alpha_0\f$,...,\f$ \alpha_{i-1}\f$,\f$ \alpha_{i+1}\f$,...,\f$ \alpha_d\f$\f$ \rangle{}\f$(<I>d0</I>).
\section Generalized_mapDesign Design and Implementation History

View File

@ -8,19 +8,16 @@ The class `Cell_attribute_with_point` represents an attribute containing a point
\cgalModels `CellAttributeWithPoint`
\tparam LCC a model of the `LinearCellComplex` concept,
\tparam Info_ the type of the information contained in the attribute, `void` for no information,
\tparam LCC a model of the `LinearCellComplex` concept.
\tparam Info_ the type of the information contained in the attribute, `void` for no information. Equal to `void` by default.
\tparam Tag is `::Tag_true` to enable the storage of a \link Cell_attribute_with_point::Dart_handle `Dart_handle`\endlink of the associated cell, `::Tag_false` otherwise. Equal to `::Tag_true` by default.
\tparam OnMerge a functor called when two attributes are merged. Equal to `Null_functor` by default.
\tparam OnSplit a functor called when one attribute is split in two. Equal to `Null_functor` by default.
\tparam Tag is `::Tag_true` to enable the storage of a \link Cell_attribute_with_point::Dart_handle `Dart_handle`\endlink of the associated cell, `::Tag_false` otherwise,
\tparam OnMerge a functor called when two attributes are merged,
\tparam OnSplit a functor called when one attribute is split in two.
By default, `OnMerge` and `OnSplit` are equal to `Null_functor`; `Tag` is equal to `::Tag_true`; and `Info_` is equal to `void`.
\sa `CGAL::Linear_cell_complex_min_items<d>`
\sa `CGAL::Cell_attribute<CMap,Info_,Tag,OnMerge,OnSplit>`
\sa `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_combinatorial_map_min_items<d>`
\sa `CGAL::Linear_cell_complex_for_generalized_map_min_items<d>`
\sa `CGAL::Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`
*/
template< typename LCC, typename Info_, typename Tag, typename OnMerge, typename OnSplit >

View File

@ -1,59 +0,0 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `GMap_linear_cell_complex` represents a linear cell complex in dimension `d`, in an ambient space of dimension `d2`, using a generalized map as underlying combinatorial data-structure. This is a model of the concept of `LinearCellComplex` and a model of the concept `GeneralizedMap`.
\cgalModels `LinearCellComplex`
\cgalModels `GeneralizedMap`
\tparam d the dimension of the generalized map,
\tparam d2 the dimension of the ambient space,
\tparam LCCTraits a model of the `LinearCellComplexTraits` concept, satisfying \link LinearCellComplexTraits::ambient_dimension `LCCTraits::ambient_dimension`\endlink`==d2`,
\tparam Items a model of the `LinearCellComplexItems` concept,
\tparam Alloc has to match the standard allocator requirements.
There are four default template arguments: `d2` is equal to `d`, `LCCTraits` is equal to `CGAL::Linear_cell_complex_traits<d2>`, `Items` is equal to `CGAL::GMap_linear_cell_complex_min_items<d>` and `Alloc` is `CGAL_ALLOCATOR(int)`.
\cgalAdvancedBegin
Note that there is an additional, and undocumented, template parameter `GMap` for `GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc,GMap>` allowing to inherit from any model of the `GeneralizedMap` concept. \cgalAdvancedEnd
\sa `CGAL::Generalized_map<d,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_traits<d,K>`
\sa `CGAL::GMap_linear_cell_complex_min_items<d>`
*/
template< typename d, typename d2, typename LCCTraits, typename Items, typename Alloc >
class GMap_linear_cell_complex : public Generalized_map<d,Items,Alloc>
{
public:
/// \name Constants
/// @{
/*!
Ambient dimension, must be > 1.
*/
static unsigned int ambient_dimension = d2;
/// @}
/// \name Types
/// @{
/*!
*/
typedef GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc> Self;
/*!
The type of dart, must satisfy \link Dart::dimension `Dart::dimension`\endlink`==d`.
*/
typedef Items::Dart_wrapper<Self>::Dart Dart;
}; /* end GMap_linear_cell_complex */
} /* end namespace CGAL */

View File

@ -1,44 +0,0 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `GMap_linear_cell_complex_min_items` defines the type of darts, which is a `GMap_dart<d,LCC>`, and the traits class used. In this class, 0-attributes are enabled and associated with `Cell_attribute_with_point`.
\cgalModels `LinearCellComplexItems`
\tparam d the dimension of the generalized map.
\cgalHeading{Example}
The following example shows one implementation of the `GMap_linear_cell_complex_min_items` class.
\code{.cpp}
template <unsigned int d>
struct GMap_linear_cell_complex_min_items
{
template <class LCC>
struct Dart_wrapper
{
typedef CGAL::GMap_dart<d, LCC> Dart;
typedef CGAL::Cell_attribute_with_point<LCC> Vertex_attrib;
typedef CGAL::cpp11::tuple<Vertex_attrib> Attributes;
};
};
\endcode
\sa `CGAL::GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::GMap_dart<d,CMap>`
*/
template< typename d >
class GMap_linear_cell_complex_min_items {
public:
/// @}
}; /* end GMap_Linear_cell_complex_min_items */
} /* end namespace CGAL */

View File

@ -1,59 +0,0 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex` represents a linear cell complex in dimension `d`, in an ambient space of dimension `d2`, using a combinatorial map as underlying combinatorial data-structure. This is a model of the concept of `LinearCellComplex` and a model of the concept `CombinatorialMap`.
\cgalModels `LinearCellComplex`
\cgalModels `CombinatorialMap`
\tparam d an integer for the dimension of the combinatorial map,
\tparam d2 an integer for the dimension of the ambient space,
\tparam LCCTraits must be a model of the `LinearCellComplexTraits` concept, satisfying \link LinearCellComplexTraits::ambient_dimension `LCCTraits::ambient_dimension`\endlink`==d2`,
\tparam Items must be a model of the `LinearCellComplexItems` concept,
\tparam Alloc has to match the standard allocator requirements.
There are four default template arguments: `d2` is equal to `d`, `LCCTraits` is equal to `CGAL::Linear_cell_complex_traits<d2>`, `Items` is equal to `CGAL::Linear_cell_complex_min_items<d>` and `Alloc` is `CGAL_ALLOCATOR(int)`.
\cgalAdvancedBegin
Note that there is an additional, and undocumented, template parameter `CMap` for `Linear_cell_complex<d,d2,LCCTraits,Items,Alloc,CMap>` allowing to inherit from any model of the `CombinatorialMap` concept. \cgalAdvancedEnd
\sa `CGAL::Combinatorial_map<d,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_traits<d,K>`
\sa `CGAL::Linear_cell_complex_min_items<d>`
*/
template< typename d, typename d2, typename LCCTraits, typename Items, typename Alloc >
class Linear_cell_complex : public Combinatorial_map<d,Items,Alloc>
{
public:
/// \name Constants
/// @{
/*!
Ambient dimension, must be > 1.
*/
static const unsigned int ambient_dimension = d2;
/// @}
/// \name Types
/// @{
/*!
*/
typedef Linear_cell_complex<d,d2,LCCTraits,Items,Alloc> Self;
/*!
The type of dart, must satisfy \link Dart::dimension `Dart::dimension`\endlink`==d`.
*/
typedef Items::Dart_wrapper<Self>::Dart Dart;
}; /* end Linear_cell_complex */
} /* end namespace CGAL */

View File

@ -0,0 +1,59 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex_for_combinatorial_map` represents a linear cell complex in dimension `d`, in an ambient space of dimension `d2`, using a combinatorial map as underlying combinatorial data-structure.
\cgalModels `LinearCellComplex`
\cgalModels `CombinatorialMap`
\tparam d the dimension of the combinatorial map.
\tparam d2 the dimension of the ambient space. Equal to `d` by default.
\tparam LCCTraits be a model of the `LinearCellComplexTraits` concept, satisfying \link LinearCellComplexTraits::ambient_dimension `LCCTraits::ambient_dimension`\endlink`==d2`. Equal to `CGAL::Linear_cell_complex_traits<d2>` by default.
\tparam Items a model of the `LinearCellComplexItems` concept. Equal to `CGAL::Linear_cell_complex_for_combinatorial_map_min_items<d>` by default.
\tparam Alloc has to match the standard allocator requirements. Equal to `CGAL_ALLOCATOR(int)` by default.
\cgalAdvancedBegin
Note that there is an additional, and undocumented, template parameter `CMap` for `Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc,CMap>` allowing to inherit from any model of the `CombinatorialMap` concept. \cgalAdvancedEnd
\sa `CGAL::Combinatorial_map<d,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_traits<d,K>`
\sa `CGAL::Linear_cell_complex_for_combinatorial_map_min_items<d>`
\deprecated Before CGAL 4.9, this class was named `%Linear_cell_complex`. This old name still exist for backward compatibility.
*/
template< typename d, typename d2, typename LCCTraits, typename Items, typename Alloc >
class Linear_cell_complex_for_combinatorial_map : public Combinatorial_map<d,Items,Alloc>
{
public:
/// \name Constants
/// @{
/*!
Ambient dimension, must be > 1.
*/
static const unsigned int ambient_dimension = d2;
/// @}
/// \name Types
/// @{
/*!
*/
typedef Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc> Self;
/*!
The type of dart, must satisfy \link Dart::dimension `Dart::dimension`\endlink`==d`.
*/
typedef Items::Dart_wrapper<Self>::Dart Dart;
}; /* end Linear_cell_complex_for_combinatorial_map */
} /* end namespace CGAL */

View File

@ -0,0 +1,47 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex_for_combinatorial_map_min_items` defines the type of darts, which is a `Combinatorial_map_dart<d,LCC>`, and the attributes used. In this class, 0-attributes are enabled and associated with `Cell_attribute_with_point`.
\cgalModels `LinearCellComplexItems`
\tparam d the dimension of the combinatorial map.
\deprecated Before CGAL 4.9, this class was named `%Linear_cell_complex_min_items`. This old name still exist for backward compatibility.
\cgalHeading{Example}
The following example shows one implementation of the `Linear_cell_complex_for_combinatorial_map_min_items` class.
\code{.cpp}
template <unsigned int d>
struct Linear_cell_complex_for_combinatorial_map_min_items
{
template <class LCC>
struct Dart_wrapper
{
typedef CGAL::Combinatorial_map_dart<d, LCC> Dart;
typedef CGAL::Cell_attribute_with_point<LCC> Vertex_attrib;
typedef CGAL::cpp11::tuple<Vertex_attrib> Attributes;
};
};
\endcode
\sa `CGAL::Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Combinatorial_map_dart<d,CMap>`
*/
template< typename d >
class Linear_cell_complex_for_combinatorial_map_min_items {
public:
/// @}
}; /* end Linear_cell_complex_for_combinatorial_map_min_items */
} /* end namespace CGAL */

View File

@ -0,0 +1,57 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex_for_generalized_map` represents a linear cell complex in dimension `d`, in an ambient space of dimension `d2`, using a generalized map as underlying combinatorial data-structure.
\cgalModels `LinearCellComplex`
\cgalModels `GeneralizedMap`
\tparam d the dimension of the generalized map.
\tparam d2 the dimension of the ambient space. Equal to `d` by default.
\tparam LCCTraits a model of the `LinearCellComplexTraits` concept, satisfying \link LinearCellComplexTraits::ambient_dimension `LCCTraits::ambient_dimension`\endlink`==d2`. Equal to`CGAL::Linear_cell_complex_traits<d2>` by default.
\tparam Items a model of the `LinearCellComplexItems` concept. Equal to `CGAL::Linear_cell_complex_for_generalized_map_min_items<d>` by default.
\tparam Alloc has to match the standard allocator requirements. Equal to `CGAL_ALLOCATOR(int)` by default.
\cgalAdvancedBegin
Note that there is an additional, and undocumented, template parameter `GMap` for `Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc,GMap>` allowing to inherit from any model of the `GeneralizedMap` concept. \cgalAdvancedEnd
\sa `CGAL::Generalized_map<d,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_traits<d,K>`
\sa `CGAL::Linear_cell_complex_for_generalized_map_min_items<d>`
*/
template< typename d, typename d2, typename LCCTraits, typename Items, typename Alloc >
class Linear_cell_complex_for_generalized_map : public Generalized_map<d,Items,Alloc>
{
public:
/// \name Constants
/// @{
/*!
Ambient dimension, must be > 1.
*/
static unsigned int ambient_dimension = d2;
/// @}
/// \name Types
/// @{
/*!
*/
typedef Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc> Self;
/*!
The type of dart, must satisfy \link Dart::dimension `Dart::dimension`\endlink`==d`.
*/
typedef Items::Dart_wrapper<Self>::Dart Dart;
}; /* end Linear_cell_complex_for_generalized_map */
} /* end namespace CGAL */

View File

@ -0,0 +1,44 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex_for_generalized_map_min_items` defines the type of darts, which is a `Generalized_map_dart<d,LCC>`, and the attributes used. In this class, 0-attributes are enabled and associated with `Cell_attribute_with_point`.
\cgalModels `LinearCellComplexItems`
\tparam d the dimension of the generalized map.
\cgalHeading{Example}
The following example shows one implementation of the `Linear_cell_complex_for_generalized_map_min_items` class.
\code{.cpp}
template <unsigned int d>
struct Linear_cell_complex_for_generalized_map_min_items
{
template <class LCC>
struct Dart_wrapper
{
typedef CGAL::Generalized_map_dart<d, LCC> Dart;
typedef CGAL::Cell_attribute_with_point<LCC> Vertex_attrib;
typedef CGAL::cpp11::tuple<Vertex_attrib> Attributes;
};
};
\endcode
\sa `CGAL::Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Generalized_map_dart<d,CMap>`
*/
template< typename d >
class Linear_cell_complex_for_generalized_map_min_items {
public:
/// @}
}; /* end Linear_cell_complex_for_generalized_map_min_items */
} /* end namespace CGAL */

View File

@ -1,45 +0,0 @@
namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
The class `Linear_cell_complex_min_items` defines the type of darts, which is a `Dart<d,LCC>`, and the traits class used. In this class, 0-attributes are enabled and associated with `Cell_attribute_with_point`.
\cgalModels `LinearCellComplexItems`
\tparam d the dimension of the combinatorial map.
\cgalHeading{Example}
The following example shows one implementation of the `Linear_cell_complex_min_items` class.
\code{.cpp}
template <unsigned int d>
struct Linear_cell_complex_min_items
{
template <class LCC>
struct Dart_wrapper
{
typedef CGAL::Dart<d, LCC> Dart;
typedef CGAL::Cell_attribute_with_point<LCC> Vertex_attrib;
typedef CGAL::cpp11::tuple<Vertex_attrib> Attributes;
};
};
\endcode
\sa `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Dart<d,CMap>`
*/
template< typename d >
class Linear_cell_complex_min_items {
public:
/// @}
}; /* end Linear_cell_complex_min_items */
} /* end namespace CGAL */

View File

@ -4,7 +4,7 @@ namespace CGAL {
\ingroup PkgLinearCellComplexOperations
Returns the normal vector of the 0-cell containing `dh`, i.e.\ the average of all the normal vectors of the 2-cells incident to the 0-cell containing `dh`.
\pre \link LinearCellComplex::ambient_dimension `LCC::ambient_dimension`\endlink==3 and `*dh`\f$ \in\f$\link GenericMap::darts `lcc.darts()`\endlink.
\pre \link LinearCellComplex::ambient_dimension `LCC::ambient_dimension`\endlink==3 and `*dh` \f$ \in \f$ \link GenericMap::darts `lcc.darts()`\endlink.
\sa `CGAL::compute_normal_of_cell_2<LCC>`
@ -17,7 +17,7 @@ typename LCC::Dart_const_handle dh);
\ingroup PkgLinearCellComplexOperations
Returns the normal vector of the 2-cell containing `dh`.
\pre \link LinearCellComplex::ambient_dimension `LCC::ambient_dimension`\endlink==3 and `*dh`\f$ \in\f$\link GenericMap::darts `lcc.darts()`\endlink.
\pre \link LinearCellComplex::ambient_dimension `LCC::ambient_dimension`\endlink==3 and `*dh` \f$ \in \f$ \link GenericMap::darts `lcc.darts()`\endlink.
\sa `CGAL::compute_normal_of_cell_0<LCC>`
*/

View File

@ -4,19 +4,17 @@ namespace CGAL {
/*!
\ingroup PkgLinearCellComplexClasses
This geometric traits concept is used in the `Linear_cell_complex` and `GMap_linear_cell_complex` classes. It can take as parameter any model of the concept `Kernel` (for example any \cgal kernel), and defines inner types and functors corresponding to the given dimension.
This geometric traits concept is used in the `Linear_cell_complex_for_combinatorial_map` and `Linear_cell_complex_for_generalized_map` classes. It can take as parameter any model of the concept `Kernel` (for example any \cgal kernel), and defines inner types and functors corresponding to the given dimension.
\cgalModels `LinearCellComplexTraits`
\tparam d the dimension of the kernel,
\tparam K a model of the concept `Kernel` if `d==2` or `d==3`; a model of the concept `Kernel_d` otherwise.
\tparam K a model of the concept `Kernel` if `d==2` or `d==3`; a model of the concept `Kernel_d` otherwise. Equal by default to `CGAL::Exact_predicates_inexact_constructions_kernel` if `d` is 2 or 3, and is `CGAL::Cartesian_d<double>` otherwise.
There is a default template arguments for `K` which is `CGAL::Exact_predicates_inexact_constructions_kernel` if `d` is 2 or 3, and is `CGAL::Cartesian_d<double>` otherwise.
Note that the default argument used for `K` when <I>d</I> > 3 does not use exact predicates because operations that use predicates are only defined in 2D and 3D.
Note that the default argument used for `K` when <I>d</I>>3 does not use exact predicates because operations that use predicates are only defined in 2D and 3D.
\sa `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`
*/
template< typename d, typename K >

View File

@ -6,8 +6,8 @@ The concept `LinearCellComplex` represents a linear cell complex in dimension `d
\cgalRefines `GenericMap`
\cgalHasModel \link CGAL::Linear_cell_complex `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`\endlink
\cgalHasModel \link CGAL::GMap_linear_cell_complex `CGAL::GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`\endlink
\cgalHasModel \link CGAL::Linear_cell_complex_for_combinatorial_map `CGAL::Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`\endlink
\cgalHasModel \link CGAL::Linear_cell_complex_for_generalized_map `CGAL::Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`\endlink
\sa `LinearCellComplexItems`
\sa `LinearCellComplexTraits`
@ -117,7 +117,7 @@ Vertex_attribute_const_range& vertex_attributes() const;
/*!
Returns true iff this linear cell complex is valid.
A linear cell complex `lcc` is valid if it is a valid generic map (cf. `GenericMap::is_valid()`), and if for each dart handle <I>dh</I> such that `*dh`\f$\in\f$\link GenericMap::darts `darts()`\endlink: \link GenericMap::attribute `dh->attribute<0>()`\endlink`!=NULL`.
A linear cell complex `lcc` is valid if it is a valid generic map (cf. `GenericMap::is_valid()`), and if for each dart handle <I>dh</I> such that `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink: \link GenericMap::attribute `dh->attribute<0>()`\endlink`!=NULL`.
*/
bool is_valid() const;
@ -164,7 +164,7 @@ const Point& point(Dart_const_handle dh) const;
/*!
Creates a new dart in this linear cell complex, sets its associated 0-attribute to `vh` and returns the corresponding handle.
\pre `*vh`\f$ \in\f$`vertex_attributes()`.
\pre `*vh` \f$ \in \f$ `vertex_attributes()`.
*/
Dart_handle create_dart(Vertex_attribute_handle vh);
@ -181,14 +181,14 @@ create_vertex_attribute(T1 t1);
/*!
Removes the 0-attribute pointed to by `vh` from this linear cell complex (a shortcut for \link GenericMap::erase_attribute `erase_attribute<0>(vh)`\endlink).
\pre `*vh`\f$ \in\f$`vertex_attributes()`.
\pre `*vh` \f$ \in \f$ `vertex_attributes()`.
*/
void erase_vertex_attribute(Vertex_attribute_handle vh);
/*!
Associates the 0-attribute of all the darts of the 0-cell containing `dh` to `vh` (a shortcut for \link GenericMap::set_attribute `set_attribute<0>(dh,vh)`\endlink).
\pre `*dh`\f$ \in\f$\link GenericMap::darts `darts()`\endlink and `*vh`\f$ \in\f$`vertex_attributes()`.
\pre `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink and `*vh` \f$ \in \f$ `vertex_attributes()`.
*/
void set_vertex_attribute(Dart_handle dh, Vertex_attribute_handle vh);
@ -211,7 +211,7 @@ void correct_invalid_attributes();
/*!
Returns the barycenter of the <I>i</I>-cell containing `dh`.
\pre 1\f$ \leq\f$<I>i</I>\f$ \leq\f$\link GenericMap::dimension `dimension`\endlink and `*dh`\f$ \in\f$\link GenericMap::darts `darts()`\endlink.
\pre 1 \f$ \leq \f$ <I>i</I> \f$ \leq \f$ \link GenericMap::dimension `dimension`\endlink and `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink.
*/
template<unsigned int i> Point barycenter(Dart_const_handle dh) const;
@ -219,7 +219,7 @@ template<unsigned int i> Point barycenter(Dart_const_handle dh) const;
/*!
Inserts a point, copy of `p`, in the <I>i</I>-cell containing `dh`.
Returns a handle on one dart of this cell.
\pre <I>i</I>\f$ \leq\f$\link GenericMap::dimension `dimension`\endlink \f$ \leq\f$ 2 and `*dh`\f$ \in\f$\link GenericMap::darts `darts()`\endlink.
\pre <I>i</I> \f$ \leq \f$ \link GenericMap::dimension `dimension`\endlink \f$ \leq \f$ 2 and `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink.
If \link GenericMap::are_attributes_automatically_managed `are_attributes_automatically_managed()`\endlink`==true`, if <I>i</I>-attributes are non void, \link CellAttribute::On_split `Attribute_type<i>::type::On_split`\endlink(<I>a</I>,<I>a'</I>) is called, with <I>a</I> the original <I>i</I>-attribute associated with <I>dh</I> and <I>a'</I> each new <I>i</I>-attribute created during the operation.
@ -233,7 +233,7 @@ template <unsigned int i> Dart_handle insert_point_in_cell(Dart_handle dh, Point
/*!
Inserts a point in the barycenter of the <I>i</I>-cell containing `dh`.
Returns a handle on one dart of this cell.
\pre <I>i</I>\f$ \leq\f$\link GenericMap::dimension `dimension`\endlink \f$ \leq\f$ 2 and `*dh`\f$ \in\f$\link GenericMap::darts `darts()`\endlink.
\pre <I>i</I> \f$ \leq \f$ \link GenericMap::dimension `dimension`\endlink \f$ \leq \f$ 2 and `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink.
If \link GenericMap::are_attributes_automatically_managed `are_attributes_automatically_managed()`\endlink`==true`, if <I>i</I>-attributes are non void, \link CellAttribute::On_split `Attribute_type<i>::type::On_split`\endlink(<I>a</I>,<I>a'</I>) is called, with <I>a</I> the original <I>i</I>-attribute associated with <I>dh</I> and <I>a'</I> each new <I>i</I>-attribute created during the operation.
@ -246,7 +246,7 @@ template <unsigned int i> Dart_handle insert_barycenter_in_cell(Dart_handle dh);
/*!
Inserts a 1-cell in the 2-cell containing `dh`, the 1-cell being attached only by one of its vertex to the 0-cell containing `dh`. The second vertex is associated with a new 0-attribute containing a copy of `p` as point. Returns a handle on one dart belonging to the new 0-cell.
\pre 2\f$ \leq\f$\link GenericMap::dimension `dimension`\endlink and `*dh`\f$ \in\f$\link GenericMap::darts `darts()`\endlink.
\pre 2 \f$ \leq \f$ \link GenericMap::dimension `dimension`\endlink and `*dh` \f$ \in \f$ \link GenericMap::darts `darts()`\endlink.
\cgalAdvancedBegin
If \link GenericMap::are_attributes_automatically_managed `are_attributes_automatically_managed()`\endlink`==false`, non void attributes are not updated; thus the combinatorial map can be no more valid after this operation.

View File

@ -9,8 +9,8 @@ The concept `LinearCellComplexItems` refines the concept of `GenericMapItems` by
The first type in `Attributes` tuple must be a model of the `CellAttributeWithPoint` concept.
\cgalHasModel \link CGAL::Linear_cell_complex_min_items `CGAL::Linear_cell_complex_min_items<d>`\endlink
\cgalHasModel \link CGAL::GMap_linear_cell_complex_min_items `CGAL::GMap_linear_cell_complex_min_items<d>`\endlink
\cgalHasModel \link CGAL::Linear_cell_complex_for_combinatorial_map_min_items `CGAL::Linear_cell_complex_for_combinatorial_map_min_items<d>`\endlink
\cgalHasModel \link CGAL::Linear_cell_complex_for_generalized_map_min_items `CGAL::Linear_cell_complex_for_generalized_map_min_items<d>`\endlink
\sa `LinearCellComplex`
\sa `CellAttributeWithPoint`

View File

@ -3,11 +3,12 @@
\ingroup PkgLinearCellComplexConcepts
\cgalConcept
Required types and functors for the `LinearCellComplexTraits` concept. This geometric traits concept is used in the \link CGAL::Linear_cell_complex `Linear_cell_complex`\endlink class.
Required types and functors for the `LinearCellComplexTraits` concept. This geometric traits concept is used in the \link CGAL::Linear_cell_complex_for_combinatorial_map `Linear_cell_complex_for_combinatorial_map`\endlink and \link CGAL::Linear_cell_complex_for_generalized_map `Linear_cell_complex_for_generalized_map`\endlink classes.
\cgalHasModel \link CGAL::Linear_cell_complex_traits `CGAL::Linear_cell_complex_traits<d,K>`\endlink
\sa `CGAL::Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`
\sa `CGAL::Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`
*/

View File

@ -37,7 +37,7 @@ Note that the dimension of the combinatorial \tred{or the generalized} map <I>d<
\section Linear_cell_complexSoftware Software Design
\tred{The diagram in \cgalFigureRef{fig_lcc_diagramme_class} shows the main classes of the package. `Linear_cell_complex` is the main class if you use combinatorial maps as combinatorial data-structure, and `GMap_linear_cell_complex` is the main class if you use generalized maps as combinatorial data-structure (see Section \ref sseclinearcellcomplex). `Linear_cell_complex` inherits from the `Combinatorial_map` class and `GMap_linear_cell_complex` inherits from the `Generalized_map` class.} Attributes can be associated to some cells of the linear cell complex thanks to an items class (see Section \ref sseclccitem "Linear Cell Complex Items"), which defines the dart type and the attributes types. These types may be different for different dimensions of cells, and they may also be void. In the class `Linear_cell_complex`, it is required that specific attributes are associated to all vertices of the \tred{combinatorial or generalized} map. These attributes must contain a point (a model of \link Kernel::Point_2 `Point_2`\endlink or \link Kernel::Point_3 `Point_3`\endlink or \link Kernel_d::Point_d `Point_d`\endlink), and can be represented by instances of class `Cell_attribute_with_point` (see Section \ref ssecattributewp "Cell Attributes").
\tred{The diagram in \cgalFigureRef{fig_lcc_diagramme_class} shows the main classes of the package. `Linear_cell_complex_for_combinatorial_map` is the main class if you use combinatorial maps as combinatorial data-structure, and `Linear_cell_complex_for_generalized_map` is the main class if you use generalized maps as combinatorial data-structure (see Section \ref sseclinearcellcomplex). `Linear_cell_complex_for_combinatorial_map` inherits from the `Combinatorial_map` class and `Linear_cell_complex_for_generalized_map` inherits from the `Generalized_map` class.} Attributes can be associated to some cells of the linear cell complex thanks to an items class (see Section \ref sseclccitem "Linear Cell Complex Items"), which defines the dart type and the attributes types. These types may be different for different dimensions of cells, and they may also be void. In the class `Linear_cell_complex_for_combinatorial_map`, it is required that specific attributes are associated to all vertices of the \tred{combinatorial or generalized} map. These attributes must contain a point (a model of \link Kernel::Point_2 `Point_2`\endlink or \link Kernel::Point_3 `Point_3`\endlink or \link Kernel_d::Point_d `Point_d`\endlink), and can be represented by instances of class `Cell_attribute_with_point` (see Section \ref ssecattributewp "Cell Attributes").
\cgalFigureBegin{fig_lcc_diagramme_class,lcc_diagramme_class.svg}
UML diagram of the main classes of the package. Gray elements come from the \ref ChapterCombinatorialMap "Combinatorial maps" \tred{and \ref ChapterGeneralizedMap "Generalized maps"} packages.
@ -46,15 +46,15 @@ UML diagram of the main classes of the package. Gray elements come from the \ref
\section sseclinearcellcomplex Linear Cell Complex
The \link CGAL::Linear_cell_complex `Linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`\endlink class is a model of the `LinearCellComplex` concept \tred{that uses a combinatorial map as underlying combinatorial data-structure}. Similarly, the \link CGAL::GMap_linear_cell_complex `GMap_linear_cell_complex<d,d2,LCCTraits,Items,Alloc>`\endlink class is a model of the `LinearCellComplex` concept \tred{that uses a generalized map as underlying combinatorial data-structure. These two classes} guarantee that each vertex is associated with an attribute containing a point. These classes can be used in geometric algorithms (they play the same role as `Polyhedron_3` for \ref chapterHalfedgeDS "Halfedge Data Structures").
The \link CGAL::Linear_cell_complex_for_combinatorial_map `Linear_cell_complex_for_combinatorial_map<d,d2,LCCTraits,Items,Alloc>`\endlink class is a model of the `LinearCellComplex` concept \tred{that uses a combinatorial map as underlying combinatorial data-structure}. Similarly, the \link CGAL::Linear_cell_complex_for_generalized_map `Linear_cell_complex_for_generalized_map<d,d2,LCCTraits,Items,Alloc>`\endlink class is a model of the `LinearCellComplex` concept \tred{that uses a generalized map as underlying combinatorial data-structure. These two classes} guarantee that each vertex is associated with an attribute containing a point. These classes can be used in geometric algorithms (they play the same role as `Polyhedron_3` for \ref chapterHalfedgeDS "Halfedge Data Structures").
These classes has five template parameters standing for the dimension of the map, the dimension of the ambient space, a traits class (a model of the `LinearCellComplexTraits` concept, see Section \ref sseclcctraits "Linear Cell Complex Traits"), an items class (a model of the `LinearCellComplexItems` concept, see Section \ref sseclccitem "Linear Cell Complex Items"), and an allocator which must be a model of the allocator concept of \stl. %Default classes are provided for the traits, items, and for the allocator classes, and by default `d2=d`.
A linear cell complex is valid, if it is a valid combinatorial \tred{or generalized} map where each dart is associated with an attribute containing a point (i.e.\ an instance of a model of the `CellAttributeWithPoint`
concept). Note that there are no validity constraints on the geometry (test on self intersection, planarity of 2-cells...). We can see two examples of `Linear_cell_complex` in \cgalFigureRef{fig_lcc_instantiations}.
concept). Note that there are no validity constraints on the geometry (test on self intersection, planarity of 2-cells...). We can see two examples of `Linear_cell_complex_for_combinatorial_map` in \cgalFigureRef{fig_lcc_instantiations}.
\cgalFigureBegin{fig_lcc_instantiations,lcc_instantiations.svg}
Examples of `Linear_cell_complex`. Gray disks show the attributes associated to vertices. Associations between darts and attributes are drawn by small lines between darts and disks. <B>Left:</B> Example of `Linear_cell_complex<2,2>`. <B>Right:</B> Example of `Linear_cell_complex<3,3>`.
Examples of `Linear_cell_complex_for_combinatorial_map`. Gray disks show the attributes associated to vertices. Associations between darts and attributes are drawn by small lines between darts and disks. <B>Left:</B> Example of `Linear_cell_complex_for_combinatorial_map<2,2>`. <B>Right:</B> Example of `Linear_cell_complex_for_combinatorial_map<3,3>`.
\cgalFigureEnd
@ -66,7 +66,7 @@ The `Cell_attribute_with_point<LCC,Info_,Tag,OnMerge,OnSplit>` class is a model
\subsection Linear_cell_complexLinearCellComplexTraits Linear Cell Complex Traits
\anchor sseclcctraits
The `LinearCellComplexTraits` geometric traits concept defines the required types and functors used in the `Linear_cell_complex` class. For example it defines \link LinearCellComplexTraits::Point `Point`\endlink, the type of points used, and \link LinearCellComplexTraits::Vector `Vector`\endlink, the corresponding vector type. It also defines all the required functors used for constructions and operations, as for example \link LinearCellComplexTraits::Construct_translated_point `Construct_translated_point`\endlink or \link LinearCellComplexTraits::Construct_sum_of_vectors `Construct_sum_of_vectors`\endlink.
The `LinearCellComplexTraits` geometric traits concept defines the required types and functors used in the `Linear_cell_complex_for_combinatorial_map` class. For example it defines \link LinearCellComplexTraits::Point `Point`\endlink, the type of points used, and \link LinearCellComplexTraits::Vector `Vector`\endlink, the corresponding vector type. It also defines all the required functors used for constructions and operations, as for example \link LinearCellComplexTraits::Construct_translated_point `Construct_translated_point`\endlink or \link LinearCellComplexTraits::Construct_sum_of_vectors `Construct_sum_of_vectors`\endlink.
The class `Linear_cell_complex_traits<d,K>` is a model of `LinearCellComplexTraits`. It defines the different types which are obtained from `K` that, depending on `d`, is a model of the concept `Kernel` if `d==2` or `d==3`, and a model of the concept `Kernel_d` otherwise.
@ -75,9 +75,9 @@ The class `Linear_cell_complex_traits<d,K>` is a model of `LinearCellComplexTrai
The `LinearCellComplexItems` concept refines the `GenericMapItems` concept by adding the requirement that 0-attributes are enabled, and associated with a type of attribute being a model of the `CellAttributeWithPoint` concept.
The class `Linear_cell_complex_min_items<d>` is a model of `LinearCellComplexItems` when using combinatorial maps. It uses `Dart<d>`, and instances of `Cell_attribute_with_point` (which contain no information) associated to each vertex. All other attributes are `void`.
The class `Linear_cell_complex_for_combinatorial_map_min_items<d>` is a model of `LinearCellComplexItems` when using combinatorial maps. It uses `Combinatorial_map_dart<d>`, and instances of `Cell_attribute_with_point` (which contain no information) associated to each vertex. All other attributes are `void`.
\tred{Similarly, the class `GMap_linear_cell_complex_min_items<d>` is a model of `LinearCellComplexItems` when using generalized maps. It uses `GMap_dart<d>`, and instances of `Cell_attribute_with_point` (which contain no information) associated to each vertex. All other attributes are `void`.}
\tred{Similarly, the class `Linear_cell_complex_for_generalized_map_min_items<d>` is a model of `LinearCellComplexItems` when using generalized maps. It uses `Generalized_map_dart<d>`, and instances of `Cell_attribute_with_point` (which contain no information) associated to each vertex. All other attributes are `void`.}
\section Linear_cell_complexOperations Operations
@ -120,7 +120,7 @@ Lastly, the function \link ::import_from_plane_graph `import_from_plane_graph(lc
\subsection Linear_cell_complexModificationOperations Modification Operations
\anchor ssecmodifop
Some methods are defined in `Linear_cell_complex` class to modify a linear cell complex and update the vertex attributes. In the following, we denote by `dh0`, `dh1`, `dh2` the dart handles for the darts `d0`, `d1`, `d2`, respectively. That is `d0 == *dh0`.
Some methods are defined in `LinearCellComplex` to modify a linear cell complex and update the vertex attributes. In the following, we denote by `dh0`, `dh1`, `dh2` the dart handles for the darts `d0`, `d1`, `d2`, respectively. That is `d0 == *dh0`.
\cgalFigureBegin{fig_lcc_insert_vertex,lcc_insert_vertex.svg}
Example of \link LinearCellComplex::insert_barycenter_in_cell `insert_barycenter_in_cell<1>`\endlink and `remove_cell<0>` operations. <B>Left</B>: Initial linear cell complex. <B>Right</B>: After the insertion of a point in the barycenter of the 1-cell containing dart <I>d1</I>. Now if we remove the 0-cell containing dart <I>d2</I>, we obtain a linear cell complex isomorphic to the initial one.
@ -202,7 +202,7 @@ The output is:
This example illustrates the way to use a 3D linear cell complex by
adding another information to vertices. For that, we need to define
our own items class. The difference with the
`Linear_cell_complex_min_items` class is about the definition of
`Linear_cell_complex_for_combinatorial_map_min_items` class is about the definition of
the vertex attribute where we use a `Cell_attribute_with_point`
with a non `void` info. In this example, the <em>vertex color</em> is just
given by an `int` (the second template parameter of the
@ -212,7 +212,7 @@ resulting of the merging of two vertices to the average of the two
initial values. This functor is associated with the vertex attribute
by passing it as template parameter. Using this items class instead of
the default one is done during the instantiation of template
parameters of the `Linear_cell_complex` class.
parameters of the `Linear_cell_complex_for_combinatorial_map` class.
Now we can use `LCC_3` in which each vertex is associated with an
attribute containing both a point and an information. In the following