ConsBequestModel.py, ConsWealthPortfolioModel, and their inheritances
Closed this issue · 12 comments
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.
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?
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.
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.
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.
Two questions:
-
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.
-
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.
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.
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.
@dedwar65 just tried to debug this and it solves on my end. Have you tried this again? maybe re-install the environment?
@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).