commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [math] Some issues with DoubleArrays
Date Mon, 23 Jun 2003 14:23:40 GMT
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.

> 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.

>>(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.

I agree here as well.

>>(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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message