Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <27211855.192271290153555950.JavaMail.jira@thor>
Date: Fri, 19 Nov 2010 02:59:15 -0500 (EST)
From: "Luc Maisonobe (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=12933714#action_12933714 ] 

Luc Maisonobe commented on MATH-439:
------------------------------------

Our exception handling is already quite complex now, so I'd rather slow the pace on this and wait for users feedback before going further.

For DormandPrince, yes, raising the threshold is an appropriate fix. This test belongs to the non-regression kind, it's not a mandatory threshold defined from earlier precise settings, so updating it when the code changes is often fair. The problem is that there is no general relationship between the local error for which we configure a threshold and the global error we get at the end. This is still a research subject. The test is here mainly as a safety check to avoid introducing large regression without noticing them.

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