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.
I set the verbose=true variant of the test. However, the test
is of level zero in terms of deepness. This is in contrast with
the other programs in examples/Segment_Delaunay_graph_Linf_2/ and
probably should also be changed to level 1, which does not test
validity of the triangulation data structure. I have to talk to
Menelaos about this matter.
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
Laurent Rineau