commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
Date Tue, 23 Nov 2010 15:58:19 GMT


Gilles commented on MATH-439:

I've recoded the algorithm in "BrentSolver" using the "zero" in Brent's book "Algorithms for
minimization without derivatives". I wanted to make sure that it was not something in there
that caused the problem; the code did not look like in the book and there was no code description
in the reference indicated in the Javadoc.
Unfortunately the {{testCircleFitting}} still fails in {{NonLinearConjugateGradientOptimizerTest}}.

Also with the new code, the {{testIllConditioned}} fails:
java.lang.AssertionError: expected:<-81.0> but was:<-80.80925624330811>

The tolerance in the "assert" is set to 1e-1, shall I raise it to 2e-1 ?
I'd like to keep the new implementation since it follows more closely the book; that would
make it easier for someone to check it in the future, in case another problem is encountered
that could be blamed on "BrentSolver" if it used in the underlying code. Is that OK?

So, I'm back to wondering whether the code in {{NonLinearConjugateGradientOptimizer}} is safe:
Could it be that it uses a solution provided by "BrentSolver" which it shouldn't? I mean:
If all the points in the search interval are equally good, what's the point in calling {{solve}}?

> Refactoring of solvers (package "analysis.solvers")
> ---------------------------------------------------
>                 Key: MATH-439
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Gilles
>            Priority: Minor
>             Fix For: 3.0
>         Attachments:
> The classes in package "analysis.solvers" could be refactored similarly to what was done
for package {{optimization}}.
> * Replace {{MaxIterationsExceededException}} with {{TooManyEvaluationsException}}:
> Apart from the class {{MaxIterationsExceededException}} being deprecated, this approach
makes it difficult to compare different algorithms: While the concept of iteration is algorithm-dependent,
the user is probably mostly interested in the number of function evaluations. 
> * Implement the method {{solve}} in the base class ({{UnivariateRealSolverImpl}}) and
define an abstract method {{doSolve}} to be implemented in derived classes. This method would
then use a new {{computeObjectiveFunction}} method that will take care of the counting of
the function evaluations.
> * Remove "protected" fields (the root is unnecessary since it is returned by {{solve}}).
Arguingly the function value is also not very useful (as we know what it should be), except
for debugging purposes (in which case, it might not be a problem to call the function's {{value}}
method once more).
> * Remove the tolerance setter (accuracy) and make the corresponding fields "final".

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

View raw message