Issue Details
This is an issue with parts of the API choices of 2D and 3D triangulations concerning locate().
According to the documentation of Triangulation_2:
If the point query lies outside the convex hull of the triangulation but in the affine hull, the returned face is an infinite face which is a proof of the point's location:
- for a two dimensional triangulation, it is a face (∞,p,q) such that query lies to the left of the oriented line pq (the rest of the triangulation lying to the right of this line).
- for a degenerate one dimensional triangulation it is the (degenerate one dimensional) face (∞,p,nullptr) such that query and the triangulation lie on either side of p.
i.e. to identify if the query is outside the triangulation we check against locate(...)->vertex(0)
According to the documentation of Triangulation_3
If the point query lies outside the convex hull of the points, an infinite cell with vertices {p,q,r,∞} is returned such that the tetrahedron (p,q,r,query) is positively oriented (the rest of the triangulation lies on the other side of facet (p,q,r)).
i.e. to identify if the query is outside the triangulation we check against locate(...)->vertex(2).
This adds variations to a codebase for a method that is supposed to work in 2D and 3D, that are not immediately obvious and seem like an arbitrary choice.
I'm aware that has_vertex() exists, but this does come at the cost of additional checks.
I have no good solution for how to address this, as I imagine it might brick working code that relies on this behavior. Maybe adding method akin to has_infinite_vertex() that correctly checks at index 0 or 2 in 2D and 3D.
Issue Details
This is an issue with parts of the API choices of 2D and 3D triangulations concerning
locate().According to the documentation of Triangulation_2:
i.e. to identify if the query is outside the triangulation we check against
locate(...)->vertex(0)According to the documentation of Triangulation_3
i.e. to identify if the query is outside the triangulation we check against
locate(...)->vertex(2).This adds variations to a codebase for a method that is supposed to work in 2D and 3D, that are not immediately obvious and seem like an arbitrary choice.
I'm aware that
has_vertex()exists, but this does come at the cost of additional checks.I have no good solution for how to address this, as I imagine it might brick working code that relies on this behavior. Maybe adding method akin to
has_infinite_vertex()that correctly checks at index 0 or 2 in 2D and 3D.