[MATH-397] Inconsistencies between "optimization.univariate" and "optimization.general"

• Type: Improvement
• Status: Closed
• Priority: Minor
• Resolution: Duplicate
• Affects Version/s: 2.1
• Fix Version/s: 3.0
• Assignee: Gilles Sadowski
• Reporter: Gilles Sadowski
• Created: 27/Jul/10 15:18
• Updated: 24/Mar/12 16:16
• Resolved: 30/Aug/10 13:52

Description

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:

protected void incrementIterationsCounter()
    throws ConvergenceException {
    if (++iterationCount > maximalIterationCount) {
        throw new ConvergenceException(new MaxIterationsExceededException(maximalIterationCount));
    }
}

This is still not the best since in "BaseAbstractScalarOptimizer", we have

protected void incrementIterationsCounter()
    throws OptimizationException {
    if (++iterations > maxIterations) {
        throw new OptimizationException(new MaxIterationsExceededException(maxIterations));
    }
}

(thus: two codes for the same problem, throwing different exceptions).

Then it seems that there is also a functionality overlap between "ConvergingAlgorithm" and "ConvergenceChecker"...

Issue Links

• is part of: MATH-413 Miscellaneous issues concerning the "optimization" package