commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (MATH-868) Default sigma for CMAESOptimizer is wrong when using bounds
Date Mon, 01 Oct 2012 16:27:08 GMT


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.


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:
>             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:

View raw message