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

[llorracc]

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]

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]

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]

@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]

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]

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/)

[sbenthall]

@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]

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]

The main feedback I have is that I think the right concept is not a tick. it is what I have been calling a "transition" from one "period" to another. The 'tick' terminology seems to have a specific meaning in the context of agent-based models in which there is generically not a possibility that the agent will have an interesting transition to a period in which their problem might be fundamentally different. It is about creating a global Newtonian universal time indicator in which everyone in a simulation moves forward, perhaps subject to similar "aggregate" shocks. But a bedrock (implicit) idea seems to be that the agent faces the same problem after a tick that they did before the tick. We want the agent to maybe make a "transition" from a working phase of life to a retired phase of life, where the states, controls, utility functions, etc may all be different in the retirement phase than in the working phase. We do need a terminology to refer to aggregate transitions (say, from boom to recession) that affect everyone simultaneously). But I'm afraid that the use of 'tick for those events will confuse people coming from the ABM world in which the meaning of tick is clear, and is clearly not something that encompasses individual transitions.

…

On Wed, May 31, 2023 at 11:08 AM Sebastian Benthall < ***@***.***> wrote: 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 <https://github.com/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 <https://github.com/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. — Reply to this email directly, view it on GitHub <#1264 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK74EAXW6OE3ZDHMQEMDXI5NF7ANCNFSM6AAAAAAXYKOAOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- - Chris Carroll

[sbenthall]

Hmmm. I wonder if you could elaborate on how the following are connected: - your proposal about using 'age' and date' - your proposal about 'periods' and 'transitions' - the current notation and implementation in HARK, including $t$ and $T$ These feel like three different tracks to me, at this point. I believe it is the legacy of dynamic programming which makes $t$ implicitly recurrent. I would say that this is also a problem with "period", which connotes cyclicity. I think 'tick' carries fewer meanings than you think it does. It's a quite simple programming construct. Recall that in most ABMs agents are not "solving problems" at all, and so the simulation can have arbitrary structure. Loosely speaking, there seems to be a difference between subjective time, in which an agent imagines their future when solving for their decision rule, and objective time, when they participate in a multiagent environment. Most simple models conflate these. Maybe you are right and 'tick' is an inappropriate term for how an agent sees their own problems? On the other hand, "year" is an objective measure of time and also a way I see my own life's problems. "Tick" is, as I see it, just a generic term for discrete time. But I am quite confused by "transition". I have thought that going from a state to a post state is a "transition". Recently you've been using "transition" for the movement from the post state to the next state. Are they both transitions? If the first is not a transition, what is it? And why rename it? On Thu, Jun 1, 2023, 11:24 PM Christopher Llorracc Carroll < ***@***.***> wrote:

…

The main feedback I have is that I think the right concept is not a tick. it is what I have been calling a "transition" from one "period" to another. The 'tick' terminology seems to have a specific meaning in the context of agent-based models in which there is generically not a possibility that the agent will have an interesting transition to a period in which their problem might be fundamentally different. It is about creating a global Newtonian universal time indicator in which everyone in a simulation moves forward, perhaps subject to similar "aggregate" shocks. But a bedrock (implicit) idea seems to be that the agent faces the same problem after a tick that they did before the tick. We want the agent to maybe make a "transition" from a working phase of life to a retired phase of life, where the states, controls, utility functions, etc may all be different in the retirement phase than in the working phase. We do need a terminology to refer to aggregate transitions (say, from boom to recession) that affect everyone simultaneously). But I'm afraid that the use of 'tick for those events will confuse people coming from the ABM world in which the meaning of tick is clear, and is clearly not something that encompasses individual transitions. On Wed, May 31, 2023 at 11:08 AM Sebastian Benthall < ***@***.***> wrote: > 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 > <https://github.com/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 <https://github.com/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. > > — > Reply to this email directly, view it on GitHub > <#1264 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAKCK74EAXW6OE3ZDHMQEMDXI5NF7ANCNFSM6AAAAAAXYKOAOA > > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- - Chris Carroll — Reply to this email directly, view it on GitHub <#1264 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQZEHUTOFEYHYNG25XBFDXJFMIBANCNFSM6AAAAAAXYKOAOA> . You are receiving this because you were mentioned.Message ID: ***@***.***>