[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934869#action_12934869
]
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:
{noformat}
java.lang.AssertionError: expected:<-81.0> but was:<-80.80925624330811>
{noformat}
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: https://issues.apache.org/jira/browse/MATH-439
> Project: Commons Math
> Issue Type: Improvement
> Reporter: Gilles
> Priority: Minor
> Fix For: 3.0
>
> Attachments: AbstractUnivariateRealSolver.java
>
>
> 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.
