ENH: moved the lucas_tree tuple to a new LucasTree class #41
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updated examples and solutions to match change
We had a
lucas_tree
named tuple and a functioncompute_lt_price
in the file originally. This pull request moved to aLucasTree
class with acompute_lt_price
method. There are a few reasons for this: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. Havingintegrate
andlucas_operator
be methods of the class instead of nested functions defined withincompute_lt_price
allows me to test them.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.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.I also made a couple minor changes to
compute_fixed_point
:*args
and**kwargs
tocompute_fixed_point
that I pass directly on to theT
argument of that function. This enables the user to pass arbitrary positional and keyword arguments on to theirT
mappingv = new_v
at the end of the iteration to readv[:] = new_v
. This change is subtle, but coupled with the ability to pass arbitrary arguments on to theT
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 asnew_v
. If we pass a kwarg that specifies the output of theT
operator (to avoid allocating in withinT
), then after the first iterationv
andnew_v
will point to the same memory address and effectively be the exact same variable. This means when we check the error, it will be0.0
on the second iteration. With the[:]
python interprets the line as 'fill the memory held byv
with the values fromnew_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.