econ-ark / EstimatingMicroDSOPs

https://econ-ark.github.io/EstimatingMicroDSOPs/
MIT License
2 stars 10 forks source link

Add PortfolioConsumerType #10

Closed alanlujan91 closed 1 year ago

alanlujan91 commented 1 year ago

@llorracc same exercise but using PortfolioConsumerType There are some issues as you can see from the graphical results.

alanlujan91 commented 1 year ago

Do not merge.

alanlujan91 commented 1 year ago

@Mv77 I am trying to add the ability to use PortfolioConsumerType with this code. However, the results don't seem to be coming out great.

I just realized I forgot to add the graphs for the Portfolio run.

alanlujan91 commented 1 year ago

@Mv77 do you have any idea what could be going wrong?

alanlujan91 commented 1 year ago

changing the grid parameters seems to improve the sensitivity output, but makes the contour output much worse.

Mv77 commented 1 year ago

Looks like the objective function is returning NaN for some parameter convos. You have to figure out why.

The alternatives are: A) An error in the agent type is preventing the model from generating simulations under some parameter combinations. This would be pretty bad.

B) an error in the objective function is preventing it from transforming simulated data into moments and a loss for some parameter values. E.g., for some discount factors everyone is hand to mouth and this turns into a division by zero somehow. This would be easier to fix.

alanlujan91 commented 1 year ago

I'm unfortunately leaning toward A)

sim_w_history = agent.history["bNrm"]

under some simulations, the line above has nan bank balances.

alanlujan91 commented 1 year ago

Some aLvlPrev are nan... trying to figure out why...

alanlujan91 commented 1 year ago

In some instances... cNrm = nan.. are the solutions wrong under some parameters?

alanlujan91 commented 1 year ago

self.state_now["mNrm"][np.isnan(self.controls["cNrm"])] Out[5]: array([-1.58754814e+06, -5.45254711e+11, -9.76738291e+02, -6.22966535e+05, -1.44951519e+02])

cNrm is nan when mNrm is negative. But in this model mNrm should never be negative... unless aNrm is negative or return is negative?

alanlujan91 commented 1 year ago

Interesting.... This seems like a major bug because effective R in portfolio should never be negative

np.sum(ReffNow < 0) Out[6]: 5

alanlujan91 commented 1 year ago

I think I have found the problem, sometimes Share is less than 0

self.controls["Share"][self.controls["Share"] <0] Out[9]: array([-1.58137652e+01, -1.22690789e+03, -1.21129003e+00, -1.27012186e+01, -4.84300986e-01])

Mv77 commented 1 year ago

Yeah that's weird.

We should create an issue to look it up. Must be an easy fix

Mv77 commented 1 year ago

I just took a look at the code.

I think the issue is that we are identifying "constrained top" (s==1.0) and constrained bottom (s==0.0) agents. We are manually replacing the s==1's but I do not think we are doing it for s==0's.

alanlujan91 commented 1 year ago

Thank you! I'll review this.

I think because there is a share_limit > 0, I didn't think we needed to really fix constrained at bottom since none would go under that level, but this estimation is really pushing the boundaries of that assumption.

Mv77 commented 1 year ago

Ah i see. i didn't remember that