Version 2.0 was commit: 5b8b5c21ec18c878a93be2fca95f9c9dafd58ac6
Short version:
Made it work without point/weighted_point implicit conversions
and made it more generic by reworking the inheritance of adaptors and providing
appropriate constructors
Long version:
-- Reworked P3_construct_point_3 and P3_construct_weighted_point_3 to inherit
a base Construct_point_3 and initialize it properly at construction.
-- Renamed Traits_with_offset / Regular_traits_with_offset adaptors. These
classes now inherit the base functor and the constructors allow to initialize
that base from an existing functor (meaning that we don't default constructor
functors anymore). This also means that we can use the base operator() of the
functors and can thus use all possible inputs (with or without offsets).
-- Static filters now probably inherit the correct *_filtered_traits_base_3.
-- All traits classes now have constructor to be able to initialize traits
from a given domain and a given base kernel (rather than default construct)
-- Fixed Del/regular_remove_traits inherting the wrong classes
-- Filtered traits have exact and approximate traits rather than exact and
approximate domains with default constructed traits
One problem is left:
Filtered traits members are initialized with a default constructed base kernel.
Ideally, it should use Cartesian_converter(Base::kernel()), but this does not
exist...
Version 2.0 was commit: 5b8b5c21ec18c878a93be2fca95f9c9dafd58ac6
Short version:
Made it work without point/weighted_point implicit conversions
and made it more generic by reworking the inheritance of adaptors and providing
appropriate constructors
Long version:
-- Reworked P3_construct_point_3 and P3_construct_weighted_point_3 to inherit
a base Construct_point_3 and initialize it properly at construction.
-- Renamed Traits_with_offset / Regular_traits_with_offset adaptors. These
classes now inherit the base functor and the constructors allow to initialize
that base from an existing functor (meaning that we don't default constructor
functors anymore). This also means that we can use the base operator() of the
functors and can thus use all possible inputs (with or without offsets).
-- Static filters now probably inherit the correct *_filtered_traits_base_3.
-- All traits classes now have constructor to be able to initialize traits
from a given domain and a given base kernel (rather than default construct)
-- Fixed Del/regular_remove_traits inherting the wrong classes
-- Filtered traits have exact and approximate traits rather than exact and
approximate domains with default constructed traits
One problem is left:
Filtered traits members are initialized with a default constructed base kernel.
Ideally, it should use Cartesian_converter(Base::kernel()), but this does not
exist...
It was a giant mess of point, construct_point, Point_3, point,
and the same for segment, triangle, tetrahedron.
With this commit :
-- All types are aligned on Point and Point_3, that is the former
may in fact be a K::Weighted_point_3 while the latter is always
a K::Point_3. For example, the type Periodic_segment is a periodic
segment with extremities of type Point (thus possible weighted),
while Periodic_segment_3 has extremities Point_3 (bare points).
-- Functions with 'construct_' in the name will return a
"bare" type (e.g. construct_segment() returns a Segment_3,
construct_periodic_segment() a Periodic_segment_3, etc.).
Functions without 'construct_' will return possibly-weighted
types (e.g. segment() returns a Segment, periodic_segment()
returns a Periodic_segment, etc.).
-- Fixed many duplicates functions
-- Geometric functions now allow all possible inputs (e.g. it is
possible to call construct_point() on a Point, a Point_3, a Periodic_point,
and a Periodic_point_3).
-- Fixed a few bugs:
-- tr.point() will correctly return a Weighted_point when called
from a regular triangulation
-- construct_point() must not be called before the predicates otherwise
we are using the wrong version of the domain (and get wrong filters)
-- Fixed wrong function types (e.g. nearest_power_vertex takes a Bare_point
in argument, not a weighted_point)
It was a giant mess of point, construct_point, Point_3, point,
and the same for segment, triangle, tetrahedron.
With this commit :
-- All types are aligned on Point and Point_3, that is the former
may in fact be a K::Weighted_point_3 while the latter is always
a K::Point_3. For example, the type Periodic_segment is a periodic
segment with extremities of type Point (thus possible weighted),
while Periodic_segment_3 has extremities Point_3 (bare points).
-- Functions with 'construct_' in the name will return a
"bare" type (e.g. construct_segment() returns a Segment_3,
construct_periodic_segment() a Periodic_segment_3, etc.).
Functions without 'construct_' will return possibly-weighted
types (e.g. segment() returns a Segment, periodic_segment()
returns a Periodic_segment, etc.).
-- Fixed many duplicates functions
-- Geometric functions now allow all possible inputs (e.g. it is
possible to call construct_point() on a Point, a Point_3, a Periodic_point,
and a Periodic_point_3).
-- Fixed a few bugs:
-- tr.point() will correctly return a Weighted_point when called
from a regular triangulation
-- construct_point() must not be called before the predicates otherwise
we are using the wrong version of the domain (and get wrong filters)
-- Fixed wrong function types (e.g. nearest_power_vertex takes a Bare_point
in argument, not a weighted_point)
Preparation for rebase on the implicit conversion branch.
Improved consistency on typedefs in P3T3:
-Point: either Gt::Point_3 or Gt::Weighted_point_3
-Point_3: Gt::Point_3
-Periodic_point: a periodic Point
-Periodic_point_3: a periodic Point_3
in P3RT3:
-Bare_point: Gt::Point_3
-Weighted_point: Gt::Weighted_point_3
-Periodic_bare_point: a periodic Bare_point
-Periodic_weighted_point: a periodic Weighted_point
in P3T3, functions:
construct_point: return_type --> Gt::Point_3
point: return_type --> Point
construct_periodic_point: return_type --> Periodic_point_3
periodic_point: return_type --> Periodic_point
in P3RT3, functions:
construct_weighted_point: return_type --> Gt::Weighted_point_3
Preparation for rebase on the implicit conversion branch.
Improved consistency on typedefs in P3T3:
-Point: either Gt::Point_3 or Gt::Weighted_point_3
-Point_3: Gt::Point_3
-Periodic_point: a periodic Point
-Periodic_point_3: a periodic Point_3
in P3RT3:
-Bare_point: Gt::Point_3
-Weighted_point: Gt::Weighted_point_3
-Periodic_bare_point: a periodic Bare_point
-Periodic_weighted_point: a periodic Weighted_point
in P3T3, functions:
construct_point: return_type --> Gt::Point_3
point: return_type --> Point
construct_periodic_point: return_type --> Periodic_point_3
periodic_point: return_type --> Periodic_point
in P3RT3, functions:
construct_weighted_point: return_type --> Gt::Weighted_point_3
BEFORE:
A template mecanism allows to determine wether the kernel offers filtered, or
even statistically filtered operations. The highest level is chosen and includes
the sub-levels. For example, if the kernel offers filtered but _not_ statistically
filtered operations, using the traits class `Periodic_3_triangulation_traits_3`
is equivalent to using the class `Periodic_3_triangulation_filtered_traits_3`,
which inherits the operations of `Periodic_3_triangulation_traits_3` (implemented
in `Periodic_3_triangulation_traits_base_3`) and overwrites some of them.
A similar mecanism is done for Delaunay and regular traits; e.g. if the kernel
offers statistically filtered traits, then using `Periodic_3_Delaunay_triangulation_traits_3`
is similar to using `Periodic_3_Delaunay_triangulation_statistically_filtered_traits_3`,
which inherits from `Periodic_3_Delaunay_triangulation_filtered_traits_3`, which itself
inherits from `Periodic_3_Delaunay_triangulation_traits_3`.
PROBLEM:
The base class of Delaunay and regular traits, respectively
`Periodic_3_Delaunay_triangulation_traits_base_3` and
`Periodic_3_regular_triangulation_traits_base_3` inherit the class
`Periodic_3_triangulation_traits_base_3`. Thus, if the kernel is filtered
or statistically filtered, then the filtered operations that should
"belong" at the level of triangulation traits (for example, orientation_3)
must be duplicated in the Delaunay and regular traits file otherwise
they are not filtered.
AFTER:
With this commit, the Delaunay and regular bases traits inherit
from `Periodic_3_triangulation_traits_3` (no "_base"). This means
that the base class will also select its highest possible level of
filtration and there is no need to duplicate code 3 times anymore.
BEFORE:
A template mecanism allows to determine wether the kernel offers filtered, or
even statistically filtered operations. The highest level is chosen and includes
the sub-levels. For example, if the kernel offers filtered but _not_ statistically
filtered operations, using the traits class `Periodic_3_triangulation_traits_3`
is equivalent to using the class `Periodic_3_triangulation_filtered_traits_3`,
which inherits the operations of `Periodic_3_triangulation_traits_3` (implemented
in `Periodic_3_triangulation_traits_base_3`) and overwrites some of them.
A similar mecanism is done for Delaunay and regular traits; e.g. if the kernel
offers statistically filtered traits, then using `Periodic_3_Delaunay_triangulation_traits_3`
is similar to using `Periodic_3_Delaunay_triangulation_statistically_filtered_traits_3`,
which inherits from `Periodic_3_Delaunay_triangulation_filtered_traits_3`, which itself
inherits from `Periodic_3_Delaunay_triangulation_traits_3`.
PROBLEM:
The base class of Delaunay and regular traits, respectively
`Periodic_3_Delaunay_triangulation_traits_base_3` and
`Periodic_3_regular_triangulation_traits_base_3` inherit the class
`Periodic_3_triangulation_traits_base_3`. Thus, if the kernel is filtered
or statistically filtered, then the filtered operations that should
"belong" at the level of triangulation traits (for example, orientation_3)
must be duplicated in the Delaunay and regular traits file otherwise
they are not filtered.
AFTER:
With this commit, the Delaunay and regular bases traits inherit
from `Periodic_3_triangulation_traits_3` (no "_base"). This means
that the base class will also select its highest possible level of
filtration and there is no need to duplicate code 3 times anymore.
Because the point lies on a vertex does not mean that it is closest to that
vertex for the power distance (e.g. there could be a point with near infinite
weight somewhere else and that point would be the closest)
Because the point lies on a vertex does not mean that it is closest to that
vertex for the power distance (e.g. there could be a point with near infinite
weight somewhere else and that point would be the closest)
This aligns the way Periodic_3_regular_triangulation_3 is built with Triangulation_3's
Regular_triangulation_3: the TDS now uses a Regular_triangulation_vertex_base_3 and
a Weighted_point_mapper_3 wraps the Point_3 type out of the base geometric traits
This aligns the way Periodic_3_regular_triangulation_3 is built with Triangulation_3's
Regular_triangulation_3: the TDS now uses a Regular_triangulation_vertex_base_3 and
a Weighted_point_mapper_3 wraps the Point_3 type out of the base geometric traits
-- A real kernel is now passed to the traits and not some kind of Regular_traits
thus removing the need for Weighted_converter_3 (and similar changes)
-- Updated function objects names
-- A real kernel is now passed to the traits and not some kind of Regular_traits
thus removing the need for Weighted_converter_3 (and similar changes)
-- Updated function objects names
-- Gave Regular_traits_with_offsets_adaptor its own file
-- Updated function objects names
(e.g. power_test_3 -> Power_side_of_oriented_power_sphere_3)
-- Regular_traits_with_offsets_adaptor now has all the required operator()
overloads to avoid losing point weights due to implicit WP->P conversions
-- Periodic_3_regular_triangulation_traits_base_3 now derives from
Periodic_3_triangulation_traits_base_3
-- Gave Regular_traits_with_offsets_adaptor its own file
-- Updated function objects names
(e.g. power_test_3 -> Power_side_of_oriented_power_sphere_3)
-- Regular_traits_with_offsets_adaptor now has all the required operator()
overloads to avoid losing point weights due to implicit WP->P conversions
-- Periodic_3_regular_triangulation_traits_base_3 now derives from
Periodic_3_triangulation_traits_base_3
Followup to:
> commit 535c5bb5b2
> Author: Laurent Rineau <laurent.rineau@cgal.org>
> Date: Wed Apr 6 16:03:55 2016 +0200
>
> Speed-up Triangulation_3::read_cells...
>
> ... by a factor 5 for big triangulations! The old code was using:
>
> std::map<size_t, Vertex_handle> V;
> std::map<size_t, Cell_handle> C;
>
> whereas the indices are contiguous: from 0 to n. `std::vector` is a lot
> better for that use case!
Locate functions returns an Offset indicating the translation to apply on the
periodic geometry object associated to a cell, to get the periodic
geometry object really containing the input point.
The start_vertices vector has been invalid since we remove vertex references in
virtual_vertices_reverse causing periodic_locate() to fail.
For the moment, Cell_handle() is provided as start cell for periodic_locate().
Maybe a better approach is possible.
If a point must be hidden in the triangulation, get_location_offset()
can't find a valid offset and fails with an assert.
So, it is ok for P3RT3 that get_location_offset() doesn't find an offset
at this step of the insertion.
The vertex was deleted in the tds, but it was still referenced in
some attributes of P3T3 (virtual_vertices and virtual_vertices_reverse).
Points are hidden in wrong cells. Work on this bug has begun.
Regular_traits_with_offsets_adaptor was created for compatibility with
less_power_distance() method. Construct_circumcenter is defined to be
compatible with Periodic_3_triangulation_3.
Add class Periodic_3_triangulation_traits_3.
Add class Periodic_3_triangulation_filtered__traits_3.
Put Traits_with_offsets_adaptor in a separate header.
Put Periodic_3_construct_point_3 in a separate header.
Update tests.
The class Periodic_3_triangulation_filtered_traits_3 is renamed.
The class Periodic_3_triangulation_filtered_traits_base_3 is renamed.
New header file.
Periodic_3_triangulation_filtered_traits_base_3 is set deprecated.
Classes Periodic_3_triangulation_traits_3 and
Periodic_3_triangulation_traits_base_3 are renamed.
Tests, examples, ... are updated.
Doc is updated.
Periodic_3_triangulation_traits_3.h is set deprecated.
This branch adds an additional way to filter predicates that are only doing
operations using a ring number type. In case of failure, a RT is used rather
than an FT which speeds things up.
Successfully tested in CGAL-4.3Ic-37
I just needed to added a constructor where the approximate predicates and exact
one needed to be provided (which is reasonable and cannot hurts thanks to the
explicit)
Wextra results in a dreadful wall of yellow in the test-suite and is
scary when using CGAL. Reduce some of the noise by silencing the
obvious cases with CGAL_USE or comments.
-Wunused-local-typedefs is a new warning flag of gcc-4.7, and it will enabled
by -Wall since gcc-4.8 (not yet released).
The fix is a big set of removals of unused typedefs (or comments, or moves,
depending on the context).
This seems required. At least the Intel Compiler version 12 gives a set of errors
(not even warnings!). Here is one of them:
/home/lrineau/CGAL/CGAL-4.0-Ic-248/include/CGAL/Periodic_3_triangulation_ds_cell_base_3.h:192:29: error: non-constant-expression cannot be narrowed from type 'int' to 'unsigned int' in initializer list
unsigned int off0[3] = {(o0>>2)&1,(o0>>1)&1,(o0&1)};
^~~~~~~~~
/home/lrineau/CGAL/CGAL-4.0-Ic-248/include/CGAL/Periodic_3_triangulation_ds_cell_base_3.h:192:29: note: override this message by inserting an explicit cast
unsigned int off0[3] = {(o0>>2)&1,(o0>>1)&1,(o0&1)};
^~~~~~~~~
static_ca)t<unsigned int>(
| ------------------------------------------------------------------------
| r58079 | mcaroli | 2010-08-15 20:28:30 +0200 (Sun, 15 Aug 2010) | 2 lines
| Changed paths:
| M /trunk/Periodic_3_triangulation_3/include/CGAL/Periodic_3_triangulation_traits_3.h
|
| minor fix
|
| ------------------------------------------------------------------------
The issue is that Periodic_3_triangulation_traits_3<K> needs to be
specialized for Filtered_kernel, but
CGAL::Exact_predicates_inexact_constructions_kernel is no longer a typedef
for Filtered_kernel<Simple_cartesian<double> >: it is now a class
CGAL::Epick, equivalent to Filtered_kernel<...>.
The solution is to partially specialize
Periodic_3_triangulation_traits_3<K> for CGAL::Epick too. But, for that, I
needed to make Periodic_3_triangulation_filtered_traits_base_3 have a
second template parameter Offset, like Periodic_3_triangulation_traits_3<K>
(Offset has a default value), to avoid an instantiation loop.
The revision 58079 above was just a patch that showed that
Periodic_3_triangulation_filtered_traits_base_3 was no longer used with the
EPIC kernel.
by namespace CGAL { and } //namespace CGAL. in all .h and .cpp files
in a directory.
Apply it to all packages in the trunk
Remove macro definition from the config.h file.
Mael Rouxel-Labbé
Sébastien Loriot
Laurent Rineau
Andreas Fabri
Sebastien Loriot
Aymeric Pellé
Monique Teillaud
Nico Kruithof
Marc Glisse
Philipp Möller
Philipp Möller
Laurent Rineau
Manuel Caroli
Mikhail Bogdanov