Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add robust jitted root finding routine
5 participants