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 JDKsupplied 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, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
