Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 25 Sep 2012 02:20:07 +1100 (NCT)
From: "Nikolaus Hansen (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <958685564.116974.1348500007585.JavaMail.jiratomcat@arcas>
In-Reply-To: <681098766.110030.1348268048729.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits
 finely near lower bound and coarsely near upper bound.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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