Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <22926286.43771280320336394.JavaMail.jira@thor>
Date: Wed, 28 Jul 2010 08:32:16 -0400 (EDT)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-397) Inconsistencies between
 "optimization.univariate" and "optimization.general"
In-Reply-To: <5048089.25671280243956864.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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