commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tobr...@transolutions.net (O'brien, Tim)
Subject Re: [math][patch] New RollingUnivariateImpl
Date Fri, 16 May 2003 19:06:54 GMT
> p.s. Just a small criticism, while your free as an Apache committer to 
> take what ever you want out of my patches to apply to your codebase. I 
> hope I might retain some acknowledgement over the inclusion of ideas I 
> may have produced or  helped to produce. 

125% agree, don't take any of this in the wrong way, you have already
made valuable contributions with patches and discussion both here and on
other lists.  I hope that you continue to make good contributions.  


On Fri, 2003-05-16 at 13:18, Mark R. Diggory wrote:
> Ahhh, I missed that you were using Contractable, I thought you were 
> using Expandable directly, I clearly see now that Contractable extends 
> Expandable and provides those features, thats nice. I had missed that 
> before and was wondering why expandable and contractable were separate.
> 
Performance, if I know that I'm only going to be growing my array, why
bother calculating the contractionCriteria after every modification? 
That's why ContractableDoubleArray is separate from
ExpandableDoubleArray.  


> What are the benifits of retaining this ordering in the array structure 
> itself? Are there really any stats that would benifit from this 
> ordering? Its also my understanding is that you would probibly need to 
> apply sorting to a copy of the array to get the mode, median and quantiles.
> 

In ListUnivariateImpl and StoreUnivariateImpl, one can effectively
change the window size at any time.  This makes the most sense in the
implementation backed by the List, StoreUImpl.  In essence,
StoreUnivariate impls commit to storing all values which contribute to a
population, it seems a small step to gaurantee that order is preserved.


> >It might be useful to have a FixedDoubleArray which supports the
> >rolling functionality described in your patch, but, in general, these
> >objects provide usefulness outside of Univariate.  Essentially, I don't
> >want an implementation of Univariate to have to worry about storage.
> >
> 
>  From what I see, you've successfully implemented the Rolling 
> functionality now and theres really no reason to use my separate 
> RollingUnivariate Implementation because of this. As well, I see you've 
> applied some of the recommendations for moving the window into to the 
> UnivariateImpl as well.

I think there is room for a FixedDoubleArray extension of DoubleArray
which would provide the capabilities of rolling in an
array of fixed width.  I know these object wrappers around array may
seem a little overdone, but I anticipate other utilities needing to
reuse some of this functionality.

> 
> I have another idea rolling around in my head, it involves the solution 
> of the higher order moments like kurtosis and skew in such a way that 
> they can be applied without any storage requirements. This is difficult 
> in that I havn't seen any applications of this idea on the net or in 
> research that I know of so far. Basically, I think it just involves 
> calculating the sumcube and sumquad and applying them in the same 
> strategy as a sum and sumsq. But, I havn't yet found the correct 
> algorithm to capture this capability ( there are some details I may be 
> missing). But if I did accomplish this feat, it would possibly alow you 
> to pull the kurtosis and skew methods into the Univariate Interface. 
> What do you think?

This sounds very interesting and it would allow us to move skew and
kurtosis up to the Univariate interface. 


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