The bug is shown, for example, in input pssprob1.cin:
s 0 100 100 100
s 0 100 0 0
p 20 -40
Let the above input be: AB, AC, D. The vertex computed for the
triple (D, AB, AC) was (140,30) and now it is the correct (70,30).
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Avoid bisectors in the following case:
one segment is horizontal and the other is vertical and
the point p is not an endpoint of the segments
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Avoid using bisector computations; partially done for the
pss case with axis-parallel segments; it remains to do the
case when the two segments are not parallel and the point
is not the endpoint of any of the segments.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
In the pps case, avoid delegating to a ppp computation when the
segment is axis-parallel and the two points share a coordinate and
the line connecting the two points is parallel to the segment.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This is only partially implemented. Still, it improves the
performance of the norway.cin benchmark.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
These changes are related to inputs ppsphor1.cin etc.
and brsp1less.cin:
s 50 100 250 300
s -100 110 200 80
p 0 150
p 0 100
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Fix for input brsp1less.cin validity problem:
s 50 100 250 300
s -100 110 200 80
p 0 150
p 0 100
Incircle predicate (A, AB, F, E) is now ZERO.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This returns ZERO (instead of POSITIVE) in some pssp incircle tests
like in the case of input pssphor2.cin:
s -100 -50 50 100
s 100 0 100 -100
p 0 0
Similar changes have to be made to the sqrt new code.
This will probably break some inputs like brsp1less.cin:
s 50 100 250 300
s -100 110 200 80
p 0 150
p 0 100
and pps predicates should be changed too.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Change of function point_inside_touching_sides (renamed
to points_inside_touching_sides) in order to process correctly
inputs like br80.cin:
s 10 120 60 20
s 60 40 70 60
s 30 110 100 40
(segments AB, CD, EF, respectively)
The incircle predicate (CD, B, F, EF) returns 0.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fix is to avoid the following warning when Gmpz is used:
CGAL warning: check violation!
Expression : is_integer(d)
File : /Users/philaris/code/mycgal/Number_types/include/CGAL/GMP/Gmpz_type.h
Line : 102
Explanation: Gmpz constructed from non-integer double value
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes an assertion failure for the input vbc1a.cin:
s 60 20 60 220
p 40 160
p 30 50
p 40 50
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Use the line optimization when computing the bisector of two
parallel segments.
This also fixes a bug for inputs of the following form:
s 100 20 0 20
s 0 80 100 80
s 30 40 30 60
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Addition of is_line_optimization boolean member variable in object
of class Polychainline_2. Suppose this variable of an obect is set
to true. If this object is tried for an intersection with another
Polychainline object pcl, using the function
first_intersection_point_with, then instead the function
line_first_intersection_point_with is used.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
The oscandidate fix was not in the incircle_pss predicate, but it was
in the incircle_sps predicate.
This fixes a bug for the following input (br60parplus.cin):
p 50 0
s 0 0 200 -30
s 0 0 -50 150
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes exact computation for inputs like parpar2.cin:
s -250 50 -50 -150
p -100 -50
p -60 -50
p -150 50
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This corrects exact computations for inputs like br61.cin:
s 0 0 200 -30
s 0 100 100 100
s 0 100 0 0
s 0 0 50 0
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Now, exact computation is correct with input like br80pt.cin:
s 10 120 60 20
s 30 110 100 40
p 60 40
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes input 2a1badaless3noint.cin for exact number types:
s 0 0 200 -30
s 0 0 -50 150
p 0 100
p 100 100
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This is a fix for the following input (r2minpt.cin):
s -91 36 36 87
p -23 4
p -17 37
p -17 40
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Avoid computing a predicate for the support line of a query segment,
if that segment has a common endpoint with another segment and this
endpoint also defines the vertex and also the two segments have the
same slope. In that case, the sl value should be ZERO.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Use the most distant point to choose segment direction in
the bisector of two segments computation.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
These new insert functions are from the SDG L2 code and will be
useful for the test_sdg_new_range_api test for the SDG Linf code.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes the computation of neighbors for
insert_point_on_segment and is the same as the
insert_exact_point_on_segment fix.
Here are some inputs that are affected.
(5sqin.cin)
s 0 0 0 100
s 0 100 100 100
s 100 100 100 0
s 0 0 100 0
s -100 50 150 50
(lala3.cin)
s 1 2 3 2
s 13 25 13 25
s 27 24 54 24
s 43 31 43 35
s 41 51 71 51
s 57 93 57 141
s 75 117 96 117
s 143 95 143 143
s 81 162 117 162
s 101 171 101 211
s 189 156 222 156
s 219 123 219 219
s 121 199 199 199
s 229 159 229 229
s 156 186 246 186
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
I might have to do the same with insert_point_on_segment.
This fixes a bug in the validity check of diammid1.cin:
s -200 0 0 200
s 0 -200 200 0
s -200 0 0 -200
s 0 200 200 0
p 100 100
p -100 -100
p 100 -100
p -100 100
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes a bug in validity check of ipe10gperm.cin:
s 10 120 60 20
s 30 110 100 40
s 60 40 70 60
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This avoids a ping-pong effect in the PSSP case.
It fixes the validity check of the following input br50noseg.cin:
s -50 -20 0 +30
s 0 +30 +50 -20
p -20 0
p +20 0
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This is to fix validity checks of inputs like (rx8m8var.cin):
s -11 82 -11 4
p 58 60
p 89 1
p -11 16
s -11 16 89 1
This fixes the validity check of point t = p -11 82.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This is to fix validity checks of inputs like (rx8m8var.cin):
s -11 82 -11 4
p 58 60
p 89 1
p -11 16
s -11 16 89 1
This fixes point t = p -11 16, but I still have to fix
point t = p -11 82.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
The following inputs had problems before this fix:
(s2.cin)
s -100 50 200 -100
p 0 100
p 0 150
p 0 0
(s2hor.cin)
s -100 50 200 -100
p 100 0
p 150 0
p 0 0
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Many changes to support the tie breaking predicates
in the implementation and the declaration part of
the algorithm class.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes validity checking for spl1.cin input (and others):
s -100 110 200 80
s 200 80 -110 -190
p 0 0
p 0 100
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
I added point_inside_touching_sides_v function
in vsqrnew code, which is an adaptation of the
respective vring code.
This fixes, among other things, the validity checking
of input ppswedge.cin:
s -200 -200 0 0
s -200 200 0 0
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
The check for point t against a segment s is too
strong at the moment. I have to implement a predicate
similar to point_inside_touching_sides of the ring code.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Before this fix, the point t was not tested at all with
segments q or r.
This fixes a bug for input (v4nox.cin):
s 100 100 300 300
s -100 110 200 80
p 0 150
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
If point t is inside any of the two sides of the square
that touch the touching corner of a segment s in p, q, r,
then return negative.
Use helper function point_inside_touching_sides.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
In pqrt, if points p and t are on the same side of
the square, if t is further in the tie break, then
return POSITIVE.
This is a bug fix for this input (1asegverp2nocrminus.cin):
s 0 100 200 80
p 0 60
p 0 80
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
case of predicate pqrt of type PPSP:
if new point t is on the same side of line pq
as the other endpoint of r, then NEGATIVE, else POSITIVE.
This fixes inputs of the following form (zppsp1.cin):
s -100 50 0 0
p 100 0
p 0 100
With the fix, point p 0 0 has as neighbors both
p 100 0 and p 0 100. Before, p 0 100 was not a neighbor.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
When a point v is inserted in the interior of a segment, we take
more care in computing the sites that are connected with v in the
final SDG. In L2, v is just connected to two sites, but in Linf,
we might have more neighbors.
The change is in the find_faces_to_split function, which also has
two additional parameters flipf, flipg that control whether there
will be new neighbors. This new function is used by
insert_exact_point_on_segment and insert_point_on_segment, which
are also changed to use flipf and flipg.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Be more diligent in Oriented_side_C2, when the finite
vertex is on the Linf-perpendicular line lp which is
passing through the splitting point p.
This fixes a problem with the following input:
$ cat ~/Dropbox/cgal/sdg/split/prob3seg.cin
s -172 -263 124 -49
s -109 -2 64 -202
s -117 -39 97 -39
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This fixes a drawing bug in the demo with input 3segconstr.cin:
s -268 65 238 71
s 206 -89 -241 -11
s -94 171 -155 -196
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
If construction templates for bisectors (line, segment, ray)
exist in the traits, then use them, otherwise, use the L2 traits.
The check is implemented by a type Has_bisector_constructions_type
that might be included in the traits and using the
"Substitution failure is not an error" (SFINAE) principle.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
This is to prepare a generalized algorithm that chooses
construction traits automatically. The choice is controlled
by type Has_bisector_constructions_type. A similar change has
been done with the non-filtered traits too. I also commented out
the old code.
Signed-off-by: Panagiotis Cheilaris <philaris@cs.ntua.gr>
Panagiotis Cheilaris