[ 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)