Parameters that depend on permanent types

1

Suppose I have two permanent types, \theta_e \in \{0,1\} and \theta_h \in \{0,1\}. Think of them as education and ‘genetic’ health, respectively, but they can be whatever you want. Furthermore, assume there is a parameter than depends on \theta_e but not on \theta_h.

I know that I can define it in this way for the toolkit. Let

Names_i = {'e0h0','e1h0','e0h1','e1h1'};
Params.phi.e0h0 = 0.5;
Params.phi.e1h0 = 1.5;
Params.phi.e0h1 = 0.5;
Params.phi.e1h1 = 1.5;

Question: Instead of doing the above, can I write the simpler

N_i = 4;
Params.phi = [0.5,1.5,0.5,1.5]';

Also: Does it matter if Params.phi is a row or a column vector? Moreover, what happens in the unlikely but not impossible case where N_i=N_j ? There could be a model where one period corresponds to 10 years in real life and you have N_j=5 and maybe also 5 permanent types :frowning:

2

Yes you can.

Does it matter if Params.phi is a row or a column vector?

Does not matter.

What happens when N_i=N_j

When you set N_i=N_j=5 and have a parameter that is 5-by-1 (or 1-by-5) the toolkit will assume that the dependence is on N_i.

It is getting to the stage where I need to find a way to let people handle that you set N_i equal to N_j (or T, etc.) and that there is a specific behaviour that you can expect in this situation. That or make it throw errors when you try. But I haven’t yet gone about implementing such a thing. Currently the easiest thing to do in this situation is just add in an extra permanent type (so add one to N_i) and then give this extra ptype mass zero, so it slows down code a little bit but doesn’t actually do anything to model.

1 Like
3

Back in the day when I first coded them it was something like “dependence on j is as row vector and dependence on i is as column vector”, but this was just such a pain in the arse for the user as you constantly forgot to transpose a parameter, that I got rid of this. Made life as a user infinitely better not to have to deal with that crap.

Maybe I just need to bring it back, but only enforce it when you set N_i=N_j, and then verbose=1 can tell you which parameters are classified as age-dependent, ptype-dependent, both-dependent.

1 Like
4

Thanks for the answer. But what happens if (looking at my example above) the parameter phi depends both on age and also on permanent type? There are in total 4 possible combinations of permanent types (2*2) so I would like to define phi as a [N_j,4] matrix. Can I do this? Or I am forced to use the first method with field names, i.e.

Names_i = {'e0h0','e1h0','e0h1','e1h1'};
Params.phi.e0h0 = vector with N_j elements;
Params.phi.e1h0 = vector with N_j elements;
Params.phi.e0h1 = vector with N_j elements;
Params.phi.e1h1 = vector with N_j elements;
5

This will work just fine as long as N_i is not equal to N_j.

PS. Easy test that it works as you expect, just set up the parameter as N_i-by-N_j matrix (or N_j-by-N_i, shouldn’t matter). Then set up a FnToEvaluate the just gives the value of that parameter, then look at age-conditional stats by ptype, and you should see the parameter values in the places as you expect. [I have done this myself before, but will be an easy test you have things set up how you want them.]

1 Like
6

Suppose I follow this new method and I have a parameter that depends on both age and permanent types. So I will set it as a N_j*N_i matrix (and it does not matter if age is the first or the second dimension).

We have seen that all toolkit commands are able to handle this setup. Thanks @robertdkirkby for cleaning up all my PRs!

But what about the calibration command?

This function seems to treat each field of the parameter structure as either a scalar or a vector, so if it finds a field that is a matrix it will break. I can post the precise lines if needed but is around here:

calibparamsvec0=[]; % column vector
for pp=1:length(CalibParamNames)
 tempparam=Parameters.(CalibParamNames{pp});
calibparamsvec0=[calibparamsvec0; tempparam];
end

@robertdkirkby your demo does not return an error because you put a scalar parameter, w, in CalibParamNames.

Note: I am happy to write my own calibration function, I am just flagging this as a todo.

7

An easy solution would be to replace this part

% Make them both column vectors
        if size(tempparam,1)==1
            tempparam=tempparam';
        end

with

tempparam = tempparam(:);

However, I don’t know if this would create problems in the rest of the function.

Update
Here we should add a reshape

CalibParams.(CalibParamNames{pp})=calibparamsvec(calibparamsvecindex(pp)+1:calibparamsvecindex(pp+1))
8

Just implemented this (parameter depending on ptype as a matrix, for the calibration/estimation commands). All works cleanly and correctly on the two examples I tried out.

Have since realised there is something a bit silly. Everything works well, but when you input parameter as a matrix you still get output parameter as a structure. That is, every output calibrated parameter that depends on ptype is a structure, regardless of whether you input it is a structure or matrix.

I will try clean this up monday so that when you input parameter depending on ptype as a matrix you get output as a matrix. Otherwise is going to irritate the user (certainly would irritate me).

[What I did was just found the dependence on ptype as a matrix for CalibParamNames parameters, and then replaced then with structures so that none of the internal code needs changing. This is done near the beginning where the code is figuring out how to take the parameters you want to calibrate and set the whole thing up as a single vector (which is what most optimization commands require).]

1 Like
9

Just pushed to github, now the final output will follow what you did as input: matrix or structure for ptype dependence, and if matrix then will use N_i as first or second dimension following what was input.

1 Like