Thanks Robert. I do not desperately want the RU2004. No need for extra time on it.
I will refer to this ,
thanks!
Best,
Good morning Robert, when I’m taking advantage of the '_tminus1’ function, I may find a problem in the toolkit.
I find that in line 273 of TransitionPath_Case1_FHorz_shooting, the “for pp=1:length(use_tminus1AggVars)” should be “for pp=1:length(tminus1AggVarsNames)”.
Similarly, beginning from line 267 of TransitionPath_Case1_FHorz_shooting_fastOLG, the
“” for pp=1:length(use_tminus1AggVars)
if i>1
% The AggVars have not yet been updated, so they still contain previous period values
Parameters.([use_tminus1AggVars{pp},‘_tminus1’])=Parameters.(use_tminus1AggVars{pp});
else
Parameters.([use_tminus1AggVars{pp},‘_tminus1’])=transpathoptions.initialvalues.(use_tminus1AggVars{pp});
end
end
end"
should be
" for pp=1:length(tminus1AggVarsNames)
if i>1
% The AggVars have not yet been updated, so they still contain previous period values
Parameters.([tminus1AggVarsNames{pp},‘_tminus1’])=Parameters.(tminus1AggVarsNames{pp});
else
Parameters.([tminus1AggVarsNames{pp},‘_tminus1’])=transpathoptions.initialvalues.(tminus1AggVarsNames{pp});
end
end
end"
In my test, I just found that the internal function never read the value of “transpathoptions.initialvalues.AccidentalBeqLeft”. Then in the step-by-step test, I find this problem.
I just fixed these and pushed changes to github. Thanks for spotting them.
Thank you for fixing the program.
Good morning Robert, sorry to bother again.
In this example program, I find that the “delta” is missing in line 239 and line 412, i.e., the GE condition of capitalmarket (FOC of r), of DemogTransOLG.m . This is not a big deal and easy to fix.
But my question is that, after fixing the missing delta and given a converged initial and final steady state, why does the computation of the transition path not converge? The minimum of the “Current distance to convergence” in my test is about 4 and then bounds back to larger values. When I keep track of the PricePath (the PricePathHistory option allows for it) of each iteration and plot them to compare with the old PricePath with the missing delta but converged transition, I find that the corrected PricePath are more fluctuating than the old ones. And the difference between each iteration is now larger than the old result according to the diagrams (the lines do not overlap when number of iteration increases but persist to exhibit a slight gap). This could be the potential cause that it does not converge.
Changing the tolerence of convergence for the transition path to 5*10^-4 could be the most simple way to solve my question, but this may not solve the key problem. Intuitively, adding a delta just lowers the r according to the FOC. In the result, it should just shift down the r path. For other variables, the changes depend on the general equilibrium effect. But why does it result in more fluctuation in the path such that non-convergence and how to improve the convergence? This is my key question.
Thanks.
aka. why do I put transpathoptions.tolerance=5*10^(-4), rather than just leaving the default of 10^(-4)?
Short answer: I had exact same issue you describe, the tail has some small vibrations and oscillates back and forth at an accuracy of roughly 2*10^(-4) without quite converging.
Long answer: I strongly suspect but do not know (as did not check) that simply using a few more grid points for assets would eliminate this and get full convergence. When you use less points the prices can jump about a bit and give these kind of oscillating tails (I say this based on experience, I am not aware of formal theory establishing this; I intuitively understand it as being that if you have few points then the true path would jump a bit, whereas the updating rules tend to smooth, and so it gets smoothly stuck between the two sides of the jump). So I think you could just increase the grid and then you would get the full convergence at 10^(-4). I was a bit lazy when creating this example and hence instead I just loosened the tolerance (it was clear after a long run time with the grid in the example that the path was just vibrating slightly back and forth but staying in the same place the whole time, so I was confident this was the solution just not quite accurate enough to reach the 10^(-4) default convergence criteria). When I have some spare runtime I will rerun the example with a slightly larger grid and hopefully can then delete the loosened convergence tolerance.
As to the question of why correcting the delta makes this issue worse (from the sounds of things you had vibrations of size around 4*10^(-4) while I had them around 2*10^(-4)) I have no idea. I would suggest just bad luck? (Obviously not actual luck, but just a combination of parameters that made the issue marginally more notable.)
Thanks Robert!
You confirm my guess. I will try changing the grid number and leave the rest to the experience.
I see. This means more trial and errors.
Thanks again for your suggestion!
Best
Good evening Robert,
In the replication of Restuccia & Urrutia (2004), I learn the toolkit can deal with age-dependent decision variables, endogenous state variables, and exogenous state variables. But RU2004 is a Case2 problem. And I found commands in ValueFnIter_Case2_FHorz that deals with the age-dependent variables. However, in the ValueFnIter_Case1_FHorz, I don’t see the relevant commands. Does this mean that the ValueFnIter_Case1_FHorz cannot deal with this type of variable?
Sorry about asking a new question in an old and not relevant post. But when I try to create a new topic, the forum returns “404 not found”. I don’t know why. So I have to ask this question here.
Thanks,
Simon
As you have noticed there is some, but limited, handling of age-dependent decision, endogenous state, and exogenous state variables. Not because they are difficult per se, but just because it takes a fair bit of time to code, and I don’t yet have a nice way to keep it really simple to set up (although now that VFI Toolkit is version 2 that should be easier to figure out how to do). From memory it is essentially just Case 2 FHorz, and only for value fn, agent dist, and one or two others.
Anything with age-dependent decisions has to be Case 2 (as the state is changing each period, Case 1 assumes that one of the decisions is next period state, and that this is just the same as this period endogenous state).
For some problems, you can just repurpose a state or decision variable at different ages. If you look at the Intro to Life-Cycle Models, example 21 does this for the exogenous shock (which is labor productivity until retirement, and then health status from then on), although this is easy because the toolkit handles age-dependent exogenous shocks just using vfoptions.pi_z_J and vfoptions.z_grid_J (and same in simoptions) and you can just make the ReturnFn do different things with these values at different ages. For endogneous state and decision variables it is possible to use a workaround: essentially, because the actual meaning of the state is all occuring through the ReturnFn you can just reinterpret it inside there for different ages. While the grids have to be the same at different ages, you can just pass the grid as an index, and the actual values as parameters (although because parameters are scalar, you don’t want too many grid points; there is a ‘state dependent parameters’ that can be used, but is only in the standard value function commands at the moment).
If you email me a pdf describing the exact model you want to solve I can take a look and let you know if it can be done and how (am about to disappear for 4 days, so response will be slow). And if not, I might be able to implement the functionality to handle it (functionality requests are a nice way for me to prioritise features).
Weird about the 404 not found when trying to create a new topic. Is working for me (just tested it). Not sure what the cause is so cannot try fix it unfortunately.
Thanks, Robert, you confirm my guess. Actually, I searched for keywords like “age dependent” in the toolkit package and found many other solvers include the relevant command (e.g. PType, etc.) except for the Case 1 FHorz module. Therefore I guess this may not (or may take time to code it as you said) be used for the Case 1 type model. Thanks for explaining it.
I’ve read the file Intro to Life-Cycle Models and know how the toolkit deals with age-dependent exogenous shock. But for my model, I’m trying to take advantage of the toolkit to deal with the age-dependent decision variables following your replication example of RU2004. Thanks for the possible workaround suggestion. I’ll email you a pdf of my exact model later(in a few hours) and elaborate a little bit more about my way to solve it using the toolkit.
Take your time and thanks for your time and help.
Haha, it is Okey. Maybe it’s my safari issue. I should have tried another browser.