ConsBequestModel.py, ConsWealthPortfolioModel, and their inheritances

[dedwar65]

why does the "update_parameters" method of the "BequestWarmGlowConsumerType" class have the following conditional statement:

self.BeqCRRA *= self.T_cycle for the case where the bequest CRRA parameter is a single value?

If T_cycle = 2 for example, why is it that self.BeqCRRA is being multiplied by 2?

For the case where self.BeqCRRA is a list, this makes sense: [1,2] * T_cycle = [1,2, 1,2] which represents the two cycles of the agent's problem. This intuition just isn't making sense for me if bequest CRRA is a single parameter.

[mnwhite]

Hopefully it was converted to a list earlier. I.e. if 2.0 was passed, something converted it to [2.0] earlier. If that's not the case, then brackets need to be added there.

…

On Thu, Jan 18, 2024, 9:26 AM Decory Edwards ***@***.***> wrote: why does the "update_parameters" method of the "BequestWarmGlowConsumerType" class have the following conditional statement: self.BeqCRRA *= self.T_cycle for the case where the bequest CRRA parameter is a single value? If T_cycle = 2 for example, why is it that self.BeqCRRA is being multiplied by 2? For the case where self.BeqCRRA is a list, this makes sense: [1,2] * T_cycle = [1,2, 1,2] which represents the two cycles of the agent's problem. This intuition just isn't making sense for me if bequest CRRA is a single parameter. — Reply to this email directly, view it on GitHub <#1370>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFOTPGAU67CRQQOSUO3YPEWIPAVCNFSM6AAAAABCAL2S2CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA4DQNBQGE3TANY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dedwar65]

In "ConsRiskyAssetModel.py", I understand there's a RiskyAssetConsumerType which allows for an agent to solve for optimal consumption given they can invest only in a risky asset (so the share=1). There are also "fixedshare" and "portfolio" agent types which allow for fixed or optimal shares.

My question is, when the "IndShockRiskyAssetConsumerType" class is being defined, why isn't the method "get_Rfree" being called/referenced anywhere else in the code? It seems like this method should be called somewhere in one of the solver's for the "RiskyAssetConsumerType".

This is of interest because the other agent types, and presumably solvers as well, are made using "RiskyAssetConsumerType" as the parent class, so they would seemingly inherit this omission. Is the "get_Rfree" method not needed anywhere?

[mnwhite]

If I recall correctly, get_Rfree is a *simulation* method, not ever used during solution. It generates *many* values of the return factor (not really risk free), not ones that are to be used to calculate expectations during solution.

…

On Thu, Jan 18, 2024 at 11:55 AM Decory Edwards ***@***.***> wrote: In "ConsRiskyAssetModel.py", I understand there's a RiskyAssetConsumerType which allows for an agent to solve for optimal consumption given they can invest only in a risky asset (so the share=1). There are also "fixedshare" and "portfolio" agent types which allow for fixed or optimal shares. My question is, when the "IndShockRiskyAssetConsumerType" class is being defined, why isn't the method "get_Rfree" being called/referenced anywhere else in the code? It seems like this method should be called somewhere in one of the solver's for the "RiskyAssetConsumerType". This is of interest because the other agent types, and presumably solvers as well, are made using "RiskyAssetConsumerType" as the parent class, so they would seemingly inherit this omission. Is the "get_Rfree" method not needed anywhere? — Reply to this email directly, view it on GitHub <#1370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFOA3JCOFDXJR6Z2Y63YPFHWPAVCNFSM6AAAAABCAL2S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJYHA3DAMZSGY> . You are receiving this because you commented.Message ID: ***@***.***>

[dedwar65]

Is there any concise way of understanding why two programs ("ConsRiskyAssetModel.py" and "ConsPortfolioModel.py") are needed to solve the portfolio problem using HARK?

My current interpretation is that the former is used to define the agent and solver for the case of i) only having access to the risky asset and ii) having a fixed share in the risky asset across the simulation. The latter defines and solves what the end user has in mind when thinking of "optimal portfolio choice". So the former seems to be constructed only for completeness -- to not leave out "special cases" of the more general portfolio choice problem.

If that's true, then why does the more general "portfolio choice" program use the special case as the parent class? From the naive user's perspective, I am just not seeing why the "ConsRiskyAssetModel" is so important. Shouldn't it be that ConsPortfolioModel could standalone and i) and ii) could be implemented in a notebook which imports from ConsPortfolioModel? That would be the meaning of a special case of a more general setting, anyways.

P.S. None of these are major points. I am just reading through HARK's treatment of the portfolio choice problem as a naive end user.

[dedwar65]

A small, related question: A "SequentialPortfolioConsumerType" is defined in "ConsPortfolioModel.py" but there is no doc string which describes what this agent type is. I'm having some issue inferring what the agent type is from its defined methods.

[mnwhite]

