[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <gilles@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx

- Prev by Date:
**[text] release 1.4** - Next by Date:
**[GitHub] darkma773r opened a new pull request #4: Points/Vectors as VALJOs** - Previous by thread:
**[Geometry] New Cartesian-centric API** - Next by thread:
**Re: [Geometry] New Cartesian-centric API** - Index(es):