modify `opt_tax_recur` #204

shizejin · 2021-06-02T05:07:34Z

Refactorize code in the lecture opt_tax_recur as listed in #203.

github-actions · 2021-06-02T05:09:53Z

🚀 Deployed on https://60c09e8744acd5c5343bfc9e--cocky-austin-ce446a.netlify.app

QBatista · 2021-06-02T05:20:07Z

source/_static/lecture_specific/opt_tax_recur/crra_utility.py

        σ = self.σ
        if σ == 1.:
            U = np.log(c)
        else:
            U = (c**(1 - σ) - 1) / (1 - σ)
-        return U - n**(1 + self.γ) / (1 + self.γ)
+        return U - (1-l) ** (1 + self.γ) / (1 + self.γ)


My understanding is that n+l=1 is not supposed to be enforced for this case (at least with with n>=0 and l>=0). Quoting from Tom's email: "It is ok if [n] exceeds 1; this part of the lecture is using the alternative utility and technology specification". Of course, you can define l this way, but then, I think it won't match what leisure is supposed to be under this "alternative utility and technology specification".

More generally, at least in the AMSS lecture, there's a mismatch between the model being solved and the model described in the lecture. Is this the case here too?

I am not sure about the amss lecture but here n+l=1 is enforced (see equation (1)).

What about the "Specification with CRRA Utility" section that says "We also eliminate Lucas and Stokey’s restriction that ℓt+nt≤1."

Note that right below the sentence you quoted, it says "With these adjustments, the analysis of Lucas and Stokey prevails once we make the following replacements".

To me the original complete formulation of the model from eq. (1)-(26) is what I should follow closely when we design the code, and the CRRA case which eliminates "l+n=1" is just a special case and special replacements are needed to fit it into the original general framework.

Since I am not imposing a restriction on l, the possible range for n in the CRRA case after replacements should still be [0,+∞], and imposing n+l=1 is no more than a linkage of a special specification to the general framework defined above.

Yes, I understand. My point is just that you'll get l<0 since n>1. I don't think the lecture specifies l<0, but negative leisure is surprising. In the LS paper, the utility function seems to be a mapping from R^2_{+} to R (below eq 2.2), so it looks like they don't allow for negative leisure although I would probably need to read the paper carefully to verify this. Hence, my guess is that the n in the CRRA specification is not the n in (1).

Since the CRRA formulation eliminates l, it is probably not so meaningful to discuss the sign of l.

I may want to clarify my two reasons for designing the code like this: (1) I prefer to impose n+l=1 in the class, since this is how it is defined at the very beginning when introducing the general framework, (2) we want to fit the CRRA case into the general framework, in that case n=1-l is necessary. Since the "economic" meaning of l has been eliminated in the CRRA case, l plays a role no more than linking the specific CRRA case to the general framework, and a negative l associated with n>1 does not bother me too much.

Might this sound a little more reasonable to you?

I understand that you want to fit the CRRA case into the "general" framework. I am just wondering whether imposing n=1-l is the right way to do it. I'll double-check with Tom.

Sure it would be great to consult Tom about this. Please include me in the communication.

QBatista · 2021-06-02T05:28:50Z

source/_static/lecture_specific/opt_tax_recur/recursive_allocation.py

-from quantecon import MarkovChain
-from scipy.optimize import root
-
-
 class RecursiveAllocation:


I don't understand the choice of class names in these lectures. In the lecture, allocations seem to be sequences. Are RecursiveAllocation and SequentialAllocation supposed to represent sequences?

I am just keeping what was used originally but these names do not bother me too much. Quoting one sentence from the content: "After first presenting the model in a space of sequences, we shall represent it recursively in terms of two Bellman equations formulated along lines that we encountered in Dynamic Stackelberg models." It seems that the lecture is emphasizing the contrast between sequential representation and recursive representation. If you come up with better names for these representations, it would be great, but we would need to adjust the lecture content in a consistent way.

Or do you mean you don't like "Allocation"s in the class names?

How about SequentialLS and RecursiveLS standing for the sequential and recursive representations of the Lucas-Stokey model? The other lecture has RecursiveAllocationAMSS -- I can shorten that to AMSS.

Or do you mean you don't like "Allocation"s in the class names?

Yes -- I guess those should be classes that are meant to represent the model(s) described in the lecture.

SequentialLS and RecursiveLS sound good if you insist. But I want to note that in the recursive representation, allocation is actually formulated in a recursive way (see the time invariant functions in eq. (32)), and I have to admit that it's not obvious to me yet how does changing these names improve the clearness.

“The difference between the right word and the almost right word is really a large matter – it is the difference between the lightning and the lightning bug.” -- Mark Twain :)

What I was saying is that I am not so sure why one is "right" and the other is "almost right", since "RecursiveAllocation" and "SequentialAllocation" form a good contrast in how the model solution is formulated as emphasized in the content, but it seems that you have a strong preference for what you are proposing, and I am indifferent between these. I will add this modification to this PR.

mmcky · 2021-06-03T06:09:08Z

@shizejin can you ping me when this is ready to review (from a publishing perspective). Thanks!

shizejin · 2021-06-03T09:57:44Z

@shizejin can you ping me when this is ready to review (from a publishing perspective). Thanks!

Sure @mmcky , I will let you know!

shizejin · 2021-06-09T11:12:06Z

Hi @mmcky, with the careful review and help from @QBatista, I think this PR is now ready for your review from a publishing perspective.

mmcky · 2021-06-10T00:44:27Z

thanks @shizejin and @QBatista -- amazing work! Does @thomassargent30 need to review this or has this happened already?

shizejin · 2021-06-10T04:21:51Z

Hi @mmcky, thanks so much for merging! I think Tom approves this. And @QBatista would you like to continue working under the mod_amss branch? In that case we should probably restore the branch.

mmcky · 2021-06-10T04:25:24Z

@QBatista It is usually better to get the latest master and then work from that in a new branch. I have found that workflow typically saves a lot of headaches when time comes to merge.

modify opt_tax_recur

3925311

add dependency on interpolation

5644453

QBatista reviewed Jun 2, 2021

View reviewed changes

Modify class names.

e63f41f

Add comment regarding l in the CRRA utility

24eef14

QBatista approved these changes Jun 9, 2021

View reviewed changes

mmcky merged commit 4f8fec4 into master Jun 10, 2021

mmcky deleted the mod_amss branch June 10, 2021 01:30

mmcky restored the mod_amss branch June 10, 2021 04:24

Uh oh!

modify opt_tax_recur #204

modify opt_tax_recur #204

Uh oh!

Conversation

shizejin commented Jun 2, 2021

Uh oh!

github-actions bot commented Jun 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

QBatista Jun 2, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mmcky commented Jun 3, 2021

Uh oh!

shizejin commented Jun 3, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

shizejin commented Jun 9, 2021

Uh oh!

mmcky commented Jun 10, 2021

Uh oh!

shizejin commented Jun 10, 2021

Uh oh!

mmcky commented Jun 10, 2021

Uh oh!

Uh oh!

modify `opt_tax_recur` #204

modify `opt_tax_recur` #204

github-actions bot commented Jun 2, 2021 •

edited

Loading

QBatista Jun 2, 2021 •

edited

Loading

shizejin commented Jun 3, 2021 •

edited

Loading