Fixed-Point Pass

[arnavs]

Wherever possible, replace homebrewed fixed-point iteration with the fixedpoint() routine from NLsolve.jl. Need to make sure the math checks out. This could cause tests of exact equality to fail; will need to be updated.

[arnavs]

Same goes for lectures that use the compute_fixed_point() from QuantEcon. So: career, ifp, jv, odu, optgrowth, wald_friedman.

[jlperla]

Where possible, we want to use out-of-place functions instead of inplace. They are usually faster, and much less errorprone for new users (i.e. forgetting the .=)

I will add it to style guide.

[Nosferican]

I found that for roots, using Roots.jl was the best solution,

roots = find_zeros(f, lb, up)

For optimization in an interval (using Optim.jl),

optimize(f, lb, up)

Not sure we want to go with compute_fixed_point since it is isn't well documented and I rather use a simple straightforward syntax.

[jstac]

The function compute_fixed_point is mainly used for iteration with the Bellman operator or some other closely related operator.

I've had a few comments from users that they would rather see this logic --- that is, the logic of value function iteration --- written out explicitly. I agree with them. The lectures are, after all, intended to teach. So on the Python side, every time we iterate with a Bellman operator, we're going to write an explicit loop that looks like the while loop in input cell [8] of http://notes.quantecon.org/submission/5bae5cb538674f000fd2c8e3

[jlperla]

• Yes, find_zeros is the right thing for univariate roots, which I think are most of those. I think we shoiuld have a pass where we convert over to that from any QuantEcon.jl homegrown stuff. But that is a different issue.
• This first pass with QuantEcon.compute_fixed_point is to essentially deprecated it in these notes, and move towards the library provided NLsolve.fixedpoint based version. I think this is the first thing this pass would do. You can submit more documents to fixedpoint if you think it is unclear, but it is pretty straightforward.

As for other fixed point code as it currently stands, the naive "Picard" type of fixed point iteration used in many of these lectures is just one of many fixed point algorithms - and in general not the one you would start with. Anderson iteration, Newton iteration, etc. are often much better.

For teaching people, I think we need to show them how the fixed point iteration can be written (as it now is in the intro lectures) but they should rarely do it by hand after that. Maybe the first time we show a dynamic programming problem we could show them the equivalent hardcoded code with picard iteration built-in.

But for other places that have fixed point iterations:

1. Much further away from the mathematics than the direct bellman operators defined in the model
2. Prevents using better algorithms such as Anderson acceleration, newton fixed point iteration with auto-differentiation
3. Need to force the user to learn how to write generic code correctly, or else they will do something wrong in the implementation which prevents AD, StaticArrays, BigFloat, etc. from working
4. Very error prone since they end up having to write their own iteration termination code and frequently make mistakes

Python is very different because it can't compose packages very well, so anyone writing python code will probably have to put the full logic in themselves (or else numba wouldn't work)

[arnavs]

@XiaojunGuan, can you make a note here of any issues you were having using the NLsolve fixedpoint function? I'll investigate whether these are issues with the method or on our side.

[XiaojunGuan]

@arnavs Okay, so I tried with ifp.rst. And when I was using the NLsolve fixedpoint function with the f being the coleman_operator(), it returns a DimensionMismatch error. I also tried with some simpler functions and they appear to be working ok.

[Nosferican]

@XiaojunGuan do you need help on the ifp.rst issue or was that taken care off?

[XiaojunGuan]

@Nosferican Yes, I would appreciate some help on that. When using fixedpoint(), the interpolation part of the coleman_operator!() fails and I don't know how to resolve that.

[jlperla]

Where are we on this one? Is there a checklist of which files still need the fixed-point pass? If not, we should create one.

[XiaojunGuan]

These are the three remaining ones that still need to replace compute_fixed_point with fixedpoint:

• Job Search IV: Modeling Career Choice
• Optimal Savings III: Occasionally Binding Constraints
• Job Search III: Search with Learning

For these three files I have had the same problems as in ifp.rst, so once that is fixed, these can be done very quickly.

According to @arnavs, there are also places that compute fixed point manually, which may also need a pass?

[jlperla]

We can wait to covert the other places that have manual fixed points

[arnavs]

@Nosferican is rewriting the amss lecture (occasionally binding constraints). I think we can follow his lead on that and then do the rest.

[arnavs]

Likewise as #135