Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4EB7E85B.2080506@free.fr>
Date: Mon, 07 Nov 2011 15:16:59 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] CMA-ES input sigma
References: <4EB7D60B.5080302@free.fr>
 <20111107132428.GK953@dusk.harfang.homelinux.org> <4EB7E044.5080607@free.fr>
In-Reply-To: <4EB7E044.5080607@free.fr>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Le 07/11/2011 14:42, Luc Maisonobe a �crit :
> Le 07/11/2011 14:24, Gilles Sadowski a �crit :
>> Hi Luc.
>>
>>> I am trying to use CMA-ES optimizer with simple boundaries.
>>> It seems the inputSigma parameter should be normalized as it is checked
>>> 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.
>>>
>>> What do you think about it ? Should we keep normalized inputSigma (end
>>> hence improve documentation so people know they have to normalize the
>>> value) or should we accept values in the same units as the other
>>> parameters and use "encode" to do the normalisation ?
>>>
>>> As far as I am concerned, I would prefer the second solution, i.e. keep
>>> normalization an internal implementation detail.
>>
>> I like implementation details.
> 
> OK, I'll do that.

Done in revision 1198741. I have created and resolved Jira issue 702 to
track the problem.

Luc

> 
>>
>>
>> Best regards,
>> Gilles
>>
>> P.S. Please don't forget that the "CMAESOptimizer" is not yet upgraded to
>>      use the new "optimize" API (for simple bounds); I intended to change
>>      that by next week.
> 
> Ah, thanks. This explain some strange behaviour I get. I will let you
> adapt this, for now I will simply set the boundaries both in the
> constructor and in the call to optimize. I guess the constructot will be
> changed later so the boundaries are set only in optimize, is this right ?
> 
> 
>>
>> P.P.S. If, by any chance, you could use your current work in order to expand
>>        the code coverage of the unit tests for "BOBYQAOptimizer", that would
>>        be most useful! [And this optimizer's API is ready for use.]
> 
> I'll try to do it. However the models I optimize are quite large and
> depend on an external library (Orekit, of course), so this will need
> much rework, so I'm afraid I will do it only if I encounter problems
> that need some debugging.
> 
> Luc
> 
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org