Hello,

Since release of 1.2, several people have asked for advices on using the
estimation and optimization packages imported from mantissa. This showed
these packages were poorly designed (you can blame me for that). After
one of the discussions on this topic, issue MATH-177
(https://issues.apache.org/jira/browse/MATH-177) was set up to ask for a
refactoring. I also opened MATH-196
(https://issues.apache.org/jira/browse/MATH-196) for constrained
optimization, Gilles contributed Brent minimization (which was appended
to MATH-177 and committed recently in the analysis.minimization
package), and Benjamin contributed an implementation of Dantzig's
simplex method in MATH-246
((https://issues.apache.org/jira/browse/MATH-246).

As we are refactoring many packages for 2.0, I propose to refactor these
two packages too.

The existing code is :
  - package o.a.c.math.analysis.minimization:
      Brent minimization algorithm for univariate scalar valued functions
  - package o.a.c.math.estimation:
      Levenberg-Marquardt method for weighted least square minimization
of a vector of residuals
      Gauss-Newton method for weighted least square minimization of a
vector of residuals
  - package o.a.c.math.optimization:
      Nelder-Mead simplex method for multivariate function minimization
without derivatives
      Virginia Torczon's multidirectional method for multivariate
function minimization without derivatives
  - attached to JIRA issue MATH-246
      Dantzig's simplex method for linear systems with linear equality
and inequality constraints

Some generalization attempts have been made separately in estimation and
optimization with a few interfaces  (EstimationProblem, Estimator on one
side CostFunction and ConvergenceChecker on the other side). These
interfaces seems difficult to understand to users. They were in fact
designed with a specific problem in mind (orbit determination for
spacecrafts to be precise) and are not generic enough.

Here is what I propose to do :

1) let Brent minimization in the analysis.minimization package where it
is now

2) gather everything else in a package hierarchy:
    o.a.c.math.optimization with better interfaces (CostFunction may be
kept, the other should be replaced)
    o.a.c.math.optimization.linear for Dantzig's simplex method
    o.a.c.math.optimization.direct for direct search methods
(Nelder-Mead and Torczon)
    o.a.c.math.optimization.general for everything else

3) some provisions should be made for constrained optimization in the
general case, but implementation could probably be delayed until 2.1
(the target revision for MATH-196 is already 2.1)

4) The fancy EstimatedParameter and WeightedMeasurements classes should
be dropped (i.e. deprecated) they do not belong to commons-math layer.
This is a major change. I think it is better for users to have an easy
to understand low level package rather than a big unusable bunch of
code. If this option is not chosen, it should be at least possible to
use the package at a lower level and provide these classes only as a
convenience for those whose needs fit well with this ad-hoc design.

5) the possibility to switch a parameter status between "should be
estimated" and "should not be touched at all" should be removed (I think
nobody ever realized it was possible)

6) the interfaces should define an optimization problem in terms of
simple structures (both double[] and RealVector) instead of the dropped
parameters and measurements objects.

7) the linear cost function and linear constraints should be specialized
interfaces extending more general cost and constraints interfaces from
the optimization package. This is mainly for consistency as I don't
expect many people will want to use a general solver for linear problems.

I have no idea yet of what the main interfaces should be. It is possible
nothing useful will be put in the upper level package except for
exceptions. I will have a look at this later, after we get an agreement
on the global structure and the level of service these packages should
provide.

Does this seems sensible ?

Luc

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

Reply via email to