Precision Problems & Debugging

Naturally thinking of an easy case to start with are graphs that admit a drawing with a ply-number of 1. This case is easy to describe and points out the difficulty of computing the ply-number : A graph that admits a drawing with ply-number 1 has no overlapping ply-disks and can be drawn such that every edge has equal length l and any two vertices are at a distance of at least l.

Suppose that there exists a drawing Γ and a vertex v with different edge lengths

|(u, v)| = l1 and |(w, v)| = l2 and let w.l.o.g l1 > l2. l₂2 is a lower bound on the

ply-disk Dw and since l₂1 +l₂2 > l2 the ply-disks Dv and Dw intersect and the ply-

number of Γ is _{≥ 2. Furthermore, since the radius for any ply-disk D}v is ₂l, the

distance dist(v, w) between any two vertices has to be _{≥ l.}

The complete graph K3 admits a drawing with ply-number 1, since the vertices

can be placed on an equilateral triangle. Computing a drawing of K3 with the ver-

tices u, v, and w, some coordinates must be irrational, since otherwise the condition dist(u, v) = dist(u, w) = dist(v, w) is violated as shown in Figure 3.29.

Since a computer is limited in the representation of numbers, we run into pre- cision problems, since the computer would often need an infinite precision to rep- resent a drawing with ply-number 1. Additionally, the calculation of coordinates for intersection points of circles involves precise arithmetic and is likely to result in irrational coordinates.

During the implementation of the plane sweep algorithm we experienced a num- ber of precision errors in the sweep line status. To check for consistency at the

3.5 Implementation & Ply Computation

Element 3 : TOP 10, current Y position: 1307.011187049395

Element 4 : TOP 7, current Y position: 1295.4695805456354

Element 5 : TOP 1, current Y position: 1235.4794682409479

Element 6 : BOT 10, current Y position: 1163.82255318498 Element 7 : TOP 66, current Y position: 1163.8225531849826 Element 8 : TOP 83, current Y position: 976.3626815537044 Element 9 : BOT 39, current Y position: 959.5613407831479

Figure 3.30: The actual event is an intersection between Hb

10 and H66t . The execution of

the intersection event and thereby the swap of these halfcircles will recover the correct order of the halfcircles, whereas the current status is inconsistent.

Element 87 : BOT 43, current Y position: 969.0000050810148 Element 88 : TOP 23, current Y position: 969.0000050810147 Element 89 : BOT 62, current Y position: 969.0000027201414 >>Element 90 : TOP 28, current Y position: 969.0000027201404 <<

Element 91 : BOT 72, current Y position: 969.000002720141 >>Element 92 : TOP 99, current Y position: 969.0000027201406 <<

Element 93 : BOT 9, current Y position: 969.0000013131587

Element 94 : TOP 47, current Y position: 969.0000013131586 Element 95 : BOT 22, current Y position: 968.9999972798596 Element 96 : TOP 61, current Y position: 968.9999972798594

Figure 3.31: The current intersection event indicates an intersection betweenHt

28andH99t

but there still exists the halfcircle Hb

72. The next event solves this issue, since it is the

event indicating the intersection betweenHt

28 andH72b .

current status, we compute the y-coordinates for every halfcircle. As an example we present a part of the sweep line status where the current event is an intersection

event between the two halfcircles Hb

10 and H66t . By definition of an intersection

point, the (x, y)-coordinates of both halfcircles have to be equal, whereas the top

halfcircle already admits a higher y_{−coordinate. One of two reasons might have}

happened. Either the x- or the y-coordinate is not exact due to rounding. The current status is shown in Figure 3.30.

More importantly, these precision errors can induce events which cannot be han- dled consistently, for example an intersection-event that requires a swap of halfcir- cles, which are not neighboured in the current state. In the following scenario, the

current intersection event indicates an intersection between H₂₈t and H₉₉t but there

still exists the halfcircle Hb

72 in between. Additionally, the y−coordinate suggests

that the halfcircle H₇₂b should be above H₂₈t .

This event will be executed and we jump back to the unresolved one. We repeat

this until it can be resolved. The following intersection event swaps Ht

28 and H72b ,

so if we revisit the initial intersection event, it is now solvable. The number of revisited events will be tracked as postponed events. In the results section we evaluate this delay and describe graphs where this periodically occurs.

During the plane-sweep algorithm halfcircles are checked for intersections, once they occur next to each other in the sweep line status. Here another type of precision problem might occur, if we encounter two halfcircles next to each other. It might have happened that their first intersection has been at a previous x-coordinate, if there was a rounding error while computing the intersection event which causes the halfcircles to be next to each other. When encountering two halfcircles for the first time, we allow a short distance before the actual sweepline. The distance is set to 0.0001. This range seems to be sufficient, since the precision errors we observed were around 0.00001. A similar problem involves the leftmost and the rightmost coordinates of the ply-disk. If there is an intersection exactly at the start coordinate we cannot distinguish whether there is an intersection with the bottom or top part

of the halfcircles. Ultimately we want to enclose these halfcircles entering the

newly inserted ply-disk between the corresponding halfcircles. Therefore, we allow intersections with the top halfcircle, if the other halfcircle is above in the sweep- line status and allow an intersection with the bottom halfcircle if it is below in the sweep-line status, respectively.

Previous Applications

In previous applications [7, 30] precision errors were tackled by increasing the pre- cision using the Apfloat library. The apfloat library allows to define the number of digits, which will be calculated to be precise. This allows calculation on up to 1000 digit decimal precision. On the downside these arithmetics require high computational effort and long runtimes.

These implementations suggested that if there is an inconsistent intersection event, there had to be a precision error. To determine the correct order of intersec- tion events, the decimal precision of the coordinates were iteratively increased in [7]. In [30] the decimal precision was set to 20 digits and between the events they added consistency tests. If an intersection event was encountered, they recalculate possible intersections to resolve this error. The main issue in these implementations

occurs, if by a rounding error, the x_{−coordinate of an intersection is incorrect.}

Furthermore, they do only allow the removal of neighboured halfcircles if an end event is queued, this favours intersection events where in our implementation these intersection events will be neglected. In fact, we encountered some drawn instances, where the ply-numbers by the two computations differ.