Closed sbenthall closed 4 years ago
@llorracc Some clarifying questions/comments:
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.
'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?
'Absolute time' -- HARK doesn't have this yet, so I think we should focus on 1 and 2 for now.
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.
- "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:
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:
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.
@sbenthall, @albop
This is to follow up on some of the things I was saying in our call earlier today.
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:
For the BST model:
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.
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.
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.
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.
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:
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
From @llorracc