[ 
https://issues.apache.org/jira/browse/MATH-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466912#comment-13466912
 ] 

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.

and

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

Reply via email to