[
https://issues.apache.org/jira/browse/MATH-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933532#action_12933532
]
Luc Maisonobe commented on MATH-439:
------------------------------------
The HighamHall54IntegratorTest.testEventsNoConvergence test is explicitly set
up to check an exception is thrown. The exception has changed so the test must
be updated. If you look at the end of the test, you will see:
{code}
try {
integ.integrate(pb,
pb.getInitialTime(), pb.getInitialState(),
pb.getFinalTime(), new double[pb.getDimension()]);
fail("an exception should have been thrown");
} catch (IntegratorException ie) {
assertTrue(ie.getCause() != null);
assertTrue(ie.getCause() instanceof ConvergenceException);
}
{code}
So the behavior you see is normal, you have to adapt the test. As the
TooManyEvaluationsException is not wrapped anymore, it should be sufficient to
replace the catch part with:
{code}
} catch (TooManyEvaluationsException tmee) {
// expected
}
{code}
For the Dormand-Prince test, could you replace at line 238 the
{code}
assertTrue(handler.getMaximalValueError() < 5.0e-8);
{code}
with
{code}
assertEquals(0, handler.getMaximalValueError(), 5.0e-8);
{code}
and tell me the value of the error in the failing test ? It may simply be a too
sensitive test that blows up as soon as you slightly change the code.
I don't understand what happens with the non linear conjugate gradient. The
value is completely out of control (a circle radius of 5 billions instead of
69), so the algorithm has clearly diverged. There is probably a bug somewhere
here.
> 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.
