commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math] Univariate / StoreUnivariate interface cleanup
Date Sat, 21 Jun 2003 18:50:42 GMT
Mark R. Diggory wrote:
> 
> 
> Phil Steitz wrote:
> 
> 
>>
>> I would not add these to Univariate. I understand your desire to keep 
>> them implemented in UnivariateImpl, but I do not want to force 
>> implementation of these statistics in the Univariate interface.  
> 
> 
> I also understand your interest in being able to provide a "subset" of 
> statistical functions via Univariate. The problem is that I want to be 
> able to provide the same sort of capabilities in the Storageless 
> approaches that we're providing in the Storage based approaches.
> 
> I feel we have implemented these methods throughout all the versions of 
> Univariate, they are common to all implementations, I believe then it is 
> wise to place them into the interface that spans all implementations.

-1  I would prefer to remove them from UnivariateImpl

> 
> I also am starting to feel that as long as the storageless approach is 
> based solely on the Univariate Interface, neither of us will be happy, 
> or one of us will end up having to compromise our position.

Implementation classes implement methods defined in interfaces.  The 
Univariate interface defines the methods that all Univariate 
implementations must support.  As such, it should be limited to core 
functions. Skewness and Kurtosis are non-core, IMHO.

> 
> I really want to find a way to provide an extensible means to add other 
> statistical methods to the library and make them available via 
> interfaces. I understand the importance of keeping the interfaces 
> controlled or I wouldn't have opened up the discussion. If you like "x 
> method", and I like "y method", we should be able to find room for both 
> of these in the library *and* in the interfaces. There are allot of 
> useful statistics out there that would benefit from implementation over 
> a non-storage or storage based strategy.
> 
> One consideration is that delineating the Interfaces on "Univariate" vs. 
> "StoreUnivariate" is way too *implementation specific*. I don't think 
> implementation specific interfaces are very useful.  I understand its 
> logical to base them on implementation initially, but I'm starting to 
> feel it would be far less to restrictive to draw lines in terms of 
> functionality. better to categorize on "application" or "usage". 
> Something like:
> 
> RankStatistics
> 
> MomentStatistics
> 
> NonParametricStatistics
> 
> etc.
> 
> (not suggesting these as the ultimate solution, just an example)
> 
> then if someone writes a particular statistic and they what to donate it 
> to the package, there's room for expansion.
> 
> I'm going to spend some of my own time looking Aspect Oriented Design 
> further. I think there has to be a means of separating the statistical 
> approach from the underlying storage/storageless implementation.

I suggest that our time is better spent completing the remaining tasks 
for initial release.  As stated in the proposal

"Commons-Math is a library of lightweight, self-contained mathematics 
and statistics components addressing the most common practical problems 
not immediately available in the Java programming language or 
commons-lang. The guiding principles for commons-math are:

    1. Real-world application use cases determine priority
    2. Emphasis on small, easily integrated components rather than large 
libraries with complex dependencies
    3. All algorithms are fully documented and follow generally accepted 
best practices
    4. In situations where multiple standard algorithms exist, use the 
Strategy pattern to support multiple implementations
    5. Limited dependencies. No external dependencies beyond Commons 
components and the JDK "

Commons-math is not intended to be a general-purpose statistics package 
any more than it is intended to be a general-purpose numerics package. 
  If this is your area of interest, it might be better to start a 
separate project to build a general-purpose Java statistics library.

Phil

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




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