Parameters, AggVars, and GE Prices

The general and greatly simplified process of the HeteroAgentStationaryEqm subfns is:

  • Update Parameters with GEPriceParameters (as proposed by. the solver)
  • Compute V and Policy using Value Function Iteration (using grids, Parameters, and ReturnFn)
  • Compute the Stationary Distribution (using Policy)
  • Compute the AggVars (using grids, Parameters, Stationary Distribution, and FnsToEvaluate)
  • Update Parameters with AggVars
  • Update Parameters with Intermediate Eqns and Custom Model Stats (if any)
  • Compute and return the GE Conditions for the round

The solver calls the HeteroAgentStationaryEqm until the GE Conditions meet the tolerance for convergence (or maxiter is reached).

This seems all well and good for finding GE prices, but it’s not so good when we want to use an AggVar or Intermediate Equation as an input to our VFI. For example, if a firm chooses to give a particular dividend, capital markets can decide how much to buy at that price. If it turns out that a different dividend level results in a better overall optimum, the solver will find it when the firm chooses to give a different dividend that receives a better reception. And share-buying customers could know the dividend offer price by accessing the AggVar that tells them the price. Alas, while the initial guess of that dividend price can be pre-loaded into Parameters for the first VFI, the Parameter Values across iterations remain unchanged throughout the solution. Yes, the GE prices are updated as a step, but never do resulting AggVars calculations update the Parameters that the VFI sees.

The workaround for this order of operations is to declare a market expectation price for the dividend and to ask the GE solver to chase the dividend offers with the pricing expectation that feeds the buyers’ decisions. But this creates a lot of work for the solver to find something that’s basically known for that round.

Here’s an idea: when updating Parameters with AggVars (and possibly Intermediate Eqs and Custom Model Stats), note which VFI parameter lists depend on the Paramters that are changed, and mark those for re-evaluation. After updating all the Parameters, re-evaluate the V, Policy, and the Stationary Dist, AggVars, etc. If we are using PTypes, we must iterate this process across all PTypes. (It may take some topological sorting to do the PTypes in the best order.) And then proceed to calculating the GE conds.

Thoughts? I might just try it when I get back from my travels, unless there’s a good argument that it’s a really bad idea (i.e., it will produce wrong results).

Short answer: No

Long answer: “This seems all well and good for finding GE prices, but it’s not so good when we want to use an AggVar or Intermediate Equation as an input to our VFI.” What you are proposing as an alternative is not really a complete solution, you just want a more complicated update procedure. The current approach of the toolkit is param->VFI->AggVar together with optimization to get param=Aggvar. The way you advocate to do this would be param->VFI->AggVar->VFI–>AggVar, doing twice what the code currently does once, and you would then still need to combine this with the optimization that param=AggVar.

So what you are suggesting is just a substantially more complex (in terms of code), possibly faster (but not obvious that it would be), approach to updating param each iteration of the optimization. I really doubt that the properties of this newer update rule are sufficiently improved from the current one as to be worth the substantially more complex code involved. In some sense you are moving from a joint-optimization on the GEparams (which includes some AggVars and some other parameters) to doing a nested-optimization with an inner optimization on the GEparams that are AggVars and an outer optimization on the GEparams that are not AggVars.

It is not going to produce the wrong results (baring the highly unlikely chance this is a bad update rule, nested optimization works just fine) but unless this turns out to be a substantially improved update rule you are going to add a major complication to the code for little to no runtime improvement, possibly a runtime worsening as you prevent the optimizer from finding out the relations (e.g., cross-derivatives) between the GEparams in the inner and outer parts of your code.

My main objection is that it is a substantial complication of the code for what looks to me to be at best a very minimal gain, and one that only applies to a modest subset of all models.

PS. If it were to turn out I am wrong and the speed gain is substantial then I am open to rethinking, but I just see just as likely to lead to slower as to faster code (you are only going to improve, e.g., 1 of 4 GE condns, and joint to nested optimization often hurts performance).

1 Like

Is there a preferred way to tell the optimizer “trust me, you’ll want to use this AggVar for setting this price, then feel free find the real equilibrium among the rest of the prices you have to play with”? That would also solve the problem (because it would reduce the number of iterations the optimizer needs to do every time that AggVar changes).

