On Sun, 22 Jun 2003, Mark R. Diggory wrote: > Hey Tim, > > I've got two big concerns right now with DoubleArrays: > > (1) To take advantage of any of the StatUtil methods on any of the > DoubleArray objects, one has to use "getElements()" to get a double[] > from the DoubleArray object to pass on to the StatUtils method, > unfortunately DoubleArray.getElements() needs to generate a "copy" of > the internal storage, so this often isn't efficient to do every time one > is calling a statistic. I have a couple proposals that can resolve this > issue.
Agreed 100%. Calling System.arrayCopy() is fast, but requiring it for every calculation seems misguided. > (a) Have methods in StatUtils that accept both double[] and DoubleArray > as input paramters. and have the StatUtil.xxx(double []) methods > actually only wrap the double[] in a DoubleArray wrapper and then > delegate to the StatUtil.xxx(DoubleArray) methods. > Mmmm.....I'm not sure why, but that seems like a code smell to me. No reason to involve DoubleArray if you just have a double[]. 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. 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); Mark, do you see the value here? > (b) Then add a constructor to FixedDoubleArray so it can be easily used > to wrap the double[], or write a thin wrapper implementation of > DoubleArray for this specific case. > > (2) Some of the methods in DoubleArray are questionable as they are > statistical in nature and replicated in the Univariate Interface, > specifically DoubleArray.getMin() and DoubleArray.getMax(), and I can't > find anywhere that these ever actually get used, I recommend we remove > these methods from the Interface and Implementations. 100% agreed. There is really no need to calulate min and max in these classes. It seems very redundant. > > (3) Following our same philosophy of not having methods in the interface > that can't be supported across all implementations, > DoubleArray.discardFrontElements seems problematic as not all > DoubleArrays may support it. I do understand the usage, requirement and > need for this method. I wonder if there is some way to internalize the > discarding or provide a more generic sort of DoubleArray.trim() method. > Discarding really only comes into play when working with > ContractableDoubleArrays, maybe it should be exposed at that level > instead of in the interface. Any thoughts? I noticed this as well. It would make sense to remove method from the interface completely. > > -Mark > > -- ---------------------- Tim O'Brien Evanston, IL (847) 863-7045 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
