Perfect foresight model with CRRA = 1

[ghost]

Inspired by demo file, I am writing demos for each model in ConsIndShockModel. It is fun to play with parameters and helps me to understand consumption-saving dynamics model. In fact, I talked to other graduate students and realized only a few had experienced Python language. David's example is superb, and I think more demos would be instructive. Of course, I noticed David left homework assignment in the demo. For some people, I guess it is quite difficult.. Learning by doing would be ideal, but more guidelines also are useful. I just want to share struggles I faced earlier (even now:) ).

Anyway, I checked some variant versions of perfect foresight case.

from HARK.ConsumptionSaving.ConsIndShockModel import PerfForesightConsumerType
Example = PerfForesightConsumerType()
Example.CRRA = 1.0
Example.solve()

It throws out an error. This is because line 410 in ConsIndShockModel.py MPCnvrs = self.MPC**(-self.CRRA/(1.0-self.CRRA))

I guess we need to fix defValueFuncs function. Am I right?

p.s. CRRA=1.0 works for other types.

[mnwhite]

Yes, this should be fixed. Off the top of my head, I'm not actually sure what MPCnvrs should be when CRRA=1. This issue seems to exist for other classes as well, when calculating the value function is requested.

[llorracc]

The problem isn't in the MPC, it's in dividing by 1-1 = 0

We should add an "if CRRA == 1" and in that case use the fact that d/dc log c = 1/c.

[pkofod]

Seems sprintable for an economist.

[pkofod]

So I think this comes back to the fact that more than one user has turned into a question mark when reading the lines that define MPCnvrs. Should we/you/someone maybe sit down and do the math and put a note somewhere? It's the slope of the inverse MPC function in a perfect foresight model right @mnwhite ?

[pkofod]

@llorracc @mnwhite if CRRA == 1 is the slope of the inverse MPC function then 1 ? That's the limit of that expression, right? I can make a PR with the change so we can fix this :)

[mnwhite]

I worked this out in my head around the time that Patrick last commented, but that was also when my daughter was born and now I forget.

[MridulS]

A quick hack-ish way of fixing it to check if self.CRRA == 1.0 and replace it with self.CRRA = 1.0 + \epsilon. Print out a warning after doing the transformation.

[nomadj1s]

Does this problem also exist with the IndShockConsumerType model when you set "vFuncBool" : True? I'm getting a similar error:

~/opt/anaconda3/lib/python3.9/site-packages/HARK/ConsumptionSaving/ConsIndShockModel.py in make_vFunc(self, solution)
   1222         vNvrs = np.insert(vNvrs, 0, 0.0)
   1223         vNvrsP = np.insert(
-> 1224             vNvrsP, 0, self.MPCmaxEff ** (-self.CRRA / (1.0 - self.CRRA))
   1225         )
   1226         MPCminNvrs = self.MPCminNow ** (-self.CRRA / (1.0 - self.CRRA))

ZeroDivisionError: float division by zero

[mnwhite]

That's right. There needs to be a different "pseudo-inverse value function" transformation here. It might be that this part of the code (in both models) should be rewritten to use the utility function structure, which has the inverses (and derivatives, etc) built into it. As long as that object knows how to handle rho=1, then the rest of the code will behave nicely.

On Tue, Nov 26, 2024 at 10:29 AM nomadj1s @.***> wrote:

Does this problem also exist with the IndShockConsumerType model when you set "vFuncBool" : True? I'm getting a similar error:

~/opt/anaconda3/lib/python3.9/site-packages/HARK/ConsumptionSaving/ConsIndShockModel.py in make_vFunc(self, solution) 1222 vNvrs = np.insert(vNvrs, 0, 0.0) 1223 vNvrsP = np.insert(-> 1224 vNvrsP, 0, self.MPCmaxEff ** (-self.CRRA / (1.0 - self.CRRA)) 1225 ) 1226 MPCminNvrs = self.MPCminNow ** (-self.CRRA / (1.0 - self.CRRA)) ZeroDivisionError: float division by zero

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/issues/75#issuecomment-2501162780, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKRAFJ3OJBVM4GSRWJSOID2CSHVXAVCNFSM6AAAAABSQW6XJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBRGE3DENZYGA . You are receiving this because you were assigned.Message ID: @.***>

[llorracc]

@mnwhite is there a quick fix, until we get to the right fix?

[mnwhite]

The immediate workaround is to use CRRA = 1.01 or 0.99.

I remember realizing years ago that something goes funny with the math when you try to do the alternative version of the transformation. Off the top of my head, I think it might be something to do with the permanent growth factor turning into an additive shifter of log(Gamma) rather than a multiplicative factor.

On Tue, Nov 26, 2024, 7:53 PM Christopher Llorracc Carroll < @.***> wrote:

@mnwhite https://github.com/mnwhite is there a quick fix, until we get to the right fix?

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

[llorracc]

or 1.00001. Better than 0.99999

On Tue, Nov 26, 2024 at 7:59 PM Matthew N. White @.***> wrote:

The immediate workaround is to use CRRA = 1.01 or 0.99.

I remember realizing years ago that something goes funny with the math when you try to do the alternative version of the transformation. Off the top of my head, I think it might be something to do with the permanent growth factor turning into an additive shifter of log(Gamma) rather than a multiplicative factor.

On Tue, Nov 26, 2024, 7:53 PM Christopher Llorracc Carroll < @.***> wrote:

@mnwhite https://github.com/mnwhite is there a quick fix, until we get to the right fix?

— Reply to this email directly, view it on GitHub https://github.com/econ-ark/HARK/issues/75#issuecomment-2502364748, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ADKRAFOC6AJHK2RL6SZ6AML2CUJZTAVCNFSM6AAAAABSQW6XJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBSGM3DINZUHA>

. You are receiving this because you were mentioned.Message ID: @.***>

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

--

• Chris Carroll

[nomadj1s]

I agree, when using log utility, the value function is no longer proportional to the normalized value function, but shifted by a constant. The additive term drops out when you take a derivative, leaving the normalized Euler equation unchanged, but the level of the value function has to be calculated differently than when $\rho \neq 1$. For example, the terminal value function is:

$$ \begin{align*} V_{T}(M_T,P_T) & = \log(M_T)\ & = \log(P_T m_T) \ & = \log(m_T) + \log(P_T) \ & = v_T(m_T) + \log(P_T) \end{align*} $$

For earlier periods, the additional term gets a little more complicated.