[
https://issues.apache.org/jira/browse/MATH-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923820#action_12923820
]
Gilles commented on MATH-428:
-----------------------------
Is the convergence check (within the {{iterateSimplex}} of
{{MultiDirectional}}) a safe-guard to prevent infinite looping? I.e. can it
happen that none of the preceding {{return}} statements gets ever reached,
whatever the number of iterations of the loop?
If so, maybe we could set a maximal number of iterations for that loop (a
constructor parameter), and let the optimizer check the convergence.
> Simplify "DirectSearchOptimizer"
> --------------------------------
>
> Key: MATH-428
> URL: https://issues.apache.org/jira/browse/MATH-428
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Assignee: Gilles
> Priority: Minor
> Fix For: 3.0
>
> Attachments: opt_direct.tar.gz
>
>
> This issue refers to classes in package {{optimization.direct}}.
> Currently the class {{NelderMead}} inherits from {{DirectSearchOptimizer}}.
> However the method {{doOptimize}} is implemented in
> {{DirectSearchOptimizer}}. This is backwards from the intended design (where
> an "optimizer" is defined as a class that implements a specific algorithm
> within {{doOptimize}}). According to this "terminology",
> {{DirectSearchOptimizer}} is the optimizer whereas {{NelderMead}} could be
> considered as a specific way to construct a simplex. Indeed, that's what
> seems intended since it overrides the abstract method {{iterateSimplex}}.
> I suggest to create 2 classes that will make it clear the separation between
> the "optimizer" and the "simplex manager".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
