commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-397) Inconsistencies between "optimization.univariate" and "optimization.general"
Date Wed, 28 Jul 2010 12:32:16 GMT

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

Luc Maisonobe commented on MATH-397:
------------------------------------

About ConvergingAlgorithm and ConvergenceChecker, I don't think there is a real overlap.
The first one is merely an interface for a complete algorithm whereas the second one is an
interface to be implemented by user (if our own implementations do not suit him) for one specific
problem. It is the way that was chosen to have general search algorithms that can be used
with problem-specific convergence conditions.

If however we consider there is an overlap and something difficult to understand, then ConvergingAlgorithm
should be the interface that could be removed and ConvergenceChecker is the important interface
that must be kept.

> 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