[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16981151#comment-16981151
]
Gilles Sadowski commented on GEOMETRY-32:
-----------------------------------------
{quote}VectorXD.linearCombination()
{quote}
Isn't it possible to increase the number of allowed parameters? It would be
more robust than disabling the rule.
Note: Javadoc for the {{linearCombination}} methods needs fixing (it mentions
"coordinate" instead of "vector").
Also, for clarity, we should definitely use MathJax; the meaning of this:
{noformat}
* @return vector with coordinates calculated by {@code (a1 * v1) + (a2 * v2) +
(a3 * v3)}
{noformat}
would be more clearly conveyed with:
{noformat}
* @return a new vector: \( a1 \vec{v1} + a2 \vec{v2} + a3 \vec{v3} \)
{noformat}
{quote}[not] losing any [functionality]
{quote}
What about e.g.
[FieldVector3D|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/geometry/euclidean/threed/FieldVector3D.html]?
Not that it would be within the scope of Commons Geometry, but we should figure
out what should not be delete from Commons Math (as not having any replacement
in the new component).
{quote}it could be done after the main code is refactored
{quote}
Sure.
> 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)
