Le 14/05/2011 21:04, Phil Steitz a écrit :
On 5/14/11 10:57 AM, Luc Maisonobe wrote:
Le 14/05/2011 16:03, Phil Steitz a écrit :
On 5/14/11 2:08 AM, Luc Maisonobe wrote:
Hello,
Some weeks ago, I have imported in the sandbox a new component,
Apache Commons BSP which implements Binary Partitioning Trees (see
the thread about this creation here:
<http://markmail.org/thread/mcg23trgtl472ica>).
Thinking further about it, I would like to directly merge it into
[math]. We are creating a new major release for [math], so it may
be a good time to do so. Also as I changed the code to put it in
sandbox, in fact I already did all the necessary work to have a
working implementation, with tests and clean reports from
checkstyle and findbugs. The implementation is complete for
dimensions 1, 2 and 3 in Cartesian space. I also need an
implementation on spherical geometry but I can do that regardless
of the component hosting this package. So the component could be
promoted and it really makes sense to have it inside [math].
It could be put as a bsp package at top level (alongside with
geometry, analysis, ode ...).
Does this suggestion makes sense ?
+1 to integrate this code into [math]. I don't think we need
anything beyond lazy consensus to do this, since we are not creating
a Commons proper component here. Lets just give others a little
while to weigh in.
I am on the fence re top level package vs subpackage of geometry,
leaning toward the latter. Why would you consider it as not a
natural part of geometry?
We could put it there. In this case, we should probably move the
current classes that are 3D specific in a sub-package too.
The current layout in [math] is one o.a.c.math.geometry package
with 6 3D specif classes. The current layout in [bsp] is one
o.a.c.bsp.partitioning package that is dimension-independent, one
o.a.c.bsp.utility package, three dimension-specific euclidean
packages o.a.c.bsp.euclidean.oneD, o.a.c.bsp.euclidean.twoD,
o.a.c.bsp.euclidean.threeD.
We could import bsp by changing o.a.c.bsp into
o.a.c.math.geometry, putting the existing math 3D classes into the
new o.a.c.math.euclidean.threeD package. This would open the
opportunity to add 2D classes (some people have asked me if we
would consider adding them).
The next step I mentioned in my original post would be to add
later on o.a.c.math.sphere.oneD (for modeling planar angular
sectors) and o.a.c.math.sphere.twoD (for modeling geographic data).
Why wouldn't all of these be subpackages of geometry?
o.a.c.m.geometry.euclidean, o.a.c.m.geometry.sphere, etc?
Yes, this is what I wanted to say. I failed my copy/paste, everything is
inside o.a.c.m.geometry.
Sorry for the confusion
Luc
Phil
Luc
Phil
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
