You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Juntunen <ma...@hotmail.com> on 2018/06/03 03:48:37 UTC
Re: [Geometry] New Cartesian-centric API
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 <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Geometry] New Cartesian-centric API
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <gi...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org