[ https://issues.apache.org/jira/browse/GEOMETRY23?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=16664505#comment16664505
]
Matt Juntunen commented on GEOMETRY23:

I did some more digging on this from a mathematical standpoint and this is what I found: while
there are indeed multiple representations possible for vectors (eg, Cartesian, polar, barycentric,
etc), they are not equally useful from a computational perspective. The best source I found
for this is from [this https://www.amazon.com/LinearAlgebraMatrixTheoryMathematics/dp/0486623181]
book, where it says (p31)
{quote}Using analytic geometry, it is possible to reduce the study of planar vectors to a
study of pairs (a1, a2)T of real numbers... and such vectors can be uniquely identified with
the rectangular coordinates of their respective endpoints.
{quote}
So, Cartesian coordinates function as something of a lowest common denominator for analytic
geometry. This is witnessed by your dot product example above where the spherical coordinates
had to be converted to Cartesian and back again. It therefore makes sense to me to have our
primary vector/point class use this system and provide an API for easy conversion between
other coordinate systems. This is what we have now.
I believe that our most basic data structure should have the most obvious and shortest name
possible. When I first started working with commonsmath v4, I was very confused by the {{Cartesian?D}}
classes. I had to read the documentation to find out what it was, how it related to other
geometric objects, and to answer basic questions like whether or not I could get a dot product
with it. With the name {{Vector?D}}, these questions are automatically answered. No user should
be surprised or confused by the API, especially if they've used other geometry libraries or
even the {{java.awt.geom.Point2D}} classes.
I don't mean to belabor this issue. I just feel strongly about the naming here, especially
since these classes are the bedrock of the Euclidean module. If we can't come to an agreement,
perhaps we should post the issue to the dev ML for some outside feedback?
> Remove Euclidean Point Classes
> 
>
> Key: GEOMETRY23
> URL: https://issues.apache.org/jira/browse/GEOMETRY23
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
> Labels: pullrequestavailable
>
> Based on discussion of the current Point/Vector API in GEOMETRY14 and research into
other geometric libraries, I think we should remove the Euclidean Point?D classes and make
Vector?D also implement Point. This will end up being similar to the previous commonsmath
design but avoids the issue raised in MATH1284 since the Point and Vector interfaces are
not related. They just happen to be implemented by the same class, which we're calling Vector?D
since a vector can be used to indicate a point (by adding it to the origin).
> In the course of trying this out this design, I ended up removing 7 classes and simplifying
several methods. I think that's a good indicator that this is a good design choice.
>
> Pull request: https://github.com/apache/commonsgeometry/pull/15

This message was sent by Atlassian JIRA
(v7.6.3#76005)
