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 Mon, 15 Nov 2010 22:28:13 GMT


Gilles commented on MATH-439:

I'm not an "interface" fanatic, meaning that everything should have its
interface Something {
    // ...
together with a
public class SomethingImpl {
    // ...
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
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:
>             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