commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <hotfusion...@yahoo.com>
Subject Re: [math] Proposal for Package restructuring and Class renaming
Date Sat, 08 Nov 2003 23:03:57 GMT
--- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
> Al Chou wrote:
> > --- "Mark R. Diggory" <mdiggory@latte.harvard.edu> wrote:
...
> >>2.) Like in my last emails concerning "Univariate" I would like to, (and 
> >>have done so in my checkout successfully) Make the following Class changes:
> >>
> >>interface o.a.c.m.stat.StoreUnivariate -->
> >>            abstract class o.a.c.m.stat.DescriptiveStatistics
> >>
> >>this actually becomes a factory class and uses Discovery to instantiate 
> >>new instances of the following implementations
> >>
> >>*default implementation*
> >>o.a.c.m.stat.StoreUnivariateImpl -->
> >>           o.a.c.m.stat.univariate.StatisticsImpl
> > 
> > 
> > Forgive me for not refamiliarizing myself with the code first, but should
> the
> > storeless version perhaps be the default implementation instead?  What do
> we
> > lose by going that way?  I'm thinking it would be nice to keep memory usage
> > lower if possible.
> 
> The Storeless version (UnivariateImpl) doesn't support rank Statistics 
> because of its storeless nature, the more fully featured implementation 
> is StoreUnivariateImpl, it does everything, but has the limitation of 
> requiring storage of the values. These are two different implementations 
> with different internal storage configurations. I choose 
> StoreUnivariateImpl because I think the default should have full 
> capabilities.
> 
> The storeless version is more of an Optimized solution, It probably wise 
> to suggest that one use it only if one needs that functionality (ie 
> trying to get moments across huge datasets or realtime value streams of 
> sorts)

That sounds reasonable.  Thanks for the refresher (I looked at the current code
based on your remarks, too).


> > Before we go overboard, can you give a quick example of instantiating one
> of
> > the implementations?  Or perhaps, both the default and one alternative
...
> Yes, like that
> 
> For the default Discovery configured implementation:
> 
> DescriptiveStatistics stats = DescriptiveStatistics.newInstance();
> 
> stats.addValue(5.0);
> ...
> 
> double mean = stats.getMean();
> 
> 
> For any alternate Implementations:
> 
> DescriptiveStatistics stats = 
> DescriptiveStatistics.newInstance(StorelessDescriptiveStatisticsImpl.class);
> 
> stats.addValue(5.0);
> ...
> 
> double mean = stats.getMean();
> 
> and/or
> 
> DescriptiveStatistics stats = 
>
DescriptiveStatistics.newInstance("o.a.c.math.stat.impl.StorelessDescriptiveStatisticsImpl");
> 
> stats.addValue(5.0);
> ...
> 
> double mean = stats.getMean();
> 
> depending n which people like more

OK, I see.  The one thing I notice is that the names are getting awfully long,
especially for the non-default case.  I guess that's a price we pay for having
descriptive (no play on words intended) names like DescriptiveStatistics....



Al

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message