The Rate of Return Should Be Allowed to Be Risky In ConsIndShockModel

[llorracc]

At present, in ConsIndShockModel, the return factor is given as Rfree, a nonstochastic scalar.

The code should be generalized so that it can accommodate a return that is risky (which should be called Risky), and whose structure is given by a Distribution object.

Once that is done, it would be very easy to build a class that inherits from ConsIndShockModel and solves the classic portfolio choice problem with a risky and a safe asset.

[mnwhite]

Do you want this as a separate AgentType than IndShockConsumerType, or to overwrite / extend it? The model with risky returns but no portfolio choice can be done with the current toolkit using the "Markov agent type"; the interest factor is allowed to vary in that. It will be solved somewhat inefficiently, as the Markov model is set up to allow risky returns that are serially correlated, whereas you're describing iid returns.

…

On Sat, Jan 22, 2022 at 12:58 PM Christopher Llorracc Carroll < ***@***.***> wrote: At present, in ConsIndShockModel, the return factor is given as Rfree, a nonstochastic scalar. The code should be generalized so that it can accommodate a return that is risky (which should be called Risky), and whose structure is given by a Distribution object. Once that is done, it would be very easy to build a class that inherits from ConsIndShockModel and solves the classic portfolio choice problem with a risky and a safe asset. — Reply to this email directly, view it on GitHub <#1107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFJR3AWFGNYL2AVVSO3UXLV2RANCNFSM5MSH4GOA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alanlujan91]

Was just thinking about this the other day. In particular a generalized portfolio choice model with share constraints.

1. Portfolio Choice - risky share in (0, 1), constrained borrowing a >=0
2. ConsIndShock - risky share constrained at 0; natural or artificial borrowing constraint a >= abar
3. ConsRiskyIndShock - risky share constrained at 1; constrained borrowing a >= 0

[llorracc]

Allowing (optionally) for the rate of return to be (uncontrollably) risky doesn't add any states or controls, and the attractive thing about it is that if that capacity exists then a model with portfolio choice is very easy to build on top of it as an extension that just wraps the model without portfolio choice. That is, gothic v'_{t}(a) for any given portfolio share is computed by evaluating the expected marginal value for the consumer in the next period who is unalterably subject to a portfolio whose riskiness is determined by that portfolio weight. The classic portfolio choice model is then super easy to build.

[mnwhite]

To put things in HARK terms, continuing from Alan's comment. Is this what you want: 1) IndShockConsumerType's functionality remains the same, but some details get twiddled under the hood to make it extensible. 2) We add a new AgentType that extends IndShockConsumerType, swapping the float Rfree for the distribution Risky. 3) We add a second new AgentType that extends (2), replacing the current portfolio choice consumer type (I can't remember what it's called). That is, the point is to bring the portfolio model into the "model tree" rather than being separate. Is that right?

…

On Sun, Jan 23, 2022 at 11:16 PM Christopher Llorracc Carroll < ***@***.***> wrote: Allowing (optionally) for the rate of return to be (uncontrollably) risky doesn't add any states or controls, and the attractive thing about it is that if that capacity exists then a model with portfolio choice is very easy to build on top of it as an extension that just wraps the model without portfolio choice. That is, gothic v'_{t}(a) for any given portfolio share is computed by evaluating the expected marginal value for the consumer in the next period who is unalterably subject to a portfolio whose riskiness is determined by that portfolio weight. The classic portfolio choice model is then super easy to build. — Reply to this email directly, view it on GitHub <#1107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFPQJ2C4L3LL5XFYSP3UXTHDVANCNFSM5MSH4GOA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[llorracc]

Close, but my idea was to combine 1 and 2 so that IndShockConsumerType would itself handle a risky interest rate if (optionally) provided. If the user provided only a safe rate, it would use that. If the user provided only a risky rate, it would use the risky rate.

If the user provided BOTH a risky and a safe rate,

• it would determine which to use based on a boolean like UseRiskyReturn
  • if UseRiskyReturn was not set it would spit out a warning log message and plow ahead to use one of them (presumably the risky one).

This does actually qualify as a case where "IndShockConsumerType's functionality remains the same, but some details
get twiddled under the hood to make it extensible" in the sense that the new IndShockConsumerType should work with all existing code.

Then we would add a second new AgentType that extends IndShockConsumerType to solve the canonical portfolio choice problem between a risky and safe asset.

That is, the point is to bring the portfolio model into the "model tree" rather than being separate. Is that right?

Yes.

