How to set up FnsToEvaluate

1

Suppose I have a life-cycle model with dual-earners and I would like to compute the mean earnings of male, female and total. I was doing the following:

FnsToEvaluate.ym_coh=@(l_f,aprime,a,zm,zf,eff_j,w_m) w_m*eff_j*z_m;
FnsToEvaluate.yf_coh=@(l_f,aprime,a,zm,zf,eff_j,w_m) w_f*eff_j*z_f*l_f;
FnsToEvaluate.y_coh = @(l_f,aprime,a,zm,zf) ym_coh+yf_coh;

where the static choice is l_f (female labor supply can be either 0 or 1), the state variables are (a,zm,zf) and the terms (eff_j,w_m,w_f) are model parameters. I would like to compute the sum of male and female income, denoted as y_coh. However, this doesn’t work: the toolkit returns an error message saying that it does not find the parameters ym_coh and yf_coh

FAILED TO FIND PARAMETER ym_cohFAILED TO FIND PARAMETER yf_coh

This is of course true, strictly speaking, since ym_coh and yf_coh are not parameters but names in FnsToEvaluate. So it seems that is not possible to pass names of FnsToEvaluate to other FnsToEvaluate, correct? The right way of doing things is then a bit more verbose:

FnsToEvaluate.ym_coh=@(l_f,aprime,a,zm,zf,eff_j,w_m) w_m*eff_j*z_m;
FnsToEvaluate.yf_coh=@(l_f,aprime,a,zm,zf,eff_j,w_m) w_f*eff_j*z_f*l_f;
FnsToEvaluate.y_coh = @(l_f,aprime,a,zm,zf,eff_j,w_m,w_f) w_m*eff_j*z_m+w_f*eff_j*z_f*l_f;

I am asking this since when it comes to GE conditions I think the user is allowed to pass GE names as inputs, if I remember correctly.

2

You cannot pass FnsToEvaluate names as inputs to FnsToEvaluate.

You can pass FnsToEvaluate names as inputs to GeneralEqmEqns.

You cannot pass GeneralEqmEqns names as inputs to GeneralEqmEqns.

Internally this reflects the ordering that:
i) get all the relevant parameters out of the parameter structure
ii) use these to evaluate all the FnsToEvaluate
iii) use everything from first two steps to evaluate GeneralEqmEqns

[I have thought about setting up the FnsToEvaluate to accept other FnsToEvaluate as inputs, I am capable of writing this code but haven’t yet decided to prioritize it. Essentially it requires me to ‘order’ the FnsToEvaluate, and while it would be easy for things like AggVars it gets more complex if I do things like covariance or conditional. I’ll likely do this at some stage as when the models get more complex being able to do this becomes more advantageous.]

PS. It is possible to evaluate GeneralEqmEqns ‘conditional on ptype’, but this is not yet publicly documented anywhere (e.g., we can have two permanent types of agents, and they each leave bequests, and bequests received are conditional on the type of agent; so high income agents leave bequests to high income agents, and low income agents leave bequests to low income agents).

1 Like
3

PPS. If you tell me that being able to pass FnsToEvaluate as inputs to other FnsToEvaluate is a ‘priority’ feature in your view, then I will go implement it. Happy to take advice on what priorities should be :slight_smile:

4

Hi Rob, thanks a lot for the clarification! No, I don’t think should be a priority, at least in my view. I asked just because I was unsure about this possibility. The toolkit is already great in terms of flexibility. For example, I found it really nice that since version XX the user doesn’t have to specify anymore the parameter names of ReturnFn in a separate cell array of characters.

In my view (and this is really very subjective, based on my experience in coding) some nice features to add would be

  • divide and conquer (and I think this is already implemented in several places) for speed
  • models with “human capital” broadly defined, of the type hprime=f(shock,a,h,effort) where h is a continuous state variable that requires interpolation and effort is a choice variable.
  • two asset models
1 Like
5

Perfect! Because those three plus GMM estimation of life-cycle models is pretty much a list of exactly what I am expecting to have public during the second half of this year :smiling_face: [all but the two-asset using divide-and-conquer are already coded, just going through quality control]

Yeah, anything where a FnToEvaluate would be reused in another FnToEvaluate can always be rewritten as a single FnToEvaluate (which is not quite as user friendly, but is still workable). So I’m viewing it as a nice-to-have rather than a need-to-have.

1 Like
6

Regarding GMM, I think it would be a nice addition to the toolkit but it is something that is not so difficult to program yourself (unless we are talking about standard errors). Quite often, when I write a new code, the bottleneck in terms of my time as a programmer is the model solution (Vfi and distribution). The VFI toolkit drastically reduces this time and this is why I like it so much :slight_smile:
However, when it comes to writing a routine to minimize the distance between a set of data moments and the corresponding model moments, that’s not a big deal. That being said, I don’t have much experience with “proper GMM” and computation of standard errors for parameter estimates: maybe here is where the toolkit can really make a big difference.

1 Like
7

It will be proper GMM, with standard errors as well as some sensitivity and identification stuff :smiley: (there is also going to be a ‘Calibrate’ command for when you just want the informal targeting of data statistics)

1 Like