[
https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13529989#comment-13529989
]
Luc Maisonobe commented on MATH-874:
------------------------------------
I was trying to catch up the latest changes.
Here is what I understand:
* from an algorithms point of view, there are no change, the methods
from the former optimization package are still available both in
their original form and under the new package with a new API
* from a packaging point of view, everything as been reorganized
with a level for linearity or not, a level for dimension and
a level for derivation order
* from an API point of view, everything is packed in the OptimizationData
marker interface, and each level picks up the data it needs, ignores
the rest, and call the upper level optimize method which also does the
same
* there are no DerivativeStructure anymore but the user can use them
if it is worth using it for implementing the ModelFunction and
ModelFunctionJacobian classes
* all these changes have been committed and the former package is not deprecated
Did I understood correctly?
> 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: fitting.tar.gz, optimizers.patch, optim_linear.tar.gz,
> optim.tar.gz
>
>
> 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
