Generic monte carlo simulation #1296
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sbenthall
commented
Jun 30, 2023
HARK/simulation/test_monte_carlo.py
Outdated
|
|
||
| ###############################################################3 | ||
|
|
||
| ''' |
There was a problem hiding this comment.
whoops ignore the stuff below this line. I was going to develop more robust tests from this material later.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1296 +/- ##
==========================================
+ Coverage 73.02% 73.33% +0.30%
==========================================
Files 79 83 +4
Lines 13377 13596 +219
==========================================
+ Hits 9769 9971 +202
- Misses 3608 3625 +17 ☔ View full report in Codecov by Sentry. |
|
Current This feature is not yet used in the ConsIndShockModel The broader issue is what assumptions we make about aging and mortality in the Monte Carlo simulator, and to what extent they are part of 'dynamics' or something else. My sense is that the AgentType class makes somewhat strong assumptions about these things in order to, for example, guarantee a constant size population. I'd like for this PR to do as much as it can without making assumptions about this part of the framework. |
|
Thinking this through -- I think the next move on this is a MonteCarloSimulator class, which takes a model and a decision rule, and does the work of the AgentType simulation parts. This will build on #1292. We've discussed this as the right direction. I suppose it will be smoother if it mimics AgentType's functionality as much as possible. The goal would be for it to replace the AgentType monte carlo simulator entirely, which would be a forcing function for AgentType models to include model dynamics in a logically separate way. |
sbenthall
changed the title
|
This PR now has a draft of an
The aim is to implement the basic current AgentType simulation functionality in Some changes that are coming up:
This design is feeling lighter weight. A few things I haven't worked out yet are:
Other things I'm thinking about:
|
8 tasks
|
Current choice is to have an |
|
@mnwhite I am thinking that we need a kind of modeling primitive to deal with termination/death. I think the cleanest way to do this is to stipulate that there is a particular variable, Then, setting this state can be part of the dynamics, or it can be drawn as a shock -- the simulation architecture doesn't care how that variable is set. It just monitors it and, if it's 0, it initiates the death routine. Does that make sense? Any alternate ideas? |
|
Having However, this assumption that Given that we have control over the random seed, I would assume that this feature is rather rarely used. The |
|
@Mv77 has touched the |
|
Ah, that's right. Originally, mortality shocks were *not* part of
make_shock_history, and I think initialization shocks were omitted as well.
The actual exogenous shock that can be pre-specified is an underlying
Uniform[0,1] distribution of mortality shocks. That can be transformed in
any way to generate flags for who_dies, including both "basic mortality" of
comparing the shocks to a value in LivPrb *and* endogenous mortality where
the reference value is state-dependent. The mistake was in how mortality
history was added to the shock history, not in the fundamental structure.
…On Wed, Jul 26, 2023 at 9:57 AM Sebastian Benthall ***@***.***> wrote:
Having who_dies be a variable that can be due to either shocks or
dynamics breaks the assumptions in make_shock_history, according to which
who_dies can be age-dependent, but not endogenous.
However, this assumption that who_dies is not endogenous is not
guaranteed by the framework, because sim_death can be overwritten by
subclasses. This assumption is also not documented.
Given that we have control over the random seed, I would assume that this
feature is rather rarely used. The make_shock_history and read_shocks
code is long; I think I can streamline it in the Monte Carlo solver and get
the same feel.
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKRAFPMJTXGO6VKWBIEJP3XSEO3JANCNFSM6AAAAAAZ2H65AA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Ok, so after exchanging with Matt and Mateo about this, I've implemented mortality in what I think is a very clean and flexible way. The MonteCarloSimulator expects agents to have a variable,
There is no more I believe this is:
I don't think it does everything on @mnwhite 's simulation bucket list, which I think may be out of scope of this PR, but does some of it. See this comment: #1295 (comment) I believe this PR is now ready for review. Requesting feedback from @mnwhite and @Mv77 |
sbenthall
changed the title
|
Cool, that sounds like an improvement. I'll check this (hopefully) soon. |
|
This whole discussion is an instance of the value of the project of trying
to specify canonically what elements constitute a period, a stage, a step
within a stage, what goes into a transition function, etc.
The tricky thing here is that the _distribution_ of assets is not a state
variable for the individual, it is a state variable for the aggregate
system. Nor is "death" meaningfully a state variable for the individual,
as there is no optimization problem or stochastic shocks or any of the
other apparatus associated with the "problem" of a person who is dead.
Death and replacement seem naturally to belong to the transition process
between periods.
On Thu, Jul 27, 2023 at 10:16 AM Matthew N. White ***@***.***>
wrote:
… Ah, that's right. Originally, mortality shocks were *not* part of
make_shock_history, and I think initialization shocks were omitted as
well.
The actual exogenous shock that can be pre-specified is an underlying
Uniform[0,1] distribution of mortality shocks. That can be transformed in
any way to generate flags for who_dies, including both "basic mortality"
of
comparing the shocks to a value in LivPrb *and* endogenous mortality where
the reference value is state-dependent. The mistake was in how mortality
history was added to the shock history, not in the fundamental structure.
On Wed, Jul 26, 2023 at 9:57 AM Sebastian Benthall ***@***.***>
wrote:
> Having who_dies be a variable that can be due to either shocks or
> dynamics breaks the assumptions in make_shock_history, according to
which
> who_dies can be age-dependent, but not endogenous.
>
> However, this assumption that who_dies is not endogenous is not
> guaranteed by the framework, because sim_death can be overwritten by
> subclasses. This assumption is also not documented.
>
> Given that we have control over the random seed, I would assume that
this
> feature is rather rarely used. The make_shock_history and read_shocks
> code is long; I think I can streamline it in the Monte Carlo solver and
get
> the same feel.
>
> —
> Reply to this email directly, view it on GitHub
> <#1296 (comment)>,
or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFPMJTXGO6VKWBIEJP3XSEO3JANCNFSM6AAAAAAZ2H65AA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKCK765YOWMNCRA2OLG5JDXSJZ5DANCNFSM6AAAAAAZ2H65AA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
- Chris Carroll
|
|
OK, there is now a notebook in this PR that directly compares the HARK 0.13 Perfect Foresight simulation with the results from using the HARK 0.13 Perfect Foresight solution with the generic Monte Carlo simulator I've been working on here. The good news is that it executes in reasonable-looking way while using the Python PF model definition. This means that in the Python configured model, the update of income y is not lagged behind the update of permanent income p as I believe it was in the HARK version. The bad news is that the two simulation outputs look different! I'm not sure if this is caused by the model change I just described, or a deeper problem. Here's mean normalized market resources over time from H0.13 PF:
Here's mean normalized market resources over time from the current state of this PR:
Here is the notebook I can keep trying to fix this up. But I think that at this point, the PR would benefit hugely from a review from @mnwhite . |
|
I'll take a look. The behavior in the current version looks correct,
assuming this is an infinite horizon model.
…On Mon, Oct 9, 2023, 6:34 PM Sebastian Benthall ***@***.***> wrote:
OK, there is now a notebook in this PR that directly compares the HARK
0.13 Perfect Foresight simulation with the results from using the HARK 0.13
Perfect Foresight *solution* with the generic Monte Carlo simulator I've
been working on here.
The good news is that it executes in reasonable-looking way while using
the Python PF model definition.
I did need to make one small change to the model compared to how it was
originally merged in:
5ef3a19
<5ef3a19>
This means that in the Python configured model, the update of income *y*
is not lagged behind the update of permanent income *p* as I believe it
was in the HARK version.
The bad news is that the two simulation outputs look different! I'm not
sure if this is caused by the model change I just described, or a deeper
problem.
Here's mean normalized market resources over time from H0.13 PF:
[image: image]
<https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
Here's mean normalized market resources over time from the current state
of this PR:
[image: image]
<https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
Which is pretty weird.
Here is the notebook
https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
I can keep trying to fix this up.
But I think that at this point, the PR would benefit hugely from a review
from @mnwhite <https://github.com/mnwhite> .
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKRAFM6SSS5HUQ6L6XHQB3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Thanks @mnwhite |
|
In the PF model infinite horizon model, the growth factor for consumption
is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The definition
of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
(nearly equivalently) (1/\rho)(r-\theta) < 0$.
Lessons:
1. You should be plotting the logarithm of m not the level.
2. The correct answer is that it is perpetually declining, always at
exactly the same rate (linearly)
- So the first diagram looks approximately right
This all neglects permanent income growth, but the same propositions hold
for normalized consumption growth, where the relevant impatience condition
is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
I take it that the reason you need to do simulations is that you have
introduced stochastic mortality, so some agents die and are replaced by
newborns.
But the second figure looks deeply wrong to me.
PS. Note that I do the math for the version of the model with population
growth and mortality in the last section of my TractableBufferStock lecture
notes:
https://llorracc.github.io/TractableBufferStock
and a more general version in this paper with my colleague Olivier Jeanne:
https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
…On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***> wrote:
OK, there is now a notebook in this PR that directly compares the HARK
0.13 Perfect Foresight simulation with the results from using the HARK 0.13
Perfect Foresight *solution* with the generic Monte Carlo simulator I've
been working on here.
The good news is that it executes in reasonable-looking way while using
the Python PF model definition.
I did need to make one small change to the model compared to how it was
originally merged in:
5ef3a19
<5ef3a19>
This means that in the Python configured model, the update of income *y*
is not lagged behind the update of permanent income *p* as I believe it
was in the HARK version.
The bad news is that the two simulation outputs look different! I'm not
sure if this is caused by the model change I just described, or a deeper
problem.
Here's mean normalized market resources over time from H0.13 PF:
[image: image]
<https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
Here's mean normalized market resources over time from the current state
of this PR:
[image: image]
<https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
Which is pretty weird.
Here is the notebook
https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
I can keep trying to fix this up.
But I think that at this point, the PR would benefit hugely from a review
from @mnwhite <https://github.com/mnwhite> .
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
- Chris Carroll
|
|
Thanks for the theoretical review, Chris.
No doubt there is a bug in my code somewhere.
I'm running these simulations to test Generic Monte Carlo simulation
functionality on a known case.
The two plots use the same consumption function.
So I suspect that either the way I've specified the dynamics and parameters
in the second simulation diverges in some way from the HARK 0.13 version,
or something about how I'm handling mortality is different.
Naturally, I agree that reproducing the HARK 0.13 results is necessary.
On Tue, Oct 10, 2023, 11:19 PM Christopher Llorracc Carroll <
***@***.***> wrote:
… In the PF model infinite horizon model, the growth factor for consumption
is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The definition
of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
(nearly equivalently) (1/\rho)(r-\theta) < 0$.
Lessons:
1. You should be plotting the logarithm of m not the level.
2. The correct answer is that it is perpetually declining, always at
exactly the same rate (linearly)
- So the first diagram looks approximately right
This all neglects permanent income growth, but the same propositions hold
for normalized consumption growth, where the relevant impatience condition
is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
I take it that the reason you need to do simulations is that you have
introduced stochastic mortality, so some agents die and are replaced by
newborns.
But the second figure looks deeply wrong to me.
PS. Note that I do the math for the version of the model with population
growth and mortality in the last section of my TractableBufferStock
lecture
notes:
https://llorracc.github.io/TractableBufferStock
and a more general version in this paper with my colleague Olivier Jeanne:
https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***>
wrote:
> OK, there is now a notebook in this PR that directly compares the HARK
> 0.13 Perfect Foresight simulation with the results from using the HARK
0.13
> Perfect Foresight *solution* with the generic Monte Carlo simulator I've
> been working on here.
>
> The good news is that it executes in reasonable-looking way while using
> the Python PF model definition.
> I did need to make one small change to the model compared to how it was
> originally merged in:
> 5ef3a19
> <
5ef3a19>
>
> This means that in the Python configured model, the update of income *y*
> is not lagged behind the update of permanent income *p* as I believe it
> was in the HARK version.
>
> The bad news is that the two simulation outputs look different! I'm not
> sure if this is caused by the model change I just described, or a deeper
> problem.
>
> Here's mean normalized market resources over time from H0.13 PF:
>
> [image: image]
> <
https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
>
> Here's mean normalized market resources over time from the current state
> of this PR:
>
> [image: image]
> <
https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
> Which is pretty weird.
>
> Here is the notebook
>
>
https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
>
> I can keep trying to fix this up.
>
> But I think that at this point, the PR would benefit hugely from a
review
> from @mnwhite <https://github.com/mnwhite> .
>
> —
> Reply to this email directly, view it on GitHub
> <#1296 (comment)>,
or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
--
- Chris Carroll
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAQZEDPWQPSFBRNMPR3PRDX6YF5RAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWG4YDGMRYG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
One way to frame the debug question is:
Given consumers with perfect foresight expectations, what departures from
their expectations in the dynamics they experience, either individually or
as a population, would result in plot #2?
What if income grew faster than they expected?
On Wed, Oct 11, 2023, 8:37 AM Sebastian Benthall ***@***.***>
wrote:
… Thanks for the theoretical review, Chris.
No doubt there is a bug in my code somewhere.
I'm running these simulations to test Generic Monte Carlo simulation
functionality on a known case.
The two plots use the same consumption function.
So I suspect that either the way I've specified the dynamics and
parameters in the second simulation diverges in some way from the HARK 0.13
version, or something about how I'm handling mortality is different.
Naturally, I agree that reproducing the HARK 0.13 results is necessary.
On Tue, Oct 10, 2023, 11:19 PM Christopher Llorracc Carroll <
***@***.***> wrote:
> In the PF model infinite horizon model, the growth factor for consumption
> is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The definition
> of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
> (nearly equivalently) (1/\rho)(r-\theta) < 0$.
>
> Lessons:
>
> 1. You should be plotting the logarithm of m not the level.
> 2. The correct answer is that it is perpetually declining, always at
> exactly the same rate (linearly)
> - So the first diagram looks approximately right
>
> This all neglects permanent income growth, but the same propositions hold
> for normalized consumption growth, where the relevant impatience
> condition
> is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
> equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
>
> I take it that the reason you need to do simulations is that you have
> introduced stochastic mortality, so some agents die and are replaced by
> newborns.
>
> But the second figure looks deeply wrong to me.
>
> PS. Note that I do the math for the version of the model with population
> growth and mortality in the last section of my TractableBufferStock
> lecture
> notes:
>
> https://llorracc.github.io/TractableBufferStock
>
> and a more general version in this paper with my colleague Olivier
> Jeanne:
>
> https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
>
>
>
> On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***>
> wrote:
>
> > OK, there is now a notebook in this PR that directly compares the HARK
> > 0.13 Perfect Foresight simulation with the results from using the HARK
> 0.13
> > Perfect Foresight *solution* with the generic Monte Carlo simulator
> I've
> > been working on here.
> >
> > The good news is that it executes in reasonable-looking way while using
> > the Python PF model definition.
> > I did need to make one small change to the model compared to how it was
> > originally merged in:
> > 5ef3a19
> > <
> 5ef3a19>
>
> >
> > This means that in the Python configured model, the update of income
> *y*
> > is not lagged behind the update of permanent income *p* as I believe it
> > was in the HARK version.
> >
> > The bad news is that the two simulation outputs look different! I'm not
> > sure if this is caused by the model change I just described, or a
> deeper
> > problem.
> >
> > Here's mean normalized market resources over time from H0.13 PF:
> >
> > [image: image]
> > <
> https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
>
> >
> > Here's mean normalized market resources over time from the current
> state
> > of this PR:
> >
> > [image: image]
> > <
> https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
>
> > Which is pretty weird.
> >
> > Here is the notebook
> >
> >
> https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
> >
> > I can keep trying to fix this up.
> >
> > But I think that at this point, the PR would benefit hugely from a
> review
> > from @mnwhite <https://github.com/mnwhite> .
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <#1296 (comment)>,
> or
> > unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
>
> > .
> > You are receiving this because you were mentioned.Message ID:
> > ***@***.***>
> >
>
>
> --
> - Chris Carroll
>
> —
> Reply to this email directly, view it on GitHub
> <#1296 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAQZEDPWQPSFBRNMPR3PRDX6YF5RAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWG4YDGMRYG4>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
Let's do something easier first: Turn off mortality by setting LivPrb to
zero. See what the second graph looks like then. Also make sure that
initial wealth is uniform by setting aNrmInitStd to zero.
On Wed, Oct 11, 2023 at 8:43 AM Sebastian Benthall ***@***.***>
wrote:
… One way to frame the debug question is:
Given consumers with perfect foresight expectations, what departures from
their expectations in the dynamics they experience, either individually or
as a population, would result in plot #2?
What if income grew faster than they expected?
On Wed, Oct 11, 2023, 8:37 AM Sebastian Benthall ***@***.***>
wrote:
> Thanks for the theoretical review, Chris.
>
> No doubt there is a bug in my code somewhere.
>
> I'm running these simulations to test Generic Monte Carlo simulation
> functionality on a known case.
>
> The two plots use the same consumption function.
>
> So I suspect that either the way I've specified the dynamics and
> parameters in the second simulation diverges in some way from the HARK
0.13
> version, or something about how I'm handling mortality is different.
>
> Naturally, I agree that reproducing the HARK 0.13 results is necessary.
>
> On Tue, Oct 10, 2023, 11:19 PM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
>> In the PF model infinite horizon model, the growth factor for
consumption
>> is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The
definition
>> of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
>> (nearly equivalently) (1/\rho)(r-\theta) < 0$.
>>
>> Lessons:
>>
>> 1. You should be plotting the logarithm of m not the level.
>> 2. The correct answer is that it is perpetually declining, always at
>> exactly the same rate (linearly)
>> - So the first diagram looks approximately right
>>
>> This all neglects permanent income growth, but the same propositions
hold
>> for normalized consumption growth, where the relevant impatience
>> condition
>> is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
>> equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
>>
>> I take it that the reason you need to do simulations is that you have
>> introduced stochastic mortality, so some agents die and are replaced by
>> newborns.
>>
>> But the second figure looks deeply wrong to me.
>>
>> PS. Note that I do the math for the version of the model with
population
>> growth and mortality in the last section of my TractableBufferStock
>> lecture
>> notes:
>>
>> https://llorracc.github.io/TractableBufferStock
>>
>> and a more general version in this paper with my colleague Olivier
>> Jeanne:
>>
>> https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
>>
>>
>>
>> On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***>
>> wrote:
>>
>> > OK, there is now a notebook in this PR that directly compares the
HARK
>> > 0.13 Perfect Foresight simulation with the results from using the
HARK
>> 0.13
>> > Perfect Foresight *solution* with the generic Monte Carlo simulator
>> I've
>> > been working on here.
>> >
>> > The good news is that it executes in reasonable-looking way while
using
>> > the Python PF model definition.
>> > I did need to make one small change to the model compared to how it
was
>> > originally merged in:
>> > 5ef3a19
>> > <
>>
5ef3a19>
>>
>> >
>> > This means that in the Python configured model, the update of income
>> *y*
>> > is not lagged behind the update of permanent income *p* as I believe
it
>> > was in the HARK version.
>> >
>> > The bad news is that the two simulation outputs look different! I'm
not
>> > sure if this is caused by the model change I just described, or a
>> deeper
>> > problem.
>> >
>> > Here's mean normalized market resources over time from H0.13 PF:
>> >
>> > [image: image]
>> > <
>>
https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
>>
>> >
>> > Here's mean normalized market resources over time from the current
>> state
>> > of this PR:
>> >
>> > [image: image]
>> > <
>>
https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
>>
>> > Which is pretty weird.
>> >
>> > Here is the notebook
>> >
>> >
>>
https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
>> >
>> > I can keep trying to fix this up.
>> >
>> > But I think that at this point, the PR would benefit hugely from a
>> review
>> > from @mnwhite <https://github.com/mnwhite> .
>> >
>> > —
>> > Reply to this email directly, view it on GitHub
>> > <#1296 (comment)>,
>> or
>> > unsubscribe
>> > <
>>
https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
>>
>> > .
>> > You are receiving this because you were mentioned.Message ID:
>> > ***@***.***>
>> >
>>
>>
>> --
>> - Chris Carroll
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#1296 (comment)>,
or
>> unsubscribe
>> <
https://github.com/notifications/unsubscribe-auth/AAAQZEDPWQPSFBRNMPR3PRDX6YF5RAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWG4YDGMRYG4>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKRAFITJ4BKSXUPZEMALLLX62H6NANCNFSM6AAAAAAZ2H65AA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
And just to be clear: Chris meant plot the log of mNrm - lower bound of
mNrm.
…On Wed, Oct 11, 2023 at 8:50 AM Matthew White ***@***.***> wrote:
Let's do something easier first: Turn off mortality by setting LivPrb to
zero. See what the second graph looks like then. Also make sure that
initial wealth is uniform by setting aNrmInitStd to zero.
On Wed, Oct 11, 2023 at 8:43 AM Sebastian Benthall <
***@***.***> wrote:
> One way to frame the debug question is:
>
> Given consumers with perfect foresight expectations, what departures from
> their expectations in the dynamics they experience, either individually
> or
> as a population, would result in plot #2?
>
> What if income grew faster than they expected?
>
> On Wed, Oct 11, 2023, 8:37 AM Sebastian Benthall ***@***.***>
> wrote:
>
> > Thanks for the theoretical review, Chris.
> >
> > No doubt there is a bug in my code somewhere.
> >
> > I'm running these simulations to test Generic Monte Carlo simulation
> > functionality on a known case.
> >
> > The two plots use the same consumption function.
> >
> > So I suspect that either the way I've specified the dynamics and
> > parameters in the second simulation diverges in some way from the HARK
> 0.13
> > version, or something about how I'm handling mortality is different.
> >
> > Naturally, I agree that reproducing the HARK 0.13 results is necessary.
> >
> > On Tue, Oct 10, 2023, 11:19 PM Christopher Llorracc Carroll <
> > ***@***.***> wrote:
> >
> >> In the PF model infinite horizon model, the growth factor for
> consumption
> >> is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The
> definition
> >> of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
> >> (nearly equivalently) (1/\rho)(r-\theta) < 0$.
> >>
> >> Lessons:
> >>
> >> 1. You should be plotting the logarithm of m not the level.
> >> 2. The correct answer is that it is perpetually declining, always at
> >> exactly the same rate (linearly)
> >> - So the first diagram looks approximately right
> >>
> >> This all neglects permanent income growth, but the same propositions
> hold
> >> for normalized consumption growth, where the relevant impatience
> >> condition
> >> is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
> >> equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
> >>
> >> I take it that the reason you need to do simulations is that you have
> >> introduced stochastic mortality, so some agents die and are replaced
> by
> >> newborns.
> >>
> >> But the second figure looks deeply wrong to me.
> >>
> >> PS. Note that I do the math for the version of the model with
> population
> >> growth and mortality in the last section of my TractableBufferStock
> >> lecture
> >> notes:
> >>
> >> https://llorracc.github.io/TractableBufferStock
> >>
> >> and a more general version in this paper with my colleague Olivier
> >> Jeanne:
> >>
> >> https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
> >>
> >>
> >>
> >> On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***>
> >> wrote:
> >>
> >> > OK, there is now a notebook in this PR that directly compares the
> HARK
> >> > 0.13 Perfect Foresight simulation with the results from using the
> HARK
> >> 0.13
> >> > Perfect Foresight *solution* with the generic Monte Carlo simulator
> >> I've
> >> > been working on here.
> >> >
> >> > The good news is that it executes in reasonable-looking way while
> using
> >> > the Python PF model definition.
> >> > I did need to make one small change to the model compared to how it
> was
> >> > originally merged in:
> >> > 5ef3a19
> >> > <
> >>
> 5ef3a19>
>
> >>
> >> >
> >> > This means that in the Python configured model, the update of income
> >> *y*
> >> > is not lagged behind the update of permanent income *p* as I believe
> it
> >> > was in the HARK version.
> >> >
> >> > The bad news is that the two simulation outputs look different! I'm
> not
> >> > sure if this is caused by the model change I just described, or a
> >> deeper
> >> > problem.
> >> >
> >> > Here's mean normalized market resources over time from H0.13 PF:
> >> >
> >> > [image: image]
> >> > <
> >>
> https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
>
> >>
> >> >
> >> > Here's mean normalized market resources over time from the current
> >> state
> >> > of this PR:
> >> >
> >> > [image: image]
> >> > <
> >>
> https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
>
> >>
> >> > Which is pretty weird.
> >> >
> >> > Here is the notebook
> >> >
> >> >
> >>
> https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
> >> >
> >> > I can keep trying to fix this up.
> >> >
> >> > But I think that at this point, the PR would benefit hugely from a
> >> review
> >> > from @mnwhite <https://github.com/mnwhite> .
> >> >
> >> > —
> >> > Reply to this email directly, view it on GitHub
> >> > <#1296 (comment)>,
>
> >> or
> >> > unsubscribe
> >> > <
> >>
> https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
>
> >>
> >> > .
> >> > You are receiving this because you were mentioned.Message ID:
> >> > ***@***.***>
> >> >
> >>
> >>
> >> --
> >> - Chris Carroll
> >>
> >> —
> >> Reply to this email directly, view it on GitHub
> >> <#1296 (comment)>,
> or
> >> unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/AAAQZEDPWQPSFBRNMPR3PRDX6YF5RAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWG4YDGMRYG4>
>
> >> .
> >> You are receiving this because you authored the thread.Message ID:
> >> ***@***.***>
> >>
> >
>
> —
> Reply to this email directly, view it on GitHub
> <#1296 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADKRAFITJ4BKSXUPZEMALLLX62H6NANCNFSM6AAAAAAZ2H65AA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
OK, so these are not with mortality and replacement. In that case you
could compare both the HARK simulation and yours with the analytical
solution.
On Wed, Oct 11, 2023 at 8:38 AM Sebastian Benthall ***@***.***>
wrote:
… Thanks for the theoretical review, Chris.
No doubt there is a bug in my code somewhere.
I'm running these simulations to test Generic Monte Carlo simulation
functionality on a known case.
The two plots use the same consumption function.
So I suspect that either the way I've specified the dynamics and
parameters
in the second simulation diverges in some way from the HARK 0.13 version,
or something about how I'm handling mortality is different.
Naturally, I agree that reproducing the HARK 0.13 results is necessary.
On Tue, Oct 10, 2023, 11:19 PM Christopher Llorracc Carroll <
***@***.***> wrote:
> In the PF model infinite horizon model, the growth factor for
consumption
> is $\frac{c_{t+1}}{c_{t}}=(R \beta)^{1/\rho}$ perpetually. The
definition
> of the Absolute Impatience condition is $(R \beta)^{1/\rho} < 1$., or
> (nearly equivalently) (1/\rho)(r-\theta) < 0$.
>
> Lessons:
>
> 1. You should be plotting the logarithm of m not the level.
> 2. The correct answer is that it is perpetually declining, always at
> exactly the same rate (linearly)
> - So the first diagram looks approximately right
>
> This all neglects permanent income growth, but the same propositions
hold
> for normalized consumption growth, where the relevant impatience
condition
> is the Growth Impatience Condition $(R \beta)^{1/\rho}/\Gamma < 1$ or
> equivalently $(1/\rho)(r-\theta) - \gamma < 0.$
>
> I take it that the reason you need to do simulations is that you have
> introduced stochastic mortality, so some agents die and are replaced by
> newborns.
>
> But the second figure looks deeply wrong to me.
>
> PS. Note that I do the math for the version of the model with population
> growth and mortality in the last section of my TractableBufferStock
> lecture
> notes:
>
> https://llorracc.github.io/TractableBufferStock
>
> and a more general version in this paper with my colleague Olivier
Jeanne:
>
> https://www.econ2.jhu.edu/people/ccarroll/papers/cjSOE/
>
>
>
> On Mon, Oct 9, 2023 at 6:34 PM Sebastian Benthall ***@***.***>
> wrote:
>
> > OK, there is now a notebook in this PR that directly compares the HARK
> > 0.13 Perfect Foresight simulation with the results from using the HARK
> 0.13
> > Perfect Foresight *solution* with the generic Monte Carlo simulator
I've
> > been working on here.
> >
> > The good news is that it executes in reasonable-looking way while
using
> > the Python PF model definition.
> > I did need to make one small change to the model compared to how it
was
> > originally merged in:
> > 5ef3a19
> > <
>
5ef3a19>
>
> >
> > This means that in the Python configured model, the update of income
*y*
> > is not lagged behind the update of permanent income *p* as I believe
it
> > was in the HARK version.
> >
> > The bad news is that the two simulation outputs look different! I'm
not
> > sure if this is caused by the model change I just described, or a
deeper
> > problem.
> >
> > Here's mean normalized market resources over time from H0.13 PF:
> >
> > [image: image]
> > <
>
https://user-images.githubusercontent.com/68752/273717374-510ac5d2-dca3-43fc-a7d1-9280323980a5.png>
>
> >
> > Here's mean normalized market resources over time from the current
state
> > of this PR:
> >
> > [image: image]
> > <
>
https://user-images.githubusercontent.com/68752/273717656-e74ba722-cd1f-4d93-9282-da328a099f9d.png>
>
> > Which is pretty weird.
> >
> > Here is the notebook
> >
> >
>
https://github.com/econ-ark/HARK/blob/b95b0f4a20092651481413cf400203040d055137/examples/MonteCarlo/Generic%20Monte%20Carlo%20Perfect%20Foresight.ipynb
> >
> > I can keep trying to fix this up.
> >
> > But I think that at this point, the PR would benefit hugely from a
> review
> > from @mnwhite <https://github.com/mnwhite> .
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <#1296 (comment)>,
> or
> > unsubscribe
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK77YXXPYPTRYNKNI6N3X6R3XDAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJTHE4TKOBXGA>
>
> > .
> > You are receiving this because you were mentioned.Message ID:
> > ***@***.***>
> >
>
>
> --
> - Chris Carroll
>
> —
> Reply to this email directly, view it on GitHub
> <#1296 (comment)>,
or
> unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAAQZEDPWQPSFBRNMPR3PRDX6YF5RAVCNFSM6AAAAAAZ2H65ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWG4YDGMRYG4>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1296 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKCK76LI6WI4CDFXIWM7ELX62HKRANCNFSM6AAAAAAZ2H65AA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
- Chris Carroll
|
|
Hmmm. With
But I suppose there are good numerical explanations for this. Turning off mortality and variance in starting wealth didn't fix the major ways the generic simulation is off. Which makes me think that the dynamics are not captured in the new python configuration properly. This is the HARK 0.13 transition function: This is the new python configuration for perfect foresight. It has some differences. One key one being that I don't think So, I'll work on a comparable model that is normalized and closer to the HARK 0.13 version. |
…eneric monte carlo example shows exact match
|
I'm pleased to report that using the new normalized perfect foresight configuration (which took just a few minutes to code up): and with no mortality and initial wealth variance, I am getting an exact match between HARK 0.13 and generic monte carlo normalized m.
Numerical tests show that there is indeed 0 difference. Now, I believe this PR is ready for your review, @mnwhite |
|
As of the most recent commit, the example notebook in this PR uses the |
|
There is a small discrepancy between the results in this PR and the results in HARK 0.13 In HARK 0.13, the simulation loop at time
When tracking the I believe that in conversation, @mnwhite has said that this is a mistaken design. I'm aiming to correct this mistake in the PR. How should it work? I think it should go like this: Is that right? |
|
What I'll do is patch HARK 0.13 so that 'who_dies' is recorded into history at |
…onte carlo now matches exact
|
The generic Monte Carlo perfect foresight example now matches the HARK 0.13 results exactly. |
|
Finally got it passing all the pre-commit checks. Phew. |
|
Polished up the documentation. All the checkboxes are checked. I think this is ready to merge. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a start to an implementing a generic sim_one_period method for Monte Carlo approaches. . See #1295
It is a standalone function that takes as arguments:
The transition function is then very simple.
Not yet implemented: