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, 19 Aug 2010 09:39:17 GMT

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

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

Another source of confusion: in package "optimization", the terms "Scalar" and "Real" are
used to construct various class names (e.g. "MultivariateRealOptimizer" and "RealPointValuePair").
Since there is a "DifferentiableMultivariateVectorialOptimizer" counterpart, I think that
the correct term is "Scalar"; hence we should rename all the classes that use "Real" in that
sense.
For the classes in package "optimization", it's just one more step towards in the current
rationalizing of the code; however that could extend beyond it since the problem probably
stems from the naming of the "function" interfaces (in package "analysis"):
{{MultivariateRealFunction}} vs {{MultivariateVectorialFunction}}. This name change will trickle
down to many classes in all CM.

I'm for including this change in 3.0, together with going from a checked "FunctionEvaluationException"
to an unchecked one. We trail this checked exception (mandatory "throws" clauses) everywhere
without ever using the feature inside CM. We can easily decide, as a policy, that a function
evaluation problem will throw a new, unchecked,  "FunctionEvaluationException" (to be defined
in the "exception" package). This would hugely lighten the CM code and, for users of API v3,
it would just mean modifying one "import" statement (i.e. they won't have to touch any existing
try/catch blocks).


> 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