Add a precondition checking for degeneracies before calling intersection

[sloriot]

Provided the fact that I have to update some tests, maybe we do not want that (or at least turn the precondition into a warning).

[sloriot]

TODO: I did not run yet the tests for do_intersect

[sloriot]

@CGAL/geometryfactory I'd be happy to get some feedback on this PR

[lrineau]

I find that strange that Do_intersect_3 or Intersect_3 would require non-generated inputs. CGAL is supposed to deal with degenerated inputs, and be robust. I would prefer that the intersection code deal with the degenerated cases.

[sloriot]

Note that the initial motivation was to not penalize users that have clean data. Everywhere in CGAL, we expect the input to be clean. We could of course have more generic versions.

[lrineau]

Note that the initial motivation was to not penalize users that have clean data. Everywhere in CGAL, we expect the input to be clean. We could of course have more generic versions.

That is not true. Historically, CGAL algorithms were designed and coded to be robust to degenerated cases. See Triangulation_2, Triangulation_3, Nef, were the input can be very degenerated. A 3D Delaunay triangulation can even deal with a set of aligned points.

Only recently in CGAL, we have introduced new algorithms that are more constructions-based, and not predicates-based, and less tolerant to degenerated cases: CDT with intersections, Mesh_2/Mesh_3, Straight Skeleton, most of PMP...

I think the kernel should be robust. Maybe we can introduce new functors to deal with non-degenerated cases. But how far? Should the non-degenerated intersection code deal with coplanar triangles and segments?

[sloriot]

You are mixing things up. Generic positions and degenerate input are two different things.

[maxGimeno]

@lrineau @sloriot When do you think this PR will be ready for testing ?

[lrineau]

I think we want both:

• for general purpose, our functors should deal with degenerate objects when that it possible (a degenerated Plane_2/Plane_3 is completely unusable), as they did before,
• but I understand that, for performance reason, we would like other "instances" of kernel functors that can assume non-degenerated objects.

[lrineau]

@lrineau @sloriot When do you think this PR will be ready for testing ?

We are still discussing.

[sloriot]

I'm pretty sure I can easily do a mechanism handling the forwarding of degenerate inputs automatically, but the hardest part is to find a name for the function that supports degenerate input. Alternatively, we could have a global switch enabling degenerate inputs for do_intersect, I guess the initial if should be negligible compared to the tests to be done after.

[lrineau]

Should not K::Intersect_[23] and K::Do_intersect_[23] deal, by default, with degenerated objects?

Actually, for backward compatibility, they should behave exactly as they do in CGAL-5.1. I do not know how that is documented.

Then we should invent other names for the variant that behaves differently.

At the level of the global functions, it could be dispatched using a tag. Actually, if our kernels were like NewKernel_d, it could also be a special tag at the level of kernel functors. Is not it, @mglisse?

[mglisse]

Actually, if our kernels were like NewKernel_d, it could also be a special tag at the level of kernel functors. Is not it, @mglisse?

Functor<K, Intersection_tag, No_degeneracy_tag> or Functor<K, Intersection_without_degeneracy_tag>? I created the first one thinking I might use it as Functor<K, Orientation_tag, Inexact_tag> for structural filtering in Triangulation, but I never reached that point.
(NewKernel_d is missing Intersection_d)

[maxGimeno]

ping