From issues-return-29757-apmail-commons-issues-archive=commons.apache.org@commons.apache.org Mon Oct 1 16:27:09 2012 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 0E417D8E9 for ; Mon, 1 Oct 2012 16:27:08 +0000 (UTC) Received: (qmail 57917 invoked by uid 500); 1 Oct 2012 16:27:08 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 57850 invoked by uid 500); 1 Oct 2012 16:27:08 -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 57841 invoked by uid 99); 1 Oct 2012 16:27:08 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Oct 2012 16:27:08 +0000 Date: Tue, 2 Oct 2012 03:27:08 +1100 (NCT) From: "Gilles (JIRA)" To: issues@commons.apache.org Message-ID: <647525183.148301.1349108828493.JavaMail.jiratomcat@arcas> In-Reply-To: <1136939261.110231.1348271287489.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (MATH-868) Default sigma for CMAESOptimizer is wrong when using bounds 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-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466912#comment-13466912 ] Gilles commented on MATH-868: ----------------------------- Quoting Nikolaus Hansen (from issue MATH-867): bq. Points beyond, say, startpoint + 10*sigma are not likely to be sampled in the beginning. and bq. Codes I write typically don't accept a default value for inputSigma, [...] I wonder whether it wouldn't be better to not have a default, i.e. deprecate the constructors that do not require the values to be specified. The situation is even worse, I see now, in that "inputSigma" should not be passed at all at construction because it depends on the number of parameters and on their scale (values of the upper and lower bounds), whereas the interface to the CM optimizers was designed to allow multiple "optimize" calls to the _same_ optimizer with * different functions (even with a different number of parameters), * different start points, * different boundaries. All these arguments are passed with the call to "optimize". Ideally the "inputSigma" argument should be specified at that level too. But it can't because it's not (and cannot be) part of the general interface. A solution to this API problem would be welcome for 4.0. > Default sigma for CMAESOptimizer is wrong when using bounds > ----------------------------------------------------------- > > Key: MATH-868 > URL: https://issues.apache.org/jira/browse/MATH-868 > Project: Commons Math > Issue Type: Bug > Reporter: Frank Hess > > The documentation suggests setting inputSigma to 1/3 the range you are fitting over. However, in CMAESOptimizer.initializeCMA() if boundaries are specified the sigmaArray is by default assigned a value of 0.3 divided by the range. If the user had specified the inputSigma to be 0.3 of the range (as suggested by the docs) then sigmaArray would have been assigned the value of 0.3. Thus, it looks like the 0.3 should not be divided by the range, only a user-specified inputSigma should get divided by the range. -- 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