mirror of https://github.com/CGAL/cgal
be6109dc14
There are two use cases: - either we care about the shifted position (for example for P3M3 where we will insert the shifted position) - either we don't care about the shifted position, and we are ok with point + shifting offset (for example in P3M3 predicates to determine is_bad) In the first case, we cannot determine the shift using predicates, otherwise we could have an inconsitency in the final result: the predicates say the point is in, but once constructed it is not. So this commit distinguishes between both. When we care about the actual shifted position, we construct the point. There might be numerical errors if we are not using exact constructions, but it does not really matter. What should be done better: - use compare_x/y/z_3 instead of < - handle the case where the numerical errors are such that you get a really silly point far from the truth. Maybe this should all be done in EPECK. There is something like this in the history of canonicalize_helper.h .... |
||
|---|---|---|
| .. | ||
| Periodic_3_mesh_3 | ||
| Implicit_to_labeled_subdomains_function_wrapper.h | ||
| Periodic_3_function_wrapper.h | ||
| Periodic_3_mesh_triangulation_3.h | ||
| make_periodic_3_mesh_3.h | ||
| optimize_periodic_3_mesh_3.h | ||
| refine_periodic_3_mesh_3.h | ||