search

econ-ark / HARK

Heterogenous Agents Resources & toolKit
Apache License 2.0
315 stars 195 forks source link

Correct human wealth with risky returns #1403

Closed mnwhite closed 1 month ago

mnwhite commented 1 month ago

Through a combination of math and experimentation, I've found the correct computation of "human wealth" in the presence of risky returns. I've implemented it for RiskyAssetModel and FixedShareModel. On the next commit I'll get it working for the PortfolioChoice models, and then turn to ConsMarkovModel.

The good news is that I have the right answer. The bad news is that (other than partly getting to it via whiteboard math and following some clues from experimentation) I don't have a proof of why it's correct. I'll write it up in a short file and circulate.

This PR will also fix a very small mistake in the computation of hNrm by calc_limiting_values; that code uses an alternate definition of hNrm that will be off by exactly 1.

llorracc commented 1 month ago

Great!

I imagine that somehow it depends on the extremes of the shock distribution.

Are you using what we have now declared to be the default spec of discrete approximations, where there the infimum and maximum points are represented but have zero probability weight? Actually, I'm not sure whether we have substituted those for the old distributions in, say, ConsIndShock ...

On Thu, Mar 28, 2024 at 3:56 PM Matthew N. White @.***> wrote:

Through a combination of math and experimentation, I've found the correct computation of "human wealth" in the presence of risky returns. I've implemented it for RiskyAssetModel and FixedShareModel. On the next commit I'll get it working for the PortfolioChoice models, and then turn to ConsMarkovModel.

The good news is that I have the right answer. The bad news is that (other than partly getting to it via whiteboard math and following some clues from experimentation) I don't have a proof of why it's correct. I'll write it up in a short file and circulate.

This PR will also fix a very small mistake in the computation of hNrm by calc_limiting_values; that code uses an alternate definition of hNrm that will be off by exactly 1.

  • Tests for new functionality/models or Tests to reproduce the bug-fix in code.
  • Updated documentation of features that add new functionality.
  • Update CHANGELOG.md with major/minor changes.

You can view, comment on, or merge this pull request online at:

https://github.com/econ-ark/HARK/pull/1403 Commit Summary

File Changes

(1 file https://github.com/econ-ark/HARK/pull/1403/files)

Patch Links:

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/pull/1403, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKCK73YAAETWSVQ4BUSGU3Y2RYXNAVCNFSM6AAAAABFNMUAOKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYTIMBRHEYDMMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

mnwhite commented 1 month ago

No, the infimum and supremum of distribution support hasn't been put in yet. There's no special impact of the extreme values in the human wealth formula, but I suspect tail realizations have a disproportionate impact on "human wealth", especially with unbounded support. I'll play with it.

mnwhite commented 1 month ago

I think I'm clicking the wrong thing @alanlujan91 in trying to make you a reviewer. Don't merge this yet, obviously.

mnwhite commented 1 month ago

More mixed news: The updated hNrm formula seems to be correct when there's portfolio choice... but now MPCmin is off by 0.0001 or so. I'm not sure if this is because ShareLimit is slightly off, or because there's a mismatch between solving a large (but finite) number of periods vs a true infinite horizon.

mnwhite commented 1 month ago

This is mostly done and ready to be merged. The one thing that hasn't been done is implementing the "refined share search" in the bells-and-whistles ConsPortfolioModel. So hNrm and MPCmin are calculated correctly (and stored in the solution), but not actually used for the consumption function, because they can break due to tiny inaccuracies in the ShareFunc.

There are three options here:

1) Leave as is and merge, returning to do the "refined search" for that solver in another PR because it takes substantial work. Also leave hNrm and MPCmin unused by the cFunc for now.

2) Use hNrm and MPCmin to construct the limiting linear cFunc, with the knowledge that it will break if aXtraMax is too high. Maybe leave a note in the documentation about this.

3) Do all of the remaining work on ConsPortfolioModel in this PR.

llorracc commented 1 month ago

Seems like something to discuss at next Econ-ARK meeting

