[ https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932232#action_12932232 ]
Gilles commented on MATH-439: ----------------------------- I'm not an "interface" fanatic, meaning that everything should have its {code} interface Something { // ... } {code} together with a {code} public class SomethingImpl { // ... } {code} Especially when there is a single best way to implement the "Something". In that sense, I find the {{UnivariateRealSolveFactory}} and its associated {{UnivariateRealSolveFactoryImpl}} quite clumsy (the more so that the former is not even an interface). However, in the {{UnivariateRealSolver}} case, I find it completely appropriate that the interface should be an exact image of the full behaviour of the implementing classes. If not, it has no purpose from a programming design viewpoint. For example, in the {{optimization}} package, there is a specialized interface for optimizers that rely on differentiability of the objective function. It should be the same here for the {{NewtonSolver}}. Similarly, there are also separate interfaces for scalar and vectorial functions; so for the solvers too, we should find a design that clearly distinguish between real solvers and complex solvers. > 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.