commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nikolaus Hansen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
Date Fri, 28 Sep 2012 16:39:07 GMT

    [ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465719#comment-13465719
] 

Nikolaus Hansen commented on MATH-867:
--------------------------------------

{quote}
I believe the reason is that defaulting sigma to 0.3 times the range causes the fitter to
jump from the initial value (which is order of 1 away from the target) to some huge value
on the order of 1e16 on the first step.
{quote}
Right. I suggest to make sigmaArray independent of the boundary values. Otherwise setting
boundaries like [1e-15,1e15] still will most likely lead to an unexpected behavior: the user
just does not want to exceed this value, while the algorithm interprets the interval as being
reasonable values to be checked out. Still it makes perfectly sense to check consistency between
the initial guess, sigmaArray and boundaries, in that, say, 

{code}
fitfun.encode(guess)[i] - sigmaArray[i]/2. > fitfun.encode(boundaries[0])[i] 
{code}

in case of a lower bound. 

{quote}
It doesn't reach the target exactly due to one of the many stop conditions hard-coded into
the generationLoop which decide that the fit is "good enough" and quit. 
{quote}
more specifically, stopTolX is defined relative to the initial value of sigmaArray. This specific
problem should therefore go away if stopTolX is defined as an absolute value like 1e-11. I
think absolute and relative definition of stopTolX are both justified. 

Generally, the patch becomes buggy, when encode and decode are changed/reused. In this case,
where solutions are compared with boundaries, like 

{code}
if(x[i] < boundaries[0][i])
{code}

the comparison must be done with encoded boundaries: 
{code}
encLboundaries = fitfun.encode(boundaries[0]); 
if (x[i] < encLboundaries[i])
{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: 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

Mime
View raw message