"Needed" is probably the wrong word here. There have been *many* iterations of the portfolio choice model-- six, I think. The answer is simply that this is where the current version ended up. I agree that a reasonable framing of the model structure/hierarchy is that "the agent must choose 100% risky portfolio share" is a special case of "the agent can choose which percentage to allocate to a risky vs riskless asset". However, it's *also* a reasonable framing of model hierarchy to say that one "higher level" model is "the agent can only invest in a risk free asset", and another model on that level is "the agent can only invest in a risky asset"; then *below* that in the hierarchy is the more complicated model "the agent can choose which percentage to allocate to a risky vs riskless asset". In that framing, ConsPortfolioModel does properly "descend from" ConsRiskyAssetModel. But this is all a very good demonstration of the fundamental fact that *there is no proper model hierarchy* and we want to get away from this structure going forward. "Model inheritance" is not something we want to use going forward.

…

On Mon, Jan 22, 2024 at 8:13 AM Decory Edwards ***@***.***> wrote: Is there any concise way of understanding why two programs ("ConsRiskyAssetModel.py" and "ConsPortfolioModel.py") are needed to solve the portfolio problem using HARK? My current interpretation is that the former is used to define the agent and solver for the case of i) only having access to the risky asset and ii) having a fixed share in the risky asset across the simulation. The latter defines and solves what the end user has in mind when thinking of "optimal portfolio choice". So the former seems to be constructed only for completeness -- to not leave out "special cases" of the more general portfolio choice problem. If that's true, then why does the more general "portfolio choice" program use the special case as the parent class? From the naive user's perspective, I am just not seeing why the "ConsRiskyAssetModel" is so important. Shouldn't it be that ConsPortfolioModel could standalone and i) and ii) could be implemented in a notebook which imports from ConsPortfolioModel? That would be the meaning of a special case of a more general setting, anyways. P.S. None of these are major points. I am just reading through HARK's treatment of the portfolio choice problem as a naive end user. — Reply to this email directly, view it on GitHub <#1370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFNOFNV2KWCSI4ROVMLYPZQV3AVCNFSM6AAAAABCAL2S2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBTHE4DANZUGE> . You are receiving this because you commented.Message ID: ***@***.***>

[alanlujan91]

This is a good point. I think we should call all of these models some variation of "WealthInUtility", and whether we are talking about bequests, savings as luxury, or derived services from wealth (social or political power), depends on the particular interpretation of the user.

[dedwar65]

Two questions:

1. Are there articles in the literature which use a non-separable WUF specification such as the one found here: https://github.com/econ-ark/SolvingMicroDSOPs-LifeCycle/blob/main/content/paper/structural_estimation.pdf ? I have look at the references there but may have missed it. I ask because this is the specification that is implemented in "ConsWealthPortfolioModel.py". This would also point me in the direction of finding papers which explain what "bequests as a luxury good" means.

2. Similar to the point of the previous comment, each of these models are called "bequests", but as I understand it, HARK is not solving an "overlapping generations" model where it keeps tracks of households parents and descendants? If not, then how does HARK keep track of where a households assets go upon death to retain the notion of "bequests"? For ex., if we are modeling bequests, shouldn't I be able to pick out a wealthy household and how much that household left to its replacement during the simulation?

This is why I think calling it wealth-in-utility is nicer; no need to change the way assets are dealt with upon death to fit the implications of a title like bequests... assuming I understand this correctly.

[dedwar65]

Another small comment: In "ConsBequestModel.py", the consumer types are being called "BequestWarmGlowConsumerType" and "BequestWarmGlowPortfolioType" but they are being initialized by the dictionary "init_wealth_in_utility", which has "TermBeqFac = 0". As I understand it, isn't the "warm glow" referring to agents who get some utility from leaving a bequest upon death, which should be in reference to the terminal period (meaning "TermBeqFac > 0")?

Minor point, since the end-user can set the values of these parameters before solving. But a change could make the default settings of the code consistent with the definitions of these terms in the literature.

[dedwar65]

When trying to duplicate what is done here https://github.com/econ-ark/HARK/blob/master/examples/ConsBequestModel/example_ConsIndShockComp.ipynb but for the consumer type with bequest motives and portfolio choice, a bug occurs when setting beq_type.TermBeqFac = 0.

I've made a branch "examples-beq-extensions" which contains the example notebook producing the bug.

[alanlujan91]

@dedwar65 just tried to debug this and it solves on my end. Have you tried this again? maybe re-install the environment?

[dedwar65]

@alanlujan91 I just reran it and got the same error. I published a branch called examples-beq-extensions. There you will find a notebook called example.ConsPortfolioComp.ipynb which replicates the error.

To recap the issue: when I try to make the analog of the example.ConsIndShockComp.ipynb notebook, there is an issue specific to how the cfunc is defined for portfolio choice (cfunc_adjust).