commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] CMA-ES input sigma
Date Mon, 07 Nov 2011 14:16:59 GMT
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.


>> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message