commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [VOTE] Release Math 1.0
Date Mon, 20 Sep 2004 00:29:24 GMT
Kim van der Linde wrote:
> Phil,
> 
> Phil Steitz wrote:
> 
>> Kim,
>>
>> Can you be more explicit?  Most of your objections were addressed in RC1.
> 
> 
> Some of my objections were resolved. The matrix stuff was partially 
> resolved, as is the name of the regression, which is still in the wrong 
> package. 

We discussed this and concluded that it did not make sense to combine 
univariate and multivariate statistics into one package and by any 
reasonable definition regression (even with just one independent variable) 
is a multivariate technique.  Therefore, it belongs in .multivariate.

> Furthermore, the different types of variances remains unsolved, 
> as they are variant's of each other and should be in one single class. 

Unfortunately, this is inconsistent with the basic design of the 
univariate statistics package. Having each statistic class compute just 
one statistic has lots of advantages -- one of which is that it is trivial 
to add alternative implementations for the same or similar statistics 
without breaking compatability with existing code.

> And I differ in the basic idea of dealing with regression types (LS, MRA 
> MA). 

Right now, we support only simple OLS regression. Post 1.0, we welcome 
ideas about how to represent and support alternative models.

> And I think the random class should be either eliminated (bad 
> random) or be replaced with something more robust so that is actually 
> usefull to be used for serious scientific work.

The value of the random package is in how it *uses* the PRNG, not (at 
least currently) that it *supplies* a PRNG. Alternative PRNGs (or even 
RNGs) can be substituted for the JDK-supplied PRNG used by the default 
implementation.  This could be made easier (currently you need to subclass 
or provide an alternative RandomDataImpl) and I will add this to the 
WishList.

> Finally, I start 
> doubting more and more the way most methods are implemented trough 
> interfaces, which makes less and less sense to me the longer I deal with 
> them.

This is really a Java issue. Takes some getting used to, but provides a 
lot of flexibility.

Thanks again for the feedback.

Phil

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