Skip to content
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

Add bisection and brent's method for root finding #424

Merged
merged 3 commits into from
Jul 30, 2018

Conversation

supavitd
Copy link

Hi @jstac and @mmcky

I would like to resolve #422 in this PR.

I've added two new robust root finding methods bisect and brentq which are based on Scipy's version.
These procedures were written in C originally and I rewrote them in Python to jit compile.

I added two jitted robust root finding methods: Bisection and Brentq
which are based on Scipy's version which is written in C. They both
follow the previous jitted root finding procedures by returning a
namedtuple with relevant information.

I also added a basic test for each method.
@coveralls
Copy link

coveralls commented Jul 25, 2018

Coverage Status

Coverage increased (+0.01%) to 95.163% when pulling 20b6437 on spvdchachan:robust-root-finding into 1155267 on QuantEcon:master.

@jstac
Copy link
Contributor

jstac commented Jul 25, 2018

Thanks! Nice code and nicely documented. This looks good to me.

@@ -3,4 +3,4 @@
"""

from .scalar_maximization import brent_max
from .root_finding import newton, newton_halley, newton_secant
from .root_finding import *
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @spvdchachan I would rather list the items here rather than using *. That way if someone adds a support function that isn't prepended with _ it won't get promoted through import.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually I just realised you have used __all__ in root_finding.py. Please ignore.

@mmcky mmcky added the ready label Jul 25, 2018
@supavitd
Copy link
Author

@mmcky I've fixed import to list items as requested.

Copy link
Member

@oyamad oyamad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks nice (I did not go into details though). Minor comments:

  • Default values for optional arguments should be described in the docstrings.
  • There are several "trailing whitespaces". Check with http://pep8online.com for example.

@@ -2,26 +2,31 @@
from numba import jit, njit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jit seems not to be used in this file.

@mmcky
Copy link
Contributor

mmcky commented Jul 27, 2018

thanks @spvdchachan this is looking great.

I agree with @oyamad it would be nice to add the optional default values to the documentation. This is often done with , optional(rtol = {{ value }}) or adding it to the description. I see that many of these are set at the top of the file, i.e. using _rtol. Is there a way to fill the documentation from the set variable?

I have included optional default arguments in the docstring of all
functions.

All trailing whitespaces are now fixed conforming to PEP8. The check is
done via pycodestyle and http://pep8online.com/.
@supavitd
Copy link
Author

@oyamad @mmcky I agree with adding default values to the documentation. Hence, I've added them to all functions (including other root finding procedures to be consistent).

I also fixed issues with trailing whitespaces to follow pep8 (checked through pycodestyle).

With regards to using variables inside docstrings, one option is to use a decorator as discussed in https://stackoverflow.com/questions/10307696/how-to-put-a-variable-into-python-docstring.

@mmcky
Copy link
Contributor

mmcky commented Jul 30, 2018

thanks for the updates @spvdchachan. I am happy with values for now.

that link is interesting - I think the decorator approach would be the best but there is not need to implement this before merging. I'll think a bit more about if we want to pursue filling the docstrings from variables for default values.

@mmcky mmcky merged commit 9a47420 into QuantEcon:master Jul 30, 2018
@supavitd supavitd deleted the robust-root-finding branch July 30, 2018 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add robust jitted root finding routine
5 participants