Phil Steitz wrote:
> Shapira, Yoav wrote:
>> Does this include just arithmetic means? We have uses for both and
>> would like both. This would imply org.apache.commons.math.Mean is an
>> interface / abstract / base class, with at least two implementations.
>>
> The initial intention was just arithmetic means; but the whole point of
> this project is to provide utilities that respond to practical needs of
> applications. Personally, I would support adding this stuff, even for
> the initial release (especially if somebody else is willing to code it
> :). I would probably prefer, however, to just add methods to
> Univariate (and maybe change the name of the mean property to
> arithmeticMean) rather than defining a Mean interface. This is because
> to me, these are actually different statistics.
>
I agree, it sounds logical that the method for a particluar statistic
should return the same value no matter the implementation backing it.
For GeometricMean we'ed just need to add:
protected double multi;
...
private void insertValue(double v) {
multi*=value;
}
public double getGeometricMean() {
return Math.pow(multi,1/n);
}
to UnivariateImpl.
and add
/* (nonJavadoc)
* @see org.apache.commons.math.Univariate#getMean()
*/
public double getGeometricMean() {
return Math.pow(getMulti(),1/getN());
}
/* (nonJavadoc)
* @see org.apache.commons.math.Univariate#getSumsq()
*/
public double getMulti() {
double accum = 0.0;
for( int i = 0; i < getN(); i++) {
accum *= getElement(i);
}
return accum;
}
to the AbstracStoreUnivariate
There is another Mean available (Harmonic Mean). It seems to me that for
the Storageless solution, adding all these different means is going to
require storing more "running subtotal" style info. Like the above example.
Mark

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
