On Sun, 3 Jun 2018 03:48:37 +0000, Matt Juntunen wrote:
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,
Perhaps not. What must be clarified is the intent: Cartesian-centric
or not?
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.
It's not "interface" vs "class"; the design tells (cf. previous mail
quoted below):
public class Point3D extends Cartesian3D
which makes it Cartesian-centric.
Again, this library may be geared towards uses of the Cartesian
coordinate system, but this must be made explicit as some uses
may become prohibitively inefficient.
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.
That is not the same as defining the above inheritance.
These accessors could be provided through an interface.
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.
IIRC, the renaming was consistent with the implementation, which
seems to indeed require Cartesian coordinates in order to perform a
large part of the functionality. However, some functionality
(e.g. rotations?) might perform much better with other coordinates.
Again, there may be nothing wrong with Cartesian-centric, but if
we make that explicit, we may be able to simplify many things
and lift the (IMHO) false impression that the library is able to
accommodate other systems.
Since we (well, mostly you) create a new component, we can make
the simplifying assumptions (e.g. for the sake of clarity and
performance of selected algorithms), and as this component evolves,
we'll see where it goes...
Best regards,
Gilles
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
