Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <32843152.92981289860093985.JavaMail.jira@thor>
Date: Mon, 15 Nov 2010 17:28:13 -0500 (EST)
From: "Gilles (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-439) Refactoring of solvers (package
 "analysis.solvers")
In-Reply-To: <18591924.45371289567236619.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.