[ https://issues.apache.org/jira/browse/MATH867?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13466222#comment13466222
]
Gilles edited comment on MATH867 at 9/30/12 12:40 AM:

I don't understand. This is the documentation:
{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.
*/
private double[] inputSigma;
{code}
AFAIUC, this says that sigma is _not_ independent on the boundary values.
bq. I second to make encode/decode the identity to address the bug.
I also don't understand this. Referring to the code of "decode":
{code}
public double[] decode(final double[] x) {
if (boundaries == null) {
return x;
}
double[] res = new double[x.length];
for (int i = 0; i < x.length; i++) {
double diff = boundaries[1][i]  boundaries[0][i];
// res[i] = diff * x[i] + boundaries[0][i]; // XXX orig
// res[i] = diff * x[i]; // XXX v1
res[i] = x[i]; // XXX v2
}
return res;
}
{code}
_This_ issue's bug is solved by normalizing the variables (line marked with "XXX v1" in the
above snippet). The downside is that "testConstrainedRosen" fails.
When "decode" is made the identity (line marked with "XXX v2"), "testConstrainedRosen" passes
but "testFitAccuracyDependsOnBoundary" fails, as with the original code (line marked with
"XXX orig").
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.
Would you (or Frank) be willing to do that? In the affirmative, a new issue must be created
for that task.
Then, the "encode"/"decode" functions will disappear (by design) and so will the issue about
"inputSigma".
Unit tests "testConstrainedRosen" and "testFitAccuracyDependsOnBoundary" will also be removed
since the internal support form boundaries won't exist anymore.
All issues solved in one fell swoop! :)
was (Author: erans):
I don't understand. This is the documentation:
{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.
*/
private double[] inputSigma;
{code}
AFAIUC, this says that sigma is _not_ independent on the boundary values.
bq. I second to make encode/decode the identity to address the bug.
I also don't understand this. Referring to the code of "decode":
{code}
public double[] decode(final double[] x) {
if (boundaries == null) {
return x;
}
double[] res = new double[x.length];
for (int i = 0; i < x.length; i++) {
double diff = boundaries[1][i]  boundaries[0][i];
// res[i] = diff * x[i] + boundaries[0][i]; // XXX orig
// res[i] = diff * x[i]; // XXX v1
res[i] = x[i]; // XXX v2
}
return res;
}
{code}
_This_ issue's bug is solved by normalizing the variables (line marked with "XXX v1" in the
above snippet). The downside is that "testConstrainedRosen" fails.
When "decode" is made the identity (line marked with "XXX v2"), "testConstrainedRosen" passes
but "testFitAccuracyDependsOnBoundary" fails, as with the original code (line marked with
"XXX orig").
> CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
> 
>
> Key: MATH867
> URL: https://issues.apache.org/jira/browse/MATH867
> 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
