[
https://issues.apache.org/jira/browse/NUMBERS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361796#comment-17361796
]
Alex Herbert commented on NUMBERS-155:
--------------------------------------
{quote}However, for each access to an element of a virtual multidimensional
array, the utility must instantiate an int[].
{quote}
Requires an API change?
Which method is the main problem:
{noformat}
// Creates an int[] for the result
public int[] toMulti(int index);
// Creates an int[] for the arguments
public int toUni(int... c);
{noformat}
The first can be solved by accepting the output array as an argument:
{noformat}
// Reuses the int[] for the result.
// If null -> exception or create the array
// If too small -> exception or create the array
// If too big -> exception or use it anyway
public int[] toMulti(int index, int[] indices);
{noformat}
The second just requires the user to maintain an array to be passed in.
For single access to elements the performance may be negligible. If you are
repeat accessing a single dimension array via the counter then there are a lot
of calls to create an index. When repeat accessing elements this is either
random positions or a series. In the later case the API does not cater for
iterating over columns as it does not expose the stride length offsets. Here is
an example of using the offset of a given dimension:
{code:java}
int[] size = {2, 3, 4};
MultidimensionalCounter mc = MultidimensionalCounter.of(size);
double[] data = new double[mc.getSize()];
int x = 1;
int z = 2;
for (int y = 0,
index = mc.toUni(x, y, z),
stride = mc.getOffset(1); y < size[1]; y++, index += stride) {
data[index] = 42;
}
{code}
The class could be made more efficient with specialisations for 2D, 3D, etc.
But to be optimal they would have to declare their own toUni method:
{code:java}
public int toUni(int i, int j);
public int toUni(int i, int j, int k);
public int toUni(int i, int j, int k, int l);
{code}
If they all stick to using {{toUni(int...)}} then the factory constructor can
still return specialised instances which would improve performance by
eliminating the loop over the dimension and storing the sizes and offsets as
primitives.
> 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)
