Which returns, in addition to the power vertex, the squared distance
to this nearest power vertex
Done to avoid a call to tr.min_squared_distance() which is costly for P3M3
Now that we require CMake>=3.1, we can forget a lot of old CMake policies.
`CMP0053` `OLD` behavior is still needed, because of a bug in Qt5 CMake files, but it will
not be set with CMake>=3.10. Let's assume that a recent CMake version means
a recent Qt5 version.
- locate() falling a vertex doesn't mean that this vertex is the closest to
the point
- the cell containing the point is not necessarily in conflict with the query
in a weighted triangulation. Besides, there's no need to find the offset like
that because periodic_locate() returns it already.
Changes to be reproduced for P3DT3.
Replace a call to `force_ieee_double_precision()` by the creation of a
guard object `Set_ieee_double_precision`. The destructor of that object
restores the rounding mode. That avoids that sort of error:
```
terminate called after throwing an instance of 'CGAL::Assertion_exception'
what(): CGAL ERROR: assertion violation!
Expr: FPU_get_cw() == mode
File: /mnt/testsuite/include/CGAL/test_FPU_rounding_mode_impl.h
Line: 45
```
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
Sébastien Loriot
Laurent Rineau
Mael Rouxel-Labbé
Maxime Gimeno
Andreas Fabri
Jane Tournois