[
https://issues.apache.org/jira/browse/MATH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080697#comment-13080697
]
Phil Steitz edited comment on MATH-631 at 8/7/11 11:56 PM:
-----------------------------------------------------------
Is there actually a possibility of an infinite loop in the code? Looks to me
like the max evaluations bound will stop the while loop, so there is no
potential for an infinite loop. Apologies if I am misreading the code and the
loop can fail to terminate, in which case I agree this is a problem. (As a
side note, from a style perspective, I prefer to explicitly bound loops to
avoid this kind of uncertainty. The natural hard bound here is the evaluation
count.)
Trying to detect when a sequence of iterates has gotten "stuck" and is destined
to hit max iterations without converging is walking down a path that I think is
unwise for us and users. I see no reason not to stick with the standard impl
here, which is nicely documented in the original submission. Trying to
workaround numerical problems in simple algorithms and change contracts to
include these workarounds is asking for trouble - both for us and users. In a
simple case like this, it is much better to just stick with the documented
algorithm, which should in this case (again unless I am missing something) end
with max evaluations exceeded, which is the right exception to report.
was (Author: psteitz):
Is there actually a possibility of an infinite loop in the code? Looks to
me like the max evaluations bound will stop the while loop, so there is no
potential for an infinite loop. Apologies if I am misreading the code and
there the loop can fail to terminate, in which case I agree this is a problem.
(As a side note, from a style perspective, I prefer to explicitly bound loops
to avoid this kind of uncertainty. The natural hard bound here is the
evaluation count.)
Trying to detect when a sequence of iterates has gotten "stuck" and is destined
to hit max iterations without converging is walking down a path that I think is
unwise for us and users. I see no reason not to stick with the standard impl
here, which is nicely documented in the original submission. Trying to
workaround numerical problems in simple algorithms and change contracts to
include these workarounds is asking for trouble - both for us and users. In a
simple case like this, it is much better to just stick with the documented
algorithm, which should in this case (again unless I am missing something) end
with max evaluations exceeded, which is the right exception to report.
> "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
