In error: "AssertionError: LivPrb is not a list or time varying distribution"

[sbenthall]

parameters = {'cycles': 0,
 'aNrmInitStd': 0.0,
 'aNrmInitMean': 6,
 'LivPrb': 0.9949620563926881,
 'PermGroFac': 1.0,
 'pLvlInitMean': 0.0,
 'pLvlInitStd': 0.0,
 'Rfree': 1.0,
 'TranShkStd': [0],
 'PermShkStd': [0],
 'CRRA': 3,
 'DiscFac': 0.99,
 'ex_post': None,
 'AgentCount': 1,
 'num_per_type': 1000,
 'RiskyAvg': 1.0916031021270372,
 'RiskyStd': 0.09296520824951145,
 'T_sim': 3000,
 'UnempPrb': 1.0,
 'IncUnemp': 0.0}

a1 = SequentialPortfolioConsumerType(**parameters)

a1.solve()

Gets me this error:

AssertionError: LivPrb is not a list or time varying distribution, but should be because it is in time_vary

This doesn't seem right.

[mnwhite]

This is correct. LivPrb is survival probability, and so it should be a list. It depends on age, if we're doing a lifecycle model.

…

On Tue, Jul 18, 2023 at 2:34 PM Sebastian Benthall ***@***.***> wrote: Assigned #1305 <#1305> to @mnwhite <https://github.com/mnwhite>. — Reply to this email directly, view it on GitHub <#1305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFIN6QJUXFALLA6LBLTXQ3JMVANCNFSM6AAAAAA2OZMB4Y> . You are receiving this because you were assigned.Message ID: ***@***.***>

[alanlujan91]

In the new Parameters dictionary, If LivPrb is a float it should be recognized as time invariant, if it's a list it should be length T_cycle and recognized as time varying.

[sbenthall]

Ok, glad this is fixed with the new parameters object. @mnwhite I don't follow the logic there. It's not a lifecycle model in this case.

…

On Tue, Jul 18, 2023, 4:48 PM Alan Lujan ***@***.***> wrote: In the new Parameters dictionary, If LivPrb is a float it should be recognized as time invariant, if it's a list it should be length T_cycle and recognized as time varying. — Reply to this email directly, view it on GitHub <#1305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQZEBXQFVW52EWNWR5JW3XQ3ZBJANCNFSM6AAAAAA2OZMB4Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Mv77]

The same happens with transhkstd and permshkstd I think?

[alanlujan91]

It's not a lifecycle model, but LivPrb is a "lifecycle" attribute, so, it needs to be generated as LivPrb = [ 0.9949620563926881 ] because it's an infinitely repeated "lifecycle" of length one.

[sbenthall]

Ok. I'm following now.

It sounds like this is something that's hard-coded in the model which probably ideally is not hard-coded in the model, since we run into cases all the time where we want something that wasn't originally thought of as time-varying to be time-varying, etc.

I suppose #1240 is the fix for this.

Looking forward to that PR!

[mnwhite]

Right. For something like ConsIndShock or the portfolio model, *most* parameters can be "harmlessly" moved between time_vary and time_inv on the solution side. Because the simulation method is hard-coded with the base assumptions about what's time-varying, additional work needs to be done on that side. But with the simulation overhaul to be based on the "model equations representation", whether a particular object has a t-subscript is something that can/should be handled at runtime. In ConsIndShock, the big exception is CRRA. As written, the solution code assumes that CRRA is constant across periods, and uses this fact in approximating the upper extrapolation. This should be fixed along side the change to the timing of expectations, so that it *checks* whether next period's (marginal) value function identifies itself as coming from the standard consumption-saving problem. Or we just have a flag that can tell it not to attempt clever extrapolation.

…

On Wed, Jul 19, 2023 at 10:21 AM Sebastian Benthall < ***@***.***> wrote: Ok. I'm following now. It sounds like this is something that's hard-coded in the model which probably ideally is not hard-coded in the model, since we run into cases all the time where we want something that wasn't originally thought of as time-varying to be time-varying, etc. I suppose #1240 <#1240> is the fix for this. Looking forward to that PR! — Reply to this email directly, view it on GitHub <#1305 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADKRAFJKR7GEEOTEBMJDWV3XQ7UM3ANCNFSM6AAAAAA2OZMB4Y> . You are receiving this because you were mentioned.Message ID: ***@***.***>