working out an expanded Dolo/DolARK syntax

[sbenthall]

From @llorracc

A high priority from my point of view is working out an expanded Dolo/DolARK syntax so that we can capture:

1. "Cycles" in which the agents solve a different problem in each subperiod
2. Finite Horizons specification of the SolvingMicroDSOPs life cycle model that has age-varying magnitudes of transitory and permanent shocks, income growth, and other inputs
3. "Absolute time" A way to make reference to some absolute time (like, what year is it, in addition to what age am I). This is much less important, and if hard to do could be dropped
4. Conventions for how to keep track of agents who are "ex-ante" heterogeneous so that we can develop tools for handling such populations efficiently.

We should probably move a summary of this discussion to GitHub so it will be easy to track down in the future when we need to reference it.

[sbenthall]

@llorracc Some clarifying questions/comments:

1. "agents solve a different problem in each period". What are the assumptions here about what is maintained between periods, and what aspects can be changed as "different problems". My first guess is:

• endogenous state is carried from period to period
• arbitrage and felicity functions and controls may be different from period to period
• exogenous factors are in effect "the same" between periods, though perhaps structured as temporal vectors.

I believe having multiple arbitrage functions would entail not just a change to the dolang YAML syntax, but also a change to the Model class created after parsing the YAML.

2. 'Age varying magnitudes'. The simplest version of this would be to have the symbol name an array of {values, processes} and equations index into these with a new state variable (age). I gather from previous conversations that due to the constraints around age (always incrementing). Any reason why that would be insufficient?

3. 'Absolute time' -- HARK doesn't have this yet, so I think we should focus on 1 and 2 for now.

4. This also does not exist in HARK yet and so is currently underspecified.

It follows then that (1) and (2) are high priority for inclusion in Dolang syntax. Any elaboration on those specific points would be helpful in moving that ball forward.

[llorracc]

1. "agents solve a different problem in each period". What are the assumptions here about what is maintained between periods, and what aspects can be changed as "different problems". My first guess is:

• endogenous state is carried from period to period

all endogenous states

• arbitrage and felicity functions and controls may be different from period to period

and transition functions

• exogenous factors are in effect "the same" between periods, though perhaps structured as temporal vectors.

probably this will usually be true in practice but there is no reason to require it

I believe having multiple arbitrage functions would entail not just a change to the dolang YAML syntax, but also a change to the Model class created after parsing the YAML.

The simplest way to implement this would be to have a separate file for each "period" within the "epoch" (like, each "quarter" within the year).

That's probably not the best way to implement it, though, because there are SOME requirements for consistency across the periods, and completely separate YAML files would have no way of imposing that.

