commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-873) "maxIterations" specification in "CMAESOptimizer"
Date Wed, 10 Oct 2012 15:03:02 GMT

    [ 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

Mime
View raw message