commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] [Proposal] Deligation of UnivariateImpl to AbstractStoreUnivariate and refactoring of Univariate Interfaces.
Date Tue, 17 Jun 2003 17:29:06 GMT

--- "Mark R. Diggory" <> wrote:
> Proposal:
> The deligation of UnivariateImpl to AbstractStoreUnivariate and 
> refactoring of Univariate Interfaces.
> Goals:
> (1) I propose that UnivariateImpl should deligate to either a full 
> implmentation of StoreUnivariate or it should extend the 
> AbstractStoreUnivariate instead of supporting multiple implementations 
> of the "Statistical Methods" for StoreUnivariates and UnivariateImpl. 
> This way there is only one implementation for a stored statistical 
> method approached in AbstractStoreUnivariate. It is the case then that 
> when UnivariateImpl has a window and requires storage, that it uses the 
> same exact implementation as other storage implementations.

+1 for encapsulating the common statistical computations, -1 for collapsing to
a single interface including all methods.
> (2) Simplification of the Univariate/StoreUnivariate Interfaces. With 
> the above case in mind, there are "methods" that currently do not have 
> storageless implementations, but when in a storage based mode, 
> UnivariateImpl becomes a storage based implementation, as such those 
> methods are now available through the deligation. It is benifical then 
> to provide acces to those methods throught the Univariate Interface 
> itself. I propose the consolidation of the StoreUnivariate and 
> Univariate into one interface 

-1 Univariate should include only the methods common to all implementations.

(and in the minorboolean cases where a 
> UnivariateImpl method is not currently applicable, to just throw a 
> runitime exception).  Initially, we found storageless implmentations of 
> some statistics to be difficult to accomplish. But I feel strongly that 
> over time clean solutions will be found, we should not lock ourselves 
> out of accomplishing this be restricting the interface.
-1 We will *never* be able to support percentiles efficiently, for example,
without storage. 
> I propose a class heirarchy/naming change to occur based on the 
> following class structure
> public interface Univarate
>     - combines Univariate and StoreUnivariate
>     - *defines all Univariate stat and storage access methods*
> public abstract class AbstractUnivariate implements Univariate
>     - was AbstractStoreUnivariate
>     - *implements All Univariate Statistics and storage access*
> public class RollingUnivarate extends AbstractUnivariate
>      - *storage access and some stats only available when window is set*
> public class StoreUnivariateImpl extends AbstractUnivariate
> public class ListUnivariateImpl extends AbstractUnivariate
> public class BeanListUnivariateImpl extends AbstractUnivariate
> Lastly, if the above approach is rejected by the group, then I highly 
> recommend that there be separate implementations of the storageless 
> "RollingUnivariate" and storage based "RollingStoreUnivariate" to reduce 
> the  both interface confusion that is currently observable in the 
> package between Univariates and StoreUnivariates and the implementation 
> complexity observed in the current UnivariateImpl approach.

-1. Once the recently added changes are rolled back, there will be no
"interface confusion" -- only the need to consolidate implementations for
vector-based methods.  My "counter-proposal" to simply encapsulate the common
computational methods stands.  Are there any compelling arguments why we should
not proceed in the way that I have outlined?  


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

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!

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

View raw message