[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934018#action_12934018
]
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: 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.
