-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recommend robust method for iteratively calculated functions #170
Comments
Hey @tpapp, How do the results look like it you set |
Improved, compared to
|
If |
Aside: If you are not already I recomment using ChainRulesTestUtils, which wraps FiniteDifferences.jl. The default fdm in ChainRulesTestUtils is |
Hey @tpapp! Would you be able to confirm whether you've found a satisfactory way to compute finite differences? If so, we'll add a recommendation to the README. :) |
@wesselb: I am in the process of finishing up the unit tests for the relevant package, it seems to be working for now but I will get back here once I am done. |
Thanks for responding quickly! No need to rush at all, of course. :) |
@wesselb: I am done, and I can confirm that You may close this issue, or keep it as a reminder for the readme change if you prefer. Thanks for all the help everyone. I appreciate it, and also this great package. |
That's fantastic to hear! I've opened a PR to add a small section to the README (#174). |
I have a computation that solves an implicit equation using iterative numerical methods (bisection, Brent, etc). I would like to use FiniteDifferences.jl for unit testing partials I write for ChainRulesCore.
The problem is that since the calculated function is not technically continuous, using eg
central_fdm(5, 1)
gives me bogus results (occasionally off by a factor of 5--10). I had some success with a high number of grid points, egcentral_fdm(20, 1)
, but too much adaptation (eg 2 steps) makes things go bad again.I would appreciate recommendations on how to deal with this in a robust way for unit testing. Since it is for testing, it does not have to be super-fast, just robust.
The text was updated successfully, but these errors were encountered: