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 missing?

    /**
     * @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.

thanks,
Mark

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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]


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



Reply via email to