You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2012/10/07 19:56:02 UTC
[jira] [Created] (MATH-874) New API for optimizers
Gilles created MATH-874:
---------------------------
Summary: 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
Fix For: 3.1, 4.0
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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483251#comment-13483251 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
Reading again my previous comment, I think it doesn't clearly answers your question.
So to summarize, I would say no, it is not possible to merge the two methods further. They are already merged as much as possible (and at the end call the same optimizeInternal method).
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483314#comment-13483314 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
Oh, sorry, I did not understand it this way.
As long as we accept that a converted function is limited to what was already in the initial function (i.e. only first order derivatives) and will trigger exception if used outside of these limitations, then yes it would be possible.
The optimizers we use now are guaranteed to not ask for higher order derivatives, so this is probably acceptable as a temporary converter. Of course, if we introduce later algorithms that need second order derivatives (I think some of them require the Hessian), then this converter would not be sufficient and the users would need to implement by themselves the DerivativeStructure method properly to provide these derivatives.
I'll have a look at setting up the converter.
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475483#comment-13475483 ]
Gilles commented on MATH-874:
-----------------------------
Revision 1397759: New API applied to "SimplexOptimizer".
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471782#comment-13471782 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
After thinking about it for a while, I am alomst convinced by this approach.
Let's give it a try.
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478984#comment-13478984 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
bq. OK to upgrade the "optimize" method in "AbstractDifferentiableOptimizer" (and in package "o.a.c.m.optimization.general")?
Yes.
> 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
[jira] [Updated] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles updated MATH-874:
------------------------
Attachment: optimizers.patch
Attached a patch with some of the proposed changes.
The common "OptimizationData" parameters (number of evaluations, optimization type, initial guess) are handled in the base class; the specific ones are handled in the optimizer that requires it (e.g. "AbstractSimplex" for "SimplexOptimizer").
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483231#comment-13483231 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
Well, in fact there is not really new CM code here, only a small glue code. The code that really changes, is user code...
What changes is how users provided the Jacobian. With the former API, the user had to provide two interlinked implementation. An implementation of the DifferentiableMultivariateVectorFunction interface, which itself was a mean to retrieve an implementation of the MultivariateMatrixFunction interface. These two implementations had to be in different classes, as they both defined a method named "value" and having a single double[] parameter, one method returning a double[] and the other returning a double[][]. A common way to do this was to use a top level class for one interface and an internal class for the second interface.
With the newer API, users provide a single class implementing two functions. The first function is the same as in the former API and computes the value only. The second function is able to merge value, the Jacobian and in fact could also provide higher order derivatives or derivatives with respect to other variables if this function were appended after other functions.
The optimizers do handle both cases in the same way after the initialization. With the former API, the optimizer stores a reference to both users objects (the one returning double[] and the one returning double[][]). In the newer API, the optimizer stores a reference to the user object and a reference to a wrapper around the user object that extract the Jacobian from the second method. The underlying optimization engine is exactly the same.
What it means for users is the following:
* the part of user code dedicated to set up and call the optimizer is not changed at all
* the part of user code dedicated to compute the function value is not changed at all
* the part of user code dedicated to compute the function Jacobian is changed
For closed form functions, the changes to Jacobians computation is in fact a simplification. Users are not required to apply the chain rules by themselves, they simply have to change double variables into DerivativeStructure variables and change accordingly the +, -, * ... operators into calls to add, subtract, multiply ...
Here is an example, reworked from the unit tests:
{code:title=FormerAPI}
public class Brown implements DifferentiableMultivariateVectorFunction {
public double[] value(double[] variables) {
double[] f = new double[m];
double sum = -(n + 1);
double prod = 1;
for (int j = 0; j < n; ++j) {
sum += variables[j];
prod *= variables[j];
}
for (int i = 0; i < n; ++i) {
f[i] = variables[i] + sum;
}
f[n - 1] = prod - 1;
return f;
}
public MultivariateMatrixFunction jacobian() {
return new Internal();
}
private class Internal implements MultivariateMatrixFunction {
public double[][] value(double[] variables) {
double[][] jacobian = new double[m][];
for (int i = 0; i < m; ++i) {
jacobian[i] = new double[n];
}
double prod = 1;
for (int j = 0; j < n; ++j) {
prod *= variables[j];
for (int i = 0; i < n; ++i) {
jacobian[i][j] = 1;
}
jacobian[j][j] = 2;
}
for (int j = 0; j < n; ++j) {
double temp = variables[j];
if (temp == 0) {
temp = 1;
prod = 1;
for (int k = 0; k < n; ++k) {
if (k != j) {
prod *= variables[k];
}
}
}
jacobian[n - 1][j] = prod / temp;
}
return jacobian;
}
}
}
{code}
{code:title=NewerAPI}
public class Brown implements MultivariateDifferentiableVectorFunction {
public double[] value(double[] variables) {
double[] f = new double[m];
double sum = -(n + 1);
double prod = 1;
for (int j = 0; j < n; ++j) {
sum += variables[j];
prod *= variables[j];
}
for (int i = 0; i < n; ++i) {
f[i] = variables[i] + sum;
}
f[n - 1] = prod - 1;
return f;
}
public DerivativeStructure[] value(DerivativeStructure[] variables) {
DerivativeStructure[] f = new DerivativeStructure[m];
DerivativeStructure sum = variables[0].getField().getZero().subtract(n + 1);
DerivativeStructure prod = variables[0].getField().getOne();
for (int j = 0; j < n; ++j) {
sum = sum.add(variables[j]);
prod = prod.multiply(variables[j]);
}
for (int i = 0; i < n; ++i) {
f[i] = variables[i].add(sum);
}
f[n - 1] = prod.subtract(1);
return f;
}
}
{code}
You can note that with the newer API, creating the second method (with DerivativeStructure) from the first method (with double), is straightforward. It is mainly copy/paste then change the variable types and fix all operators calls (and this is what Commons Nabla attempts to do automatically at bytecode level).
> 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
[jira] [Updated] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13475482#comment-13475482 ]
Gilles commented on MATH-874:
-----------------------------
Revision 1397758: Marker interface and modification of the "BaseAbstractMultivariateOptimizer" class.
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483647#comment-13483647 ]
Gilles commented on MATH-874:
-----------------------------
Thanks a lot!
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476100#comment-13476100 ]
Gilles commented on MATH-874:
-----------------------------
Revision 1398263: Simple bounds as a kind of "OptimizationData".
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471347#comment-13471347 ]
Gilles commented on MATH-874:
-----------------------------
Of course we could also leave the "maxEval" and "goalType" parameters as they are (i.e. not implementing "OptimizationData").
The real simplification is that passing the simplex (for "SimplexOptimizer"), the sigmas (for "CMAESOptimizer", see MATH-868 and MATH-872), and the boundaries can be done with the same API (no overloading and no additional setter methods).
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478914#comment-13478914 ]
Gilles commented on MATH-874:
-----------------------------
OK to upgrade the "optimize" method in "AbstractDifferentiableOptimizer" (and in package "o.a.c.m.optimization.general")?
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509843#comment-13509843 ]
Gilles commented on MATH-874:
-----------------------------
Moreover, as Luc proposed, the prototype of the "optimize" methods will be changed so that derivative-based algorithm will take two separate arguments (one for the value or vector value function, the other for the gradient or Jacobian function), instead of the deprecated "DifferentiableMultivariateFunction" and "DifferentiableMultivariateVectorFunction".
> 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
[jira] [Updated] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles updated MATH-874:
------------------------
Fix Version/s: (was: 3.1)
Rest of the cleanup must be postponed to the preparation of version 4.0 (next major release).
> 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: 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479967#comment-13479967 ]
Gilles commented on MATH-874:
-----------------------------
I noticed that "o.a.c.m.optimization.AbstractLeastSquaresOptimizer" contains two versions of "optimize", one with the deprecated "DifferentiableMultivariateVectorFunction" and the other with the new "MultivariateDifferentiableVectorFunction".
Would it be possible to create a temporary converter from the deprecated one to the new one (like you did for "DifferentiableUnivariateFunction"), so that we could redirect the old "optimize" to the new one?
This would ensure that the new CM code is called in 3.1 without users having to change their code.
> 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
[jira] [Commented] (MATH-874) New API for optimizers
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483511#comment-13483511 ]
Luc Maisonobe commented on MATH-874:
------------------------------------
I have implemented the converters in the subversion repository as of r1401837 and use them in the optimizers as you suggested as of r1401838.
> 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