You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2012/10/10 17:03:02 UTC

[jira] [Commented] (MATH-873) "maxIterations" specification in "CMAESOptimizer"

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

Gilles commented on MATH-873:
-----------------------------

The piece of code which I find disturbing is at lines 559-563:
{code}
        damps = (1. + 2. * Math.max(0, Math.sqrt((mueff - 1.) /
                (dimension + 1.)) - 1.)) *
                Math.max(0.3, 1. - dimension /
                        (1e-6 + Math.min(maxIterations, getMaxEvaluations() /
                                lambda))) + cs; // minor increment

{code}

IMO, "getMaxEvaluations()" is out-of-place here, since it modifies the algorithm _behaviour_ whereas the API's intended behaviour is to limit processing time (assuming that function evaluation is the most expensive part of the computation).

If it's really the case, it should be made clear in the doc that "maxIterations" is not purely a counter, but modifies the algorithm's behaviour, and how the 2 (non-exceptional) stopping criteria ("maxIterations" and "stopFitness") play together.


                
> "maxIterations" specification in "CMAESOptimizer"
> -------------------------------------------------
>
>                 Key: MATH-873
>                 URL: https://issues.apache.org/jira/browse/MATH-873
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: Gilles
>            Assignee: Gilles
>             Fix For: 3.1, 4.0
>
>
> The API to the optimizers assumes that the _iterative_ nature of the process is controlled by specifying a number of allowed function evaluations. This parameter is passed to the "optimize" method.
> In "CMAESOptimizer", there is an additional parameter, "maxIterations", that serves a similar purpose (i.e. avoiding that the code runs "forever").
> There are also convergence criteria (an "internal" one, based on fitness, and an "external" one, given through a user-defined convergence checker).
> It seems that the ideal termination is when convergence is achieved before reaching the maximal count (be it iterations or function evaluations).
> In the current implementation, the algorithm terminates without raising an exception and a "solution" is always returned at the end of the "generation loop", even if it fails to meet any of the convergence criteria.

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