[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361664#comment-17361664
]
Alex Herbert commented on NUMBERS-155:
--------------------------------------
Looking at the entire numbers codebase each package is in a separate module. So
if the code does not fit as a core number utility it should not go into core,
it should be in a different package and hence different module.
I think it fine to keep these modules with single classes. This is the current
case for complex.
Q. What is the implication of moving these class to the core module, under the
same package names, and then creating an arrays module and/or rootfinder module
in a future release?That is, can any packages released in the core jar be later
moved to a separate module for those packages if they are to be expanded.
A. Such a moved would keep source compatibility for downstream projects but
with a change of their dependencies. If they are updating their version numbers
then they can also add a new module dependency. One issue would be a transitive
dependency resolving a newer version of numbers core that had a package moved
to a new module. Any code assuming the previous version would be missing
classes. So this could be bad. A safer option is to keep packages in modules.
I can think of a few other use cases for an arrays package. The cases are for
methods of indexing into arrays. MultidimensionalCounter is one example. A
trivial example would be to have a wrapper object that translates 1-based
indexing to 0-based indexing into an underlying array data structure. This
would be for users familiar with 1-based indexing such as matlab. Or a 2D
MatrixTranspose wrapper that reverses the input indices to allow addressing an
underlying 2D matrix as its transpose. Or a 2D symmetric matrix data structure
where [i][j] == [j][i], thus halving the memory requirement by storing the
square matrix as a triangle.
> About modules "arrays" and "rootfinder"
> ---------------------------------------
>
> Key: NUMBERS-155
> URL: https://issues.apache.org/jira/browse/NUMBERS-155
> Project: Commons Numbers
> Issue Type: Task
> Components: arrays, core
> Affects Versions: 1.0-beta1
> Reporter: Gilles Sadowski
> Priority: Major
> Labels: refactoring
> Fix For: 1.0
>
>
> Shouldn't some functionality currently in module {{commons-numbers-arrays}}
> be moved to {{commons-number-core}}?
> Rationale is that the utilities focus on extended precision of some
> computations (on numbers that happen to be stored in an array).
> Wouldn't the Brent solver (in module {{commons-numbers-rootfinder}}) benefit
> from a version based on the new {{ExtendedPrecision}} class?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
