[
https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-874:
------------------------
Fix Version/s: 3.1
In a [discussion on the "dev" ML|http://markmail.org/message/vca2sanoulur7edu],
one point raised again was the odd naming of the subpackages under
"o.a.c.m.optimization".
Although no agreement was reached there about how the layout should look like,
I propose to create one based on the immediate API similarities (i.e. what the
caller is required as input to the "optimize" methods). Thus the package name
and contents of "direct" and "general" would be reorganized as follows:
{noformat}
optim.scalar.noderiv.PowellOptimizer
optim.scalar.noderiv.SimplexOptimizer
optim.scalar.noderiv.CMAESOptimizer
optim.scalar.noderiv.BOBYQAOptimizer
optim.scalar.gradient.NonLinearConjugateGradientOptimizer
optim.vector.jacobian.AbstractLeastSquaresOptimizer
optim.vector.jacobian.LevenbergMarquardtOptimizer
optim.vector.jacobian.GaussNewtonOptimizer
{noformat}
where
* the first sub-package ("scalar", "vector") indicates the kind of return value
of the (objective or model) function argument passed to "optimize", and
* the second sub-package ("noderiv", "gradient", "jacobian") indicates the kind
of return value of a second function argument passed to "optimize" referring to
the need to provide derivatives or not.
I'm still wondering whether we should add another level that would accommodate
the "linear" sub-package e.g.:
{noformat}
optim.linear.LinearOptimizer
optim.nonlinear.scalar. ...
optim.nonlinear.vector. ...
{noformat}
And where should the "fitting" sub-package go?
I could be viewed as a "client" of the "optim" package and since
"PolynomialFitter" also uses classes from another package, I'd suggest to
create a top-level (i.e. under "o.a.c.math3") package for it.
> New API for optimizers
> ----------------------
>
> Key: MATH-874
> URL: https://issues.apache.org/jira/browse/MATH-874
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 3.0
> Reporter: Gilles
> Assignee: Gilles
> Priority: Minor
> Labels: api-change
> Fix For: 3.1, 4.0
>
> Attachments: optimizers.patch
>
>
> I suggest to change the signatures of the "optimize" methods in
> * {{UnivariateOptimizer}}
> * {{MultivariateOptimizer}}
> * {{MultivariateDifferentiableOptimizer}}
> * {{MultivariateDifferentiableVectorOptimizer}}
> * {{BaseMultivariateSimpleBoundsOptimizer}}
> Currently, the arguments are
> * the allowed number of evaluations of the objective function
> * the objective function
> * the type of optimization (minimize or maximize)
> * the initial guess
> * optionally, the lower and upper bounds
> A marker interface:
> {code}
> public interface OptimizationData {}
> {code}
> would in effect be implemented by all input data so that the signature would
> become (for {{MultivariateOptimizer}}):
> {code}
> public PointValuePair optimize(MultivariateFunction f,
> OptimizationData... optData);
> {code}
> A [thread|http://markmail.org/message/fbmqrbf2t5pb5br5] was started on the
> "dev" ML.
> Initially, this proposal aimed at avoiding to call some optimizer-specific
> methods. An example is the "setSimplex" method in
> "o.a.c.m.optimization.direct.SimplexOptimizer": it must be called before the
> call to "optimize". Not only this departs form the common API, but the
> definition of the simplex also fixes the dimension of the problem; hence it
> would be more natural to pass it together with the other parameters (i.e. in
> "optimize") that are also dimension-dependent (initial guess, bounds).
> Eventually, the API will be simpler: users will
> # construct an optimizer (passing dimension-independent parameters at
> construction),
> # call "optimize" (passing any dimension-dependent parameters).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
