[Question] A problem with stages

[Mv77]

Hi,

I have been working on a new risky asset model with a pension contribution scheme, and have a question about how to implement the agent type's simulation method in the most compatible way with the current tools.

The only relevant characteristic of the model is that, at each time-period, the agent's problem can be broken down into three sequential sub-stages:

1. Defining the income-deduction scheme going forwards.
2. Moving assets between the risky (iliquid) and risk-free (liquid) account.
3. Consuming out of liquid assets.

I have a working solver and am thinking of how to implement the simulate method. Looking at the simOnePeriod(self): from AgentType, it works by calling getStates -> getControls -> getPostStates once. With my setup, it would be useful if I could split the time-period into the three sub-stages and run this sequence three times, with a stage's postStates becoming the next stage's states.

@llorracc suggested this could be achieved with the cycles property, and mentioned the Ski instructor example. Yet, I'm not quite sure how this would be achieved: the Ski instructor makes the same decisions at every stage and just cycles through different parameter values.

So I wanted to ask if this stage-splitting is possible with the current tools, if there is an example you could point me to, or if it'd be better to create the class' own simOnePeriod method with these characteristics.

[Mv77]

Hi again,

I was revisiting this question with @llorracc today, and he told me I should tag @mnwhite and @sbenthall for the discussion.

We are sure that the Ski instructor example could be adapted in some way to address this period-with-stages kind of problems. One could:
a) Treat every sub-period as a period, so that a Ski instructor that lives for 30 years would have a T_cycle of 30*4. One could then find a way to call a different solve/simulate-onePeriod method at different times (is this already possible?).
b) Write one's own simOnePeriod function which would call sub-functions for every sub-stage.

@llorracc recalled discussions of this kind of features being already built into HARK and just not being documented yet.

So we are still trying to figure out what would be the most backward and forward-compatible way of implementing these types of agents, and were wondering if you could provide some guidance?

[mnwhite]

HARK already has the capability to use different solveOnePeriod functions across periods. Just put the different functions into a list, put that in the solveOnePeriod attribute, and then name 'solveOnePeriod' in the time_vary attribute. Because you're treating "subperiods" as periods, you'll need to put dummy values (like None) into the time-varying attributes for the periods when these objects are irrelevant. This isn't how a "normal human" would describe the problem, so it might be most convenient to have the user pass "raw" time-varying attributes that don't have dummy values, and then you write a simple method that "interlaces" Nones into these lists as appropriate. On the simulation side, my recommendation would be to not use the getShocks, getStates, getControls, getPostStates framework and just overwrite simOnePeriod directly with custom code. If you treat the sub-periods as actual periods, this top-level method might just be a fork method that calls sub-period-specific methods depending on the phase you're in. In terms of future modularity, one big thing we would need to do is to change the indexing of shocks and the domain of the value function (as recorded by the solution output). As is, IncomeDstn[t] refers to the distribution of income shocks that arrive at the beginning of period *t+1*, because we use that information to solve the agent's problem at t; this is also why the indexing for IncomeDstn is t-1 in the simulator. While it was natural to structure things this way, and we generate (marginal) value functions over m_t (or generally, the decision-time states), the way economists usually think about them, this makes it harder to make the solvers modular and "chain up" with different types of (sub)periods. To structure things better for modularity, we would want to take expectations over period t shocks *in the period t solver*. That is, everything that happens in period t should actually be handled by the function that solves the period t problem. Thus the (marginal) value functions that are stored in the solution for period t would be what Chris and I call the "end-of-period (marginal) value functions" for period t-1. The end of period t-1 *is* the beginning of period t; what I call "post-states" are the interface between consecutive periods. Then we could chain together any solvers whose "interface states" match (and whose solution representation has the expected attributes).

…

On Wed, Sep 2, 2020 at 2:00 PM Mateo Velásquez-Giraldo < ***@***.***> wrote: Hi again, I was revisiting this question with @llorracc <https://github.com/llorracc> today, and he told me I should tag @mnwhite <https://github.com/mnwhite> and @sbenthall <https://github.com/sbenthall> for the discussion. We are sure that the Ski instructor example could be adapted in some way to address this period-with-stages kind of problems. One could: a) Treat every sub-period as a period, so that a Ski instructor that lives for 30 years would have a T_cycle of 30*4. One could then find a way to call a different solve/simulate-onePeriod method at different times (is this already possible?). b) Write one's own simOnePeriod function which would call sub-functions for every sub-stage. @llorracc <https://github.com/llorracc> recalled discussions of this kind of features being already built into HARK and just not being documented yet. So we are still trying to figure out what would be the most backward and forward-compatible way of implementing these types of agents, and were wondering if you could provide some guidance? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFOQEGAFFTKQEGLU6R3SD2B2HANCNFSM4QNUVMKA> .

[Mv77]

Thank you! That makes a lot of sense. I did not know one could have time-varying solveOnePeriod methods.

I'll have a go at adapting my solution to this framework and code up simulation methods soon. I'll post progress/questions here.

[Mv77]

I've followed @mnwhite 's advice and implemented a time-varying solveOnePeriod version where each sub-stage is treated as a period. It works great! (thank you)

I'm now moving on to the simulation methods. As suggested, since each sub-stage is being treated as a period, I'll code up my own simOnePeriod which will call stage-specific methods. I will keep you posted.

[llorracc]

Great, thanks for the update!

…

On Sun, Sep 20, 2020 at 9:15 PM Mateo Velásquez-Giraldo < ***@***.***> wrote: I've followed @mnwhite <https://github.com/mnwhite> 's advice and implemented a time-varying solveOnePeriod version where each sub-stage is treated as a period. It works great! (thank you) I'm now moving on to the simulation methods. As suggested, since each sub-stage is being treated as a period, I'll code up my own simOnePeriod which will call stage-specific methods. I will keep you posted. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#826 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK73AHBX7Y7G6J27RLD3SG2SL3ANCNFSM4QNUVMKA> .

-- - Chris Carroll

[Mv77]

#832 now has an explicitly stage-oriented solution and simulation strategy that seems to work and follows @mnwhite 's advice.

I will focus on cleaning up the code and producing a well-calibrated life-cycle example in the following days.