New model: endogenous labor supply (intensive margin)

[mnwhite]

We want to move into models with labor supply choice soon. For starters, a model with choice over quantity of labor supplied is quite feasible. Consider the utility form:

u(C,\ell) = ((1-\ell)^\alpha C)^(1-\rho)/(1-\rho)

With transitory and permanent productivity shocks, this model can be solved in normalized form using EGM. State variables will be (bNrmNow,TranShkNow). In precomputation step, will construct a function that maps (EndOfPrdvP,TranShkNow) to (cNrmNow,LbrNow) solutions to the EGM-style FOCs. cFunc will be a LinearInterpOnInterp1D.

[mnwhite]

Posted this now because one of my students will be tackling this model for her course project.

[edmundcrawley]

One thing your student will find (I think) when they do this is that for very wealthy people, the model implies the optimal amount of labor is negative. For the super wealthy (relative to their wage), 'buying leisure' will even when labor=0 will get more utility than more consumption. I wrote this model up in a very scrappy way a while back (I can see if I can find the code if your student is interested, but it might be best to start from scratch). One way I've seen that people include labor in a heterogenous agent model is using GHH preferences (see for example the well known HANK <http://www.princeton.edu/~moll/HANK.pdf> paper ). It's possible that might be more useful than the above model as it will give more empirically reasonable results for the labor of the wealthy (especially those who choose negative hours in the above model...). Edmund

…

On 19 May 2017 at 14:30, Matthew N. White ***@***.***> wrote: We want to move into models with labor supply choice soon. For starters, a model with choice over quantity of labor supplied is quite feasible. Consider the utility form: u(C,\ell) = ((1-\ell)^\alpha C)^(1-\rho)/(1-\rho) With transitory and permanent productivity shocks, this model can be solved in normalized form using EGM. State variables will be (bNrmNow,TranShkNow). In precomputation step, will construct a function that maps (EndOfPrdvP,TranShkNow) to (cNrmNow,LbrNow) solutions to the EGM-style FOCs. cFunc will be a LinearInterpOnInterp1D. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJy-S0QgWbm-zxqo_QL-2JZQYcXcVzC8ks5r7d_egaJpZM4Ng3O-> .

[mnwhite]

Yes, for very large values of mNrmNow, the agent would like to supply negative labor (if it were allowed). The (EndOfPrdvP,TranShkNow) to (cNrmNow,LbrNow) function will be allowed to return LbrNow < 0, but this will be constrained to LbrNow = 0 during solution when calculating bNrmNow = aNrmNow - WageRteTranShkNowLbrNow + cNrmNow. Interestingly, I think the correct approach is to store negative labor values in the interpolated policy function, but set them to zero when the function is called. That will result in the LbrNow=0 seam being identified correctly, rather than subject to quirks of gridpoint placement.

I actually have no problem with this model saying that very wealthy people should not / will not work. I mean, that's true. If you have $1M in the bank and have the capability to earn $5/hour, you shouldn't work at all: your wealth-to-productivity ratio is extremely high. This model can be normalized by permanent income (productivity in this case), so it does not predict that high income people should work less.

[mnwhite]

Ugh, a set of asterisks for multiplication because italicizations up there (around TranShkNow).

[mnwhite]

Addendum: When the (EndOfPrdvP,TranShkNow) to (cNrmNow,LbrNow) function returns LbrNow < 0, cNrmNow needs to be recalculated as cNrmNow = EndOfPrdvP**(-1./CRRA) before calculating the endogenous bNrmNow gridpoint.

[mnwhite]

The grad student (Tiphanie Magne) has now more or less completed the solver for this model. The module lacks simulation methods and needs to be tested at other parameter sets (and lifecycle testing), but it ostensibly works. For simplicity, I had her assume that there is always a positive probability of TranShk=0, so that the lower boundary of admissible states is easy to calculate.

I'll introduce Tiphanie to GitHub and try to get this into a PR soon-ish. One holdup is that I had her use file versions from the ConsAggMarkov branch, as they have functionality she required. Until that branch gets merged to master, this model can't / shouldn't be merged.

[mnwhite]

After sitting in my private fork of HARK for nearly two years, I finally put this model into public HARK, in the LaborIntMarg branch. The solver works correctly, and the comments for it have been cleaned up. I'm partway through cleaning other docstrings and comments. A couple tiny remaining items that anyone could do:

