[
https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483278#comment-13483278
]
Gilles commented on MATH-874:
-----------------------------
My question was related to what happens before any specifics of the optimizer
code (base class included).
In "FunctionUtils", you created a converter:
{code}
public static UnivariateDifferentiableFunction toUnivariateDifferential(final
DifferentiableUnivariateFunction f) {
// ...
}
{code}
(With the nice consequence that old user code can be transparently transformed
(in CM) and passed to the new API.)
I was asking whether the same kind of converter could be written for the vector
function (from the type used in the old, now deprecated, optimizer API to the
new type):
{code}
public static MultivariateDifferentiableVectorFunction
toMultivariateDifferentiableVectorFunction(DifferentiableMultivariateVectorFunction
f) {
// ???
}
{code}
With this converter, the deprecated method in "AbstractLeastSquaresOptimizer"
(lines 302-322):
{code}
@Deprecated
public PointVectorValuePair optimize(int maxEval,
final
DifferentiableMultivariateVectorFunction f,
final double[] target, final double[]
weights,
final double[] startPoint) {
// Reset counter.
jacobianEvaluations = 0;
// Store least squares problem characteristics.
jF = f.jacobian();
// Arrays shared with the other private methods.
point = startPoint.clone();
rows = target.length;
cols = point.length;
weightedResidualJacobian = new double[rows][cols];
this.weightedResiduals = new double[rows];
cost = Double.POSITIVE_INFINITY;
return optimizeInternal(maxEval, f, target, weights, startPoint);
}
{code}
can be transformed into
{code}
@Deprecated
public PointVectorValuePair optimize(int maxEval,
final
DifferentiableMultivariateVectorFunction f,
final double[] target, final double[]
weights,
final double[] startPoint) {
return optimize(maxEval,
FunctionUtils.toMultivariateDifferentiableVectorFunction(f),
target,
weights,
startPoint);
}
{code}
By which I mean that old user code will automatically use the new
{{DerivativeStructure}} API.
> 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
