Ptypes and conditional statistics

I am comparing a lifecycle model with endogenous labor supply in Fortran vs Toolkit. I will post the results in another post. Here I wanted to clarify a source of discrepancy between the fortran implementation (which is correct) and the toolkit (which may be wrong or not clear).

The model has state variables (a,z,j,\theta), where \theta is a fixed productivity type which takes two values with equal probability. In the toolkit we do this defining \theta as a permanent type and setting

Params.theta = [0.8,1.2];
Params.ptypeweights=[0.5,0.5];

When I compute the variance of income (or any variable) by age using the toolkit Ptype command I get a result which is not what I expect. So I was wondering what formula does the toolkit use. To be clear, I am computing the variance of variable X conditional on age (NOT conditional on permanent type), let’s call it Var(X|j) for j=1,...,J.

\operatorname{Var}(X \mid j) = \frac{ \sum_{a,z,\theta} \left[ X(a,z,j,\theta)-\bar X_j \right]^2 \mu(a,z,j,\theta) }{ \sum_{a,z,\theta}\mu(a,z,j,\theta) },

where

\bar X_j = \frac{ \sum_{a,z,\theta} X(a,z,j,\theta)\mu(a,z,j,\theta) }{ \sum_{a,z,\theta}\mu(a,z,j,\theta) }.

There must be some inconsistency in the toolkit: if I include \theta as a second z state and do NOT use the ptype functions, I do get the correct result for the age-conditional variance.

Maybe @MichaelTiemann already flagged this problem in some other post (or even myself, I tend to forget :slight_smile:

I think you are running into the same problem I noted in the post PType Weights--the new `units` error!

That you are trying to compute a variance based on age and not on PType may not be relevant. What is likely relevant is how you compute your AggVars (the sum of evaluations of a function). What I found is that the per-PType AggVars have their values divided by their PType weights, anticipating that they will ultimately be summed to produce a correct result. But if you use the AggVar by itself (asking what is the Income of one of the PTypes), it will give you a weight-factored answer, which is not what you want.

I solved the simple problem of computing the conditional mean across PTypes. I think the problem you have identified, which I also note in the above thread, remains to be solved. I could give it a crack later today, in which case I’ll post to this thread a link to the commits that will get you there.

1 Like

I’ve looked at this more closely, and see the following cases:

When there are specific functions to be evaluated over the Stationary Distribution (as is typical in my case), these can be passed in via simoptions. This case then has a few sub-cases:

a. Each function computes an AggVar exclusive to its PType. In this case you want all the ptype masses to be 1 and the function indicators function as unique selectors that only select one single PType mass at a time. This is my case.

b. For a given PType mass and a group of functions, the functions are each weighted according to their masses. In this case all functions must select PType masses that add to 1. In a simple case this could be ptypemass=[0.6,0.4] and function A and function B both compute values for PType1 (with weight 0.6) and PType2 (with weight 0.4). When the AggVar A is finally reported, it will be 0.6*A_1 + 0.4*A_2. Similarly B will be 0.6*B_1 + 0.4*B_2.

In case (b), A cannot have one weighting and B another. Neither can A just apply to PType1 and B to PType2.

One could certainly define many different PTypeDistParamNames that pair up with different lists of AggVar functions to evaluate by calling the appropriate StationaryDist PType function. But in each case it would either have to be consistent with case (a) or (b) above.

One can also call the StationaryDist PType function without specifying any functions. The only way I see to make that make sense is to default to case (b), and assume that all AggVar functions are spread across all PTypes according to PTypeDistParamNames.

Now back to Alessandro’s use case: if the PType weights are split 50/50, the value of the AggVar is only half-right when examined within a single PType context. It is only when the AggVar values for all PTypes are added up does it give a correct answer. I don’t know where would be the right place to renormalize the AggVar value on a per-PType basis.

1 Like