[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931957#action_12931957
]
Gilles commented on MATH-439:
-----------------------------
I'm stuck because some of the classes do not seem to fit together in the same
package.
# {{LaguerreSolver}} has more {{solve}} methods than mandated by the interface
(for dealing with complex numbers).
# {{MullerSolver}} has a {{solve2}} method.
# {{NewtonSolver}} requires a {{DifferentiableUnivariateRealFunction}} argument
(which is a more stringent requirement than mandated by the interface).
Ideas for cleaning this up are welcome...
Other things which I noticed while working on this issue:
* What's the purpose of {{UnivariateRealSolverFactory}}?
* I don't think that the {{solve}} "shortcut" methods in
{{UnivariateRealSolverUtils}} are very safe. I'd rather have the package
documentation provide guidance about which solver to use than relying on some
"default" solver that is subject to change without notice.
> 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
>
>
> 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.
