commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] AbstractDescriptive Statistics
Date Sat, 29 May 2004 05:18:50 GMT

Phil Steitz wrote:
> Mark R. Diggory wrote:
>> I'm curious about AbstractDescriptiveStatistics, currently our Type 
>> Hierarchy looks like this:
>> Object
>>     --> DescriptiveStatistics (implements Statistical Summary)
>>               --> AbstractDescriptiveStatistics
>>                            --> DescriptiveStatisticsImpl
>>                            --> ListUnivariateImpl
>>                                         --> BeanListUnivariateImpl
>> Why don't we consolidate AbstractDescriptiveStatistics into 
>> DescriptiveStatistics? Then we will have
>> Object
>>     --> DescriptiveStatistics (implements StatisticalSummary)
>>               --> DescriptiveStatisticsImpl
> I agree that this would be better.  The only loss is that the algorithm 
> specification part (now in AbstractDescriptiveStatistics) would be 
> recombined with the storage management part (now in 
> DescriptiveStatisticsImpl).  I see no real loss in this.

Now I actually understand the reason why we broke it up into two 
classes, The Abstract class maintains the Statistics parts so they can 
be reused in the ListUnivariateImpl etc.  Your maintaining the 
SummaryStatistics as an abstract interface and all the Implementation is 
in SummaryStatisticsImpl.

The modifications I'm suggesting place the methods for creating the 
UnivariateStatistics up in DescriptiveStatistics and only the storage in 
the Implementation. My edits basically combine DescriptiveStatistics and 
AbstractDescriptiveStatistics (not AbstractDescriptiveStatistics and 

> I agree with Stephen, however, that DescriptiveStatistics should be 
> renamed DescriptiveStatisticsFactory.

Problem is that DescriptiveStatistics both the factory and the interface 
for the objects the factory creates. As such its ambiguous as both. 
Factory tends to just lengthen the name in this case.

>>               --> ListUnivariateImpl
>>                            --> BeanListUnivaraiteImpl
>> Likewise, for consistency, we should probibly rename 
>> ListUnivariateImpl and BeanListUnivariateImpl to 
>> ListDescriptiveStatisticsImpl and BeanDescriptiveStatisticsImpl
> I agree here as well, but I thought that we had agreed to push these 
> into /experimental, so we could release 1.0 without the BeanUtils (and 
> associated chain of) dependencies.

I remember something like that.

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message