Hi,
Not sure if I would be able to help much regarding the domain specific
knowledge, and verifying if the API makes sense.
But I can try helping with the part about the API being more extensible. I
compared the branch with the master branch with
https://github.com/apache/commons-geometry/compare/master...darkma773r:geometry-32-working?expand=1
Q) are the *_Old.java modifications necessary?
Q) there are multiple commits, so I thought it would be easier to look at the
comparison in GitHub. Maybe a draft pull request would be easier to
review/comment?
CheersBruno
On Friday, 7 June 2019, 11:54:01 pm NZST, Matt Juntunen
<[email protected]> wrote:
Hi all,
I've been working on GEOMETRY-32 for the past several months and I've come to
the point where I could really use some help and/or another pair of eyes on the
code to get it wrapped up. The issue involves refactoring the original binary
space partitioning (BSP) tree code from commons-math to clean up the API and
make it more extensible. If you're not already aware, the BSP tree classes are
what allows the code to perform geometric calculations (such as computing the
size, boundary, barycenter, etc) of arbitrary shapes and regions, including
infinite regions. It's a very powerful feature and I think it will make
commons-geometry that much better if we can get the API right.
I have the code for this issue in a working branch on Github [1]. I have the
generic BSP tree code implemented and unit-tested along with Euclidean 1D and
most of 2D. I still need to finish Euclidean 2D and then do Euclidean 3D,
Spherical 1D, and Spherical 2D.
Let me know if you're interested in helping out in any way.
Thanks,
Matt
[1] https://github.com/darkma773r/commons-geometry/tree/geometry-32-working.
