Sommer (2016), and how to go to a different value fn on 'death'?

1

qianphhh asked:
“Hello there! Is there any possible for this toolkit to solve lifecycle or OLG model with given ReturnToExitFn function of exogenous survival possibility? Such as in every period an agent is facing an exogenous risk of entering into another form of value function (not zero), and also facing the probability of death. An example is the model in “Fertility choice in a life cycle model with idiosyncratic uninsurable earnings risk” (Sommer, 2016). Thank you very much! Your toolkit really helps me a lot !!”

[github is for opening/closing code/bugs so I have copy/pasted the question to here to answer]

2

Not only can you solve Sommer (2016), here are some codes that do it :smiley:

The fertility state, which is what your question is really about, can just be modeled as a markov exogenous state (a z state in VFI Toolkit terminology). The markov state in this model, f, captures fertile/infertile and the fact that infertile is permanent just appears as the markov process having an ‘absorbing’ state.

Note that it was not possible to actually implement Sommer (2016) exactly. She has a parameter h_t (I call it h_j in codes) which is the deterministic age-conditional component of earnings. However her paper does not report the actual values of h_t, I emailed her and she said she does not have the codes handy so could not send me the values of h_t. As such these have been lost to time. The codes therefore instead use some numbers from Kaplan (2012) which should have a similar age-profile, but may be the wrong scale.

[The paper also has a parameter p^I_t which is the probability of transitioning from fertile to infertile state. This was not provided by the paper, but the explanation of how it was created from data was clear enough that I was able to reproduce it.]

[The codes are on the low side for number of grid points, if you want to use this model seriously you should increase them. You can set vfoptions.lowmemory=2 to avoid out of memory errors, although this will slow the codes down.]

Sommer (2016) does describe how to create h_j parameter values: “The average age-profile for wages, h(t), is calculated from the 2004 CPS by dividing the family labor income, defined as a sum of yearly earnings of both spouses in husband–wife families, by the sum of total hours worked by the couple. [Footnote 14: The average age of the couple is taken to represent the age of the household. The profile is smoothed using a cubic polynomial in age.]”

But makes it sound like you will end up with a process on hourly earnings. But then in the model this is multiplied by (1-l_t), which is a value between zero and one. So it is not entirely clear if this is what was actually done or not.

Modelling a markov with an absorbing state with just a standard markov (which is what these codes are doing) is slightly wasteful computationally. But only slightly.

1 Like
3

[Before reading Sommer (2016) I had written the following as I was simply guessing from how the question was posed that it was going to look, in the relevant mathematical aspect, like Borella, De Nardi & Yang (2018) - The Aggregate Implications of Gender and Marriage. What I said does not apply to Sommer (2016) but I leave it here as it may still be of interest.]

I expect you mean something like a model in which there are two types of agents, ‘married couple’ and ‘single female’.

With some probability s1, a single female survives and so with 1-s1 they die and get zero utility (or a warm glow of bequest). This is a standard exogenous survival probability.

What you refer to (if I understand correctly) would be that a ‘married couple’ has a survival probability s2, and with probability 1-s2 the husband dies and the household therefore becomes a single female and gets the value function of the single female from then on.

VFI Toolkit cannot quite handle this. Specifically it cannot handle that you have different parameters for different types, but that these types are not permanent. VFI Toolkit can handle different parameters (and much more) for different permanent types. These kind of ‘evolving types’ can easily be done as a markov state, but then you cannot easily make the parameters different as toolkit does not permit parameters to depend on exogenous states.

Note that you could actually ‘fool’ the toolkit to solve this, just it gets really messy (you would have to put all parameters for both married and single into the return function, and then use an if statement for them).

[BDY2018 allow married to single female or to single male, but conceptually this is much the same thing from coding perspective.]

1 Like
4

I ran your example based on Sommer (2016) and got warning messages saying that the transition matrix rows generated by semi-exo shocks do not sum to one. This seems a bit troubling :slight_smile:

vfoptions =

[struct](matlab:helpPopup('struct')) with fields:

z_grid_J: [9×63 gpuArray]
pi_z_J: [14×14×63 double]
n_e: 3
e_grid: [3×1 gpuArray]
pi_e: [3×1 gpuArray]
n_semiz: 6
semiz_grid: [6×1 double]
SemiExoStateFn: @(n,nprime,K,probstayhome)Sommer2016_SemiExoStateFn(n,nprime,K,probstayhome)
verbose: 1
lowmemory: 1

Warning: Using semi-exo shocks, your transition matrix has some rows that dont sum to one for age 1
1 Like
5

This should fix it: Fix semi-exogenous child transition warning by aledinola · Pull Request #1 · robertdkirkby/Sommer2016example · GitHub

It was a mistake that did not affect the results: in the original code, the transition matrix \Pr(semiz,semiz'|d,j) has rows that do not sum to one for a certain point, but that point is never chosen, therefore this apparent inconsistency does not affect the results, which are correct.

The fix proposed in the PR makes the transition matrix for semiz well-defined and avoids the warning message.

3 Likes
6

There are a couple of issues to fix in the lifecycle document for Model 28.

First, the equation for childcare costs:

childcarecosts = childcarec(h > 0)n

The term (h>0) should read as an argument of an indicator function. And you should add the constraint f \in \{0,1 \} for the decision variable f.

Second: I think this example should cite the Sommers (2016) paper.

1 Like
7

Another issue:

% order must be: (d,aprime,a,z,semiz,e,...)
ReturnFn=@(l,x,K,aprime,a,n,epsilon,f,upsilon,agej,Jr,h_j,r,mew,psi1,psi2,theta,gamma,zeta,kappa,qbar,maxnumchildren,pension,earningsshifter) ...
    Sommer2016_ReturnFn(l,x,K,aprime,a,n,epsilon,f,upsilon,agej,Jr,h_j,r,mew,psi1,psi2,theta,gamma,zeta,kappa,qbar,maxnumchildren,pension,earningsshifter);

I think nowadays the toolkit uses a different ordering for the action space variables: (d,aprime,a,semiz,z), instead of (d,aprime,a,z,semiz) used in this code.

2 Likes
8

Thanks for finding this mistake. I was using this code as a template for another model of mine.

The bottom line is that instead of ordering (z,semiz) I should order as (semiz,z)? I was confused because the wrong order does not give an error in matlab.

2 Likes
9

Merged this pull request, which fixes the ‘rows add to one’ (good thing I have added warnings about that nowadays :slight_smile: )

Cleaned up the comment to use (…,semiz,z,..) ordering, which the code already does.
[Originally it was implemented as z,semiz. But as part of rolling the Tan improvement out across the toolkit it became clear that the Tan improvement would perform better with semiz,z ordering, so everything was rewritten to use semiz,z ordering.]

I’m not sure there is a way to spot and give an error for the wrong ordering in the ReturnFn, because currently the toolkit has no way to see the ‘names’ of the inputs to ReturnFn and check them (for the action and state space, there are of course checks for the parameters because these have to coincide with the parameter structure). [The output shapes of V and Policy would have reflected the (…,semiz,z,…) ordering, but obviously this is easy to miss unless you are trying to plot them.]

1 Like