[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13467764#comment-13467764
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
And I have no idea how to improve the documentation...
{quote}
Here are my suggestions: Replace (several times)
{code}
* @param inputSigma Initial search volume; sigma of offspring objective
variables.
{code}
with
{code}
* @param inputSigma Initial standard deviations to sample new points from
startPoint
{code}
and
{code}
/**
* Individual sigma values - initial search volume. inputSigma determines
* the initial coordinate wise standard deviations for the search. Setting
* SIGMA one third of the initial search region is appropriate.
*/
{code}
with
{code}
/**
* Values in inputSigma define the initial coordinate-wise
* standard deviations for sampling new search points about
* startPoint.
* Setting inputSigma roughly to the predicted distance of
* startPoint to the actually desired optimum is appropriate.
* Small values for inputSigma induce the search to be more local
* and very small values are more likely to find a local optimum
* close to startPoint.
* Extremely small values will however lead to early termination.
*/
{code}
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Fix For: 3.1
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466199#comment-13466199
]
Nikolaus Hansen commented on MATH-867:
--
I second to make encode/decode the identity to address the bug. I don't even
see a different way to address it. Then, inputSigma/sigmaArray/insigma should
become independent of the boundary values (which seems consistent with the doc,
as long as encode/decode remains the identity).
my previous snippet must read
{code}
guess[i] - sigmaArray[i]/2. fitfun.encode(boundaries[0])[i]
{code}
because we have
{code}
final double[] guess = fitfun.encode(getStartPoint());
{code}
i.e. guess is an encoded initial guess.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466238#comment-13466238 ] Nikolaus Hansen commented on MATH-867: -- This issue's bug is not solved by v1 alone. The way how to check the boundaries in isFeasible and the method repair must be adapted to the encode/decode function, otherwise a more severe bug has been introduced (even if it would pass all tests). I agree that v1, along with corrected boundary checks, can solve the issue. However v2 makes the remaining modifications simpler. Besides, the testConstrainedRosen must not fail, definitely not! CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: MATH867_patch, Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466239#comment-13466239
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
Since in some previous comments, you indicated that boundaries do not
necessarily need to be taken into account inside the CMAES algorithm, a
possibility is to review the entire code, and remove all code related to
boundaries.
{quote}
I believe that this must be a misunderstanding. We do not need the
transformation into [0,1] (or any other transformation for that matter) to take
into account boundaries. But we need to possibly take into account the
boundaries within CMAES, if the returned solution is supposed to be in the
bounds.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466240#comment-13466240 ] Nikolaus Hansen commented on MATH-867: -- regarding the documentation of inputSigma: I don't see in what sense the doc says that it depends on the bounds. The doc says how it should be set (but this is a bit blurry, to the extend of how initial search volume and initial search region are interpreted) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: MATH867_patch, Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466246#comment-13466246
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
However v2 makes the remaining modifications simpler.
The problem is that we don't know what are the remaining modifications:
{quote}
I thought I knew...
{quote}we never got beyond to the point were both
testFitAccuracyDependsOnBoundary and testConstrainedRosen pass.
{quote}
the former, because inputSigma was not adapted appropriately, the latter
because the test against boundaries was not adapted appropriately.
{quote}
There are two different things:
1. Does the existence of constraints modify the search procedure is some way
(i.e. CMAES must know that it deals with boundaries)?
{quote}
yes. Otherwise it will sample and evaluation points outside the boundaries.
{quote}
2. Alternately, is it possible to pass a modified objective function (in which
the allowed range of the original objective function has been mapped to the
[-inf, +inf] interval) and have CMAES behave the same (i.e. find the same
solution)?
{quote}
probably not the same, but possibly reasonably well, unless the boundary is
mapped to (or close to) inf, which is likely to lead to unexpected results, if
the optimum is on (or close to) the boundary.
checking MultivariateFunctionPenaltyAdapter (which does not map the parameters,
rather computes a penalty), the answer is likely to be no, if the optimal
solution happens to be on (or very close to) the bound.
{quote}
regarding the documentation of inputSigma: I don't see in what sense the doc
says that it depends on the bounds.
Then what is initial search volume?
{quote}
the volume/region where points are likely to be sampled in the beginning of the
search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled
in the beginning.
{quote}
I interpret the doc as roughly saying 0.3 times the range. Perhaps this is
wrong, in which case it should be made clearer...
{quote}
I agree, it is not clear (I guess it was taken from another doc and slightly
changed context).
{quote}
We noticed that very small or very large values for sigma did not work; so
maybe we should say inputSigma must be of order 1 .
{quote}
no, it entirely depends on how far we expect the optimal solution to be from
the start solution. Putting it differently: one could rescale parameters by a
factor 1000 (say in one case it is km, in the other m), then one would need to
rescale inputSigma accordingly (which would not be in the order of one).
Codes I write typically don't accept a default value for inputSigma, basically
for this reason. I agree however that a value of 1 might often turn out OK.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466246#comment-13466246
]
Nikolaus Hansen edited comment on MATH-867 at 9/30/12 2:32 AM:
---
{quote}
However v2 makes the remaining modifications simpler.
The problem is that we don't know what are the remaining modifications:
{quote}
I thought I knew...
{quote}we never got beyond to the point were both
testFitAccuracyDependsOnBoundary and testConstrainedRosen pass.
{quote}
the former, because inputSigma was not adapted appropriately, the latter
because the test against boundaries was not adapted appropriately.
{quote}
There are two different things:
1. Does the existence of constraints modify the search procedure is some way
(i.e. CMAES must know that it deals with boundaries)?
{quote}
yes. Otherwise it will sample and evaluation points outside the boundaries.
{quote}
2. Alternately, is it possible to pass a modified objective function (in which
the allowed range of the original objective function has been mapped to the
[-inf, +inf] interval) and have CMAES behave the same (i.e. find the same
solution)?
{quote}
probably not the same, but possibly reasonably well, unless the boundary is
mapped to (or close to) inf, which is likely to lead to unexpected results, if
the optimum is on (or close to) the boundary.
checking MultivariateFunctionPenaltyAdapter (which does not map the parameters,
rather computes a penalty), the answer is likely to be no, if the optimal
solution happens to be on (or very close to) the bound. The methods developed
for CMA-ES should work much better in this case.
{quote}
regarding the documentation of inputSigma: I don't see in what sense the doc
says that it depends on the bounds.
Then what is initial search volume?
{quote}
the volume/region where points are likely to be sampled in the beginning of the
search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled
in the beginning.
{quote}
I interpret the doc as roughly saying 0.3 times the range. Perhaps this is
wrong, in which case it should be made clearer...
{quote}
I agree, it is not clear (I guess it was taken from another doc and slightly
changed context).
{quote}
We noticed that very small or very large values for sigma did not work; so
maybe we should say inputSigma must be of order 1 .
{quote}
no, it entirely depends on how far we expect the optimal solution to be from
the start solution. Putting it differently: one could rescale parameters by a
factor 1000 (say in one case it is km, in the other m), then one would need to
rescale inputSigma accordingly (which would not be in the order of one).
Codes I write typically don't accept a default value for inputSigma, basically
for this reason. I agree however that a value of 1 might often turn out OK.
was (Author: jolievie):
{quote}
However v2 makes the remaining modifications simpler.
The problem is that we don't know what are the remaining modifications:
{quote}
I thought I knew...
{quote}we never got beyond to the point were both
testFitAccuracyDependsOnBoundary and testConstrainedRosen pass.
{quote}
the former, because inputSigma was not adapted appropriately, the latter
because the test against boundaries was not adapted appropriately.
{quote}
There are two different things:
1. Does the existence of constraints modify the search procedure is some way
(i.e. CMAES must know that it deals with boundaries)?
{quote}
yes. Otherwise it will sample and evaluation points outside the boundaries.
{quote}
2. Alternately, is it possible to pass a modified objective function (in which
the allowed range of the original objective function has been mapped to the
[-inf, +inf] interval) and have CMAES behave the same (i.e. find the same
solution)?
{quote}
probably not the same, but possibly reasonably well, unless the boundary is
mapped to (or close to) inf, which is likely to lead to unexpected results, if
the optimum is on (or close to) the boundary.
checking MultivariateFunctionPenaltyAdapter (which does not map the parameters,
rather computes a penalty), the answer is likely to be no, if the optimal
solution happens to be on (or very close to) the bound.
{quote}
regarding the documentation of inputSigma: I don't see in what sense the doc
says that it depends on the bounds.
Then what is initial search volume?
{quote}
the volume/region where points are likely to be sampled in the beginning of the
search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled
in the beginning.
{quote}
I interpret the doc as roughly saying 0.3 times the range. Perhaps this is
wrong, in which case it should be made clearer...
{quote}
I agree, it is not clear (I guess it was taken from another doc and slightly
changed context).
{quote}
We noticed that very small or very large values
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466253#comment-13466253 ] Nikolaus Hansen commented on MATH-867: -- just another motivation: inputSigma is related to the uncertainty on getStartPoint(), as we cannot intrinsically know whether this is in the order of 1 or 1e-4 or 1e4 or 10e23. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: MATH867_patch, Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466297#comment-13466297
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
Revision 1391840 contains modified encode and decode functions. Both unit
tests now pass (for testConstrainedRosen I had to move the initial guess
closer to the solution).
{quote}
if the test does not pass with initial point at 0.1, something is wrong (and it
doesn't look like a good idea to change the test to make the code pass).
I found at least one problem:
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
for (int i = 0; i x.length; i++) {
if (x[i] 0) {
repaired[i] = 0;
} else if (x[i] 1.0) {
repaired[i] = 1.0;
} else {
repaired[i] = x[i];
}
}
return repaired;
}
{code}
must read
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
if (boundaries == null) {
for (int i = 0; i x.length; i++) {
repaired[i] = x[i];
}
} else {
final double[] bLoEnc = encode(boundaries[0]);
final double[] bHiEnc = encode(boundaries[1]);
for (int i = 0; i x.length; i++) {
if (x[i] bLoEnc[i]) {
repaired[i] = bLoEnc[i];
} else if (x[i] bHiEnc[i]) {
repaired[i] = bHiEnc[i];
}
}
}
return repaired;
}
{code}
I am not sure whether or not this is the reason why the test fails.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466308#comment-13466308
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
Revision 1391840 contains modified encode and decode functions. Both unit
tests now pass (for testConstrainedRosen I had to move the initial guess
closer to the solution).
No change was required for inputSigma; I still do not understand why it works
as is (cf. lines 588, 589).
{quote}
to me it makes perfectly sense: luckily enough line 589 performs the same
transformation on inputSigma as the encode function on getStartPoint() (maybe
this should be mentioned in a comment?). As the transformation is linear, the
situations before and after the transformations are mathematically equivalent
(the bug came from loosing digits due to a subtraction, which is now omitted).
As said before it would simplify the code if both transformations were omitted
(but we could leave this to another issue).
{quote}
And I have no idea how to improve the documentation...
{quote}
I'll think about it.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466297#comment-13466297
]
Nikolaus Hansen edited comment on MATH-867 at 9/30/12 7:52 AM:
---
{quote}
Revision 1391840 contains modified encode and decode functions. Both unit
tests now pass (for testConstrainedRosen I had to move the initial guess
closer to the solution).
{quote}
if the test does not pass with initial point at 0.1, something is wrong (and it
doesn't look like a good idea to change the test to make the code pass).
I found at least one problem:
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
for (int i = 0; i x.length; i++) {
if (x[i] 0) {
repaired[i] = 0;
} else if (x[i] 1.0) {
repaired[i] = 1.0;
} else {
repaired[i] = x[i];
}
}
return repaired;
}
{code}
must read
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
if (boundaries == null) {
for (int i = 0; i x.length; i++) {
repaired[i] = x[i];
}
} else {
final double[] bLoEnc = encode(boundaries[0]);
final double[] bHiEnc = encode(boundaries[1]);
for (int i = 0; i x.length; i++) {
if (x[i] bLoEnc[i]) {
repaired[i] = bLoEnc[i];
} else if (x[i] bHiEnc[i]) {
repaired[i] = bHiEnc[i];
} else {
repaired[i] = x[i];
}
}
}
return repaired;
}
{code}
I am not sure whether or not this is the reason why the test fails.
was (Author: jolievie):
{quote}
Revision 1391840 contains modified encode and decode functions. Both unit
tests now pass (for testConstrainedRosen I had to move the initial guess
closer to the solution).
{quote}
if the test does not pass with initial point at 0.1, something is wrong (and it
doesn't look like a good idea to change the test to make the code pass).
I found at least one problem:
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
for (int i = 0; i x.length; i++) {
if (x[i] 0) {
repaired[i] = 0;
} else if (x[i] 1.0) {
repaired[i] = 1.0;
} else {
repaired[i] = x[i];
}
}
return repaired;
}
{code}
must read
{code}
private double[] repair(final double[] x) {
double[] repaired = new double[x.length];
if (boundaries == null) {
for (int i = 0; i x.length; i++) {
repaired[i] = x[i];
}
} else {
final double[] bLoEnc = encode(boundaries[0]);
final double[] bHiEnc = encode(boundaries[1]);
for (int i = 0; i x.length; i++) {
if (x[i] bLoEnc[i]) {
repaired[i] = bLoEnc[i];
} else if (x[i] bHiEnc[i]) {
repaired[i] = bHiEnc[i];
}
}
}
return repaired;
}
{code}
I am not sure whether or not this is the reason why the test fails.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466309#comment-13466309
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
Hence, unless someone wants to try it out, we'll of course trust you and leave
the internal boundary handling in place.
{quote}
I spent several hundreds of hours (really!) to investigate (and try to
understand) this with the greatest care I was able to. That of course doesn't
mean there could be still surprises out there...
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466317#comment-13466317
]
Nikolaus Hansen commented on MATH-867:
--
I have corrected the repair: the last assignment
{code}
} else {
repaired[i] = x[i];
{code}
was missing (sorry). Now there is some chance that it might pass...
{quote}
I certainly agree. But since there was something wrong before in the code, one
could also imagine that it was because of the problem that it passed before...
{quote}
that seems somehow irrelevant: it is an absolute statement about the algorithm,
that an implementation of it must pass this test. It's not related to the
question when and why it has already been past or not.
otherwise, the code was, AFAICS, not wrong before unless with boundary values
as large as 1e16 in absolute value.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466319#comment-13466319
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
I would like to, but as I said, the identity transformation makes one of the
tests fail.
It must be because something else in the code assumes that the parameters have
been restricted into the [0, 1] interval, which is not true anymore.
{quote}
The reason is IMHO line 589, which does need to be changed according to the
change in encode/decode.
{quote}
I wonder whether the various matrices (around lines 380) are computed based on
this assumption...
{quote}
I would not worry much, I am pretty sure they are not.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466328#comment-13466328
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
I may be missing something (and I can just make wild guesses since I have no
clue about the CMAES algorithm) but I would be expecting that the code behaves
the same way without boundaries as with boundaries that become arbitrarily
large (i.e. when the [loBound, hiBound] interval becomes [-inf, +inf]).
The line that uses inputSigma does not behave that way since the range
becomes arbitrarily large as the bounds grow although when there is no
boundaries it is set 1.0.
{quote}
as both, x and sigma are transformed in the same way it does not matter
mathematically. If you choose boundaries as large as (close to) maxdouble, it
will matter numerically.
{quote}
This is also shown by some unit tests which I've just set up, by copying
existing ones which minimized a function without constraint and specifying a
very large allowed interval (e.g. [-1e20, 1e20]): those tests fail.
{quote}
did you correct the mistake in the repair method I proposed above?
{quote}
Intuitively, when the solution is far from the bounds (and the initial point
also), whether there are bounds or not should not matter. But with the current
implementation that's clearly not the case.
{quote}
I agree. I am confident we will be able to sort this out.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13466331#comment-13466331
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
And the two tests still fail.
{quote}
did you correct the bug in the repair method that I proposed above?
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465693#comment-13465693
]
Nikolaus Hansen commented on MATH-867:
--
{quote}
But when set to false, the result is:
sol=[0.997107074864516, 0.9942080214735094, 0.9884131718553784,
0.9768835748661846, 0.954143705394098, 0.910067297297918, 0.8275510138614142,
0.6833931486612853, 0.4636505565068948, 0.20554769008446425, 0.0,
0.009899135523990096, 0.0]
Is this expected?
{quote}
No! The code must pass this test with high probability.
CMAESOptimizer with bounds fits finely near lower bound and coarsely near
upper bound.
---
Key: MATH-867
URL: https://issues.apache.org/jira/browse/MATH-867
Project: Commons Math
Issue Type: Bug
Reporter: Frank Hess
Attachments: MATH867_patch, Math867Test.java
When fitting with bounds, the CMAESOptimizer fits finely near the lower bound
and coarsely near the upper bound. This is because it internally maps the
fitted parameter range into the interval [0,1]. The unit of least precision
(ulp) between floating point numbers is much smaller near zero than near one.
Thus, fits have much better resolution near the lower bound (which is mapped
to zero) than the upper bound (which is mapped to one). I will attach a
example program to demonstrate.
--
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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463721#comment-13463721 ] Nikolaus Hansen commented on MATH-867: -- the bug is not in the original code. In some CMA-ES codes, variable transformations are provided as an option (not in the one which was translated). This is however just meant as a convenience feature, as it could be equivalently implemented as part of the objective function (and should IMHO preferably viewed as such). This should IMHO be a general feature implemented in the optimization library, as the benefits of variable transformations are not tightly linked to any specific optimization method. It should be easily possible to drop the transformation in CMAESOptimizer, in which case 0 and 1 must be replaced by the lower and upper boundary values in some parts of the code. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463747#comment-13463747 ] Nikolaus Hansen commented on MATH-867: -- Why are variables transformations generally desirable? Because, for example, if a parameter x_i should only have positive values, the transformation x_i - x_i^2 makes the objective function compatible to any unbounded optimizer. Or, for example, rescaling of variables (e.g. unit m in km etc) can change an ill-conditioned problem to a well-conditioned one. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461853#comment-13461853 ] Nikolaus Hansen commented on MATH-867: -- I don't see anything wrong with the new version (the original version better facilitates the display of the evolution of variables in a single picture). It seems also clear where the original version fails: taking the difference in the above computation leads to a loss of significant digits if x[i] and boundaries[0][i] largely differ, that is, if the solution is far away from the lower bound. However the use of boundaries for a range like [0, 5e16] seems not reasonable to me and it was not meant to be used like that. More specifically, I don't see a good reason to set an upper bound of 5e16, in particular when the initial point is 1. I would expect a reasonable initial point to lie roughly in the middle of the search interval. If the variable is supposed to be as large as 5e16, it is likely advisable to apply a non-linear transformation, e.g. to optimization its logarithm. More general, when searching in an interval of size 1e16 using double precision, one can, in principle, hardly expect to get a solution with a precision better than, say, 10 in which case one has identified the optimum with 15 digits of precision. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461891#comment-13461891 ] Nikolaus Hansen commented on MATH-867: -- It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should support only applying a lower bound in some way. My suggestion would be indeed to have as interface boundaries and a unit-scale for each parameter (by default one). Only the latter would control the encoding, in the way suggested above as diff. Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) related to the unit-scale, which seem to be hidden from the user as it is now. You might think of this step-size as similar to the width of the initial simplex in NelderMead. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13461891#comment-13461891 ] Nikolaus Hansen edited comment on MATH-867 at 9/25/12 3:53 AM: --- It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should IMHO support only applying a lower bound in some way. Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) possibly in each coordinate. You might think of this step-size as similar to the width of the initial simplex in NelderMead. Choosing this step-size is equivalent to choosing a different diff-factor in the encoding as suggested above. was (Author: jolievie): It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should support only applying a lower bound in some way. My suggestion would be indeed to have as interface boundaries and a unit-scale for each parameter (by default one). Only the latter would control the encoding, in the way suggested above as diff. Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) related to the unit-scale, which seem to be hidden from the user as it is now. You might think of this step-size as similar to the width of the initial simplex in NelderMead. CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound. --- Key: MATH-867 URL: https://issues.apache.org/jira/browse/MATH-867 Project: Commons Math Issue Type: Bug Reporter: Frank Hess Attachments: Math867Test.java When fitting with bounds, the CMAESOptimizer fits finely near the lower bound and coarsely near the upper bound. This is because it internally maps the fitted parameter range into the interval [0,1]. The unit of least precision (ulp) between floating point numbers is much smaller near zero than near one. Thus, fits have much better resolution near the lower bound (which is mapped to zero) than the upper bound (which is mapped to one). I will attach a example program to demonstrate. -- 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-702) CMA-ES optimizer input sigma should not be normalized by user
I see, sorry for my ignorance. Even though I would prefer a different solution it does make sense, if the boundaries are meaningful in all variables. I am not so sure what you do if some variables don't have natural boundaries. On Tue, 08 Nov 2011 22:57:51 +0100, Luc Maisonobe (Commented) (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146597#comment-13146597 ] Luc Maisonobe commented on MATH-702: Does coordinate-wise means that each coordinate has its dedicated sigma ? If so, this is what I have set up. The sigma vector was already an array with the same dimension as both the state vector and the lower/upper bounds, so I have simply used upper[i] - lower[i] as a multiplication factor for sigma[i]. Does what I did make sense ? CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen
Re: [jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
unfortunately, the problem already arises with a linear coordinate-wise mapping: which coordinate gives the unit where sigma is defined on? from a practical viewpoint it is important to consider coordinate-wise non-linear mappings. Multidimensional mappings (e.g. with covariance) I have never been able to apply successfully. Cheers, Niko On Mon, 07 Nov 2011 21:00:51 +0100, Luc Maisonobe (Commented) (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145744#comment-13145744 ] Luc Maisonobe commented on MATH-702: You are right. for now, encoding/decoding is both liner only and hidden in a private inner class (FitnessFunction), so users only see simple bounds and inside these bounds the transform is linear. For sure if we come up with a different mapping, we will need to come up with a way to define also the mapping of covariance. One way would be to rely on the Jacobian, but it would be strange to propose mapping function and requiring them to be smooth while the goal function by itself could be highly non-smooth. So for now, the simple linear mapping seems sufficient to me, and would need improvement only if we change some internals of the class. CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen
[jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146592#comment-13146592 ] Nikolaus Hansen commented on MATH-702: -- unfortunately, the problem already arises with a linear coordinate-wise mapping: which coordinate gives the unit where sigma is defined on? from a practical viewpoint it is important to consider coordinate-wise non-linear mappings. Multidimensional mappings (e.g. with covariance) I have never been able to apply successfully. Cheers, Niko On Mon, 07 Nov 2011 21:00:51 +0100, Luc Maisonobe (Commented) (JIRA) -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
good point. However, if the encoding/decoding methods can be defined coordinate-wise differently or are even non-linear (I am not aware whether they can be or not), I am not sure you can come up with a sufficiently reasonable and comprehensible way to apply this transformation to sigma. sigma is a scalar and positive, so it is a different object than the encoding/decoding methods are operating on, right? The interplay between sigma and an encoding is an unfortunately delicate part in the user interface, but I don't really see a way to make it right *and* look entirely obvious to the user. On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA) j...@apache.org wrote: CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen
[jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145736#comment-13145736 ] Nikolaus Hansen commented on MATH-702: -- good point. However, if the encoding/decoding methods can be defined coordinate-wise differently or are even non-linear (I am not aware whether they can be or not), I am not sure you can come up with a sufficiently reasonable and comprehensible way to apply this transformation to sigma. sigma is a scalar and positive, so it is a different object than the encoding/decoding methods are operating on, right? The interplay between sigma and an encoding is an unfortunately delicate part in the user interface, but I don't really see a way to make it right *and* look entirely obvious to the user. On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA) -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933083#action_12933083 ] Nikolaus Hansen commented on MATH-442: -- I think the CMA-ES fits fine into to direct category (but I am familiar with the meaning of the word direct search, I don't assume everyone is). Nelder-Mead and CMA-ES are similar in that they do not need derivatives and they do not even need function values: they are comparison based and only use a ranking between a number of candidate solutions. Moreover, Nelder-Mead and CMA-ES share all their invariance properties (not many other optimization algorithms do). Being rank-based implies invariance under monotonous transformations of the objective function value, but there are others (e.g. invariance under coordinate system changes). I believe these are important properties, also from the application viewpoint. The main conceptional different to Nelder-Mead: CMA-ES is stochastic (randomized, if you like). The main practical difference: CMA-ES works also in large dimension and there is a control parameter for tuning the locality of search. You could have an elaborate discussion whether CMA-ES estimates a gradient. My take on it: methods that move opposite to the gradient will regularly fail anyway. I also find it strange that algorithms in the general category are in fact less general. Where can I subscribe to the list? CMA evolution strategy is missing in optimization - Key: MATH-442 URL: https://issues.apache.org/jira/browse/MATH-442 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Reporter: Dr. Dietmar Wolz Original Estimate: 48h Remaining Estimate: 48h Recently I implemented the optimization algorithm CMA-ES based on org.apache.commons.math.linear and used it for the GTOC5 global trajectory optimization contest http://gtoc5.math.msu.su/. It implements the MultivariateRealOptimizer interface and would nicely fit into the org.apache.commons.math.optimization package. The original author of CMA-ES (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the creation of a CMA-ES contribution for commons.math. The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a very powerful algorithm for difficult non-linear non-convex optimization problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for a comparison chart. If there is interest I will create a patch including the proposed Implementation for evaluation. It seems we would need an additional sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