1. Move the relevant example parameter dictionary from the temporary ConsumerParametersTM.py into the main ConsumerParameters.py, clean up comments and formatting, and delete the former file.

2. Add a lifecycle example to the main block.

For the somewhat more ambitious, I think the model is still missing its simulation methods. I'm pretty sure the only ones that need to be written (and not just inherited) are getControls and getPostStates. The inherited IndShockConsumerType.getStates will do some wrong (but harmless) stuff, like calculate mNrmNow = bNrmNow + TranShkNow; that should be fixed in getPostStates as mNrmNow = bNrmNow + LbrNow*TranShkNow.

[llorracc]

So, I think this should be merged, and we can leave your points as "issues" to be addressed.

…

On Wed, Sep 4, 2019 at 10:12 PM Matthew N. White ***@***.***> wrote: After sitting in my private fork of HARK for nearly two years, I finally put this model into public HARK, in the LaborIntMarg branch. The solver works correctly, and the comments for it have been cleaned up. I'm partway through cleaning other docstrings and comments. A couple tiny remaining items that anyone could do: 1. Move the relevant example parameter dictionary from the temporary ConsumerParametersTM.py into the main ConsumerParameters.py, clean up comments and formatting, and delete the former file. 2. Add a lifecycle example to the *main* block. For the somewhat more ambitious, I think the model is still missing its simulation methods. I'm pretty sure the only ones that need to be written (and not just inherited) are getControls and getPostStates. The inherited IndShockConsumerType.getStates will do some wrong (but harmless) stuff, like calculate mNrmNow = bNrmNow + TranShkNow; that should be fixed in getPostStates as mNrmNow = bNrmNow + LbrNow*TranShkNow. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113?email_source=notifications&email_token=AAKCK76JTEDUYQYSYGSDPQLQIBTHDA5CNFSM4DMDOO7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD55SVDI#issuecomment-528165517>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKCK72DOYPM75D42G7OK7LQIBTHDANCNFSM4DMDOO7A> .

-- - Chris Carroll

[mnwhite]

Please not yet. Item 1 has to be done before we merge into master. We don't want a second copy of ConsumerParameters (from *two years ago*) running around in master HARK. It's literally a 2 minute task to fix this, and a basic Python competence test. On Wed, Sep 4, 2019 at 10:14 PM Christopher Llorracc Carroll < [email protected]> wrote:

…

So, I think this should be merged, and we can leave your points as "issues" to be addressed. On Wed, Sep 4, 2019 at 10:12 PM Matthew N. White ***@***.*** > wrote: > After sitting in my private fork of HARK for nearly two years, I finally > put this model into public HARK, in the LaborIntMarg branch. The solver > works correctly, and the comments for it have been cleaned up. I'm partway > through cleaning other docstrings and comments. A couple tiny remaining > items that anyone could do: > > 1. > > Move the relevant example parameter dictionary from the temporary > ConsumerParametersTM.py into the main ConsumerParameters.py, clean up > comments and formatting, and delete the former file. > 2. > > Add a lifecycle example to the *main* block. > > For the somewhat more ambitious, I think the model is still missing its > simulation methods. I'm pretty sure the only ones that need to be written > (and not just inherited) are getControls and getPostStates. The inherited > IndShockConsumerType.getStates will do some wrong (but harmless) stuff, > like calculate mNrmNow = bNrmNow + TranShkNow; that should be fixed in > getPostStates as mNrmNow = bNrmNow + LbrNow*TranShkNow. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #113?email_source=notifications&email_token=AAKCK76JTEDUYQYSYGSDPQLQIBTHDA5CNFSM4DMDOO7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD55SVDI#issuecomment-528165517 >, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/AAKCK72DOYPM75D42G7OK7LQIBTHDANCNFSM4DMDOO7A > > . > -- - Chris Carroll — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#113?email_source=notifications&email_token=ADKRAFKA25VTYPAGSO2E5FLQIBTQHA5CNFSM4DMDOO7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD55SY7A#issuecomment-528166012>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADKRAFI37WIAUJ52NENEQFTQIBTQHANCNFSM4DMDOO7A> .