commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] Commented: (MATH-439) Refactoring of solvers (package "analysis.solvers")
Date Thu, 18 Nov 2010 19:28:14 GMT


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:
    try {
                      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);
 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:
  } catch (TooManyEvaluationsException tmee) {
    // expected

For the Dormand-Prince test, could you replace at line 238 the
assertTrue(handler.getMaximalValueError() < 5.0e-8);
assertEquals(0, handler.getMaximalValueError(), 5.0e-8);
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:
>             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