[jira] [Commented] (GEOMETRY-92) Segment is not mathematically correct

["Matt Juntunen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEOMETRY-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072306#comment-17072306 ] 

Matt Juntunen commented on GEOMETRY-92:
---------------------------------------

bq. I admit that I still do not grasp the difference between Line and FullLine: Geometrically, what is the difference between a "line" and "all the points that belong the line"?

The difference is primarily in the operations supported by hyperplanes (such as {{Line}}) vs sub-hyperplanes (such as {{FullLine}} and {{Segment}}). Of particular importance is the fact that sub-hyperplanes support a {{split}} operation that returns two new, disjoint sub-hyperplanes. For example, {{Line}} and {{FullLine}} may represent the same points geometrically, but {{FullLine}} can be split into two other sub-hyperplanes, each representing part of the line. 

bq. That aside, IMHO there is an obvious problem with just the asymmetry of the names above: If a suffix "3D" is used for classes in the o.a.c.geometry.euclidean.threed package, then a similar suffix "2D" should be used for similar functionality in package o.a.c.geometry.euclidean.twod:

I did not want to require all classes to end with "XD". That seemed excessive. The convention I've been using is to use the "unqualified" name of the geometric construct in the lowest dimension that it is defined and the "qualified" name in higher dimensions. For example, lines are subspaces of dimension 1. The first dimension that this is possible is 2D, so the name of the class is {{Line}} in {{o.a.c.geometry.euclidean.twod}}. In 3D, we disambiguate the class name by using {{Line3D}}. Similarly, in 3D we have the {{Plane}} class to represent a 2 dimension subspace. If we later extended the code to support 4D, we would have the class {{Plane4D}}. 

bq. Now, how likely is it that a developer will need both the ...3D and ...2D versions of those functionalities within the same file?

It is likely. If you're doing anything involving projection, you will end up using both. 

bq. it might perhaps be nice to have the same class names in the two packages:

I would like to avoid this. This is the approach that commons-math took and it proved to be very awkward.



> 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
>
> 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)