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 Fri, 19 Nov 2010 22:20:13 GMT


Gilles commented on MATH-439:

> [...] yes, raising the threshold is an appropriate fix [...]

Fine. Thanks.

> Our exception handling is already quite complex now [...]

Now? I hold that it is much _simpler_ now (or, more exactly: It will be when the pending tasks
are completed):
* A single {{exception}} package, instead of classes interspersed in several packages.
* More specific (hence, informative) exception types.
* Obvious exceptions hierarchies (rooted at the various "Math...Exception" classes that themselves
inherit from the Java standard exception specific categories).
* Message factory and exception localization utilities located in package {{exception.util}}.
* Reduction of the number of message patterns.
* Embryo of exception usage policy (e.g. not propagating {{NullPointerException}}).
* No checked exceptions :-)

You ask to slow the pace precisely when I propose to keep something from the previous design,
i.e. the already existing {{IntegrationException}} concept (albeit moving it to the {{exception}}
package and integrating it into the new design, of course).
MATH-195 is a long-running task but it is a single one. We should cross to the other bank
instead of staying in the middle of the river...

> 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