I don't propose we decommission the existing portfolio model -- it has useful extra bells and whistles. But the canonical portfolio choice problem is such a simple extension of the problem with risky rates that it makes sense for it to be added as part of the model tree.

[alanlujan91]

Some of the functionality needed for this is on @Mv77's RiskyAssetConsumerType such as creating the Risky Distribution. Because ConsRiskyAssetModel inherits from IndShockConsumerType, it would be impossible for IndShockConsumerType to inherit from RiskyAssetConsumerType to obtain access to update_RiskyDstn (I believe this creates an inheritance loop).

One idea is to move the update_RiskyDstn to IndShockConsumerType.

The other is that as of right now, RiskyAssetConsumerType does not have a solver. Giving this consumer type a solver that inherits from ConsIndShockSolver could be straightforward while making the changes proposed.

[llorracc]

This reminds me that a virtue of @Mv77's `RiskyAssetConsumerType` is that it allows for correlation between the risks to the rate of return and the risks to labor income risk, which I had not been contemplating in the design I had in mind (I was just thinking of allowing for IID shocks to the risky asset as to the transitory and permanent shocks). If we wanted to handle the possible covariance case we would need to allow for the possibility of different variance/covariance matrices of transitory and permanent shocks for each possible realization of the risky rate. Maybe `RiskyAssetModel` already does everything I was proposing that the revised `IndShockConsumerType` should do and more? Does it basically just modify `IndShockConsumerType` to allow for (1) risky returns; with (2) arbitrary correlations with the transitory and permanent shocks? And then solve the consumption problem? If I understand the structure of how things work now, `IndShockConsumerType` takes as an input the mxn joint combinations of the transitory and permanent shocks and their joint probabilities. When we construct those we by default construct them as IID, but in principle someone who wanted to construct them with a covariance could do that, and `IndShockConsumerType` would work without modification and give the right answer. Partly this goes back to a design question we have discussed before, whether to draw all the stochastic shocks that will occur in period $t$ at one go, or whether to allow shocks to be drawn whenever convenient in the course of the evolution of the problem. My sense is that the latter is considerably easier for us humans to deal with, and the former is easier for the computers.

…

On Mon, Jan 24, 2022 at 3:07 PM alanlujan91 ***@***.***> wrote: Some of the functionality needed for this is on @Mv77 <https://github.com/Mv77>'s RiskyAssetConsumerType such as creating the Risky Distribution. Because ConsRiskyAssetModel inherits from IndShockConsumerType, it would be impossible for IndShockConsumerType to inherit from RiskyAssetConsumerType to obtain access to update_RiskyDstn (I believe this creates an inheritance loop). One idea is to move the update_RiskyDstn to IndShockConsumerType. The other is that as of right now, RiskyAssetConsumerType does not have a solver. Giving this consumer type a solver that inherits from ConsIndShockSolver could be straightforward while making the changes proposed. — Reply to this email directly, view it on GitHub <#1107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK73T4HCGMJMCQYHDQCTUXWWP5ANCNFSM5MSH4GOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- - Chris Carroll

[alanlujan91]

Unfortunately, it does not.

RiskyAssetConsumerType allows for the creation of a RiskyDstn that is independent from IncomeDstn. There is also no correlation between TranShkDstn and PermShkDstn. All three distributions are independent.

Additionally, RiskyAssetConsumerType has no solver. It is an abstract class from which PortfolioConsumerType (among others) inherits. PortfolioConsumerType does have a ConsPortfolioJointDistSolver, but it remains untested as there is no constructor of a discrete joint distribution with covariances in HARK. It works when we tell the solver that the distribution is joint (bundled in ShockDstn) but it is much slower than the standard solver.

What I am proposing is adding a solver to RiskyAssetConsumerType that handles the solution with 3 independent distributions, RiskyDstn, TranShkDstn, and PermShkDstn. Perhaps an extension would be to allow for a joint distribution solver, but we'd first need to focus on a method to discretize a joint distribution with covariances.

[llorracc]

Oh, I remember distinctly that @Mv77 wrote some code to construct discrete joint distributions with covariances, and it was around the time he was making RiskyAssetConsumerType. I had thought it was for the purpose of allowing covariance between labor income and rate of return shocks.

In any case, if there is not an already-existing tool that does the Risky-Return IID version of what I have described, I would like to put the suitable modification of IndShockConsumerType described above on the agenda. (With the optionality described, so that it will continue to work without modification with existing code).

I could be persuaded that this would be best done in three steps as Matt sketched, but am concerned that we have far too many Type objects for anybody to keep track of easily, and it would be better to make each of our types more powerful than to add a specialized type for every conceivable combination of desiderata.

[alanlujan91]

There's a quick WIP PR of this in #1108.

One reason I might prefer the 3 steps is that we already have a RiskyAssetConsumerType without a solver. This PR provides a solver for this type AND I think the name of the type is fitting to the model.

This is a working PR however, and we can discuss this further at the Wednesday meeting.

[llorracc]

OK, let's discuss Weds Btw now and then, consider idea of having RiskyAssetConsumerType and IndShockConsumerType both inherit from some upstream type as a solution for the "no circular inheritance" problem.

…

On Mon, Jan 24, 2022 at 8:22 PM alanlujan91 ***@***.***> wrote: There's a quick WIP PR of this in #1108 <#1108>. One reason I might prefer the 3 steps is that we already have a RiskyAssetConsumerType without a solver. This PR provides a solver for this type AND I think the name of the type is fitting to the model. This is a working PR however, and we can discuss this further at the Wednesday meeting. — Reply to this email directly, view it on GitHub <#1107 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK76SSE4LWMMBXGAYK4TUXX3NTANCNFSM5MSH4GOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- - Chris Carroll

[Mv77]

Mv

Yes, RiskyAssetConsumerType was originally intended as a class to nest all the models that inherited from ConsIndShock and had a risky asset: ConsPortfolio, the housing agent, my jmp, RiskyContrib. All those have different solvers but share things like needing to create, discretize and draw from a risky return factor distribution. I thought at the time putting all that in a class would be useful, and it was at least for me.

What Alan is saying is true. This was thought as a drawer inside the ConsIndShock shelve, not the other way around. Making it the greater class would need work.

[Mv77]

This reminds me that a virtue of @Mv77's RiskyAssetConsumerType is that it allows for correlation between the risks to the rate of return and the risks to labor income risk, which I had not been contemplating in the design I had in mind (I was just thinking of allowing for IID shocks to the risky asset as to the transitory and permanent shocks).

Nope, again Alan is right. RiskyAssetConsumerType is a container, solver-less method.

ConsPortfolio's solver does allow for arbitrary joint distributions of income and returns. The issue is that the init method creates only independent distributions.

[Mv77]

Oh, I remember distinctly that @Mv77 wrote some code to construct discrete joint distributions with covariances, and it was around the time he was making RiskyAssetConsumerType. I had thought it was for the purpose of allowing covariance between labor income and rate of return shocks.

Yes! I added support for a multivariate correlated normal a while ago. #948

What you might be thinking about, however, is a multivariate lognormal?

[llorracc]

It occurs to me now that a multivariate correlated lognormal might get tricky if we want to preserve the nice properties we have now for the expectation of the transitory and permanent shocks being 1. I guess they would be 1 in an unconditional sense, but allowed to be conditionally different from 1 depending on the realization of the rate-of-return shock.

Anyway, back to the main theme, which is that it seems to me the simplest approach would be to put the Risky class upstream of everything, and have everything inherit from it. If the user does not deliberately choose to make the rate of return risky, then it isn't. If they do choose a risky return, IndShockConsumerType will handle it. For that matter, the risky asset type could be upstream also of a MertonSamuelsonConsumerType which would have no labor income (or perfectly certain labor income). Then the basic frictionless consumer portfolio choice model could be downstream of IndShockConsumerType and would just feed IndShockConsumerType different rate of return distributions corresponding to different portfolio allocation choices.

[alanlujan91]

Yes! I added support for a multivariate correlated normal a while ago. #948

What you might be thinking about, however, is a multivariate lognormal?

This is great! I was not familiar with this. Is there a use case on HARK already?

[llorracc]

@alanlujan91, this is just to tie this to the increasingly related discussion at #1106.

The upshot is that I now want the code to incorporate three contributors to Rfree: RfreeInd, RfreeAgg, and RfreeTime and similarly for Risky. For Risky, in practice we will usually want to have RiskyInd and RiskyTime be time_inv and equal to 1.0, with RiskyAgg containing the structure for the risky distribution.

At present, I think we should punt on the question of how to handle a case where there might be a desire to have predictable changes in the degree of riskiness. So, you could make a test for whether more than one of the three RiskyInd, RiskyAgg, and RiskyTime is nondegenerate (length greater than 1), and if so throw an exception with a message saying that we have not yet taken a stand on how to combine risks.

cc'ing @wdu9 and @Mv77 in case they have comments. Especially @wdu9 since I envision him using this revised version of IndShockConsumerType for his Monte Carlo sims.

[alanlujan91]

New models added in #1108