--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:I think we are all starting to agree on this one.
(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.
Then, I assume via lazy group concensus, that we are, as a group, opposed to consolidating interfaces (my +1 being the minority).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?
Phil
Phil, to clarify my above point better, what I mean is that there is confusion and loss of capability in the implementation of UnivariateImpl in the following case:
UnivariateImpl becomes a storage based solution right now if the window is set (and I very strongly defend that it should have such windowing capabilities, as I use them). In this case there are actually more capabilities that could be available than are actually provided for in the Univariate interface itself. Its unfortunate that these are lost just because the storageless version cannot support them at this time. I suspect this creates ambiguity as to what should be implemented in UnivariateImpl, I feel that, in using a window and wanting capabilities like "percentiles" it is the case then user should actually be using StoreUnivariateImpl and not UnivariateImpl.
Now, UnivariateImpl could be easily implemented without this "alternate" storage capability inside UnivariateImpl for the windowed case, and then it becomes more logical to tell the user to use StoreUnivariateImpl for specific statistics and UnivariateImpl for others, the behavior and Implementation become more clearly defined. Univariate for moment statistics (means,vars,skews,kurts) and StoreUnivariate for rank statistics (min, max, mode, median, percentile, etc).
So in terms of this argument, it would be logical that all storage capabilities should then be removed from UnivariateImpl, and only those methods which can be truely supported in a storageless approach (moments) be implemented in UnivariateImpl and avaiable through Univariate. This draws some lines where rank methods getMin and getMax actually fall outside of the capabilities of a windowed UnivariateImpl. (a) they would either be removed from Univariate or (b) they throw runtime exceptions in cases where they are no longer appropriate (when a window has been set). I had gone for the later approach and extended it to all possible statistical methods given there was deligated storage. Maybe (a) is actually more appropriate.
Finally, to be even clearer, I'm not suggesting that we implement a RollingStoreUnivariateImpl, these capabilities are already present in StoreUnivariateImpl.
-Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
