[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932149#action_12932149
]
Luc Maisonobe commented on MATH-439:
------------------------------------
The specific solve methods, despite not being in the interface, correspond to
additional specialized behavior. This is part of the added value each solver
provides and some users may really depend on them. This means that for example
a user who does have a differentiable function can directly use a Newton solver
and will not use the general interface. This is fine to me.
I'm not sure the factory is still useful now, but have no clear idea on this.
The utils method may be useful for users who don't have stringent needs on the
method and simply want the current best one, even if it changes when new
versions of the library appears. This is of course a completely different use
case than the one explained above for Newton solver.
If an abstract method can be used to share common code for some solvers, then
it is interesting to add it. If not all solvers fit in this designs, then it is
fine to have some solvers not extending the common abstract class and directly
implement the interface in their own specialized way.
> 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.