Will depend on the optimizer. For Matlabs lsqnonlin() [fminalgo=8] the answer is no, because it updates based on Jacobian and Hessian matrices and you cannot just ignore a row/column. But for shooting algorithm [fminalgo=5] you can define the damping parameter so that it would be a 100% update to the new one (set ‘factor’ to 1) at each iteration (which is essentially what you are suggesting in your post, and now that I think about it this is likely a much better way to implement it, at least it terms of testing how much this does to runtimes while having to do minimum coding).

PS. shooting algo (fminalgo=5) is explained in Appendix to Intro to OLG Models. It is the same thing that is used for transition paths, just applied to stationary general eqm.

2 Likes

I think you mean fminalgo=4, not 5. I read this in the comments of HeteroAgentStationaryEqm_Case1.

Main alternatives: =4 is shooting (you set update rules), =5 is CMA-ES (robust but slow)
2 Likes

Oops, that comment is actually wrong. Have corrected it now to
heteroagentoptions.fminalgo=1; % =1 use fminsearch. Main alternatives: =4 is CMA-ES (robust but slow), =5 is shooting (you set update rules), =8 is lsqnonlin() fast but requires Matlab Optimization Toolbox (and often not quite high accuracy of results)

1 Like

For those following this thread, I have an update, and a request for feedback.

I managed to find what I think is an elegant way to integrate AggVars into PTypes so that they feed forward without duplicating any calculations or otherwise disturbing the flow of the system. It allows me to continue to use the CMA-ES solver, and it solves faster than ever, because I’ve eliminated a pricing variable that is truly unconstrained (dividend price expectation).

But that revealed a few more things about my model’s return function for firms (based on OLGModel14_FirmReturnFn.m):

function F=OLGModel14_FirmReturnFn(dividend,kprime,k,z,w,delta,alpha_k,alpha_l,capadjconstant,tau_corp,phi,tau_d,tau_cg)
% Whether we set it up so that dividends or equity issuance is the decision
% variable is unimportant, here I use dividends as the decision variable.

% Note: r is not needed anywhere here, it is relevant to the firm via the discount factor.

F=-Inf;

% We can solve a static problem to get the firm labor input
l=(w/(alpha_l*z*(k^alpha_k)))^(1/(alpha_l-1)); % This is just w=Marg. Prod. Labor, but rearranged

% Output
y=z*(k^alpha_k)*(l^alpha_l);

% Profit
profit=y-w*l;

% Investment
invest=kprime-(1-delta)*k;

% Capital-adjustment costs
capitaladjcost=(capadjconstant/2)*((invest/k-delta)^2) *k; 

% Taxable corporate income
T=profit-delta*k-phi*capitaladjcost;
% -delta*k: investment expensing
% phi is the fraction of capitaladjcost that can be deducted from corporate taxes

% Firms financing constraint gives the new equity issuance
s=dividend+invest+capitaladjcost-(profit-tau_corp*T);

% Firms per-period objective
if s>=0 % enforce that 'no share repurchases allowed'
    F=((1-tau_d)/(1-tau_cg))*dividend-s;
end

% Note: dividend payments cannot be negative is enforced by the grid on
% dividends which has a minimum value of zero

end

As discussed elsewhere, in this particular case, when tau_d is equal to tau_cg (both are set to 0.2), the ratio ((1-tau_d)/(1-tau_cg)) is 1. And when we look at dividend-s we find that because s is dividend+invest+capitaladjcost-(profit-tau_corp*T), the subtraction makes dividend irrelevant to the objective function, other than that it governs the feasibility of share issuance (s>=0). By plotting a 3D surface with x,y axes of dividends vs capital (K) and F in the z axis we can confirm that where F is not -Inf all values along the dividends axis are equal.

By feeding the actual offered dividend into the household function (rather than using a GE price that’s trying to track this largely untethered dividend value), the solver quickly steered into a very opinionated direction by optimizing this equation (the rewrite with dividends removed):

F=profit-invest-capitaladjcost-tau_corp*(profit-delta*k-phi*capitaladjcost)

