econ-ark/HARK

Time, age, period, epoch, moment, date, ....

Closed this issue · 9 comments

llorracc commented

We need to define, and stick to, a terminology for the different temporal things that we deal with in our models.

With @wdu9's tools for magically turning HARK steady-state microeconomic models into macroeconomic models by the computation of the appropriate Jacobians, we need (for example) to be able to coherently talk about agents' age, versus chronological time.

For the nonce I propose that:

  1. We consider a "nonce" as a freely available temporal indicator that we have not used yet (:->)
  2. We try to use "age" (and not "time") as the default temporal nominative for IndShockConsumerType models
    • So that Mateo's recent merge would have said he was adding a test for proper treatment of locations of parameters across ages
  3. We use "date" for the thing needed for macro models
    • @wdu9 has figured out how to construct MIT shocks at a moment of time with IndShockConsumerType models
    • e.g. "the central bank will raise rates at a date 5 quarters in the future" in text
    • This means we can have a date at which many agents of different ages exist
  4. We use "step":
    • to keep track of where we are in a sequence of calculations conceptualized as happening simultaneously
  5. We deprecate the use of the word "time" altogether until we are used to using these other words for disambiguating everything
sbenthall commented

A few questions:

  • Does this imply a change in mathematical notation, or just in our verbal language for discussing models?
  • Does this imply a change in variable names in the software itself, or just in our verbal language for discussing models?
  • When there is an aggregated market action, does that occur as a step in the same date as the AgentType actions that respond to it? Or that feed into it?
  • Is "period" also deprecated?
llorracc commented

These are good questions, to which we should devote some future thought.

At present, my inclinations are:

  • math notation: as a suggestion, yes
  • variable names: definitely
  • "When there is an aggregated market action...":
    • We can't predetermine this. Different models need to do things differently.
  • "period" should have an exact usage as defined by the DARK work Pablo is undertaking
    • In that work, only "transition" blocks are allowed to interact with multiple different periods
      • Even "transition blocks" have only the right to connect adjacent periods
      • That is, a "transition" cannot reference something that is two periods in the future or past
    • A period can include several stages
    • Each stage can have a sequence of "moves" (or "operations", or some other nontemporal word)
llorracc commented

@sbenthall,

One of the reasons I'm a bad manager is that I leave things like this open ended and can't remember to assign anyone to do them.