A simple example that could be used to develop a syntax for this is the portfolio problem:
0. "end-of-period" problem: Given assets $a$, figure out how to invest them in risky vs safe assets
* Which involves constructing a marginal end-of-period-value function $v^{'}{t,1}$
0. "beginning-of-period" problem: Given end-of-period marginal value function, compute beginning-of-period optimal consumption
* This yields $v^{'}{t,0}$

There's a fairly complete exposition of this in my SolvingMicroDSOPs lecture notes (not the HARK REMARK -- the original lecture notes at llorracc/SovingMicroDSOPs (Google it).

'Age varying magnitudes'. The simplest version of this would be to have the symbol name an array of {values, processes} and equations index into these with a new state variable (age). I gather from previous conversations that due to the constraints around age (always incrementing). Any reason why that would be insufficient?

That works in principle, but does not work well in practice, because the way state variables are represented in Dolo is as symmetric matrices. If we want to solve a life cycle problem where the maximum span of life is 120 years (when you reach age 120, probability of death becomes 100 percent), then a symmetric matrix would require the specification of a matrix of size 120 by 120 (for the annual version) to capture the probability that a person who is age 1 transitions to age 119. Of course that probability is zero -- and indeed the matrix is entirely empty except for a single entry in each row, which determines that the probability of transitioning to the next age is 1.

There are ways to handle this ("sparse matrices") computationally but they rapidly get complex to code. It's much much simpler to have a sequence of 120 problems (the problem of the 120 year old; the problem of the 119-year-old, etc).

There are two issues here:

1. What is a good syntax for capturing the "sequence of problems"
2. What is a good way to implement the solution to such a sequence

While in principle these are separable, in practice it is likely that it will be wise to construct a syntax that maps reasonably transparently into the likely computational solution method.

'Absolute time' -- HARK doesn't have this yet, so I think we should focus on 1 and 2 for now.

Agreed.

This also does not exist in HARK yet and so is currently underspecified.

It also does not exist in Dolo, which means that we face fewer constraints in how to implement it than for some other things.
I brought it up mainly because when we are designing the new syntax for Dol[ARK] we should bear in mind that we might want to do this in the future. I can imagine choices that we could make for the "periods/epochs" thing that would be easier, and some that would be harder, eventually to integrate with an extended syntax that allows for absolute time.

[llorracc]

@sbenthall, @albop

This is to follow up on some of the things I was saying in our call earlier today.

1. My top priority is to define a Dol[o/ARK] syntax in which all of our models in HARK can be expressed
   • Specifically, expressed in such a way that there is no ambiguity about exactly what the model IS
   • The syntax would NOT include parameters like the number of gridpoints used for approximations
   • The interpretation would be that the "true" model is the limit as the number of gridpoints goes to infinity
   • If there are two competing (numerical) solutions to the same "model," (like a HARK and a Dolo solution) the one that is closer to being "right" is the one that is closer to the result you get as the number of gridpoints goes to infinity
2. Even as it stands now, there are many models that can be defined unambiguously (in the desired sense above) with the existing Dolang syntax, but which cannot be solved by Dolo
   • That would also be the case for many of the models in HARK
     • They could be describable unambiguously in the new syntax even if Dolo fails to solve them
   • This is just like the fact that many math problems can be posed unambiguously but nobody can solve them

My sense is that the most effective way for you to try to wrap your mind around what we want to do would be to start with some examples of our simplest models that currently ARE ALREADY solved correctly in both Dolo and HARK, like the Buffer Stock model, and to get thoroughly familiar with how the model is represented:

1. In math (the Bellman equation description)
2. In Dolo YAML
   • which is basically an explicit and unambiguous syntax for specifying infinite horizon Bellman problems
3. In HARK
   • which is basically a set of tools for efficiently performing the steps that produce an efficient solution to particular Bellman problems; the "model" is expressed implicitly in the byzantine structure of the code, but does not have any explicit formulation
4. In the python representations created by Dolo when it parses a YAML file

For the BST model:

1. The math elaborately specified in the paper Theoretical Foundations of Buffer Stock Saving, and distilled in the REMARK
2. The Dolo YAML representation is in the DARKolo version
3. The ConsIndShockModel provides the HARK representation
4. The one interesting part that does NOT exist now, but that you should add (to the DARKolo), is the python representation of the model that results from processing the YAML file with Dolo

The DARKolo repo has a number of other models that are desired but are not in nearly the state of completion as the BST DARKolo. I'd suggest that after you get BST under your belt, you examine some of those and pick one or two which deserve a parallel treatment as above.

Once you've done that, you could take a look at some of our models that are NOT conveniently representable in Dolo syntax (I'm not sure of the state of DolARK), and wrap your mind around why (like, the life cycle/finite horizon aspect). Specifically, I'd suggest the SolvingMicroDSOPs REMARK because that one also has the math elaborately specified in my SolvingMicroDSOP lecture notes.

[sbenthall]

because there are SOME requirements for consistency across the periods, and completely separate YAML files would have no way of imposing that.

You have given me enough information to try to work out a proposed syntax for this.

Given that, I'm not sure why you think the parallelism exercise you have suggested is useful.

When I have tried what you've proposed, I've wound up hung up on the instability of Dolo and the inscrutability of HARK. It has not been a productive course of action.

If the syntax is what matters most to you, that can be developed without messing with either library.

That works in principle, but does not work well in practice, because the way state variables are represented in Dolo is as symmetric matrices.

I anticipated this response.

I am confused. On the one hand, you are saying that your first priority is the syntax, and the syntax alone.

On the other hand, you seem to be rejecting a syntax because of its effect on the complexity of the model that is interpreted from it.

What if the compiler could interpret a concise syntax and create an object with the properties you described (120 different sub-problems). I find it hard to believe anybody would be interested in hand-coding 120 sub-problems themselves.

Or am I missing something you are imagining about the potential syntax? Perhaps a special notation for a constrained type of endogenous state, one which affords an efficient multi-stage model representation?

That would, technically, not only be a new syntax for Dolo, but also a new semantics. In other words, I believe that with both of these proposals, the underlying Model object would, ultimately, need to be changed to support what you are proposing.

However, you seem very willing to bracket those implementation questions for now. I think now that I have been working with @albop a bit more to understand Dolo, through the python constructor work, I'm in a better position to create a draft syntax aligned with what you've proposed.

[sbenthall]

I've reviewed the task list for DARKolo chimera's, which has been around since last November, when I started. All of them besides BST have been blocked for one reason or another.

I did not see on my first read of your second comment statement, which I'm happy to see though it seems to be inconsistent with your overall statement of priorities (wanting, mainly an unambiguous syntax for new kinds of problems), this point:

4. The one interesting part that does NOT exist now, but that you should add (to the DARKolo), is the python representation of the model that results from processing the YAML file with Dolo

I agree that this is worthwhile to do. It is yet another motivation for my work on a Python constructor for Dolo models. When that constructor is written, it will be possible to add this to the BST chimera.

[sbenthall]

4. Conventions for how to keep track of agents who are "ex-ante" heterogeneous so that we can develop tools for handling such populations efficiently.

I see now that there is already a proposed convention for this in the dolark Model Spec. (See the last section on this page):
http://www.econforge.org/dolark/model_def/

I see now that this issue was misplaced when it was written. It would make more sense for these items to be individually ticketed on the dolark repository, as that's where the new syntax interpretation will be implemented.

[sbenthall]

As this issue has expanded in scope to cover a wide variety of tasks, I'll close it when those tasks are individually represented in other issues.

RE: the syntax requests in the original post, these are now addressed in:

• "Cycles" in which the agents solve a different problem in each subperiod EconForge/dolark.py#12
• Age varying magnitudes EconForge/dolark.py#13
• N/A -- punted for later
• N/A -- already implemented in dolark

My sense is that the most effective way for you to try to wrap your mind around what we want to do would be to start with some examples of our simplest models that currently ARE ALREADY solved correctly in both Dolo and HARK

These are covered in the issues in this repository, such as #6 #12 #13

the BST model:

This is already available as a DARKolo chimera, though it needs updating: #15

the one interesting part that does NOT exist now, but that you should add (to the DARKolo), is the python representation of the model that results from processing the YAML file with Dolo

#16