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

ENH: moved the lucas_tree tuple to a new LucasTree class #41

Merged
merged 2 commits into from Aug 5, 2014

Conversation

sglyon
Copy link
Member

@sglyon sglyon commented Aug 4, 2014

Updated examples and solutions to match change

We had a lucas_treenamed tuple and a function compute_lt_price in the file originally. This pull request moved to a LucasTree class with a compute_lt_price method. There are a few reasons for this:

  • Inside the original compute_lt_price function, we were defining two nested functions. When trying to write tests for this module I was unable to access those functions to test them. Having integrate and lucas_operator be methods of the class instead of nested functions defined within compute_lt_price allows me to test them.
  • The current version uses our compute_fixed_point function like all of the other function iteration algorithms in the QuantEcon library do. This makes this code mesh much better with the rest of QuantEcon.
    • Another point here is that the value function iteration we were doing was pretty much a copy paste from compute_fixed_point. Eventually we will want to speed up that algorithm with numba or cython and only having to do it in one place makes that change easier.
  • It felt a bit awkward to use a named tuple here, when we needed to define various nested functions using attributes of that tuple. It made more sense to have them be methods/class attributes instead.

I also made a couple minor changes to compute_fixed_point:

  1. i added *args and **kwargs to compute_fixed_point that I pass directly on to the T argument of that function. This enables the user to pass arbitrary positional and keyword arguments on to their T mapping
  2. I changed the line v = new_v at the end of the iteration to read v[:] = new_v. This change is subtle, but coupled with the ability to pass arbitrary arguments on to the T function allows us to run this whole algorithm without allocating any memory. This results in more efficient code. (without the [:] python interprets that line as make v point to the same memory as new_v. If we pass a kwarg that specifies the output of the T operator (to avoid allocating in within T), then after the first iteration v and new_v will point to the same memory address and effectively be the exact same variable. This means when we check the error, it will be 0.0 on the second iteration. With the [:] python interprets the line as 'fill the memory held by v with the values from new_v -- so we avoid the problem just described)

As a follow up to point 2 I have opened #40 so that we can update our other fixed point algorithms to use the allocation-free method. Some of those routines are quite slow and this could be a very easy potential speedup.

jstac added a commit that referenced this pull request Aug 5, 2014
ENH: moved the lucas_tree tuple to a new LucasTree class
@jstac jstac merged commit 866f6fd into master Aug 5, 2014
@jstac jstac deleted the lucastree-class branch August 5, 2014 22:04
@jstac
Copy link
Contributor

jstac commented Aug 5, 2014

Great work, thanks.

jstac added a commit that referenced this pull request Aug 25, 2014
ENH: moved the lucas_tree tuple to a new LucasTree class
@oyamad oyamad mentioned this pull request Aug 24, 2015
Merged
This was referenced Sep 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants