[
https://issues.apache.org/jira/browse/GEOMETRY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674517#comment-16674517
]
Gilles commented on GEOMETRY-23:
--------------------------------
{quote}What are your thoughts?
{quote}
I gather that it is an issue where habit (a vector is often used through its
Cartesian coordinates) conflicts with correctness (a vector is not defined as a
list of numbers). Some
[habits|https://docs.oracle.com/javase/8/docs/api/java/util/Vector.html] are
just bad. ;)
{quote}keep our vector/point classes (the most basic building in our library)
in line with industry standards.
{quote}
The problem is not the name, it is the (wrong) assumption that it must be
implemented as Cartesian coordinates.
What do you mean by "industry standard"? Is it that algorithms are implemented
in Cartesian coordinates; if so, then it only implies that a vector instance
should (for the developer's convenience) provide accessors to those; it does
not imply that the underlying implementation (a.k.a. "ValJO") must be a tuplet
of Cartesian coordinates.
We could have the "vector" concept represented by an interface:
{code:java}
public interface Vector3D extends MultiDimensionalVector<...> {
public double getX();
public double getY();
public double getZ();
}
{code}
Note: Perhaps the accessors could be shortened to {{x()}}, {{y()}}, {{z()}}.
And an implementation (for input and instance creation) would be:
{code:java}
public class Cartesian3D implements Vector3D {
private final double x, y, z;
private Cartesian3D(double x, double y, double z) {
this.x = x;
this.y = y;
this.z = z;
}
public static Cartesian3D of(double x, double y, double z) {
return new Cartesian3D(x, y, z);
}
public double getX() {
return x;
}
// etc.
}
{code}
High-level algorithms can be defined in terms of "vector"; low-level methods
(declared by the "vector" interface), such as "project", "rotate", etc. can be
overridden to take advantage of the actual implementation.
Then there can be other ValJO classes, such as
{code:java}
public class Spherical3D implements Vector3D {
private final double r, theta, phi;
// etc.: "of(...)", "getX()", ...
}
{code}
The API becomes uniform and extensible (e.g. allowing other conventions for the
definition of spherical coordinates, which the library itself won't care about).
> 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)