On Tue, Apr 9, 2024 at 1:56 PM Matthew N. White @.***> wrote:

This is mostly done and ready to be merged. The one thing that hasn't been done is implementing the "refined share search" in the bells-and-whistles ConsPortfolioModel. So hNrm and MPCmin are calculated correctly (and stored in the solution), but not actually used for the consumption function, because they can break due to tiny inaccuracies in the ShareFunc.

There are three options here:

1.

Leave as is and merge, returning to do the "refined search" for that solver in another PR because it takes substantial work. Also leave hNrm and MPCmin unused by the cFunc for now

1.

Use hNrm and MPCmin to construct the limiting linear cFunc, with the knowledge that it will break if aXtraMax is too high. Maybe leave a note in the documentation about this. 2.

Do all of the remaining work on ConsPortfolioModel in this PR.

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/pull/1403#issuecomment-2045790836, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKCK77HQXYH2K2GKO2EADTY4QTV5AVCNFSM6AAAAABFNMUAOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVG44TAOBTGY . You are receiving this because you commented.Message ID: @.***>

--

mnwhite commented 1 month ago

Huh, I didn't see those code comments until just now. I was looking for them because you mentioned something in the meeting today.

llorracc commented 1 month ago

I think my lecture notes prove the necessary proposition

Sent from Gmail Mobile

On Wed, Apr 10, 2024 at 5:37 PM Matthew N. White @.***> wrote:

@.**** commented on this pull request.

In HARK/ConsumptionSaving/ConsPortfolioModel.py https://github.com/econ-ark/HARK/pull/1403#discussion_r1560086196:

  • def calc_hNrm(S):
  • Risky = S["Risky"]
  • PermShk = S["PermShk"]
  • TranShk = S["TranShk"]
  • G = PermGroFac * PermShk
  • Rport = ShareLimit Risky + (1.0 - ShareLimit) Rfree
  • hNrm = (G / Rport*CRRA) (TranShk + solution_next.hNrm)
  • return hNrm

  • This correctly accounts for risky returns and risk aversion

  • hNrmNow = expected(calc_hNrm, ShockDstn) / R_adj

That's correct, I don't have a proof. I came up with it by a combination of trial and error and intuition from what I was seeing as I tried different parameter values:

1.

The "hNrm error" was directly related to return risk: bigger RiskyStd made the difference between calculated and "correct" hNrm bigger. 2.

The sign of the error depended on whether CRRA was greater or lesser than 1. When CRRA=1, the extent of return risk had no effect and there was no error. The further from 1 that rho was, the larger the error (fixing riskiness of returns).

So I knew there had to be something that canceled out for all values of rho when there's no return risk, and made return risk not matter when rho=1. I then just experimented with raising Rport to different powers that sum (or difference) to 1 and have power=0 when rho=1 for one of the powers. I eventually got lucky.

It was a good thing I did that work with the RiskyAsset model, else I would have stumbled onto the Rfree thing in the portfolio model and then been stumped on the other ones.

I can make "visual proof by examples", which aren't proofs at all. They involve solving the problem out to extremely high values of aNrm like 1B and show that the numerically constructed cFunc really does converge to the limiting linear function defined by MPCmin and hNrm.

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/pull/1403#discussion_r1560086196, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKCK74U3TZJDE3HVG6YX3DY4WWI5AVCNFSM6AAAAABFNMUAOKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSOJSG4ZDCMZVHA . You are receiving this because you commented.Message ID: @.***>

alanlujan91 commented 1 month ago

@mnwhite I think we can go ahead and merge this, should I?

mnwhite commented 1 month ago

Yes, I think that's ok.

On Fri, Apr 12, 2024 at 1:06 PM Alan Lujan @.***> wrote:

@mnwhite https://github.com/mnwhite I think we can go ahead and merge this, should I?

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/pull/1403#issuecomment-2052146341, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKRAFM7K66H2MRZ4SZ7G6DY5AIC3AVCNFSM6AAAAABFNMUAOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJSGE2DMMZUGE . You are receiving this because you were mentioned.Message ID: @.***>