This is important as it helps to
measure run-time of functions
in the code excluding the time to
print debug messages on the console
We added following piece of code:
//#define CGAL_SDG_VERBOSE
//#ifndef CGAL_SDG_VERBOSE
//#define CGAL_SDG_DEBUG(a)
//#else
//#define CGAL_SDG_DEBUG(a) { a }
//#endif
If the macro CGAL_SDG_VERBOSE is enabled
then we will get all the debug messages
and if it is disabled then there will be no
debug messages
we added a case when p or q
can be end point of t(segment)
example
debug finite-edge-int-cf tocheck (p,q,r,t,sgn)= (s AB) (p D) (p B (r ignored)) (s CD) -1 retval= 0
interior in conflict (cf) = 0
This should return true
ternary operator ? is changed into if-else
Line 887 in Finite edge conflict
assertions of horizontal and vertical segment is added
in Line 1050 in Basic predicate
In Finite Edge interior conflict
the basic predicate intersects_segment_interior_inf_wedge_sp
is called depending on the p.is_point()
In basic predicate
intersects_segment_interior_inf_wedge_sp
the assertions is horizontal and is vertical is
removed temporarily, need to add later
In finite edge interior conflict
when t is segment,
and it not intersected by the wedge
defined by s and p in the basic predicate
intersects_segment_interior_inf_wedge_sp
then return false
To make the basic predicate:"intersects_segment_interior_inf_wedge_sp"
more robust and specific
we added the following assertions:
CGAL_assertion( t.is_segment() );
CGAL_assertion( s.is_segment()
and (not s.is_horizontal())
and (not s.is_vertical()) );
CGAL_assertion( os_lseg_p != ON_ORIENTED_BOUNDARY );
This predicate returns true if and only if
the interior of t has non-empty intersection
with the interior of the following infinite box:
the only finite corner of the infinite box is p
and this infinite box is a 90 degree wedge defined
by the intersection of the halfplanes
with supporting lines lhor and lver through p, where
the halfplanes are both on the positive or negative
sides of the supporting lines. The positive or negative
side depends on the relative position of p with respect to s
In the incircle_p predicate of field_new,
check if p, t are endpoints of different segments among q, r.
This way, things work slightly better for inexact arithmetic.
Now, the following input also works fine:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/1a0star_target.cin
s 0 0 200 0
s 0 0 -200 -100
s -80 -130 0 0
I added refining in incircle_p_no_easy PSS case.
I also forced d1=0 in the case where t has common endpoint
with at least two segments among {p,q,r}. A similar adjustment
has to be done for d2. Maybe this change should also be applied
to the field_new file, but for the moment it does not seem needed.
Also, I did some white-space fixes.
The following is a problematic predicate:
debug: Vertex_conflict (pqrt)=
(p [50;50] [100;100])
(p [0;0] [0;0])
(p [200;200] [-100;-100])
(s [0;0] [100;100] [0;0] [0;0])
which returns -1.
It should in fact return 0.
This is a change adapted from the similar change in the field_new file.
This is a finer computation of the xxxl predicate in the field_new
file. A new function linf_refinement is used instead of the older
and less refined linf_fine_radius. These changes should also be
transferred to the ring file. The case of returning LARGER should
be checked more in the linf_refinement functions and more tests
should be run.
I fixed a problem in incircle_p(p,q,t) when p, q are a point and a segment
and the query t is a point, such that the projection of the point on the
segment equals the query point t. In that case the result of the incircle
predicate was incorrectly NEGATIVE.
For example, the Vertex_conflict(p,q,t) predicate
debug: Vertex_conflict (pqt)=
(p [0;0] [60;60])
(s [-100;-100] [110;110] [0;0] [100;100])
(p [0;0] [100;100])
returns -1
However, it should return POSITIVE (or maybe ZERO).
The following is a problematic predicate:
debug: Vertex_conflict (pqrt)=
(p [50;50] [100;100])
(p [0;0] [0;0])
(p [200;200] [-100;-100])
(s [0;0] [100;100] [0;0] [0;0])
returns -1
It should in fact return 0. A similar change has to be made
in the ring variant of Voronoi vertex.
If the DEBUGVALIDHIER variable is defined in the preprocessor, then
some more information is given in the is_valid test for the
Segment_Delaunay_graph_Linf_hierarchy_2.
If the DEBUGVALIDSDG variable is defined in the preprocessor, then
some more information is given in the is_valid test for the
Segment_Delaunay_graph_Linf_2.
At this snapshot, the variables are defined.
A refinement of the incircle l PSS predicate, like in the PPP
case. I have not done the PPS and the SSS case yet.
Here is an example input that now is displayed correctly:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/4seg3.cin
s 0 100 200 100
s 0 100 0 0
s 0 0 100 0
s 200 100 150 50
The incircle predicate for a line was refined in the PPP case
only. Probably the same has to be done for the other cases
like PPS, PSS, SSS, in the file Voronoi_vertex_ring_C2.h.
Here is an input that had a problem before, but now works:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/verseg3.cin
s -130 81 70 41
s -187 -178 26 -177
s 86 -14 86 -89
Use goodbisector to refine the choice of which of the three
bisectors of p, q, r to intersect in order to find v(pqr).
The above fix takes care of inputs like:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/2vv.cin
s 0 0 0 400
s -100 100 -100 200
Before the fix, in the PPS case, when r_ is a segment, p_ref
returns r_. Here is a formerly problematic input, that now works:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/sitesxless5.cin
s 41 576 403 561
s 360 902 637 400
s 922 398 534 156
s 107 910 169 -3
The pnt_on_seg variable was used uninitialized in some cases.
Here is a previously problematic input that now works fine:
$ cat ~/code/geom/demo/Segment_Delaunay_graph_Linf_2/2a2across.cin
s -150 -50 150 50
s -50 100 50 -100
I added several debug messages. The intersection of the bisectors
of three sites is computed in a smarter way. The distance in
incircle_p_no_easy is computed in a more refined way.
Panagiotis Cheilaris
Sandeep Kumar Dey