[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466243#comment-13466243
]
Gilles commented on MATH-867:
-----------------------------
bq. 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).
This was assumed; I only copied the "decode" function here, but the rest was
changed accordingly, and the result is as I described (and the same as obtained
by Frank, see above).
bq. However v2 makes the remaining modifications simpler.
The problem is that we don't know what are "the remaining modifications": we
never got beyond to the point were both "testFitAccuracyDependsOnBoundary" and
"testConstrainedRosen" pass.
bq. But we need to possibly take into account the boundaries within CMAES, if
the returned solution is supposed to be in the bounds.
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)?
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)?
In the second alternative, CM has adapter classes (e.g.
"MultivariateFunctionPenaltyAdapter") that handle the mapping (and
re-implementing it within each optimizer is an unnecessary source of bugs).
bq. 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"?
I interpret the doc as roughly saying "0.3 times the range". Perhaps this is
wrong, in which case it should be made clearer...
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" (?).
> 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
