[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933596#action_12933596
]
Gilles commented on MATH-439:
-----------------------------
For {{HighamHall54IntegratorTest}}, the type change did it. Thanks!
Side-note: it would indeed be clearer to wrap such low-level exception types
into an exception that is more appropriate to the method being called.
{{TooManyEvaluationsException}} is low-level in _this_ context because the user
doesn't seem to have any control on the cause of the exception he might get.
So for these useful abstractions, I'd create new classes in package
{{exception}}. This makes another use for a "MathRuntimeException" base class
from which those exceptions, as well as {{MathUserException}}, would inherit.
What do you think?
For {{DormandPrince853IntegratorTest}}, the value you requested is
{noformat}
error=5.3722054293651864E-8
{noformat}
Shall I raise the tolerance to 1e-7 ?
> 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.
