Do collinear lines or overlapping collinear line segments intersect?
I am writing a function to find the intersection of a pair of lines and another function to find the intersection of a pair of line segments. The parallel case and the single point intersection case are logically clean and my functions work well to find these. But, the cases where the lines are collinear or the line segments are collinear and overlapping is logically sloppy (at least in my mind)... Here's how I've approached the problem:
Parallel returns:
NULL (e.g. no intersection)
Point intersection returns:
a Coordinate (e.g. a point)
Collinear line segments that have a single common point returns:
a Coordinate (e.g. the common endpoint)
Collinear line segments that have multiple common points returns:
a Coordinate pair (e.g. the line segment of overlap)
Collinear lines returns:
the furthest separated pair of Coordinates (e.g. the largest line segment definable using any of the points that defined the lines being compared)
Logically in any collinear intersection situation it seems reasonable to just return any point within the overlapping region - it also seems to be reasonable to return every point in the overlapping region - it also seems reasonable to return no points at all (the argument being that collinear intersection is an illogical concept assuming the definition that line / line segment intersection is a single point). If I were to take the approach of returning every point of overlap I would not be able to represent the collinear line intersection case (X and Y would need to have infinity or zero values because there are no endpoints to the intersecting region)...
Briefly researching on the Internet I didn't find a clear-cut definition of collinear intersection - this indicates that I'm treading in the territory of the illogical... Nonetheless, I find it misleading to claim via the functions that I am writing that collinear line segments do not intersect... when I consider the case of determining whether or not a pair of rectangles that share a common collinear line segment intersect... certainly rectangles that share a portion of an edge are intersecting (aren't they)... or (broadening my thinking) is the argument that the rectangles are touching but not intersect... (is touching a standard geometric concept that's differentiated from intersection?) If touching is a differentiated concept then the situation of shared endpoint intersection of line segments is invalid (e.g. there is no intersection of the line segments, but there is touching of the line segments)...
So...
Is collinear intersection a well defined planar geometry concept?
If so, please point me to a reference so that I can absorb the definition and logic behind the definition.
If not, please comment on the approach that I'm following to validate it or provide a more effective way of thinking about these concepts.
Thanks!
geometry euclidean-geometry
add a comment |
I am writing a function to find the intersection of a pair of lines and another function to find the intersection of a pair of line segments. The parallel case and the single point intersection case are logically clean and my functions work well to find these. But, the cases where the lines are collinear or the line segments are collinear and overlapping is logically sloppy (at least in my mind)... Here's how I've approached the problem:
Parallel returns:
NULL (e.g. no intersection)
Point intersection returns:
a Coordinate (e.g. a point)
Collinear line segments that have a single common point returns:
a Coordinate (e.g. the common endpoint)
Collinear line segments that have multiple common points returns:
a Coordinate pair (e.g. the line segment of overlap)
Collinear lines returns:
the furthest separated pair of Coordinates (e.g. the largest line segment definable using any of the points that defined the lines being compared)
Logically in any collinear intersection situation it seems reasonable to just return any point within the overlapping region - it also seems to be reasonable to return every point in the overlapping region - it also seems reasonable to return no points at all (the argument being that collinear intersection is an illogical concept assuming the definition that line / line segment intersection is a single point). If I were to take the approach of returning every point of overlap I would not be able to represent the collinear line intersection case (X and Y would need to have infinity or zero values because there are no endpoints to the intersecting region)...
Briefly researching on the Internet I didn't find a clear-cut definition of collinear intersection - this indicates that I'm treading in the territory of the illogical... Nonetheless, I find it misleading to claim via the functions that I am writing that collinear line segments do not intersect... when I consider the case of determining whether or not a pair of rectangles that share a common collinear line segment intersect... certainly rectangles that share a portion of an edge are intersecting (aren't they)... or (broadening my thinking) is the argument that the rectangles are touching but not intersect... (is touching a standard geometric concept that's differentiated from intersection?) If touching is a differentiated concept then the situation of shared endpoint intersection of line segments is invalid (e.g. there is no intersection of the line segments, but there is touching of the line segments)...
So...
Is collinear intersection a well defined planar geometry concept?
If so, please point me to a reference so that I can absorb the definition and logic behind the definition.
If not, please comment on the approach that I'm following to validate it or provide a more effective way of thinking about these concepts.
Thanks!
geometry euclidean-geometry
add a comment |
I am writing a function to find the intersection of a pair of lines and another function to find the intersection of a pair of line segments. The parallel case and the single point intersection case are logically clean and my functions work well to find these. But, the cases where the lines are collinear or the line segments are collinear and overlapping is logically sloppy (at least in my mind)... Here's how I've approached the problem:
Parallel returns:
NULL (e.g. no intersection)
Point intersection returns:
a Coordinate (e.g. a point)
Collinear line segments that have a single common point returns:
a Coordinate (e.g. the common endpoint)
Collinear line segments that have multiple common points returns:
a Coordinate pair (e.g. the line segment of overlap)
Collinear lines returns:
the furthest separated pair of Coordinates (e.g. the largest line segment definable using any of the points that defined the lines being compared)
Logically in any collinear intersection situation it seems reasonable to just return any point within the overlapping region - it also seems to be reasonable to return every point in the overlapping region - it also seems reasonable to return no points at all (the argument being that collinear intersection is an illogical concept assuming the definition that line / line segment intersection is a single point). If I were to take the approach of returning every point of overlap I would not be able to represent the collinear line intersection case (X and Y would need to have infinity or zero values because there are no endpoints to the intersecting region)...
Briefly researching on the Internet I didn't find a clear-cut definition of collinear intersection - this indicates that I'm treading in the territory of the illogical... Nonetheless, I find it misleading to claim via the functions that I am writing that collinear line segments do not intersect... when I consider the case of determining whether or not a pair of rectangles that share a common collinear line segment intersect... certainly rectangles that share a portion of an edge are intersecting (aren't they)... or (broadening my thinking) is the argument that the rectangles are touching but not intersect... (is touching a standard geometric concept that's differentiated from intersection?) If touching is a differentiated concept then the situation of shared endpoint intersection of line segments is invalid (e.g. there is no intersection of the line segments, but there is touching of the line segments)...
So...
Is collinear intersection a well defined planar geometry concept?
If so, please point me to a reference so that I can absorb the definition and logic behind the definition.
If not, please comment on the approach that I'm following to validate it or provide a more effective way of thinking about these concepts.
Thanks!
geometry euclidean-geometry
I am writing a function to find the intersection of a pair of lines and another function to find the intersection of a pair of line segments. The parallel case and the single point intersection case are logically clean and my functions work well to find these. But, the cases where the lines are collinear or the line segments are collinear and overlapping is logically sloppy (at least in my mind)... Here's how I've approached the problem:
Parallel returns:
NULL (e.g. no intersection)
Point intersection returns:
a Coordinate (e.g. a point)
Collinear line segments that have a single common point returns:
a Coordinate (e.g. the common endpoint)
Collinear line segments that have multiple common points returns:
a Coordinate pair (e.g. the line segment of overlap)
Collinear lines returns:
the furthest separated pair of Coordinates (e.g. the largest line segment definable using any of the points that defined the lines being compared)
Logically in any collinear intersection situation it seems reasonable to just return any point within the overlapping region - it also seems to be reasonable to return every point in the overlapping region - it also seems reasonable to return no points at all (the argument being that collinear intersection is an illogical concept assuming the definition that line / line segment intersection is a single point). If I were to take the approach of returning every point of overlap I would not be able to represent the collinear line intersection case (X and Y would need to have infinity or zero values because there are no endpoints to the intersecting region)...
Briefly researching on the Internet I didn't find a clear-cut definition of collinear intersection - this indicates that I'm treading in the territory of the illogical... Nonetheless, I find it misleading to claim via the functions that I am writing that collinear line segments do not intersect... when I consider the case of determining whether or not a pair of rectangles that share a common collinear line segment intersect... certainly rectangles that share a portion of an edge are intersecting (aren't they)... or (broadening my thinking) is the argument that the rectangles are touching but not intersect... (is touching a standard geometric concept that's differentiated from intersection?) If touching is a differentiated concept then the situation of shared endpoint intersection of line segments is invalid (e.g. there is no intersection of the line segments, but there is touching of the line segments)...
So...
Is collinear intersection a well defined planar geometry concept?
If so, please point me to a reference so that I can absorb the definition and logic behind the definition.
If not, please comment on the approach that I'm following to validate it or provide a more effective way of thinking about these concepts.
Thanks!
geometry euclidean-geometry
geometry euclidean-geometry
edited Nov 7 '14 at 20:05
asked Nov 7 '14 at 19:59
Neoheurist
11917
11917
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
A segment is a set of points from the space. The intersection of two sets $A$ and $B$ is defined as $A cap B = {x:xin A ;wedge; xin B }.$
If you have 2 segments overlapping, why would you need to return something? I would associate each line or segment to a vector containing the slope and the shift about one coordinate axis of the given segment or line. The vector could also contain the endpoints of the segments.
Now, you would need to check if a segment is overlapping with another segment and then return the endpoints of a new segment defined as the intersection of the first two segments. This will be easy if the vectors contain the endpoints' coordinates.
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
add a comment |
If the return is always a (collection of) range(s) for which the endpoints are defined, any and every other possible return description is included.
A single point is one range with identical endpoints. A line segment is a range with different endpoints.
This avoids leaving out any part of the intersection, but doesn't require an infinite list.
add a comment |
The objects of your universe are closed segments of positive length, closed half lines, and full lines in the plane, in short: closed one-dimensional convex sets in ${mathbb R}^2$. Denote the set of these objects by ${cal O}$. The intersection of two such objects is one of the following: empty, a single point, or again an element of ${cal O}$.
Any $Sin{cal O}$ can be extended to a full line $ell_S$, the carrier line of $S$, and has a direction which can be represented by a unit vector ${bf u}_S$, whereby ${bf u}_S$ is determined only up to a factor $pm1$.
Given two objects $S_1$, $S_2in{cal O}$, let $ell_i$ be their carrier lines and ${bf u}_i$ their directions. At the top level we then have the following three cases:
(a) $quad {bf u}_1nepm {bf u}_2>$,
(b) $quad {bf u}_1=pm {bf u}_2>, $ but $ ell_1neell_2$
(c) $quad ell_1=ell_2>$.
In case $(a)$ the two carrier lines intersect in a single point ${bf p}$, and we have to test whether ${bf p}in S_1cap S_2$. The exact form of this test depends on the way the objects are presented.
In case (b) the two carrier lines are parallel and disjoint, hence $S_1cap S_2$ is empty.
In case (c) the common carrier line $ell$ has a representation of the form
$$ell:quad tmapsto{bf p}+t{bf u}qquad(-infty<t<infty) .$$
The sets $J_i:=ell^{-1}(S_i)$ are then closed intervals of ${mathbb R}$, and it remains to find the intersection of these intervals.
There is absolutely nothing fuzzy, or even illogical, in this story.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "69"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f1011023%2fdo-collinear-lines-or-overlapping-collinear-line-segments-intersect%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
A segment is a set of points from the space. The intersection of two sets $A$ and $B$ is defined as $A cap B = {x:xin A ;wedge; xin B }.$
If you have 2 segments overlapping, why would you need to return something? I would associate each line or segment to a vector containing the slope and the shift about one coordinate axis of the given segment or line. The vector could also contain the endpoints of the segments.
Now, you would need to check if a segment is overlapping with another segment and then return the endpoints of a new segment defined as the intersection of the first two segments. This will be easy if the vectors contain the endpoints' coordinates.
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
add a comment |
A segment is a set of points from the space. The intersection of two sets $A$ and $B$ is defined as $A cap B = {x:xin A ;wedge; xin B }.$
If you have 2 segments overlapping, why would you need to return something? I would associate each line or segment to a vector containing the slope and the shift about one coordinate axis of the given segment or line. The vector could also contain the endpoints of the segments.
Now, you would need to check if a segment is overlapping with another segment and then return the endpoints of a new segment defined as the intersection of the first two segments. This will be easy if the vectors contain the endpoints' coordinates.
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
add a comment |
A segment is a set of points from the space. The intersection of two sets $A$ and $B$ is defined as $A cap B = {x:xin A ;wedge; xin B }.$
If you have 2 segments overlapping, why would you need to return something? I would associate each line or segment to a vector containing the slope and the shift about one coordinate axis of the given segment or line. The vector could also contain the endpoints of the segments.
Now, you would need to check if a segment is overlapping with another segment and then return the endpoints of a new segment defined as the intersection of the first two segments. This will be easy if the vectors contain the endpoints' coordinates.
A segment is a set of points from the space. The intersection of two sets $A$ and $B$ is defined as $A cap B = {x:xin A ;wedge; xin B }.$
If you have 2 segments overlapping, why would you need to return something? I would associate each line or segment to a vector containing the slope and the shift about one coordinate axis of the given segment or line. The vector could also contain the endpoints of the segments.
Now, you would need to check if a segment is overlapping with another segment and then return the endpoints of a new segment defined as the intersection of the first two segments. This will be easy if the vectors contain the endpoints' coordinates.
answered Nov 7 '14 at 20:13
Vladimir Vargas
3,34011529
3,34011529
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
add a comment |
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
The purpose of theses functions is to provide the calling program what's within the intersection (e.g. the collection of common points)... The goal is to simply provide an approach that's most suitable for the widest range of use cases... my hope is that by posting this question, the ensuing conversation will inform my approach so as to enable clean differentiation of concepts within the greater function library that I'm building - there may well be a family of functions that need to be built (thus the concept of differentiating touching and intersection)
– Neoheurist
Nov 7 '14 at 20:38
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
Additionally, I have methods to find suitable values for each of the cases listed in the question - so, I'm not really looking for the logic behind these functions... I'm asking for help to shape the pattern of functions that I'm building grounded upon geometric best practices / orthodoxy to define the methods within the interface Thanks!
– Neoheurist
Nov 7 '14 at 20:41
add a comment |
If the return is always a (collection of) range(s) for which the endpoints are defined, any and every other possible return description is included.
A single point is one range with identical endpoints. A line segment is a range with different endpoints.
This avoids leaving out any part of the intersection, but doesn't require an infinite list.
add a comment |
If the return is always a (collection of) range(s) for which the endpoints are defined, any and every other possible return description is included.
A single point is one range with identical endpoints. A line segment is a range with different endpoints.
This avoids leaving out any part of the intersection, but doesn't require an infinite list.
add a comment |
If the return is always a (collection of) range(s) for which the endpoints are defined, any and every other possible return description is included.
A single point is one range with identical endpoints. A line segment is a range with different endpoints.
This avoids leaving out any part of the intersection, but doesn't require an infinite list.
If the return is always a (collection of) range(s) for which the endpoints are defined, any and every other possible return description is included.
A single point is one range with identical endpoints. A line segment is a range with different endpoints.
This avoids leaving out any part of the intersection, but doesn't require an infinite list.
answered May 9 '16 at 1:43
Nij
2,00711223
2,00711223
add a comment |
add a comment |
The objects of your universe are closed segments of positive length, closed half lines, and full lines in the plane, in short: closed one-dimensional convex sets in ${mathbb R}^2$. Denote the set of these objects by ${cal O}$. The intersection of two such objects is one of the following: empty, a single point, or again an element of ${cal O}$.
Any $Sin{cal O}$ can be extended to a full line $ell_S$, the carrier line of $S$, and has a direction which can be represented by a unit vector ${bf u}_S$, whereby ${bf u}_S$ is determined only up to a factor $pm1$.
Given two objects $S_1$, $S_2in{cal O}$, let $ell_i$ be their carrier lines and ${bf u}_i$ their directions. At the top level we then have the following three cases:
(a) $quad {bf u}_1nepm {bf u}_2>$,
(b) $quad {bf u}_1=pm {bf u}_2>, $ but $ ell_1neell_2$
(c) $quad ell_1=ell_2>$.
In case $(a)$ the two carrier lines intersect in a single point ${bf p}$, and we have to test whether ${bf p}in S_1cap S_2$. The exact form of this test depends on the way the objects are presented.
In case (b) the two carrier lines are parallel and disjoint, hence $S_1cap S_2$ is empty.
In case (c) the common carrier line $ell$ has a representation of the form
$$ell:quad tmapsto{bf p}+t{bf u}qquad(-infty<t<infty) .$$
The sets $J_i:=ell^{-1}(S_i)$ are then closed intervals of ${mathbb R}$, and it remains to find the intersection of these intervals.
There is absolutely nothing fuzzy, or even illogical, in this story.
add a comment |
The objects of your universe are closed segments of positive length, closed half lines, and full lines in the plane, in short: closed one-dimensional convex sets in ${mathbb R}^2$. Denote the set of these objects by ${cal O}$. The intersection of two such objects is one of the following: empty, a single point, or again an element of ${cal O}$.
Any $Sin{cal O}$ can be extended to a full line $ell_S$, the carrier line of $S$, and has a direction which can be represented by a unit vector ${bf u}_S$, whereby ${bf u}_S$ is determined only up to a factor $pm1$.
Given two objects $S_1$, $S_2in{cal O}$, let $ell_i$ be their carrier lines and ${bf u}_i$ their directions. At the top level we then have the following three cases:
(a) $quad {bf u}_1nepm {bf u}_2>$,
(b) $quad {bf u}_1=pm {bf u}_2>, $ but $ ell_1neell_2$
(c) $quad ell_1=ell_2>$.
In case $(a)$ the two carrier lines intersect in a single point ${bf p}$, and we have to test whether ${bf p}in S_1cap S_2$. The exact form of this test depends on the way the objects are presented.
In case (b) the two carrier lines are parallel and disjoint, hence $S_1cap S_2$ is empty.
In case (c) the common carrier line $ell$ has a representation of the form
$$ell:quad tmapsto{bf p}+t{bf u}qquad(-infty<t<infty) .$$
The sets $J_i:=ell^{-1}(S_i)$ are then closed intervals of ${mathbb R}$, and it remains to find the intersection of these intervals.
There is absolutely nothing fuzzy, or even illogical, in this story.
add a comment |
The objects of your universe are closed segments of positive length, closed half lines, and full lines in the plane, in short: closed one-dimensional convex sets in ${mathbb R}^2$. Denote the set of these objects by ${cal O}$. The intersection of two such objects is one of the following: empty, a single point, or again an element of ${cal O}$.
Any $Sin{cal O}$ can be extended to a full line $ell_S$, the carrier line of $S$, and has a direction which can be represented by a unit vector ${bf u}_S$, whereby ${bf u}_S$ is determined only up to a factor $pm1$.
Given two objects $S_1$, $S_2in{cal O}$, let $ell_i$ be their carrier lines and ${bf u}_i$ their directions. At the top level we then have the following three cases:
(a) $quad {bf u}_1nepm {bf u}_2>$,
(b) $quad {bf u}_1=pm {bf u}_2>, $ but $ ell_1neell_2$
(c) $quad ell_1=ell_2>$.
In case $(a)$ the two carrier lines intersect in a single point ${bf p}$, and we have to test whether ${bf p}in S_1cap S_2$. The exact form of this test depends on the way the objects are presented.
In case (b) the two carrier lines are parallel and disjoint, hence $S_1cap S_2$ is empty.
In case (c) the common carrier line $ell$ has a representation of the form
$$ell:quad tmapsto{bf p}+t{bf u}qquad(-infty<t<infty) .$$
The sets $J_i:=ell^{-1}(S_i)$ are then closed intervals of ${mathbb R}$, and it remains to find the intersection of these intervals.
There is absolutely nothing fuzzy, or even illogical, in this story.
The objects of your universe are closed segments of positive length, closed half lines, and full lines in the plane, in short: closed one-dimensional convex sets in ${mathbb R}^2$. Denote the set of these objects by ${cal O}$. The intersection of two such objects is one of the following: empty, a single point, or again an element of ${cal O}$.
Any $Sin{cal O}$ can be extended to a full line $ell_S$, the carrier line of $S$, and has a direction which can be represented by a unit vector ${bf u}_S$, whereby ${bf u}_S$ is determined only up to a factor $pm1$.
Given two objects $S_1$, $S_2in{cal O}$, let $ell_i$ be their carrier lines and ${bf u}_i$ their directions. At the top level we then have the following three cases:
(a) $quad {bf u}_1nepm {bf u}_2>$,
(b) $quad {bf u}_1=pm {bf u}_2>, $ but $ ell_1neell_2$
(c) $quad ell_1=ell_2>$.
In case $(a)$ the two carrier lines intersect in a single point ${bf p}$, and we have to test whether ${bf p}in S_1cap S_2$. The exact form of this test depends on the way the objects are presented.
In case (b) the two carrier lines are parallel and disjoint, hence $S_1cap S_2$ is empty.
In case (c) the common carrier line $ell$ has a representation of the form
$$ell:quad tmapsto{bf p}+t{bf u}qquad(-infty<t<infty) .$$
The sets $J_i:=ell^{-1}(S_i)$ are then closed intervals of ${mathbb R}$, and it remains to find the intersection of these intervals.
There is absolutely nothing fuzzy, or even illogical, in this story.
answered Nov 27 '16 at 10:52
Christian Blatter
172k7112326
172k7112326
add a comment |
add a comment |
Thanks for contributing an answer to Mathematics Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmath.stackexchange.com%2fquestions%2f1011023%2fdo-collinear-lines-or-overlapping-collinear-line-segments-intersect%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown