## Intersection of extended elements

All the intersection constraints, including the other_intersection constraints, allow their arguments to belong in families; for instance, point_intersection_of_two_lines can be used also to intersect segments. The same happens with rays and lines, and arcs and circles.

Segments which are not "parallel" might not intersect because they end before reaching the common point. It is sometimes useful to be able to intersect not the segments themselves, but the lines that contain them.

Hence, the intersection constraints allow for intersecting not the elements provided, but their extending elements. The extending elements of line_segments and rays are lines; the extending elements of arcs are circles.

Some examples:

This is the "normal" intersection of a line and a segment; note that the name of the constraint is point_intersection_of_two_lines, even though one of the intersected elements is not a line:

<point_intersection_of_two_lines> <point out="true">P</point> <line>l</line> <line_segment>s</line_segment> </point_intersection_of_two_lines>

This is the intersection of a line and the line that contains a segment; note that within the line_segment tag it is especified that it has to be extended:

<point_intersection_of_two_lines> <point out="true">P</point> <line>l</line> <line_segmentextended="true">s</line_segment> </point_intersection_of_two_lines>

This is the intersection of two arcs that are extended into circles:

<intersection_points_of_two_circles> <point out="true">P</point> <point out="true">Q</point> <arcextended="true">a1</arc> <arcextended="true">a2</arc> </intersection_points_of_two_circles>

The other_intersection constraints work in the obvious way; first the intersections are computed exactly as the corresponding intersection constraint would do, and then the different intersection point is returned if it exists. For instance, in

<other_intersection_point_of_circle_and_line> <point out="true">Q</point> <point>P</point> <arcextended="true">a</arc> <line>l</line> </other_intersection_point_of_circle_and_line>

the intersections would be calculated as if the constraint was intersection_points_of_circle_and_line, and then, if there are two intersection points and one is different to P, it will be returned in Q.

### NOTE 1

Each DGS is free to implement or not these extensions.

### NOTE 2

One way of implementing these extensions would be to translate internally (with the obvious abuse of notation)

point_intersection_of_two_lines(P, l, s extended="true")

as

endpoints_of_line_segment(X1, X2, s)

line_through_two_points(l2, X1, X2)

point_intersection_of_two_lines(P, l, l2)

and then make X1, X2 and l2 be not visible. Now, if the construction was read and then saved, it would be modified, since the segment intersection would disappear and be replaced by a line intersection. This is not a problem, because the resulting construction would work correctly in all DGS.

### NOTE 3

Ulli suggested that the default value of extended was system dependent. This has a potential problem. If a file with no extended attribute was read by a DGS where the default value is true, and then it was saved, all extended values might be saved as true, hence changing the behaviour of the construction. Three solutions come to mind:

- Let the default value be false for all DGS, and when existing Cinderella constructions are converted into i2geo, set all their extended to "true". So, basically, the system dependency is sort of transformed into a legacy conversion detail.
- Let the default value be system dependent, but let us all agree to always save explicitly all the values of extended.
- Let the default value be false everywhere, and let us always write it anyway. It’s redundant, yes, but maybe not so bad.

## Examples