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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org