Hi aledinola, yes this looks like my graph. Thanks for confirming my results
1 Like
@jake88 FYI I did the “easy stuff”, i.e. increasing the number of grid points for assets and increasing the number of agents to simulate, but it didn’t change the results
@jake88 If you are interested in life-cycle models with health risk, I wrote a post here where I cite some recent papers
1 Like
Thanks for these papers!
1 Like
Did you have time to look into the simulations and understand why the graphs look so strange? Thanks for this
1 Like
Hi @jake88, I haven’t really looked carefully at these codes since I am not really interested in this model… As a general suggestion when trying to understand why a code works (or does not work): you could first code up a simpler version that you understand well and gives expected results. Then, step-by-step, you can add features and debug them.
For example: this model has lots of types. Try using only two of them (men vs women) so that N_i=2 and see how it goes.
Hope this helps!
1 Like
Thanks for your insights! I will have to simplify the model quite a bit, since now the simulations always return (almost) flat lines
1 Like
I did a bit of improvement. Hopefully do more later this week. Not tried plotting yet, but getting close 
1 Like
Bunch more improvements (fixing a few typos in my model setup). Everything looks close to fine, except that people save way to many assets. This is partly due to the massive medical expenses that are coming and partly because the warm-glow of bequests is immense.
If you turn off bequest (theta=0) and divide the medical expenses by 100, you get close to what DFJ2010 have.
Hard to tell if I have an error in my setup relating to warm-glow of bequests. I looked and can’t find anything. I don’t think so, is not that complex.
Or an error in my setup related to medical expenses (they are about 100x as large as they should be). DFJ2010 don’t report model medical expenses, but the data ones are in their Figure 3, so presumably model should be close to this (this is basis for my x100 statement). I looked and can’t find anything, but there are a lot of numbers so not certain.
I cannot check if DFJ2010 reported parameters that are the same as in their codes. As the parameters in their codes all get imported from some ‘.fmt’ files, and these files are not part of the replication materials. So not possible to look at the params in their codes.
I plan to recheck the medical expenses parameters some time. That seems most likely issue.
1 Like
Back again, going over the medical expenses. Following is a bit stream of consciousness for how I fixed it. I realized it needs a normalization of psi that is omitted from the paper.
Eqns 6,7,8 of DFJ2010 give the functional forms for medical expenses. These are in the ReturnFn in code, and look fine.
zeta (the markov) and xi (the iid) were discretized using Tauchen-Hussey by DFJ2010, while I use Farmer-Toda (which is better, but did not exist at the time). I checked that the switch to Tauchen-Hussey does not change things, it made the max/min grid points slightly smaller, but only enough to make small changes to results. The parameter values for these are taken from Table 1 of DFJ2010, and there is nothing crazy here.
This just leaves the two coefficients in eqn 6 of DFJ2010.
To think about the max value of the medical expenses in model, exp(m_c+sigma_c*(zeta+xi)): the max of zeta (grid) is 1.73, and max of xi (grid) is 3.05, the values for m_c are about 5-7 (for q3; 6-9 for q5) and those for sigma_c are 1.5-5 (for q3; 2-6 for q6). So the crazy big medical expenses are being driven by the large values for sigma_c at high ages (if we pretend sigma_c=1 we get the max medical expense is 120,000, which even still is at the upper limits of plausible given DFJ2010). Looking at the regression coefficients that construct the medical expense coefficients, it is clear that “ageshiftFinal” alone is enough to drive these results.
A thought occurs. Given they separately estimate zeta/xi from m_c/sigma_c, is there some normalization that should be applied to zeta/xi before we multiply them by sigma_c??? There probably is, question is, can I find it in the paper/codes. Thought: footnote 3 kind of suggests this, as it says that mean medical expense will be exp(m_c+sigma_c^2), which kind of points to the std dev of zeta+xi being normalized to one. Another thought: DFJ2010 pg 54 says “We find that the average variance of log medical expenses is 2.53.”, which without a normalization is definitely not going to happen. Did a Ctrl+F for ‘normal’ in DFJ2010 pdf, to try find mention of a normalization, but nothing.
Going to try: calculate stddev(zeta+xi) as if they were both normally distributed [note: stddev(xi) we have, stddev(zeta)=stddev(innov to zeta)/(1-rho_m) so we can easy get that]. So just get stddev(zeta+xi)=sqrt(stddev(xi)^2+stddev(zeta)^2); note, zeta is AR(1), not normal, but pretty sure this still works fine. Then I can just normalize psi [=(zeta+xi)] by this, before I multiply it by sigma_c.
I implemented the normalization of psi in the codes, just everywhere I use psi I replaced it with "psi/normalizepsi’, and calculated ‘normalizepsi’ as a parameter using the ‘stddev(zeta+xi)’ formula in the previous paragraph.
I looked through the DFJ2010 C codes, cannot find normalization, but anyway would be unlikely to as most parameters cannot be seen as they are imported from files that are not provided.
1 Like
So where is this DFJ2010 code at?
Medical expenses now (with the normalization) look fine for males, for females they are seem too large, but I think this is correct. The m_coeff.maleshift makes them 30% larger (near final ages), and the sigma_coeff.maleshift makes the shocks another 30% larger (near final ages), so the female medical expenses should be a fair bit larger and they are. Problem is that this makes assets hump shaped for females. Possibly the exact renormalization of DFJ2010 for the medical expenses is slighty different from mine, and this would solve what is now a small difference here.
The big problem remaining is that the warm-glow of bequests is way to large. I believe that the code is correct, and the the issue is that the warm-glow is incorrect in the paper because it is missing a constant. DFJ2010 solve the model by the FOCs/Euler eqns, and so they only ever use the derivative of the warm-glow of bequests. So they have the derivative correct, but then when you go from derivative to the warm-glow of bequests you get a constant, and this is what is missing from the paper. Because the way they solve the model means the constant disappears for them they don’t notice the missing constant. Whereas here VFI is used, so the warm-glow of bequests is used directly, and we need the constant, and the fact it is missing makes the warm-glow super generous and people save way to many assets.
Clearly you can then fix the bequests by just subtracting the ‘right’ constant. But I haven’t attempted to do this.
[I am considering this finished, don’t currently plan to do more on it. You would need the data moments (and covar matrix) for the estimation. Maybe I will email to ask the authors for them, but otherwise there is nothing further to be done unless someone redoes the data work to get the moments.]
2 Likes
I had a look at this interesting replication of De Nardi, French and Jones, and there is something I don’t understand in the return function:
% Budget constraint (eqn 9 of DFJ2010)
if govtransfers==0
c=a + aftertaxincome+govtransfers-m-aprime;
else
% impose c=cfloor and aprime=0
c=cfloor;
if aprime>0
F=-Inf;
end
end
if c>0
% utility fn
F=(1+delta*h)*(c^(1-upsilon))/(1-upsilon);
end
The code above imposes c=cfloor and aprime=0 if government transfers are positive, as described in the DFJ paper, see bottom of page 45. But I am not sure the code does what is supposed to do. If govtransfers>0 and aprime>0, then F=-inf, but then F is overwritten and set equal to utility of consumption floor.
I think you must be looking at an outdated version of the ReturnFn?
Now says,
% If this puts you below the consumption floor, then you can get govtransfers to reach cfloor, but only if aprime=0
if c<0 && aprime==0
% impose c=cfloor
c=cfloor;
% receive govtransfers to meet Consumption floor
govtransfers=cfloor-(a+aftertaxincome-m);
% note: this is just the budget constraint rearranged, but with c=cfloor and aprime=0
end
if c>0
% utility fn
F=(1+delta*h)*(c^(1-upsilon)-1)/(1-upsilon);
end
I checked history of the file on github, I fixed this back at end of June.
1 Like
Right, I had downloaded an older version on my computer and I never updated. Sorry about that! Now it looks good
1 Like