Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
References: 
 <229269020.6606.1320673731884.JavaMail.tomcat@hel.zones.apache.org>
Subject: Re: [jira] [Created] (MATH-702) CMA-ES optimizer input sigma should
 not be normalized by user
To: issues@commons.apache.org, "Luc Maisonobe (Created) (JIRA)"
 <jira@apache.org>
From: "Nikolaus Hansen" <Nikolaus.Hansen@lri.fr>
Date: Mon, 07 Nov 2011 19:45:30 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
Message-ID: <op.v4lc54awkzty10@hn-mba-2.local>
In-Reply-To: 
 <229269020.6606.1320673731884.JavaMail.tomcat@hel.zones.apache.org>
User-Agent: Opera Mail/11.52 (MacIntel)

good point. However, if the encoding/decoding methods can be defined
coordinate-wise differently or are even non-linear (I am not aware wheth=
er
they can be or not), I am not sure you can come up with a sufficiently
reasonable and comprehensible way to apply this transformation to sigma.=

sigma is a scalar and positive, so it is a different object than the
encoding/decoding methods are operating on, right?

The interplay between sigma and an encoding is an unfortunately delicate=

part in the user interface, but I don't really see a way to make it righ=
t
*and* look entirely obvious to the user.


On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA)
<jira@apache.org> wrote:

> CMA-ES optimizer input sigma should not be normalized by user
> -------------------------------------------------------------
>
>                  Key: MATH-702
>                  URL: https://issues.apache.org/jira/browse/MATH-702
>              Project: Commons Math
>           Issue Type: Bug
>     Affects Versions: 3.0
>             Reporter: Luc Maisonobe
>             Priority: Minor
>              Fix For: 3.0
>
>
> I am trying to use CMA-ES optimizer with simple boundaries.
>
> It seems the inputSigma parameter should be normalized as it is checke=
d  =

> against the [0 - 1] range in the checkParameters private method and as=
  =

> its value defaults to 0.3 if not not set in the initializeCMA private =
 =

> method.
>
> I would have expected this value to be in the same units as the user  =

> parameters and to be normalized as part of an internal processing step=
  =

> instead of relying to the user doing this. I think the method need  =

> normalized values internally, as per the encode/decode methods in the =
 =

> inner class FitnessFunction suggest.
>
> The optimizer should accept values in the same units as the other  =

> parameters and use "encode" (or a similar function) to do the  =

> normalization. This way, normalization is considered an internal  =

> implementation detail.
>
>
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA  =

> administrators:  =

> https://issues.apache.org/jira/secure/ContactAdministrators!default.js=
pa
> For more information on JIRA, see: http://www.atlassian.com/software/j=
ira
>
>


-- =

Science is a way of trying not to fool yourself.

The first principle is that you must not fool yourself, and you
are the easiest person to fool. So you have to be very careful
about that. After you've not fooled yourself, it's easy not to
fool other[ scientist]s. You just have to be honest in a
conventional way after that.
                                         -- Richard P. Feynman

Nikolaus Hansen
INRIA, Research Centre Saclay =E2=80=93 Ile-de-France
Machine Learning and Optimization group (TAO)
University Paris-Sud (Orsay)
LRI (UMR 8623), building 490
91405 ORSAY Cedex, France
Phone: +33-1-691-56495, Fax: +33-1-691-54240
URL: http://www.lri.fr/~hansen