Re: [geometry] Initial Project Structure
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.
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
Sounds good. I'll move everything in that module to be under the o.a.c.geometry.core package.
From: Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, April 14, 2018 1:50 PM
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>
>> 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
>>> 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?
> 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
> of the different geometries that avoid the parallel postulate in one
> All thoughts, I’m +0 to +1 for the packages shown.
>>> * commons-geometry-enclosing
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx