commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [math] Static Utils and Methods (was: Re: [math] proposed ordering for task list, scope of initial release)
Date Wed, 11 Jun 2003 04:09:13 GMT
Mark R. Diggory wrote:
> Phil Steitz wrote:
>> --- "Mark R. Diggory" <> 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.

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

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

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


> Cheers,
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message