GNU Scientific Library - Bugs: bug #39713, roots/secant.c "derivative...
You are not allowed to post comments on this tracker with your current authentication level.
bug #39713: roots/secant.c "derivative value is not finite" for a good guess
Submitter: | Max <nikulin> | ||
Submitted: | Wed 07 Aug 2013 03:52:26 AM UTC | ||
Category: | Runtime error | Severity: | 3 - Normal |
Operating System: | Linux | Status: | Fixed |
Assigned to: | gladman | Open/Closed: | Open |
Release: | bzr |
Jump to the original submission
Sat 05 Oct 2013 01:14:00 PM UTC, comment #17: |
Brian Gladman <gladman> |
Sat 05 Oct 2013 11:45:00 AM UTC, comment #16: I can confirm that my examples work with 4848
|
Max <nikulin> |
Sat 05 Oct 2013 10:05:56 AM UTC, comment #15: With a small correction to the value of r (= M_PI / M_E), your modified test program (gsl-secant64.c) gives a correct result on Windows x64 using the version of secant.c now in the GSL repository:
|
Brian Gladman <gladman> |
Sat 05 Oct 2013 08:19:47 AM UTC, comment #14: Concerning API changes, in my opinion, the implementation
|
Max <nikulin> |
Sat 05 Oct 2013 08:08:52 AM UTC, comment #13: Sorry for not participating in the discussion
|
Max <nikulin> |
Thu 03 Oct 2013 09:10:07 AM UTC, comment #12: I have fixed this by returning GSL_SUCCESS if the solver input is already at a root value (as suggested below in order to maintain the existing API).
|
Brian Gladman <gladman> |
Wed 02 Oct 2013 05:49:17 PM UTC, comment #11: I'm not objecting to a quick fix but I don't wan't to put a lot of effort into making a contribution to GSL if we can't also make improvements. And I certainly consider that an API that in common situations forces twice as many function evaluations as are necessary to find a root is in need of improvement (in fact I really thought that I must be wrong about this and I still hope that I am).
|
Brian Gladman <gladman> |
Wed 02 Oct 2013 05:03:17 PM UTC, comment #10: Agreed on GSL 2.0 permitting API changes.
|
Rhys Ulerich <rhysu> |
Wed 02 Oct 2013 03:58:09 PM UTC, comment #9: Not if we have to maintain the existing API's since we would need s new item in the state for the functiopn value. And if you are saying that we have to maintain the existing API's for ever more, we cannot expect to improve GSL in areas where experience shows that API improvments are desirable. I like the Python approach where they are willing to break legacy code every few years in order to accomodate improvements built on real experience (i.e GSL v2.0 would allow API changes).
|
Brian Gladman <gladman> |
Wed 02 Oct 2013 03:43:14 PM UTC, comment #8:
|
Rhys Ulerich <rhysu> |
Wed 02 Oct 2013 03:35:46 PM UTC, comment #7: I agree that one could design a more crisp API (like you suggest) that'll better handle conditions like this, but you can't make the solver iteration routine return something other than GSL_SUCCESS without breaking legacy code. Returning GSL_CONTINUE is nonzero and you'd break existing logic looking for failure from the iteration routine.
|
Rhys Ulerich <rhysu> |
Wed 02 Oct 2013 03:20:10 PM UTC, comment #6: In fact the problem arises because there is actually one condition where the solver can detect and defend against a root that has already been found and this is when the previous function value is exactly zero. And it is the failure of the root solver to detect exactly this condition that is the cause of the problem.
|
Brian Gladman <gladman> |
Wed 02 Oct 2013 02:50:48 PM UTC, comment #5:
|
Rhys Ulerich <rhysu> |
Wed 02 Oct 2013 01:36:19 PM UTC, comment #4: When the secant method is used to find a root with a linear function, its root prediction is essentially perfect and it will give a function value that is zero (or very close). In this situation, when gsl_root_test_delta() is used to test for termination without also using gsl_root_test_residual(), they will get a return which indicates the need to continue the iteration even though this is not necessary. And this WILL lead to the "derivative value is not finite" error.
|
Brian Gladman <gladman> |
Wed 02 Oct 2013 10:17:00 AM UTC, comment #3: The section within secant.c in which the root position, the function value and the derivative value are updated is:
|
Brian Gladman <gladman> |
Tue 01 Oct 2013 07:29:54 PM UTC, comment #2: Running the program provided on Windows x64 gives:
|
Brian Gladman <gladman> |
Wed 07 Aug 2013 05:30:38 AM UTC, comment #1: My bad. Of course, the relative change of root approximation
|
Max <nikulin> |
Wed 07 Aug 2013 03:52:26 AM UTC, original submission:
Implementation of the secant method for root finding fails
|
Max <nikulin> |
Depends on the following items: None found
Items that depend on this one: None found
Follow 7 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2013-10-05 | gladman | Status | Ready For Test | Fixed | |
2013-10-05 | nikulin | Attached File | - | Added gsl-secant64.c, #29299 | |
2013-10-03 | gladman | Assigned to | None | gladman | |
2013-10-03 | gladman | Status | None | Ready For Test | |
2013-08-07 | nikulin | Attached File | - | Added gsl-roots-secant-v2.patch, #28783 | |
2013-08-07 | nikulin | Attached File | - | Added gsl-secant.c, #28779 | |
Attached File | - | Added gsl-roots-secant.patch, #28780 |
Powered by Savane 3.13-f8d8.
Corresponding source code
Thanks for testing the fix on Linux, which allows me to mark it as fixed.
The form df_new = df * (1 - f_new / f) is better than the earlier expression because it avoids the severe loss of precision when (x_new - x) is used in the demominator of the expression for df_new (this was the primary cause of the problems you experienced).
In fact I have just made a further change to:
df_new = df * ((f - f_new) / f);
which avoids the possible loss of precision in using (1 - f_new / f).