osdir.com

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]# Re: [geometry] Initial Project Structure

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

Rob: I’m a little surprised that you’re giving an entire package to hull. Wouldn’t determining a convex hull in spherical geometry differ from in euclidean? Yes, they would differ. The idea is that the algorithm-specific modules would contain the basic interfaces for the algorithm as well as implementations for specific spaces. For example, the hull module contains the space-independent ConvexHull and ConvexHullGenerator interfaces as well as implementations for euclidean 2D space. If we added a spherical implementation it would go in this module, too. Are we going to do more than just euclidean and spherical? Maybe our names should be “euclidean” and “non-euclidean” so that we can put all of the different geometries that avoid the parallel postulate in one sub-project? I don't currently have any plans to add new spaces but I think it's a possibility. I personally prefer having explicit modules for each space. Gilles: only JDK exception types are part of the public API I see what you're talking about with the exceptions in commons-numbers but I don't understand the reasoning behind it. Why don't we want to expose custom exception types to users? Wouldn't they want to be able to write catch clauses for specific conditions? In the case of the geometry code, one big condition that comes up all the time is the zero norm condition. This is why I have a special type for it. I'd avoid defining classes in "o.a.c.geometry" unless you are sure that no other (maven) module than "core" will. [Safer would be to create a "o.a.c.geometry.core" package and move the "Geometry", "Space", "Point" and "Vector" classes into it.] Sounds good. I'll move everything in that module to be under the o.a.c.geometry.core package. Thanks, Matt ________________________________ From: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> Sent: Saturday, April 14, 2018 1:50 PM To: dev@xxxxxxxxxxxxxxxxxx Subject: Re: [geometry] Initial Project Structure On Sat, 14 Apr 2018 10:46:40 -0400, Rob Tompkins wrote: >> On Apr 14, 2018, at 9:00 AM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx> >> wrote: >> >> Hello. >> >> On Sat, 14 Apr 2018 04:24:35 +0000, Matt Juntunen wrote: >>> Hi Gilles, >>> >>> That's actually really close to what I ended up with after I >>> started >>> moving the code over. I currently have >>> >>> * commons-geometry-core >>> * commons-geometry-euclidean >>> * commons-geometry-spherical >>> * commons-geometry-hull > > I’m a little surprised that you’re giving an entire package to hull. > Wouldn’t determining a convex hull in spherical geometry differ from > in euclidean? https://github.com/darkma773r/commons-geometry/tree/geometry-1/commons-geometry-hull/src/main/java/org/apache/commons/geometry > Are we going to do more than just euclidean and spherical? Maybe our > names should be “euclidean” and “non-euclidean” so that we can put > all > of the different geometries that avoid the parallel postulate in one > sub-project? > > All thoughts, I’m +0 to +1 for the packages shown. > > Cheers, > -Rob > >>> * commons-geometry-enclosing >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx

- Prev by Date:
**[RESULT][LAZY][VOTE] Release Commons Parent 46 based on RC3** - Next by Date:
**[geometry] Exceptions (Was: Initial Project Structure)** - Previous by thread:
**Re: [geometry] Initial Project Structure** - Next by thread:
**[CANCEL][LAZY][VOTE] Release Commons Parent 46 based on RC1.** - Index(es):