Tim O'Brien wrote:
What about this possibility. we could easily have DoubleArray return a reference to the internalStorageArray. I know this would violate encapsulation, but if we expose the interal array, the start and end index then there is no need to copy the contents of the array. Instead we pass a reference to an existing array - aka, no need to copy our element array.
+1 -- it *is* after all an array and if this is not exposed, you are always going to be stuck with using ArrayCopy to get at the underlying data, which makes efficient computation using large arrays impossible. I agonized over this same decision vis a vis RealMatrixImpl, where I ended up "breaking encapsulation" (similarly to other double[][]-based implementations) and exposing a getDataRef method that returns a reference to the underlying double[][] array.
I like it too, since I've been in looking at/messing with these classes I be glad to make the changes for us and add the static methods to the StatUtils. One note, I think we should retain a method that does copy the array as well as create one that exposes it, this is because the copy veriosn can provide us with an array copy that is trimmed down to the size of the actual content, because the internal store inceases "incrimentally" in the windowless case, there is the case that there are unitialized/unused sections at the end of the array (as well, in the windowed case, if the array isn't filled yet, there are unused sections). Providing an interface to retrieve a "cleaned" array is a useful option if one wants to retieve the data to manipulate it elsewhere. This would be usefull in both Fixed and Exp/Cont DoubleArrays.
Now, every method that takes a double[] in StatUtil, would be altered to take a (double[], int start, int length). So,
public static double sum(double[] values);
would delegate to a more "generic"
public static double sum(double[] values, int startIndex, int length);
I agree -- I think that Brent suggested this improvement already.
On the topic of StatUtils, what are the opinions about adding the following methods from my discussion with the lang group to provide alternate primitive implementations? These would be for short, long, int, float for now.
primitive <-- min(primitive[]) primitive <-- max(primitive[]) primitive <-- sum(primitive[]) primitive <-- sumSq(primitive[])
in terms of other stat methods the theme would be more like:
double <-- mean(primitive[]) double <-- var(primitive[]) double <-- std(primitive[])
possibly similar methods for other stat methods, these all would involve casting the elements to double prior to calculating?
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
