commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Geometry] New Cartesian-centric API
Date Wed, 06 Jun 2018 16:08:30 GMT
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 <gilles@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


Mime
View raw message