commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] Moving apply() down DescriptiveStats hierarchy, simplifying structure
Date Mon, 26 Jan 2004 00:53:39 GMT
Looks good overall, but isn't instantiating a new instance of the 
statistic each time a little heavy handed? Or is there some benefit I'm 

      * @see org.apache.commons.math.stat.DescriptiveStatistics#getMin()
     public double getMin() {
     	return apply(new Min());

Also, I know this is an ongoing battle, but we have fine working 
memoryless implementations of skew and kurt, we should maintain access 
to them in SummaryStatistics interface.


Phil Steitz wrote:

> I have committed the new / modified code. We now have 
> DescriptiveStatistics and SummaryStatistics as abstract factories for 
> aggregates depending on / not depending on storage, resp. 
> AbstractDescriptiveStatistics still exists, since it makes sense to 
> separate evaluation from storage management (as before), but there is no 
> Abstract superclass for SummaryStatistics.  To enable things like 
> TStatistic to work with either kind of aggregate, I added a 
> StatisticalSummary interface to just expose the basic stats.
> The tests and javadoc still need work.  I also notice that the BeanList 
> stuff has been moved to /test.  Are we thinking about eliminating this?
> One thing that I thought about which would provide most of the value of 
> these classes would be to just add a factory somewhere (maybe StatUtils) 
> that would create a DescriptiveStatistics instance from a collection and 
> a property name.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message