[ 
https://issues.apache.org/jira/browse/MATH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dennis Hendriks updated MATH-599:
---------------------------------

    Attachment: MyTest2.java

New test, with output for both dense and non-dense step handler.

Note how for the non-dense step handler, the derivatives are computed for 10.0, 
and the result is 24.999999999999996. It then continues to call the step 
handler for time 10.0 with value 21.35298598981348, which is the value 
calculated for time 8.784328663271161, from before the previous time the step 
handler was called. It seems the compute derivative method is called for the 
appropriate times, only the output is not correctly used to set the 
interpolator values.

If you think this is indeed *only* caused by the optionality of dense output, 
or it is no longer relevant if non-dense output is removed, then removing the 
non-dense option would indeed fix this issue.

It would probably be better to create a separate issue for the removal of 
non-dense output. I have no objections to the removal of non-dense output.

> Re-implementation of Secant-based root finding algorithms
> ---------------------------------------------------------
>
>                 Key: MATH-599
>                 URL: https://issues.apache.org/jira/browse/MATH-599
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Dennis Hendriks
>              Labels: documentation, patch
>             Fix For: 3.0
>
>         Attachments: secant-based-root-finding-algos.patch, 
> secant-based-root-finding-algos2.patch, secant-based-root-finding-algos2.zip
>
>
> Apache Commons Math currently has a SecantSolver. It is unclear exactly what 
> algorithm this solver implements. It states: "The algorithm is modified to 
> maintain bracketing of a root by successive approximations. Because of forced 
> bracketing, convergence may be slower than the unrestricted Secant algorithm. 
> However, this implementation should in general outperform the Regula Falsi 
> method." The Regula Falsi method is exactly the Secant method modified to 
> maintain a bracketed solution. It is therefore unclear what other 
> modifications were done to make it 'better' than the Regula Falsi method.
> Besides the Secant and Regula Falsi methods, several other Secant-based 
> root-finding algorithms exist, such as the the Illinois method, and the 
> Pegasus method. All 4 are well-known, publisched algorithms.
> I created a patch, which changes the following:
>  - Removed SecantSolver root-finding algorithm.
>  - Implemented new Secant-based root-finding algorithms: SecantSolver, 
> RegulaFalsiSolver, IllinoisSolver, and PegasusSolver.
>  - Introduced BracketedSolution interface and AllowedSolutions enumeration, 
> to control allowed solutions (under-approximations and over-approximations) 
> for bracketed root-finding algorithms. Implemented for RegulaFalsiSolver, 
> IllinoisSolver, and PegasusSolver.
>  - Fixed documentation of BaseUnivariateRealSolver.solve methods, such that 
> documentation order of arguments matches the order of the actual arguments.
> Note that the original SecantSolver was removed, and replaced by a 
> root-finding algorithm that actually implements the Secant root-finding 
> algorithm. As such, existing code using the SecantSolver is not backwards 
> compatible. That is, even though the new SecantSolver does implement the same 
> interfaces, the root-finding solutions may differ. In particular, the new 
> SecantSolver does not maintain a bracketed solution, and does not guarantee 
> convergence.
> I added unit tests, and I did a build, including checkstyle checking. I did 
> not fix all checkstyle warnings though, as I consider some of them false 
> positives.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to