Return-Path: X-Original-To: apmail-commons-issues-archive@minotaur.apache.org Delivered-To: apmail-commons-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7B433D0EB for ; Wed, 26 Sep 2012 11:30:15 +0000 (UTC) Received: (qmail 92644 invoked by uid 500); 26 Sep 2012 11:30:15 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 92265 invoked by uid 500); 26 Sep 2012 11:30:09 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 91923 invoked by uid 99); 26 Sep 2012 11:30:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Sep 2012 11:30:07 +0000 Date: Wed, 26 Sep 2012 22:30:07 +1100 (NCT) From: "Nikolaus Hansen (JIRA)" To: issues@commons.apache.org Message-ID: <725285670.127840.1348659007669.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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463721#comment-13463721 ] Nikolaus Hansen commented on MATH-867: -------------------------------------- the "bug" is not in the original code. In some CMA-ES codes, variable transformations are provided as an option (not in the one which was translated). This is however just meant as a convenience feature, as it could be equivalently implemented as part of the objective function (and should IMHO preferably viewed as such). This should IMHO be a general feature implemented in the optimization library, as the benefits of variable transformations are not tightly linked to any specific optimization method. It should be easily possible to drop the transformation in CMAESOptimizer, in which case 0 and 1 must be replaced by the lower and upper boundary values in some parts of the 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: 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