Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 24 Oct 2012 15:36:14 +0000 (UTC)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <942916286.22237.1351092974893.JavaMail.jiratomcat@arcas>
In-Reply-To: <623444440.6729.1349632562849.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (MATH-874) New API for optimizers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Luc Maisonobe commented on MATH-874:
------------------------------------

Oh, sorry, I did not understand it this way.

As long as we accept that a converted function is limited to what was already in the initial function (i.e. only first order derivatives) and will trigger exception if used outside of these limitations, then yes it would be possible.

The optimizers we use now are guaranteed to not ask for higher order derivatives, so this is probably acceptable as a temporary converter. Of course, if we introduce later algorithms that need second order derivatives (I think some of them require the Hessian), then this converter would not be sufficient and the users would need to implement by themselves the DerivativeStructure method properly to provide these derivatives.

I'll have a look at setting up the converter.
                
> New API for optimizers
> ----------------------
>
>                 Key: MATH-874
>                 URL: https://issues.apache.org/jira/browse/MATH-874
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 3.0
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>              Labels: api-change
>             Fix For: 3.1, 4.0
>
>         Attachments: optimizers.patch
>
>
> I suggest to change the signatures of the "optimize" methods in
> * {{UnivariateOptimizer}}
> * {{MultivariateOptimizer}}
> * {{MultivariateDifferentiableOptimizer}}
> * {{MultivariateDifferentiableVectorOptimizer}}
> * {{BaseMultivariateSimpleBoundsOptimizer}}
> Currently, the arguments are
> * the allowed number of evaluations of the objective function
> * the objective function
> * the type of optimization (minimize or maximize)
> * the initial guess
> * optionally, the lower and upper bounds
> A marker interface:
> {code}
> public interface OptimizationData {}
> {code}
> would in effect be implemented by all input data so that the signature would become (for {{MultivariateOptimizer}}):
> {code}
> public PointValuePair optimize(MultivariateFunction f,
>                                OptimizationData... optData);
> {code}
> A [thread|http://markmail.org/message/fbmqrbf2t5pb5br5] was started on the "dev" ML.
> Initially, this proposal aimed at avoiding to call some optimizer-specific methods. An example is the "setSimplex" method in "o.a.c.m.optimization.direct.SimplexOptimizer": it must be called before the call to "optimize". Not only this departs form the common API, but the definition of the simplex also fixes the dimension of the problem; hence it would be more natural to pass it together with the other parameters (i.e. in "optimize") that are also dimension-dependent (initial guess, bounds).
> Eventually, the API will be simpler: users will
> # construct an optimizer (passing dimension-independent parameters at construction),
> # call "optimize" (passing any dimension-dependent parameters).

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