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-397) Inconsistencies between "optimization.univariate" and "optimization.general"
Date Thu, 12 Aug 2010 12:31:16 GMT

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

Gilles commented on MATH-397:
-----------------------------

Actually, I think that the idea of "IterativeAlgorithm" is not useful, in the context of optimization,
since it's internal to an algorithm's implementation and its meaning is algorithm-dependent:
the objective measure of control is the number of evaluations. Hence I think that the maximal
number of iterations should not be settable.
What should be part of the user-interface are methods for:
* setting maximal number of evaluations,
* getting the number of evaluations used.

I don't know what name to give to such an interface. Ideas?

Then, for algorithms that use the gradient, should the number gradient evaluations be considered
as a separate setting or should it increment the same counter as the function evaluation?
 If the setting is used to compare the performance of various algorithms, I think that a combined
counter should be preferred.


> Inconsistencies between "optimization.univariate" and "optimization.general"
> ----------------------------------------------------------------------------
>
>                 Key: MATH-397
>                 URL: https://issues.apache.org/jira/browse/MATH-397
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 2.1
>            Reporter: Gilles
>            Assignee: Gilles
>            Priority: Minor
>             Fix For: 2.2
>
>
> I think that we could make the usage (from the developer's point-of-view) of "optimization.univariate"
more similar to what is done in "optimization.general". At first this looked like a small
change but then I discovered that "AbstractUnivariateRealOptimizer" competes with "ConvergingAlgorithmImpl"
for some functionality, and that everything could be more coherent by enforcing the use of
accessors and avoiding "protected" fields.
> Moreover the logic inside  "AbstractUnivariateRealOptimizer" seems convoluted and one
change leading to another...
> Currently only "BrentOptimizer" inherits from "AbstractUnivariateRealOptimizer", so I
hope that it's OK to revise that class.
> In "ConvergingAlgorithmImpl", I propose to add a method:
> {code}
> protected void incrementIterationsCounter()
>     throws ConvergenceException {
>     if (++iterationCount > maximalIterationCount) {
>         throw new ConvergenceException(new MaxIterationsExceededException(maximalIterationCount));
>     }
> }
> {code}
> This is still not the best since in "BaseAbstractScalarOptimizer", we have
> {code}
> protected void incrementIterationsCounter()
>     throws OptimizationException {
>     if (++iterations > maxIterations) {
>         throw new OptimizationException(new MaxIterationsExceededException(maxIterations));
>     }
> }
> {code}
> (thus: two codes for the same problem, throwing different exceptions).
> Then it seems that there is also a functionality overlap between "ConvergingAlgorithm"
and "ConvergenceChecker"...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message