That equation was optimized by using the smallest amount of labor and capital possible, and perhaps benefiting from a rounding error caused by the grids. That doesn’t inspire a lot of confidence in capitalism!

I used to be the CEO of a company, and my bonus used to be based on a combination of metrics, including revenue, profitability, and maintaining financial covenants. Here’s where I’m interested in your feedback. I added this term, intended to steer the company’s behavior to something a CEO would realistically decide:

y*(1-(dividend-0.2)^2)/10

The rationale is

  1. We want firms producing output, so Y is valuable
  2. We want firms aiming for a reasonable dividend payout rate, so square of the difference of a market target that’s meaningfully higher than the rate of risk-free return.
  3. We want these goals to steer, but not dominate, the overall return function based on profits, investments, etc. Alas, we cannot normalize Y to be profit-sized, because Y*(1/Y) defeats objective #1. I found by trial and error that once we divided by 10, the solver could meaningfully walk through the action space. Indeed, it initially started with a guess of using almost all the capital and paying a liberal dividend, but it quickly (in fewer than 10 iterations) ramped down to a dividend rate close to 20%, and labor and capital coming into line with household and other expectations (like CapitalOutputRatio).

I found that when dividing by less than 10, the solver insisted on using the absolute maximum capital the grid would allow and demanding more labor than households were able to supply.

So the whole return function calculation becomes:

F=(((1-tau_d)/(1-tau_cg))*dividend-s)+y*(1-(dividend-0.2)^2)/10

This leads to the following aggregate outputs (when there are no z and e shocks):

Following are some aggregates of the model economy (Scenario 1): 
Output: Y=    0.40 
Aggregate TFP: Y=    1.00 
Capital-Output ratio (firm side): K/Y=    2.20 
Total share value (HH side): P*S (1.10) =     1.10
Total firm value (firm side): Value of firm=    1.12 
Consumption-Output ratio: C/Y=    2.03 
Government-to-Output ratio: G/Y=    0.11 
Wage: w=    1.00 

Which look very reasonable. I’ll update when my run using z and e shocks complete.

In the meantime, the feedback I seek is this: how should one think about the balance of using very general equations (such as “maximize profits”) to find equilibrium solutions, vs. injecting behavioral opinions (such as “maximize profits while producing products and paying shareholders”)? Where is the line between discovery and self-fulfilling prophesy? Or, is this a case of saying “Lo, I have discovered good advice for both economists and capitalists: use THIS as an objective function and you’ll find both market pricing stability and satisfactory strategic behavior”?

I have an update!

We have an economy with 3 PTypes: household, firm, and energy. I now have a preliminary energy model for households, where energy costs are scaled by the size of their house, whether or not they have a car, what sort of car they have, and how much solarPV capacity they have (none if they rent).

The firm-related energy consumption is just placeholder right now. As described earlier in this thread (and in some of my other threads), but now implemented, Firms use a production function to decide capital allocation, dividend payments, and issue shares to make up whatever capital needs they cannot fund with profits. Its similar to OLGModel14, but different. The dividend they can offer on a per-period basis (D_pp) is offered as an investment choice to households. It’s not a GE price per se, but rather an outcome of the firm’s overall return function.

Households can buy shares (to get dividends and capital appreciation), or put savings in a bank account (to get a risk-free rate of return). They can buy or rent houses (possibly using collateralized loans), endow them with solarPV (if they are not renting), and buy either a petrol car or an EV. They may also choose to enjoy their leisure :smiling_face_with_sunglasses:

EnergyCosts_h and EnergyCosts_f are the respective expenses that households and firms pay for their energy. These costs are the revenues of the energy PType. Here in green you can see the waterfall of AggVars feeding from firm → household (D_pp) and from firm + household → energy (EnergyCosts_f + EnergyCosts_h = Revenue).

In the future, the energy ptype will be able to invest revenue in changing energy sources that can be observed over a transition period, with consequential impacts on the economics of households and firms. The economics of energy transition will become visible!

As with OLGModel14, there are government revenues and expenditures, but these are not tied to a particular PType. Yet.

2 Likes

Wow, this model of yours is certainly on track to be the biggest I’ve seen solved with the toolkit, cool you can get all this working.

1 Like

The separability of the PTypes is a huge enabler!