[
https://issues.apache.org/jira/browse/GEOMETRY-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087637#comment-17087637
]
Matt Juntunen commented on GEOMETRY-92:
---------------------------------------
bq. Span is a nested class and it does not follow the same naming scheme (not
ending with "3D")
We could make it a separate class if needed. One reason for its current
"special" status as a nested class is that it does not include any additional
information beyond what's already in the line, either mathematically or
programmatically; there are no start or end points present. As for the name not
ending in "3D", I did not feel it necessary to duplicate the "3D" from the
outer class, ex: {{Line3D.Span3D}} seems redundant to me.
bq. I'm still puzzled by the absence of reference to that concept wherever
"ray" is mentioned
Are you talking about in the mathematics literature?
bq. It makes me wonder whether we couldn't get away with Ray3D only, e.g. if
the abscissa would take on values in the interval (-inf, start]
An abscissa value with that range would not be a ray since "start" is an end
point and not a start point. It's possible we don't see this concept in the
literature because mathematical lines do not always have a defined direction.
In that sense, any construct with a single boundary point could be considered a
ray; you simply view the line as extending in whatever direction would make the
boundary point the "start". In our situation, we explicitly include a direction
in the definition a line. This is necessary in order to provide consistent
conversions back and forth between 1D and 2D space. Therefore, when we
construct a half-line with a single boundary point, we don't have the luxury of
re-defining the line direction to whatever is convenient. We need a way to
define half-lines with only a start ({{Ray}}) and half-lines with only an end
({{ReverseRay}}).
> Segment is not mathematically correct
> -------------------------------------
>
> Key: GEOMETRY-92
> URL: https://issues.apache.org/jira/browse/GEOMETRY-92
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
> Labels: beta1
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{Segment}} class is not mathematically correct because line segments are
> defined as having distinct start and end points, whereas the start and end
> points in {{Segment}} are optional. In other words, an instance of
> {{Segment}} can represent an entire line, a ray, or a segment. I propose
> renaming the existing {{Segment}} class to {{ConvexSubLine}} and creating
> subclasses to represent the distinct types of sublines.
> * {{ConvexSubLine}} - Abstract convex subline class. The factory methods
> (such as fromPoints()), would examine the inputs and return one of the
> specific subclasses below. Each subclass would also contain its own factory
> methods that apply input validation (eg, no null points when creating a
> {{Segment}}). This would also allow each subclass to optimize some
> computations based on the known characteristics of the represented entity.
> ** {{FullLine}} - no start or end points
> ** {{Segment}} - contains non-null start point and end point
> ** {{Ray}} - contains non-null start point and null end point
> ** {{ReverseRay}} - contains non-null end point and null start point (not
> sure if there is a more mathematical term for this)
> These changes would also apply to the 3D classes:
> * {{ConvexSubLine3D}}
> ** {{FullLine3D}}
> ** {{Segment3D}}
> ** {{Ray3D}}
> ** {{ReverseRay3D}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
