commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject [math] Refactoring multiple regression classes
Date Wed, 13 Jul 2011 19:35:23 GMT
To effectively integrate Greg's contributions on updating
regression, we really should refactor the multiple regression
hierarchy so that we have consistency in results reporting and data
definition.  Here are some initial ideas.  Better ideas and/or
patches welcome.

0. Deprecate MultipleLinearRegression (basically being replaced).

1. Create a LinearRegression interface with what is now in
UpdatingMultipleLinearRegression, minus the addObservation methods.

2. Define UpdatingLinearRegression extending LinearRegression
(adding back addObs*).

3. Define FixedLinearRegression extending LinearRegression, adding
the new*Data data definition methods now in
AbstractMultipleLinearRegression.

4. Deprecate AbstractMultipleLinearRegression.

5. Add AbstractFixedLinearRegression implementing
FixedLinearRegression and providing default impls for the new*Data
methods (taken from AbstractMultipleLinearRegression)

6. Modify OLSMultipleLinearRegression and
GLSMultipleLinearRegression to extend AbstractFixedLinearRegression,
possibly preserving MultipleLinearRegression implementation until 4.0.

7. If there is value to an abstract parent for the updating impls,
add this implementing UpdatingLinearRegression; otherwise just
implement directly.

We can talk about the names in 1-3.  We can also talk about getting
rid of the interfaces entirely and just have LinearRegression and
its immediate children abstract classes with all abstract methods. 
Or maybe others have entirely different and better ideas.   Thanks
in advance for ideas on this.  The one thing we really need is to
have the fixed matrix models report results using the new
RegressionResults object.  Without that, we will not be able to
refactor the tests to enable cross-validation (and it will obviously
be confusing for users to have the classes implementing the same
functionality exposing completely different APIs).

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message