Open mnwhite opened 3 months ago
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.
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
?
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.
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.
Right, but then how do we accomplish np.min(lognorm.atoms) = 0.0
?
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.
Ack, I just realized that the entry for the distribution itself is dist
, but it should be dstn
.
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?
This is handled by #1479 , but see comments above.
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.