commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] increment() behavior for stats constructed using external moments
Date Tue, 08 Jun 2004 14:53:42 GMT
Mark R. Diggory wrote:

>> That's the real problem -- local variables for methods should not be 
>> instance variables and certainly not part of the API (which they are 
>> as protected instance variables).
> But with that kind of logic one could argue that InnerClasses should 
> never be used to encapsulate implementation and classes should never 
> delegate to another class to accomplish a task. Factories and Services 
> would be very difficult to build. Many of the Factories and 
> Implementations throughout the Math package use this approach.
> Also, maintaining it outside of the method allows for reusage.

I don't mean to imply that all implementations should be stateless or that 
instance variables (including stateful cached instances or even stateless 
instances when instantiation is expensive) or inner classes should be 
avoided -- only that making the "helper" stats instance variables in this 
case makes it look like their state may be linked to the instance, which 
it is not, and there is no real overhead in instantiating them, so I would 
rather do it locally.

>> Of course, another option would be to move the common code back into 
>> StatUtils if these methods are going to be static.  That would add 
>> efficiency to StatUtils as well.
> The only shortfall with that I can think of is in the future I want to 
> allow for other implementations of the evaluations (for instance JNI, R, 
> Matlab or Mathematica(JLink) evaluations). I'd like to have the API use 
> Services to discover which Implementation to use, I fear we loose this 
> option when packing all the evaluation methods into StaticUtils. At 
> least, we loose the ability to "plug alternate implementations" in 
> behind StaticUtils if the implementation is static.

Not if we keep the evaluate() methods in the stats objects and have these 
methods delegate (in the default impls) to StatUtils.  Then Variance, Mean 
et al could be swapped out w/ other impls that do not use the "stock" 
numerics collected in StatUtils.  Wouldn't that provide the flexibility 
that we want?


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

View raw message