[
https://issues.apache.org/jira/browse/MATH-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13478931#comment-13478931
]
Gilles commented on MATH-868:
-----------------------------
Coming back to the issue the default value for sigma.
Currently, it is thus still 0.3 but IIUC, this might be a very bad default if
the range of the parameters is large and the initial guess is far from the
optimum (cf. Nikolaus's advice that it should be about one third of the initial
search volume).
Nikolaus also mentioned that providing a default might simply not be a good
idea at all.
Hence I'd suggest that if "inputSigma" is null, an exception be thrown (instead
of making up a possibly meaningless default).
Unfortunately, that will break some applications (if they use the constructors
without the "inputSigma" argument). Could the current behaviour (not specifying
"inputSigma") be considered buggy enough to warrant a compatibility breaking?
> 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
