commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Composition vs. Inheritance for moment statistics
Date Sun, 18 Jul 2004 17:21:48 GMT
Mark R. Diggory wrote:
> Hey Phil,
> I notice your moving much of the extended functionality out of the 
> Univariates and into a private field instead. I'm just curious what your 
> logic is behind it? I had considered wrapping vs extending initially 
> when I was building the implementation. Now that I look back, my reasons 
> for going with extending were more to take advantage of the already 
> preexisting "protected" fields in the implementation of the underlying 
> Univariate. Now that I see your changes, I think what your wrapping is 
> more kosher in terms of encapsulation underlying implementation of the 
> wrapped statistic.

I think we are agreeing here. The ones that I changed were 
StandardDeviation (wrapping, rather than extending Variance) and 
GeometricMean (wrapping, rather than extending SumOfLogs).  The reason for 
this, as you point out, is that extending (in these cases) binds the 
implementations unecessarily.  In the two cases that I changed, what is 
really going on is just delegation, so composition is better (IMHO).
> While the difference between these approaches is minimal in the front 
> end Univariates like Mean, Var, Median, StandardDev and Geomean, I 
> believe the extended hierarchy of FirstMoment -> SecondMoment -> 
> ThirdMoment -> FourthMoment takes more advantage of this extended field 
> reuse. I'm not so sure if these should be approached as wrappers too? 
> They do make significant reuse of the internal state of the underlying 
> moment. What do you think? Would these be problematic to turn into 
> wrapped implementations too?

I thought about those and they could be changed to nest instead of extend 
one another; but as you point out there is significant use of common 
fields in these classes and it would be a fair amount of work to pull them 
apart.  In addition, some efficiency might be lost by pulling them apart. 
  This is beyond my JVM knowledge; but it seems that it might be more 
expensive to create the resulting "Chinese Box" of nested moment instances 
for, e.g. FourthMoment, and dereference all of the fields attached to the 
inner moments when doing computations, rather than just accessing the 
protected fields directly.  This is especially true of the lower order 
moment values themselves, which are now stored as doubles and would have 
to be accessed via getResult() calls to the nested moments were we to 
change to composition.


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

View raw message