[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981142#comment-16981142
]
Matt Juntunen commented on GEOMETRY-32:
---------------------------------------
{quote}there are too many files
{quote}
Agreed :)
bq. ... suppression rules for CheckStyle. Are they necessary?
I believe they are. They all relate to the maximum number of method parameters
allowed and are either 1) internal methods used to avoid the necessity of
arrays (ex: {{Matrices.determinant()}} or 2) public convenience methods (ex:
{{VectorXD.linearCombination()}}. The linear combination methods existed before
this PR, and are similar to the {{LinearCombination}} methods from
commons-numbers-arrays, which also have a suppression rule. I'll add
documentation in checkstyle-suppressions.xml to say specifically what's being
suppressed.
bq. Does this PR entails that all the functionality of Commons Math's package
o.a.c.math4.geometry is now covered by Commons Geometry?
In general, yes. Overall, we have gained functionality instead of losing any.
The one exception that I can think of is the
{{o.a.c.g.euclidean.threed.OutlineExtractor}} class. I have not ported that
over to the new code yet and so it is not present in this PR. That is one of
the follow-up issues that I intend to make. I left it out for now because I
consider this as something of an edge-case functionality and I thought it could
be done after the main code is refactored and the API settled.
> BSPTree Updates
> ---------------
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core
> Reporter: Matt Juntunen
> Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}}
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used
> for defining in/out regions. This could result in a BSPTree interface and a
> RegionBSPTree interface. The goal here is to allow end-users to create their
> own extensions of these classes and specialize them for their own
> applications (for example, to implement spatial sorting or other algorithms).
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree
> construction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
