[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933203#action_12933203
]
Gilles commented on MATH-439:
-----------------------------
Changes are again cascading to faraway places.
This issue led to changes in {{BrentSolver}} so that the loop is now
evaluation-based (instead iteration-based) and it now throws
{{TooManyEvaluationsException}}.
The {{HighamHall54IntegratorTest}} test fails:
{noformat}
testEventsNoConvergence(org.apache.commons.math.ode.nonstiff.HighamHall54IntegratorTest)
Time elapsed: 0.006 sec <<< ERROR!
org.apache.commons.math.exception.TooManyEvaluationsException: maximal count
(3) exceeded: evaluations
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.incrementEvaluationCount(BaseAbstractUnivariateRealSolver.java:298)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.computeObjectiveValue(BaseAbstractUnivariateRealSolver.java:158)
at
org.apache.commons.math.analysis.solvers.BrentSolver.solve(BrentSolver.java:203)
at
org.apache.commons.math.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:89)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.solve(BaseAbstractUnivariateRealSolver.java:195)
at
org.apache.commons.math.analysis.solvers.BaseAbstractUnivariateRealSolver.solve(BaseAbstractUnivariateRealSolver.java:200)
at
org.apache.commons.math.ode.events.EventState.evaluateStep(EventState.java:260)
at
org.apache.commons.math.ode.events.CombinedEventsManager.evaluateStep(CombinedEventsManager.java:149)
at
org.apache.commons.math.ode.nonstiff.EmbeddedRungeKuttaIntegrator.integrate(EmbeddedRungeKuttaIntegrator.java:293)
at
org.apache.commons.math.ode.nonstiff.HighamHall54IntegratorTest.testEventsNoConvergence(HighamHall54IntegratorTest.java:267)
[...]
{noformat}
Because of the interface change in {{BrentSolver}}, the new set of lines
(around line 260) in "EventState.java" are:
{code}
final BrentSolver solver = new BrentSolver(convergence);
solver.setMaxEvaluations(maxIterationCount);
final double root = (ta <= tb) ? solver.solve(f, ta, tb) : solver.solve(f, tb,
ta);
{code}
Obviously, the new exception is thrown here and is never caught. I don't know
what else to change in order to get the same behaviour as before...
Expert advice welcome!
> 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.
