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

Gilles commented on MATH-428:
-----------------------------

I hadn't looked at "MultiDirectional.java"... :-(

I don't quite get what is going on inside its {{iterateSimplex}} method: It 
contains a loop that checks convergence, using the same convergence checker as 
in the loop within {{doOptimize}}! Why should the convergence criteria be the 
same?
If the checker is really the same, then this poses a problem (wrt the new 
design) since there is again a mix between optimization and simplex 
"management")...


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

Reply via email to