Originally published at: Version 2.5: InfHorz – VFI Toolkit
VFI Toolkit Version 2.5 has just been released. It breaks all infinite horizon codes. The fix is easy, just ‘find and replace all’ “_Case1” with “_InfHorz”. So for example, some of the core commands are now ValueFnIter_InfHorz(), StationaryDist_InfHorz(), EvalFnOnAgentDist_AllStats_InfHorz(), and HeteroAgentStationaryEqm_InfHorz(). [Note: finite horizon is still _Case1_FHorz, so don’t change those, only infinite horizon problems…
3 Likes
I’ve tried to update Examples. No doubt there is a teething error or two somewhere so if anyone comes across one let me know.
1 Like
Good improvement!
The renaming involves only functions that are exposed to users or also internal functions (such as for example the CreateReturnMatrix etc.) called by the main toolkit functions?
Btw, now with AI these mechanical tasks like renaming have become easy
Just the user facing ones. I’ve gradually renamed a good chunk of the internals over the last six or so months. Some internal things won’t be renamed at all (like CreateReturnMatrix, since these don’t distinguish InfHorz and FHorz).
Don’t have to apologise to users for changing the internal names 
1 Like
Thanks for the answer!
I had a look at the matlab function IIJ1995_absOmega0minusOmega1 and I was wondering about the command GeneralEqmConditions_Case1_v2. What does this command do and is it something we should be awere of as users? I think so since it is called within a user-written file for the example based on IIJ1995.
I tested all scripts in the examples folder that use infinite horizon commands with codex and it found a few bugs. Hope this is useful.
Bugs/errors found while testing the v2.5 _InfHorz examples
I tested the MATLAB examples that already use the infinite-horizon _InfHorz command names. All line numbers below refer to the current files in the examples repository.
Example-script bug fixed
Exotic Preferences/Aiyagari1994_EndoLabor_EpsteinZin/Aiyagari1994_EndoLabor_EpsteinZin.m
The script failed at the inequality-statistics step because EvalFnOnAgentDist_AllStats_InfHorz was called with FnsToEvaluate_Ineq, but the inequality functions had been defined under the different struct name FnsToEvaluateFnIneq.
Failing call, line 162:
AllStats=EvalFnOnAgentDist_AllStats_InfHorz(StationaryDist, Policy, FnsToEvaluate_Ineq, Params,[], n_d, n_a, n_z, d_grid, a_grid, z_grid,simoptions);
Before the fix, lines 158-160 defined the wrong struct:
FnsToEvaluateFnIneq.Earnings = @(d,aprime,a,z,w) w*z;
FnsToEvaluateFnIneq.Income = @(d,aprime,a,z,r,w) w*z+(1+r)*a;
FnsToEvaluateFnIneq.Wealth = @(d,aprime,a,z) a;
MATLAB reported:
Unrecognized function or variable 'FnsToEvaluate_Ineq'.
The fix was to define the functions directly in FnsToEvaluate_Ineq at lines 158-160:
FnsToEvaluate_Ineq.Earnings = @(d,aprime,a,z,w) w*z;
FnsToEvaluate_Ineq.Income = @(d,aprime,a,z,r,w) w*z+(1+r)*a;
FnsToEvaluate_Ineq.Wealth = @(d,aprime,a,z) a;
After this fix, the script ran successfully.
Transition-distribution errors still unresolved
The two transition examples got past their TransitionPath_InfHorz calls, then failed at the subsequent AgentDistOnTransPath_InfHorz distribution calculation.
HeterogeneousAgentModels/Aiyagari1994TransitionPath.m
TransitionPath_InfHorz is called at line 181:
[PricePath,GeneralEqmCondnPath]=TransitionPath_InfHorz(PricePath0, ParamPath, T, V_final, StationaryDist_init, n_d, n_a, n_z, pi_z, d_grid,a_grid,z_grid, ReturnFn, FnsToEvaluate, TransPathGeneralEqmEqns, Params, DiscountFactorParamNames, transpathoptions,vfoptionspath,simoptions);
The failure occurs later at line 190:
AgentDistPath=AgentDistOnTransPath_InfHorz(StationaryDist_init, PolicyPath,n_d,n_a,n_z,pi_z,T,simoptions);
MATLAB reported:
Sparse gpuArray matrices are not supported for this function.
The stack trace pointed to toolkit internals:
-
AgentDistOnTransPath_InfHorz, line 71 -
AgentDist_InfHorz_TPath_SingleStep, line 15:
AgentDist=reshape(AgentDist*pi_z_sparse,[N_a*N_z,1]);
HeterogeneousAgentModels/GuerrieriLorenzoni2017_Example.m
TransitionPath_InfHorz is called at line 309:
[PricePath,GeneralEqmCondnPath]=TransitionPath_InfHorz(PricePath0, ParamPath, T, V_final, StationaryDist_initial, n_d, n_a, n_z, pi_z, d_grid,a_grid,z_grid, ReturnFn, FnsToEvaluate, TransPathGeneralEqmEqns, Params, DiscountFactorParamNames, transpathoptions, vfoptionspath, simoptions);
The failure occurs later at line 317:
AgentDistPath=AgentDistOnTransPath_InfHorz(StationaryDist_initial,PolicyPath,n_d,n_a,n_z,pi_z,T,simoptions);
MATLAB reported:
Sparse gpuArray matrices are not supported for this function.
The stack trace pointed to toolkit internals:
-
AgentDistOnTransPath_InfHorz, line 86 -
AgentDist_InfHorz_TPath_SingleStep_nProbs, line 13:
AgentDist=reshape(AgentDist*pi_z_sparse,[N_a*N_z,1]);
This looks like a toolkit GPU sparse-distribution issue rather than a v2.5 naming issue, because both example scripts were already calling the new _InfHorz functions.
1 Like
Nowadays you can (and should) just use
heteroagentoptions.maxiter=0;
HeteroAgentStationaryEqm_etc(...);
to evaluate the general eqm eqns at the current parameters (at contents of the parameter structure).
This IIJ1995 is old code written before heteroagentoptions.maxiter=0 existed, where you had to do this manually with the hack of calling GeneralEqmConditions_Case1_v2(). I might go fix it later today and update this post.
[Note: the old way works okay for simple models, but fails for some of the more advanced tricks the toolkit is nowadays capable of. heteroagentoptions.maxiter=0 is just so much simpler and more powerful.]
1 Like
Fixed:
Exotic Preferences/Aiyagari1994_EndoLabor_EpsteinZin/Aiyagari1994_EndoLabor_EpsteinZin.m
Probably fixed:
HeterogeneousAgentModels/Aiyagari1994TransitionPath.m
and
HeterogeneousAgentModels/GuerrieriLorenzoni2017_Example.m
Both had essentially same error. @aledinola can you please try rerunning these, is about reshaping sparse gpu array so it won’t error on my computer as I’m running R2025b, but pretty sure I could see the issue and fixed it.
1 Like