[
https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465521#comment-13465521
]
Gilles commented on MATH-867:
-----------------------------
I've tried Frank's proposal
[above|https://issues.apache.org/jira/browse/MATH-867?focusedCommentId=13461788&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13461788];
in the code, I only modified the "encode" and "decode" functions.
This made one unit test fail ("testConstrainedRosen").
I think that the test is partly incorrect in the tolerance setting and in the
selection of the starting point, but even with those changed, I get critically
different behaviours due to the "isActiveCMA" flag.
If "true", the solution is found with pretty good accuracy:
{noformat}
sol=[1.0000000029406888, 1.0000000045238486, 0.9999999996025084,
0.9999999959542569, 0.9999999988066054, 0.9999999956724651, 1.0000000008220962,
1.0000000011037358, 1.0000000004144547, 0.9999999946437816, 0.9999999977923537,
1.0000000007816154, 1.0000000164552258]
{noformat}
But when set to "false", the result is:
{noformat}
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]
{noformat}
Is this expected? If so, wouldn't it be safer to always set this flag to "true"
(thus removing it as a user input)?
If unexpected, does it indicate that other things must be changed in addition
to "encode"/"decode"?
> 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
