commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] increment() behavior for stats constructed using external moments
Date Tue, 08 Jun 2004 15:38:32 GMT
Phil Steitz wrote:

> 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.
>
I see, I was actually thinking the otherway, rather than have to garbage 
collect the stat object each call, maintain its instance between calls. 
Really, its an assumption, I'm not sure which is more efficient, I'm 
sure theres a trade off, for one its memory for the other its cycles. If 
its clearer in the code by moving them inside the method thats fine with me.

>>>
>>> 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?
>
I guess I was thinking "opposite", I was conceiving the Implementations 
behind StatUtils to be pluggable as well.

Public Interfaces         
DescriptiveStats  ----->
SummaryStats --------> Delegate to Underlying Implementation of 
UnivariateStatistics (determined by Services API, Discovery or some 
other mechanism).
Static StatUtils ------->




Mime
View raw message