You can now just refer to parameters by name, and likewise for aggregate variables. All the examples are updated to Version 2 so you can see it in action. Makes larger models much easier to keep track of.

Sick of writing ‘ParamNames’? Good news, version 2 does away with them. You no longer create ReturnFnParamNames at all, it is simply figured out internally. Likewise for FnsToEvaluate.

Even better, FnsToEvaluate is now created as a structure, where the field names are the names of the variables. The input arguments are the decision, endogenous state, and exogeneous state variables in order, followed by any parameters. For example, in the Aiyagari (1994) model, we would want aggregate capital K, so we set
FnsToEvaluate.K=@(kprime,k,z) k
If we needed some parameter, say we tax capital (wealth) at rate tau, then the tax revenue would be calculated as
FnsToEvaluate.K=@(kprime,k,z,tau) tau*k
You can see that this makes using parameters easy (VFI Toolkit will look for tau in the parameters structure, called Params in example codes).

But it gets better. Now imagine you want to use K in your general equilibrium condition. Again, let’s consider the Aiyagari (1994) model where the general equilibrium condition is that the interest rate is equal to the marginal product of capital. So we would just set this up as
GeneralEqmEqns.CapitalMarket=@(r,K,alpha,delta) r-(alpha*K^(alpha-1)-delta);
where the inputs can be parameters (alpha, delta), general equilibrium prices (r), and even the aggregates of the FnsToEvaluate (K). Everything is just by name and in any order.

Better still, when you run commands to solve the general equilibrium you get easy-to-understand feedback. At each iteration (while finding the general equilibrium prices) you will be told the current prices (r), aggregate variables (K), and general equilibrium conditions (CaptialMarket). Because everything is by name it is easy to follow what is happening and so see where anything goes wrong.

Of course there are still more improvements. Because FnsToEvaluate contains the names of the variables, the output of all commands using them now uses these names. So for example calculating the aggregate capital in the Aiyagari (1994) model would be done as,
AggVars=EvalFnOnAgentDist_AggVars_Case1(StationaryDist, Policy, FnsToEvaluate,Params, [],n_d, n_a, n_z, d_grid, a_grid,z_grid);
and the output AggVars contains the aggregate values of the ‘FnsToEvaluate’ which are now referred to by name, so for example
AggVars.K.Mean
would be the aggregate value of K. This is also true of the command for things like the median, standard deviation, lorenz curve, etc.; they contain all results by name. The big advantage, other than ease of reading the code, is that you can add or remove FnsToEvaluate without breaking code as nothing depends on the number of functions to evaluate nor on their order.

Lastly, there is one thing that is broken by the update to version 2 and that is transition paths (both infinite and finite horizon transition path commands). This was a deliberate decision as being able to refer to everything by name in version 2 turns this from difficult into something easy enough to use. There are currently three examples available of how to compute transitions. Two infinite horizon models one of which extends the Aiyagari (1994) model with the other one based on Guerrieri & Lorenzoni (2017), and one OLG transition based Conesa & Krueger (1999).

All up Version 2 should make it both much easier to write codes, and much easier to read and understand them. In my experience it also makes it much easier to debug and correct them; since everything is by name it is possible at a glance to see from the output where a model is going wrong and therefore how to correct it. The update is especially helpful for models with lots of parameters, functions to evaluate, and general equilibrium conditions, since it becomes easy to keep track of everything and trivial to add or remove aspects.

As always, any questions or comments please use the forum: discourse.vfitoolkit.com/ (or you can email me directly at robertdkirkby@gmail.com)

—————–
Comment: The permanent type ‘PType’ commands have also been updated to only work with Version 2, but since these are yet used in the example codes it is not as noteworthy.

Comment: General equilibrium in the Aiyagari (1994) model is often described as being about getting K to match K, this is equivalent to the above where we get r to equal the marginal product of labor. I personally find it much more intuitive to think about the equilibrium in prices, but of course it is mathematically equivalent to consider it in prices or in quantities.

Comment: If you don’t want all that feedback on your general equilibrium, you can just use heteroagentoptions.verbose=0 to turn it off. verbose=0 is part of all the options so you can also set it for transitionpathoptions, etc.

Comment: Currently transition paths require a powerful GPU so may not be ‘available’ to everyone. But given two or three years they should become something just about anyone can easily do.

Disclaimer: If you are willing to assume that models are linear in the aggregate you can use these transition paths as a way to solve and simulate models with aggregate shocks, see Boppart, Krusell & Mitman (2018). There are ways to further exploit this linearity assumption to massively speed up solutions, see Auclert, Bardóczy, Rognlie & Straub (2021), who also provide a Python toolkit for this purpose. I just want to let people know that these much faster methods exist for those willing to assume linearity of the model in the aggregates.