The tests check that the number of elements is the one expected, but if the
random generator changes (even for a fixed seed), this breaks everything...
Instead, we dump the random generator for a given seed and use this output
as input every time.
This commit is inspired by the playstation network.
This reverts commit 0a5e3320d99327f649a39e97ebb5e12966afec0e.
Not sure what this commit was, might have been for P3M3 ? In any case, this is
not how it should be done...
-- canonical_dual() is what the old dual() function was: returns the
representation of the dual of the cell handle that is in the domain
-- dual() returns the 'true' dual of the cell handle, which might be out of
the canonical domain.
The point is that P3M3 must return the 'true' dual to have no issue with the
conflict assertions of Mesh_3, and not a canonicalized dual !
This is a way to handle points that are epsilon-close to the boundary yet still
outside. This might create numerical issue such that the point + any offset
does not fall into the domain (due to -epsilon + 1 ~= 1)
The numerical issue is detected when the offset is computed and we snap the
point to the domain.
This is done for P3M3 only (not P3T3: people should give proper input points!)
The purpose of that class is somewhat similar to Robust_weighed_circum...etc.:
it aims to provide robust circumcenter computations.
This is the parallel version that switches to exact if the circumcenter is
not in the (smallest) power sphere of the points.
The accuracy issue comes from the use of construct_point_3 with offsets.
Consequently, this class only overrides the versions with offsets.
The other robust class should be used for non-offset versions.
-- It's a bit dangerous to take random points in the complete periodic domain
because insert(p) should have p in the original domain and half the border
of the periodic domain is open
-- Cleaned some unused variables
-- It's a bit dangerous to take random points in the complete periodic domain
because insert(p) should have p in the original domain and half the border
of the periodic domain is open
-- Cleaned some unused variables
Commit f554c062e39978fd8c0f15ba6a6d90597b36d768 fixed a lot of stuff
but point() functions were still a bit messy.
Now, ALL `point()` functions return a canonical point. If one wants to
get the "real" point in the complete space, one should use v->point()
point() must be the canonical point and not the real point since we
will pass P3T3 to other packages (Mesh_3/Alpha_shapes_3) that will
use tr.point(v) and expect the canonical point.
Might be worth to introduce a function "real_point()" to return v->point()
Commit f554c062e39978fd8c0f15ba6a6d90597b36d768 fixed a lot of stuff
but point() functions were still a bit messy.
Now, ALL `point()` functions return a canonical point. If one wants to
get the "real" point in the complete space, one should use v->point()
point() must be the canonical point and not the real point since we
will pass P3T3 to other packages (Mesh_3/Alpha_shapes_3) that will
use tr.point(v) and expect the canonical point.
Might be worth to introduce a function "real_point()" to return v->point()
This reverts commit c373227616bed00f97115d5cab14ede38f3b5223.
tr.point() will now be a canonical point (a point in the base domain)
while here we do not want to have a canonical point
This reverts commit c373227616bed00f97115d5cab14ede38f3b5223.
tr.point() will now be a canonical point (a point in the base domain)
while here we do not want to have a canonical point
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.
Since P3RT3 now does orthoball size checks through the predicate
compare_weighted_squared_radius_3, there is no need to compute any weighted
circumcenter and therefore these traits are not needed.
Since P3RT3 now does orthoball size checks through the predicate
compare_weighted_squared_radius_3, there is no need to compute any weighted
circumcenter and therefore these traits are not needed.
It is pretty much the same as simple_example (but might deviate
from it in the future).
Running this example at this commit and before the merge commit
37fd886 (replacing robust_weighted_... traits with regular_eucli...
traits) yields the same output!
It is pretty much the same as simple_example (but might deviate
from it in the future).
Running this example at this commit and before the merge commit
37fd886 (replacing robust_weighted_... traits with regular_eucli...
traits) yields the same output!
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
Andreas Fabri
Maxime Gimeno
Laurent Rineau
Mael Rouxel-Labbé
Jane Tournois