I feel that this is something that you and Pablo and Alan and Matt White all need to collaborate on so that there is

  1. An unambiguous correct usage for each of the terms
  2. which is clearly and easily used whether the model is being expressed in code or in LaTeX math
  3. Where it is easy to paste back and forth between the code and the math (in some sense -- at least, when you are looking at the code you should be unambiguously able to translate that into a LaTeX math expression
  4. Probably some other desiderata that I haven't thought of but that you should be in charge of organizing a discusson about and coming to a consensus on. (One of the things you were working on earlier that has kind of fallen into abeyance was the organization of workflows to get put these kinds of things on a path to solution, rather than just lingering forerver as "wouldn't it be nice someday" issues). I think that's something you are good at when you apply yourself; maybe we can use this as an exemplar of how to handle such things going forward.

I'm super busy from now to the end of the fall semester so can only be consulted occasionally about this. But there's a lot of collective brainpower on this thread, and brainpower I am confident is capable of making good decisions.

sbenthall commented

Ok, I will add this to my task list.

I do love the idea of a consensus-building workflow with respect to this and other matters, and I appreciate a great deal the thoughtful feedback and delegation.

The model I would lean toward is something along the lines of Python Enhancement Proposal (PEP) process, which is how Python develops and approves of design documents, which then guide development. Other projects I've been involved with have used lightweight versions/variations of the PEP process.

With an understanding of how that process works in place, then a proposal about this issue can be drafted, and feedback collected from stakeholders.

When the proposal is approved, it becomes binding and a guide to development -- it's something that can be referred to in code reviews, and when prioritizing tickets.

I see that at one point I set up this repository for an Econ-ARK governance process. I believe we used it once when settling code standards given the use of mathematical symbols.
https://github.com/econ-ark/governance

I'll revisit that repository and see if what's there still seems like a viable structure for Econ-ARK. The fact that we haven't used it much recently is perhaps a sign that something is wrong with it. But that may just be because of turnover in interest or other reasons for lack of focus.

MridulS commented

The model I would lean toward is something along the lines of Python Enhancement Proposal (PEP) process, which is how Python develops and approves of design documents, which then guide development. Other projects I've been involved with have used lightweight versions/variations of the PEP process.

For some more "scientific-y" PEP like examples you can also have a look at NumPy (https://numpy.org/neps/), Scikit-Learn (https://scikit-learn-enhancement-proposals.readthedocs.io/en/latest/index.html), SPECs (https://scientific-python.org/specs/)

  • ❤️1
sbenthall commented

@llorracc I've started a draft EEP here, with the wording of the most recent proposal from this issue.

https://github.com/econ-ark/governance/wiki/EEP-V:-Conventions-about-Time

As you've noted, as it stands, this is just-another-proposal, and the process of getting consensus around it will take some effort and availability of the various stakeholders.

sbenthall commented

This is an improved EEP draft which:

  • is in the HARK repository wki. This is better because HARK is a public repo. (governance is currently private.)
  • is in the format of the EEP template, adapted from the NEP template

https://github.com/econ-ark/HARK/wiki/EEP-draft---Conventions-about-Time

The EEP template provides a rubric for analyzing the new design in ways that identify the blockers to action. In particular, what I see is:

  • HARK/NARK currently has some conventions about time which are tied to the existing code.
  • CDC's proposal on this issue is not backwards compatible with the current code, which means adopting the convention requires, first, an implementation plan
  • more information about the use case raised by @wdu9 would be helpful for figuring out the Usage/Impact/desired API

Because this proposal is primarily about conventions and notation, and not about implementation, I believe it should be possible to (a) establish conventions and (b) support them through incremental improvements through to the adoption of DARK/HARK 2.0/whatever. But that will require identifying what, if anything, needs to be changed about the current HARK code and documentation to move it forward.

Recall that HARK currently:

  • uses $t$ and $T$ ubiquitously when constructing an agent's problem
  • supports 'time-varying' parameters which variously get used as lifecycle or cyclic/seasonal parameters depending on model configuration; in all cases, these are indexed by t
  • tracks agent 'age', but only in simulation, in order to accommodate the birth and mortality mechanics.
  • Indeed, the way HARK currently models time is much discussed, rarely documented, and very tied up with how the simulator works, as opposed to how models are constructed for solving. See this list of related issues: https://github.com/econ-ark/HARK/wiki/EEP-draft---Conventions-about-Time#discussion

What I am currently missing is an understanding how how HARK currently models the interaction between markets and AgentTypes in solution and simulation, especially with the mortality effects.

So, based on all of that, here are some concrete things that could be done to improve the situation:

  • Get more detail about @wdu9's use case, and use it to motivate incremental changes to HARK that accommodate it better
  • Use 'tick' instead of 'time', because it still starts with a $t$ and so requires fewer changes than 'nonce'.
  • Try to abstract out the HARK simulation code into its own object hierarchy, decoupled from specific models. That way, an individual AgentType could be defined in terms of ticks, but the simulator (which takes responsibility for the mortality modeling) could manage the AgentType's internal tick-counter (age), keeping it in time with the global tick counter (date). Separating this code logically could help disentangle things.

The only downside to the latter move that I can see is if AgentType models are designed with, say, rational expectations of bequests that depend on the mortality logic. Maybe that's a dealbreaker. But in other work with HARK (i.e., SHARKFin), cleaner separation of simulation logic and the agent optimization problem has been a good thing.

llorracc commented
sbenthall commented