[Math] Issues 874 and 911

[Gilles Sadowski <gi...@harfang.homelinux.org>]

Hi.

These days, I've refactored the contents of package "o.a.c.m.optimization"
following the discussion on the ML and a proposal posted on the bug-tracking
system:
  https://issues.apache.org/jira/browse/MATH-874
The code is available there.

Summary of the prominent changes:
1. All the deprecated classes/fields/methods have been removed in the
   replacement package "o.a.c.m.optim".
2. The API has been quite heavily simplified: Only one "optimize" method
   remains, declared with the following signature:
   -----
      public PAIR optimize(OptimizationData... optData);
   -----
   where PAIR is a generic.
3. The optimizers' hierarchy has also been greatly reduced:

     BaseOptimizer<T>(*)
     + BaseMultivariateOptimizer<T>(*)
     | + MultivariateOptimizer(*)
     | | + PowellOptimizer
     | | + BOBYQAOptimizer
     | | + CMAESOptimizer
     | | + SimplexOptimizer
     | | + GradientMultivariateOptimizer(*)
     | | | + NonLinearConjugateGradientOptimizer
     | + MultivariateVectorOptimizer(*)
     | | + JacobianMultivariateVectorOptimizer(*)
     | | | + AbstractLeastSquaresOptimizer(*)
     | | | | + LevenbergMarquardtOptimizer
     | | | | + GaussNewtonOptimizer
     | | BaseMultiStartMultivariateOptimizer<T>
     | | + MultiStartMultivariateOptimizer
     | | + MultiStartMultivariateVectorOptimizer
     + UnivariateOptimizer(*)
     | + BrentOptimizer
     | + MultiStartUnivariateOptimizer

   Only "Base..." classes are generic.
   "abstract" classes (indicated with an asterisk
   between parentheses) have replaced all interfaces.
4. This simplification has been made possible by considering that all input
   data is an "OptimizationData": objective function, objective function
   gradient, model Jacobian, maximum number of evaluations, etc.
   [For example, this allows to pass the _same_ list of argument to all the
   optimizers, and each will pick the arguments it needs.  This has the
   drawback that missing data can only be detected at runtime... This has
   the advantage that new behaviours can be added without breaking
   compatibility...]
5. The replacements for the objective function (or vector "model function"),
   gradient and Jacobian input do not refer to "DerivativeStructure".
6. All unit tests have been adapted to the new API.

The package "fitting" (under "o.a.c.m.optimization") has yet to be updated,
as indicated in
  https://issues.apache.org/jira/browse/MATH-911
[The rest that issue could be resolved as "Won't Fix".]
Moreover, I would suggest nevertheless to move it out of "optim". A
top-level "o.a.c.m.fitting" package seems a better fit ;-) for those
classes.[1]
Unless I'm mistaken, the package "linear" (under "o.a.c.m.optimization")
could also be aligned to the changes described previously, e.g. drop the
"LinearOptimizer" interface, make "AbstractLinearOptimizer" a subclass of
"BaseOptimizer"[2] and assume that a set of linear constraints is a kind
of "OptimizationData".

Thoughts?

Best regards,
Gilles

[1] Classes in "fitting" could be viewed as _using_ the tools in "optim"
    rather than being part of them.
[2] One important difference is that the former counts iterations while the
    latter counts function evaluations. Could these be reconciled?

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