Phil Steitz wrote:
--- "Mark R. Diggory" <[EMAIL PROTECTED]> wrote:
I disagree. We need it ourselves, unless we want to duplicate code between
UnivariateImpl and AbstractStoreUnivariate. Also, I personally and I am sure
many other users would like simple array-based functions for means, sums, etc.
If I have an array of doubles and I all I want to is compute its mean, I would
like to be able to do that directly, rather than having to instantiate a stat
object.
If there is a strong motivation for it, then it should go in before release. But, I'd really rather have the static functions be static delegates for the Implementations, not the other way around. (this thought is defended later in this message).
We need it now, to improve the computations in UnivariateImpl for the finite window case. I guess I am going to have to do this, since no one else seems interested.
MathUtils (or StatUtils) provides a low overhead, natural place to encapsulate the core computation, similar to java.Math. To have the UnivariateImpls delegate like this is not a good design, IMHO. Think about what that would require in terms of instantiation, dependencies, etc. It is a *much better* idea to encapsulate the common (very basic, btw) functionality, especially given that it is generically useful. We will run in to *lots* of scenarios where we want to sum an array or find the min of an array. It is silly to force all of these things to depend on and force instantiation of Univariates.
In terms of duplicate code in Univar and StorUnivar, its not obvious to me what the static interface of MathUtils or StatUtils has to do with this? My feelings are that UnivariateImpl should delegate to StoredUnivariateImpl in situations where storage is required.
I say this because I believe other developers will become confused as to whether to use the static or OO (Object Oriented) way to use the functionality when developing.
I disagree. We should provide the flexibility to choose. Computationally
intensive applications may want to work directly with arrays (as we should
internally), while others will more naturally work with stat objects, or beans.
[defense] I agree, and I think in the case of Univariate's (and other applications) that it would be best to supply methods for working with arrays, you should be able to hand Univar a double[] without having to iterate over it and add each value using addValue(...). There should be a method or constructor that uses such a double array directly for the calculation. Again, this means that MathUtil's is just a static delegation point for such methods across different classes, those classes have to implement the methods that would get called to support such functionality.
I am suggesting "to have" such methods in MathUtil's, but keep the implementations in the classes themselves.
That is backwards an inefficient, IMHO. That would defeat the main purpose, which is to provide lighteweight, efficient, cleanly encapsulated computational methods that the stat (and other) objects can use.
If we have two different strategies for
accessing functionality, then we need to have design rules on how where to use each case in our own development.
I agree. This is why I proposed adding the static double[] -> double
computational methods -- so the many places where we will need them can all use
common, optimized implementations.
If I were writing a class that used other implementations in [math], I would use the implementations directly as much as possible and avoid usage via the static interface. I'd do this simply to support optimized object usage over constantly reintantiating the objects that may get recreated ever time such a static method is called. (Some others may disagree, I'm sure theres lots of room for opinion here).
The point is to provide the users with a choice. For some things, a Univariate is natural, for simple computations on arrays, it is overkill , IMHO. For some situations, the BeanListUnivariate is natural. There is no reason to limit things artifically or to resort to unnatural and inefficient implementation strategies when it is easy to expose the functionality. Suppose that Math did not support sqrt(). Would we add this to some Univariate implementation and build spaghetti dependencies on that? I don't think so. This kind of thing fits naturally in a MathUtils class. Similarly, the simple computational function sum: double[] |-> double belongs naturally in a StatUtils class. Have a look at the *Utils classes in lang. These are among the most useful things in the package.
Phil
Cheers, Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
