Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 7 Aug 2011 13:04:27 +0000 (UTC)
From: "Dennis Hendriks (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <323318801.14748.1312722267128.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1824962433.1547.1311464949737.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-631) "RegulaFalsiSolver" failure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080575#comment-13080575 ] 

Dennis Hendriks commented on MATH-631:
--------------------------------------

I just got back from a 3 week vacation, so I couldn't reply earlier.

The documentation for the RegulaFalsiSolver states: "Unlike the Secant method, convergence is guaranteed by maintaining a bracketed solution." While this is theoretically true, in this case it is not so, because (if I understand correctly) only a single bound is updated repeatedly, and the update is too small to matter (has no effect), due to the double representation.

The change you propose (which is difficult to see as you also change other things in the same commit) is to modify x0 and f0 if the new value of x and x1 are equal. As I see it, this changes the algorithm, and it is no longer the Regula Falsi method as known from literature. I'm therefore against this change.

The problem that is identified in this issue is very similar to the well-known problem of the Regula Falsi method: it converges very slowly for certain problems, due to one side being updated all the time, while the other one stays the same. The Illinois and Pegasus algorithms solve exactly this problem, and are well-documented in literature.

I therefore think it would be better if the RegulaFalsiSolver kept it's original implementation, and for this problem the Illinois or Pegasus method should then be used instead.

The other changes (if statements to switch with default, extracting bound switch statements, etc) can be kept, if you wish.

The suggestion to add a warning to the Secant and Regula Falsi solvers that this is a possible problem, and the solution (use Illinois or Pegasus), would indeed be a good idea. In general, adding a note that the Illinois and Pegasus algorithms perform better, would be a good idea regardless of this issue.

Once more, to be clear, I don't think this issue is a bug. It is a result of the limited convergence of the Regula Falsi method combined with the implications of limited double precision. The limited convergence of the algorithm is a property of the algorithm, and should in my opinion not be changed. I also don't think that trying to work around the limited double precision would be a good idea.

> "RegulaFalsiSolver" failure
> ---------------------------
>
>                 Key: MATH-631
>                 URL: https://issues.apache.org/jira/browse/MATH-631
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Gilles
>             Fix For: 3.0
>
>
> The following unit test:
> {code}
> @Test
> public void testBug() {
>     final UnivariateRealFunction f = new UnivariateRealFunction() {
>             @Override
>             public double value(double x) {
>                 return Math.exp(x) - Math.pow(Math.PI, 3.0);
>             }
>         };
>     UnivariateRealSolver solver = new RegulaFalsiSolver();
>     double root = solver.solve(100, f, 1, 10);
> }
> {code}
> fails with
> {noformat}
> illegal state: maximal count (100) exceeded: evaluations
> {noformat}
> Using "PegasusSolver", the answer is found after 17 evaluations.

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