I think there might be a problem with the warm glow of bequest in some codes (not specific to life-cycle model 28, but I found it while I was playing with this code)
If you change slightly the coefficient of risk aversion in the CRRA utility function (which is also equal to warmglow3), from 2 to a fractional value, e.g.
Params.sigma = 2.1;
then the code returns with an error message:
Error using gpuArray/arrayfun
POWER: needs to return a complex result, but this is not supported for real input
X and Y on the GPU. Use POWER(COMPLEX(X),COMPLEX(Y,0)) instead.
My understanding is that the following line of code in the ReturnFn is responsible:
% Warm glow of bequests
warmglow=warmglow1*((aprime-warmglow2)^(1-warmglow3))/(1-warmglow3);
What happens if aprime-warmglow2<0? If the exponent 1-warmglow3 is an integer, as in the case warmglow3=2, then it’s ok, but if 1-warmglow3 is fractional, then the mathematical expression (aprime-warmglow2)^(1-warmglow3) is not valid. In Fortran the expression x^y is computed as xx…x (y times) if y is an integer, but is computed as exp(ylog(x)) if y is a double precision number. Then if x is negative, the code crashes, since the log of a negative number does not exist. Matlab instead gives complex values !!
As a quick fix, I replaced the line
warmglow=warmglow1*((aprime-warmglow2)^(1-warmglow3))/(1-warmglow3);
with this:
warmglow=warmglow1*((max(aprime-warmglow2,0))^(1-warmglow3))/(1-warmglow3);
This assumes that if a'<warmglow2, then the utility from bequests is zero. Does it make sense?
Now the code runs correctly with sigma=2.1 but gives very different results for assets, also with respect to the case sigma=2. I think this makes sense: before it was strange that even with warm glow of bequests, households were decumulating assets to zero.
Yeah, I’ve been thinking about what I should do with warm-glow of bequests.
As far as I can tell, the literature doesn’t really know what to do with warm-glow functional forms. There is some clear guidance for Epstein-Zin preferences (mainly about how to avoid some serious errors), and this is implemented in the EZ examples. But there seems to be little to nothing with standard preferences about what a good default for the functional form of the warm-glow of bequests should be.
Your suggestion makes sense, I might roll it out later this week to the whole Intro to life-cycle models.
If anyone out there thinks there is a good paper about what a sensible default functional form for the warm-glow of bequests should be please post here and let us know. I would like to set something nice as the default in Intro to Life-cycle models.
1 Like
One suggestion comes from Fehr and Kindermann, Introduction to Computational Economics using Fortran, pp. 493-494.
The two parameters are v_j (age-dependent) and xi. gamma is 1/crra. By varying v_j and xi, one should be able to match asset accumulation behavior at older ages both in the aggregate and in the cross-section. The non-homothetic functional form makes bequests a luxury good. Fehr and Kindermann refer to a paper of De Nardi, see here.
