Hi all,
A couple follow-up notes on this FTR:
1. I don't believe the changes discussed here are actually that much
different than any previous version of the library, at least in terms of
coordinate systems. The interfaces are still coordinate-system-agnostic and the
"Cartesian-ness" of things only comes in with the concrete classes. AFAICT,
this is the same situation as all previous commons-math versions. For example,
the Vector3D class has getX(), getY(), and getZ() methods going back to version
1.3.
2. The main API change with this batch of updates is the splitting of Points
and Vectors. Previous commons-math versions had the Euclidean Vector?D classes
implement both the Point and Vector interfaces, meaning that a Vector?D
instance could function as both. This is mathematically incorrect and was
initially addressed in MATH-1284 by effectively renaming the Vector?D classes
to Cartesian?D. I felt that this made the API confusing and internally messy,
so I re-implemented the desired change with separate Point?D and Vector?D
concrete classes.
Regards,
Matt
________________________________
From: Gilles <gil...@harfang.homelinux.org>
Sent: Tuesday, May 22, 2018 10:23:20 AM
To: Commons Developers List
Subject: [Geometry] New Cartesian-centric API
Hello.
Matt Juntunen proposes to substantially modify the API of the
"geometry" code ported from "Commons Math".[1]
Since Matt is the sole currently visible contributor to this
functionality, I've just committed the changes to "master", as
agreed.[2]
However, although I understand the purpose, I'm not convinced that
it is sound (given that we try to be OO) to have e.g.
-----
public class Point3D extends Cartesian3D { /* ... */ }
-----
because the statement
Every 3D-point "is-a" set of 3 Cartesian coordinates
is false.
AFAICT, and as I indicated in the previous discussion [2], this
can only be resolved if a basic assumption of the new component
library will be that Cartesian coordinates are first-class citizens
while all other coordinate systems, even though mathematically
equivalent, won't be.
It is perhaps the right choice given the intended scope and usage
of the library, but certainly one to be fully documented (and
impossible to revert without breaking the API).
Personally, I'd prefer to base a new API on the following (true)
statement:
Every 3D-point "has-a" set of 3 Cartesian coordinates
But I'm not going to fight over it since I cannot affirm that it
won't have drawbacks perhaps (?) not worth it given the target
applications.
This post is to make that very clear FTR. Those having another
POV are most welcome to voice it *now* here.
Technical issues about this PR are discussed on the JIRA page.[3]
Regards,
Gilles
[1] https://github.com/apache/commons-geometry/pull/2
[2] https://markmail.org/message/ipngs6ambxagdtb7
[3] https://issues.apache.org/jira/projects/GEOMETRY/issues/GEOMETRY-2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
