Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Actually handle truncated distributions in solvers #1469

Open
mnwhite opened this issue Jul 3, 2024 · 9 comments
Open

Actually handle truncated distributions in solvers #1469

mnwhite opened this issue Jul 3, 2024 · 9 comments
Assignees

Comments

@mnwhite
Copy link
Contributor

mnwhite commented Jul 3, 2024

HARK's lognormal distribution can handle approximations that truncate the upper and lower tails, but this functionality isn't actually used in our models. A long-running issue with the accuracy of our solvers is that the natural borrowing constraint is based on the worst discrete point in the distribution, which makes the lower part of the solution very sensitive to the number of integration nodes.

CDC has asked me to finally actually fix this and put bounded lognormal functionality into the consumption-saving solvers.

@mnwhite mnwhite self-assigned this Jul 3, 2024
@sidd3888
Copy link
Collaborator

sidd3888 commented Jul 3, 2024

For the case of the multivariate lognormal discretization where the covariance matrix is not diagonal, I have added a feature of tails and a truncated distribution. What I have not done is actually implement a functionality for distinct tail points. That is, even if you currently specify tail_N = 3, it will create 3 copies of the boundary point. I was wondering whether these endpoints should be made manual or perhaps we can automatically choose some such points based on the bound on the CDF and the number of tail points. I have pushed the changes to the PR with a new function called _approx_equiprobable2 under the MVLogNormal class.

@mnwhite
Copy link
Contributor Author

mnwhite commented Jul 25, 2024

I'm currently working on this, but the code isn't in the state that I thought it was. For whatever reason, I thought that that limit attribute of discrete distributions contained the upper and lower support bounds for the true distribution-- its limits, in shorthand. It actually contains information about the continuous distribution from which the discretization was generated. Why is this called limit?

@alanlujan91
Copy link
Member

limit contains info on the limiting distribution as you increase the number of points.
Chris wanted the upper and lower bounds to be part of the atoms themselves.

@mnwhite
Copy link
Contributor Author

mnwhite commented Jul 25, 2024

I don't think that's going to work, at least not without adding quite a bit of code. A lot of distribution families have unbounded support, at least on one side: normal, lognormal, exponential, Weibull, T1EV, etc. If we literally put infinitesimally weighted atoms at the lower and upper bounds of discretizations, that would be +/- infinity for a lot of distributions, which would break a lot of calculations. We would have to require that all continuous distributions have bounded support.

@alanlujan91
Copy link
Member

Right, but then how do we accomplish np.min(lognorm.atoms) = 0.0 ?

@mnwhite
Copy link
Contributor Author

mnwhite commented Jul 25, 2024

I don't think we can/should, that's what I'm saying. I'm in the process of putting this information in new attributes of Distribution called infimum and supremum, which then get distributed to DiscreteDistribution as part of the limit. Then users can query that if they want to use it.

@mnwhite
Copy link
Contributor Author

mnwhite commented Jul 25, 2024

Ack, I just realized that the entry for the distribution itself is dist, but it should be dstn.

@mnwhite
Copy link
Contributor Author

mnwhite commented Jul 29, 2024

After working with this for a while, it's become apparent that the consumption function solution won't properly obey the lower bound of the income distributions unless both:

a) The aXtraGrid has points all the way down to a=10^-12 or lower, e.g. MyType.aXtraExtra = [10**j for j in range(-14,-2)]

b) A tiny probability mass at TranShk=0 or PermShk=0 is included.

Without these, the lowest non-zero gridpoint is way above zero. The solution isn't especially wrong, even with cubic interpolation, but that's only because the "constrained" consumption function is also imposed, using the natural borrowing constraint.

Are we ok with this?

@mnwhite
Copy link
Contributor Author

mnwhite commented Aug 13, 2024

This is handled by #1479 , but see comments above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants