[
https://issues.apache.org/jira/browse/GEOMETRY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658882#comment-16658882
]
Gilles commented on GEOMETRY-23:
--------------------------------
{quote}an n-dimensional vector as an n-tuple
{quote}
True, whatever the coordinate system; a vector *v* in 3 dimensions can be
expressed by 3 numbers; the tuple can be _(x, y, z)_ or _(r, theta, phi)_ or
_(r, phi, z)_ or ...
{quote}representation [...] as a matter of definition and not implementation.
{quote}
No: representation == implementation
{quote}vector operations depend on this representation
{quote}
No; the true statement is that the _implementation_ of vector operations depend
on the representation.
And *how* some operation is performed is an "implementation detail", from the
caller's perspective (API): he could develop an app that uses spherical
coordinates, build a {{Vector3D}} instance using {{ofSpherical}}, use some
functionality which you have implemented, get a {{Vector3D}} result and return
it after applying a {{toSpherical}} coordinate transform.
Then, from the perspective of a user of that app, the vector concept is
implemented in spherical coordinates, even though, deep down, some operations
are performed on the Cartesian representation as per the choice of the "Commons
Geometry" developers.
{quote}it's not possible to compute a dot product between two sets of spherical
coordinates.
{quote}
I don't follow.
# Transform each set to Cartesian coordinates
# Compute the dot product using the usual formula
The result _is_ the dot product of the two vectors, whatever their
representation in a coordinate system.
Self-documenting code ({{ofCarstesian}} is self-documenting, while {{of}} and
{{new}} are not), can help avoid potential confusion (e.g. "vector" vs
"coordinates") and unwarranted assumption ("Cartesian" vs "spherical").
> Remove Euclidean Point Classes
> ------------------------------
>
> Key: GEOMETRY-23
> URL: https://issues.apache.org/jira/browse/GEOMETRY-23
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Reporter: Matt Juntunen
> Priority: Major
> Labels: pull-request-available
>
> Based on discussion of the current Point/Vector API in GEOMETRY-14 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 commons-math design but avoids the issue
> raised in MATH-1284 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/commons-geometry/pull/15
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)