Constrained perfect foresight #299
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
PerfForesightConsumerType can now handle an artificial borrowing constraint, like in all our other models. Currently doesn't calculate value function if BoroCnstArt is not None, as this requires additional work to compute. When this is merged, it will be a breaking change for all existing instances of PerfForesightConsumerType, as they will now require BoroCnstArt and aXtraCount to be attributes.
The "universal distance metric" had a bug in one line that had never come up. If the two objects being compared have a shape, but the shapes are not the same, then it tried to take the supnorm between them; this fails because arithmetic is not defined on tuples. Fix simply converts the shape tuples into arrays.
Forgot that I eliminated the redundant mNrmMin (only use mNrmMinNow). Now fixed.
|
Okay, automated testing is pretty cool. It alerted me to a (stupid) typo I made at the last minute by failing to manually test a case. |
Apparently Py3 doesn't like to compare float and None, but Py2 is fine with this (and is correct: None is neither greater than, equal to, or less than any real number). Now fixed.
|
Even cooler: It flagged something that works in Py2 but not Py3. Very neat. |
Now everything will run like before.
|
The model notebook in DEMARK has been updated to account for this change (in a PR), but it should only be merged once this PR is merged and we do a release. Our DEMARKs are pointing to the latest public release of HARK, correct? |
|
Good question. It was not. I've now updated reqirements.txt. Also
noticed that postBuild.bat did not have the automatic connection to the
Zotero database that was there for the unix postBuild so I've added it to
the bat file. Can you test whether it works?
…On Sun, Jun 2, 2019 at 4:17 PM Matthew N. White ***@***.***> wrote:
The model notebook in DEMARK has been updated to account for this change
(in a PR), but it should only be merged once this PR is merged *and* we
do a release. Our DEMARKs are pointing to the latest public release of
HARK, correct?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK7Z2ALUI527OFONEQCDPYQTEXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX5FGY#issuecomment-498061979>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK74UQUXKZHYSJ4HZEVLPYQTEXANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
Just looked through the code -- it looks good (though haven't tested until we resolve whether this should be a "breaking change". I don't want to do the thing of including a custom version of ConsIndShockModel.py in a notebook until we make the new release. But one question: Don't see why the aXtraGrid parameter is necessary. The extra gridpoints are constructed on the fly, and there'll be one of them added for each iteration, so the user doesn't need to specify that number in advance, just needs to specify how many periods back to solve, right? In fact, if aXtraGrid is fixed and they specify that the problem should be solved one more period, there's no way to do that without adding more gridpoints? |
|
You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to run an
infinite horizon model with a borrowing constraint and aXtraCount set to
None, then the solver will repeatedly add one more kink, over and over
again. The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an array
of size 258 and an array of size 259 can be "close"! Eventually, the top
gridpoint becomes so high that there's an overflow error and the solution
collapses.
So we need to either specify a maximum amount of gridpoints or a highest
value (relative to the lowest value). I sense that you're going to suggest
that we change the distance criterion to mNrmSS, but that would have very
bad effects in the perfect foresight model. The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but the
consumption function above it is *way* off from the correct solution.
Note that you don't need to put this custom version into a notebook to test
it. Just use developer mode on your computer and change your branch to
mine. If your (locally run) notebook imports HARK, then it will use my
version!
…-- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll < ***@***.***> wrote:
Just looked through the code -- it looks good (though haven't tested until
we resolve whether this should be a "breaking change". I don't want to do
the thing of including a custom version of ConsIndShockModel.py in a
notebook until we make the new release.
But one question: Don't see why the aXtraGrid parameter is necessary. The
extra gridpoints are constructed on the fly, and there'll be one of them
added for each iteration, so the user doesn't need to specify that number
in advance, just needs to specify how many periods back to solve, right? In
fact, if aXtraGrid is fixed and they specify that the problem should be
solved one more period, there's no way to do that without adding more
gridpoints?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A>
.
|
|
Realized I never responded to this. I'll try to test it at some point; I
know I had to do some of the installation steps "by hand" because they
didn't work right in postBuild.
On Sun, Jun 2, 2019 at 5:59 PM Christopher Llorracc Carroll <
[email protected]> wrote:
… Good question. It was not. I've now updated reqirements.txt. Also
noticed that postBuild.bat did not have the automatic connection to the
Zotero database that was there for the unix postBuild so I've added it to
the bat file. Can you test whether it works?
On Sun, Jun 2, 2019 at 4:17 PM Matthew N. White ***@***.***>
wrote:
> The model notebook in DEMARK has been updated to account for this change
> (in a PR), but it should only be merged once this PR is merged *and* we
> do a release. Our DEMARKs are pointing to the latest public release of
> HARK, correct?
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK7Z2ALUI527OFONEQCDPYQTEXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX5FGY#issuecomment-498061979
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK74UQUXKZHYSJ4HZEVLPYQTEXANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFONF7ROO4G2UWIDHGDPYQ7BDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWX626Q#issuecomment-498068858>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFO6TN36SDMG5U6OYALPYQ7BDANCNFSM4HRRZV2A>
.
|
|
"until the cFunc converges" requires some convergence criterion. If that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding to
future constraints) at which the right and left derivatives are different.
(Kink points).
I hate such functions, and think that in polite society (by which I mean by
computational modelers) they should [not be received]((
https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J)) by
people doing computational work. (That is, we should not go out of our way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many derivatives)
over an interval can be (in the limit) represented with arbitrary accuracy
by polynomials (I think that's the gist of his theorem). I like him better
for pointing out the existence of functions that [CANNOT be represented
that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are finitely
different for a finite number of points, which is an abomination (from the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required to
define their own convergence criterion). But if they are supplying the
'level' criterion there is no reason to require them also (redundantly) to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <[email protected]>
wrote:
You can't specify how many periods back to solve if it's an infinite
horizon model-- it solves until the cFunc converges. If you try to run an
infinite horizon model with a borrowing constraint and aXtraCount set to
None, then the solver will repeatedly add one more kink, over and over
again.
Yay for it! That's the right thing to do!
The model is never considered "converged" because the number of
gridpoints in successive iterations isn't equal-- there's no way an array
of size 258 and an array of size 259 can be "close"! Eventually, the top
gridpoint becomes so high that there's an overflow error and the solution
collapses.
But, I think this is the right answer!
So we need to either specify a maximum amount of gridpoints or a highest
value (relative to the lowest value). I sense that you're going to suggest
that we change the distance criterion to mNrmSS, but that would have very
bad effects in the perfect foresight model. The consumption function is
essentially constructed from "bottom upward" in the PF model, so mNrmSS
will very quickly return the same value on successive iterations... but the
consumption function above it is *way* off from the correct solution.
Note that you don't need to put this custom version into a notebook to test
it. Just use developer mode on your computer and change your branch to
mine. If your (locally run) notebook imports HARK, then it will use my
version!
Yes, but I want to SHARE this notebook with referees/editors/the universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough. To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.
… -- mnw
On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
***@***.***> wrote:
> Just looked through the code -- it looks good (though haven't tested
until
> we resolve whether this should be a "breaking change". I don't want to do
> the thing of including a custom version of ConsIndShockModel.py in a
> notebook until we make the new release.
>
> But one question: Don't see why the aXtraGrid parameter is necessary. The
> extra gridpoints are constructed on the fly, and there'll be one of them
> added for each iteration, so the user doesn't need to specify that number
> in advance, just needs to specify how many periods back to solve, right?
In
> fact, if aXtraGrid is fixed and they specify that the problem should be
> solved one more period, there's no way to do that without adding more
> gridpoints?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
These "breaking changes" are incredibly minor. Fixing the problem merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries. Actually, I'll just add this stupid
feature. This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
…-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <[email protected]>
wrote:
"until the cFunc converges" requires some convergence criterion. If that
criterion includes the MPC $c^{\prime(m))$, there IS no interval over which
"the cFunc converges"
Of course there are many definitions of "converges" but because
$c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
whether $c^{\prime}(m)$ converges monotonically at every $m$.
It does not, because there are always these pesky points (corresponding to
future constraints) at which the right and left derivatives are different.
(Kink points).
I hate such functions, and think that in polite society (by which I mean by
computational modelers) they should [not be received]((
https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J)) by
people doing computational work. (That is, we should not go out of our way
to try to accommodate them).
PS. People remember Karl Weierstrass for his finding that any function
which "is" continuously differentiable (to arbitrarily many derivatives)
over an interval can be (in the limit) represented with arbitrary accuracy
by polynomials (I think that's the gist of his theorem). I like him better
for pointing out the existence of functions that [CANNOT be represented
that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
Even if it is true that the limits of the left and right derivatives
converge at every point, for any finite number of periods they are finitely
different for a finite number of points, which is an abomination (from the
standpoint of people who want to stably represent functions in discrete
terms like those that computers can easily handle). At those points,
$c^{\prime}$ is undefined.
So, my view is that the user can specify a convergence criterion for the
LEVEL of $c$ that (say) should apply at every gridpoint, or they should
supply a number of periods backwards (otherwise they should be required to
define their own convergence criterion). But if they are supplying the
'level' criterion there is no reason to require them also (redundantly) to
incorporate aExtraGrid.
PS. (I'm also on the side of Kronecker, who said "God made the integers;
all else is the work of Man").
This kind of gets into metaphysics realms of math.
On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White ***@***.***>
wrote:
> You can't specify how many periods back to solve if it's an infinite
> horizon model-- it solves until the cFunc converges. If you try to run an
> infinite horizon model with a borrowing constraint and aXtraCount set to
> None, then the solver will repeatedly add one more kink, over and over
> again.
Yay for it! That's the right thing to do!
> The model is never considered "converged" because the number of
> gridpoints in successive iterations isn't equal-- there's no way an array
> of size 258 and an array of size 259 can be "close"! Eventually, the top
> gridpoint becomes so high that there's an overflow error and the solution
> collapses.
>
But, I think this is the right answer!
>
> So we need to either specify a maximum amount of gridpoints or a highest
> value (relative to the lowest value). I sense that you're going to
suggest
> that we change the distance criterion to mNrmSS, but that would have very
> bad effects in the perfect foresight model. The consumption function is
> essentially constructed from "bottom upward" in the PF model, so mNrmSS
> will very quickly return the same value on successive iterations... but
the
> consumption function above it is *way* off from the correct solution.
>
> Note that you don't need to put this custom version into a notebook to
test
> it. Just use developer mode on your computer and change your branch to
> mine. If your (locally run) notebook imports HARK, then it will use my
> version!
>
Yes, but I want to SHARE this notebook with referees/editors/the universe.
If I could impose a requirements "econ-ark==" whatever in which I could
guarantee it would work, then that might be enough. To do that we'd need
to create a new dev branch (containing the breaking changes) which will
exist in perpetuity that my code can insist upon.
> -- mnw
>
>
>
> On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > Just looked through the code -- it looks good (though haven't tested
> until
> > we resolve whether this should be a "breaking change". I don't want to
do
> > the thing of including a custom version of ConsIndShockModel.py in a
> > notebook until we make the new release.
> >
> > But one question: Don't see why the aXtraGrid parameter is necessary.
The
> > extra gridpoints are constructed on the fly, and there'll be one of
them
> > added for each iteration, so the user doesn't need to specify that
number
> > in advance, just needs to specify how many periods back to solve,
right?
> In
> > fact, if aXtraGrid is fixed and they specify that the problem should be
> > solved one more period, there's no way to do that without adding more
> > gridpoints?
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A>
.
|
|
If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we want to
say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want to
solve, and the number of gridpoints is periods+2. Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45 degree
line). If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves, they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to make a
DemARK notebook to illustrate some of this as a companion to the LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <[email protected]>
wrote:
… These "breaking changes" are incredibly minor. Fixing the problem merely
requires anyone using PerfForesightConsumerType to add BoroCnstArt and
aXtraCount to their dictionaries. Actually, I'll just add this stupid
feature. This isn't a fight worth having.
If you prefer a different stopping condition, I can change it to aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
-- mnw
On Fri, Jun 7, 2019 at 11:21 PM llorracc-git ***@***.***>
wrote:
> "until the cFunc converges" requires some convergence criterion. If that
> criterion includes the MPC $c^{\prime(m))$, there IS no interval over
which
> "the cFunc converges"
>
> Of course there are many definitions of "converges" but because
> $c^{\prime}(m)$ is crucial for so many questions, I'd say the question is
> whether $c^{\prime}(m)$ converges monotonically at every $m$.
>
> It does not, because there are always these pesky points (corresponding
to
> future constraints) at which the right and left derivatives are
different.
> (Kink points).
>
> I hate such functions, and think that in polite society (by which I mean
by
> computational modelers) they should [not be received]((
> https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J)) by
> people doing computational work. (That is, we should not go out of our
way
> to try to accommodate them).
>
> PS. People remember Karl Weierstrass for his finding that any function
> which "is" continuously differentiable (to arbitrarily many derivatives)
> over an interval can be (in the limit) represented with arbitrary
accuracy
> by polynomials (I think that's the gist of his theorem). I like him
better
> for pointing out the existence of functions that [CANNOT be represented
> that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
>
> Even if it is true that the limits of the left and right derivatives
> converge at every point, for any finite number of periods they are
finitely
> different for a finite number of points, which is an abomination (from
the
> standpoint of people who want to stably represent functions in discrete
> terms like those that computers can easily handle). At those points,
> $c^{\prime}$ is undefined.
>
> So, my view is that the user can specify a convergence criterion for the
> LEVEL of $c$ that (say) should apply at every gridpoint, or they should
> supply a number of periods backwards (otherwise they should be required
to
> define their own convergence criterion). But if they are supplying the
> 'level' criterion there is no reason to require them also (redundantly)
to
> incorporate aExtraGrid.
>
> PS. (I'm also on the side of Kronecker, who said "God made the integers;
> all else is the work of Man").
>
>
>
> This kind of gets into metaphysics realms of math.
>
> On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
***@***.***>
> wrote:
>
> > You can't specify how many periods back to solve if it's an infinite
> > horizon model-- it solves until the cFunc converges. If you try to run
an
> > infinite horizon model with a borrowing constraint and aXtraCount set
to
> > None, then the solver will repeatedly add one more kink, over and over
> > again.
>
>
> Yay for it! That's the right thing to do!
>
>
> > The model is never considered "converged" because the number of
> > gridpoints in successive iterations isn't equal-- there's no way an
array
> > of size 258 and an array of size 259 can be "close"! Eventually, the
top
> > gridpoint becomes so high that there's an overflow error and the
solution
> > collapses.
> >
>
> But, I think this is the right answer!
>
>
> >
> > So we need to either specify a maximum amount of gridpoints or a
highest
> > value (relative to the lowest value). I sense that you're going to
> suggest
> > that we change the distance criterion to mNrmSS, but that would have
very
> > bad effects in the perfect foresight model. The consumption function is
> > essentially constructed from "bottom upward" in the PF model, so mNrmSS
> > will very quickly return the same value on successive iterations... but
> the
> > consumption function above it is *way* off from the correct solution.
> >
> > Note that you don't need to put this custom version into a notebook to
> test
> > it. Just use developer mode on your computer and change your branch to
> > mine. If your (locally run) notebook imports HARK, then it will use my
> > version!
> >
>
> Yes, but I want to SHARE this notebook with referees/editors/the
universe.
> If I could impose a requirements "econ-ark==" whatever in which I could
> guarantee it would work, then that might be enough. To do that we'd need
> to create a new dev branch (containing the breaking changes) which will
> exist in perpetuity that my code can insist upon.
>
> > -- mnw
> >
> >
> >
> > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > ***@***.***> wrote:
> >
> > > Just looked through the code -- it looks good (though haven't tested
> > until
> > > we resolve whether this should be a "breaking change". I don't want
to
> do
> > > the thing of including a custom version of ConsIndShockModel.py in a
> > > notebook until we make the new release.
> > >
> > > But one question: Don't see why the aXtraGrid parameter is necessary.
> The
> > > extra gridpoints are constructed on the fly, and there'll be one of
> them
> > > added for each iteration, so the user doesn't need to specify that
> number
> > > in advance, just needs to specify how many periods back to solve,
> right?
> > In
> > > fact, if aXtraGrid is fixed and they specify that the problem should
be
> > > solved one more period, there's no way to do that without adding more
> > > gridpoints?
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> >
> > .
> >
>
>
> --
> - Chris Carroll
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
That's essentially what aXtraCount does; I just used that variable name to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's what
generates "convergence".
…-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
[email protected]> wrote:
> If you prefer a different stopping condition, I can change it to
aXtraMax,
where you specify a (very large) aNrm beyond which you would never possibly
care about the consumption function, like 2000. Any kinks beyond that are
considered irrelevant.
I've thought about it a bit more and my view, translated from the
metaphysics, is that the right definition of convergence is that we want to
say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
converge. But every extra iteration back adds another point at which
$c'(m)$ is undefined, so the function never converges in that sense.
So, I think the user of the constrained version of the solver function
should just be required to say how many periods from the end they want to
solve, and the number of gridpoints is periods+2. Like, if they want to
solve zero periods back, we need only 2 gridpoints (to define the 45 degree
line). If they want to solve 1 period, the function is piecewise linear
with two segments, so we need 3 gridpoints, and so on. Does that make
sense? If they want to define some convergence criterion themselves, they
can do it by adding that to the specification of the function.
Didn't want to get into a fight about this, just want to be able to make a
DemARK notebook to illustrate some of this as a companion to the LiqConstr
REMARK.
On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White ***@***.***
>
wrote:
> These "breaking changes" are incredibly minor. Fixing the problem merely
> requires anyone using PerfForesightConsumerType to add BoroCnstArt and
> aXtraCount to their dictionaries. Actually, I'll just add this stupid
> feature. This isn't a fight worth having.
>
> If you prefer a different stopping condition, I can change it to
aXtraMax,
> where you specify a (very large) aNrm beyond which you would never
possibly
> care about the consumption function, like 2000. Any kinks beyond that are
> considered irrelevant.
>
> -- mnw
>
> On Fri, Jun 7, 2019 at 11:21 PM llorracc-git ***@***.***>
> wrote:
>
> > "until the cFunc converges" requires some convergence criterion. If
that
> > criterion includes the MPC $c^{\prime(m))$, there IS no interval over
> which
> > "the cFunc converges"
> >
> > Of course there are many definitions of "converges" but because
> > $c^{\prime}(m)$ is crucial for so many questions, I'd say the question
is
> > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> >
> > It does not, because there are always these pesky points (corresponding
> to
> > future constraints) at which the right and left derivatives are
> different.
> > (Kink points).
> >
> > I hate such functions, and think that in polite society (by which I
mean
> by
> > computational modelers) they should [not be received]((
> > https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J))
by
> > people doing computational work. (That is, we should not go out of our
> way
> > to try to accommodate them).
> >
> > PS. People remember Karl Weierstrass for his finding that any function
> > which "is" continuously differentiable (to arbitrarily many
derivatives)
> > over an interval can be (in the limit) represented with arbitrary
> accuracy
> > by polynomials (I think that's the gist of his theorem). I like him
> better
> > for pointing out the existence of functions that [CANNOT be represented
> > that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
> >
> > Even if it is true that the limits of the left and right derivatives
> > converge at every point, for any finite number of periods they are
> finitely
> > different for a finite number of points, which is an abomination (from
> the
> > standpoint of people who want to stably represent functions in discrete
> > terms like those that computers can easily handle). At those points,
> > $c^{\prime}$ is undefined.
> >
> > So, my view is that the user can specify a convergence criterion for
the
> > LEVEL of $c$ that (say) should apply at every gridpoint, or they should
> > supply a number of periods backwards (otherwise they should be required
> to
> > define their own convergence criterion). But if they are supplying the
> > 'level' criterion there is no reason to require them also (redundantly)
> to
> > incorporate aExtraGrid.
> >
> > PS. (I'm also on the side of Kronecker, who said "God made the
integers;
> > all else is the work of Man").
> >
> >
> >
> > This kind of gets into metaphysics realms of math.
> >
> > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> ***@***.***>
> > wrote:
> >
> > > You can't specify how many periods back to solve if it's an infinite
> > > horizon model-- it solves until the cFunc converges. If you try to
run
> an
> > > infinite horizon model with a borrowing constraint and aXtraCount set
> to
> > > None, then the solver will repeatedly add one more kink, over and
over
> > > again.
> >
> >
> > Yay for it! That's the right thing to do!
> >
> >
> > > The model is never considered "converged" because the number of
> > > gridpoints in successive iterations isn't equal-- there's no way an
> array
> > > of size 258 and an array of size 259 can be "close"! Eventually, the
> top
> > > gridpoint becomes so high that there's an overflow error and the
> solution
> > > collapses.
> > >
> >
> > But, I think this is the right answer!
> >
> >
> > >
> > > So we need to either specify a maximum amount of gridpoints or a
> highest
> > > value (relative to the lowest value). I sense that you're going to
> > suggest
> > > that we change the distance criterion to mNrmSS, but that would have
> very
> > > bad effects in the perfect foresight model. The consumption function
is
> > > essentially constructed from "bottom upward" in the PF model, so
mNrmSS
> > > will very quickly return the same value on successive iterations...
but
> > the
> > > consumption function above it is *way* off from the correct solution.
> > >
> > > Note that you don't need to put this custom version into a notebook
to
> > test
> > > it. Just use developer mode on your computer and change your branch
to
> > > mine. If your (locally run) notebook imports HARK, then it will use
my
> > > version!
> > >
> >
> > Yes, but I want to SHARE this notebook with referees/editors/the
> universe.
> > If I could impose a requirements "econ-ark==" whatever in which I could
> > guarantee it would work, then that might be enough. To do that we'd
need
> > to create a new dev branch (containing the breaking changes) which will
> > exist in perpetuity that my code can insist upon.
> >
> > > -- mnw
> > >
> > >
> > >
> > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > > ***@***.***> wrote:
> > >
> > > > Just looked through the code -- it looks good (though haven't
tested
> > > until
> > > > we resolve whether this should be a "breaking change". I don't want
> to
> > do
> > > > the thing of including a custom version of ConsIndShockModel.py in
a
> > > > notebook until we make the new release.
> > > >
> > > > But one question: Don't see why the aXtraGrid parameter is
necessary.
> > The
> > > > extra gridpoints are constructed on the fly, and there'll be one of
> > them
> > > > added for each iteration, so the user doesn't need to specify that
> > number
> > > > in advance, just needs to specify how many periods back to solve,
> > right?
> > > In
> > > > fact, if aXtraGrid is fixed and they specify that the problem
should
> be
> > > > solved one more period, there's no way to do that without adding
more
> > > > gridpoints?
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you are subscribed to this thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> >
> > --
> > - Chris Carroll
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A>
.
|
|
I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative would
be for the terminal function to be the unconstrained analytical solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <[email protected]>
wrote:
… That's essentially what aXtraCount does; I just used that variable name to
be like the other models. You're specifying how many periods worth of
kinks to care about, and throwing out everything beyond that. That's what
generates "convergence".
-- mnw
On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
***@***.***> wrote:
> > If you prefer a different stopping condition, I can change it to
> aXtraMax,
> where you specify a (very large) aNrm beyond which you would never
possibly
> care about the consumption function, like 2000. Any kinks beyond that are
> considered irrelevant.
>
> I've thought about it a bit more and my view, translated from the
> metaphysics, is that the right definition of convergence is that we want
to
> say that a function has converged if at every $m$ both $c(m)$ and $c'(m)$
> converge. But every extra iteration back adds another point at which
> $c'(m)$ is undefined, so the function never converges in that sense.
>
> So, I think the user of the constrained version of the solver function
> should just be required to say how many periods from the end they want to
> solve, and the number of gridpoints is periods+2. Like, if they want to
> solve zero periods back, we need only 2 gridpoints (to define the 45
degree
> line). If they want to solve 1 period, the function is piecewise linear
> with two segments, so we need 3 gridpoints, and so on. Does that make
> sense? If they want to define some convergence criterion themselves, they
> can do it by adding that to the specification of the function.
>
> Didn't want to get into a fight about this, just want to be able to make
a
> DemARK notebook to illustrate some of this as a companion to the
LiqConstr
> REMARK.
>
> On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
***@***.***
> >
> wrote:
>
> > These "breaking changes" are incredibly minor. Fixing the problem
merely
> > requires anyone using PerfForesightConsumerType to add BoroCnstArt and
> > aXtraCount to their dictionaries. Actually, I'll just add this stupid
> > feature. This isn't a fight worth having.
> >
> > If you prefer a different stopping condition, I can change it to
> aXtraMax,
> > where you specify a (very large) aNrm beyond which you would never
> possibly
> > care about the consumption function, like 2000. Any kinks beyond that
are
> > considered irrelevant.
> >
> > -- mnw
> >
> > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git ***@***.***
>
> > wrote:
> >
> > > "until the cFunc converges" requires some convergence criterion. If
> that
> > > criterion includes the MPC $c^{\prime(m))$, there IS no interval over
> > which
> > > "the cFunc converges"
> > >
> > > Of course there are many definitions of "converges" but because
> > > $c^{\prime}(m)$ is crucial for so many questions, I'd say the
question
> is
> > > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> > >
> > > It does not, because there are always these pesky points
(corresponding
> > to
> > > future constraints) at which the right and left derivatives are
> > different.
> > > (Kink points).
> > >
> > > I hate such functions, and think that in polite society (by which I
> mean
> > by
> > > computational modelers) they should [not be received]((
> > > https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J))
> by
> > > people doing computational work. (That is, we should not go out of
our
> > way
> > > to try to accommodate them).
> > >
> > > PS. People remember Karl Weierstrass for his finding that any
function
> > > which "is" continuously differentiable (to arbitrarily many
> derivatives)
> > > over an interval can be (in the limit) represented with arbitrary
> > accuracy
> > > by polynomials (I think that's the gist of his theorem). I like him
> > better
> > > for pointing out the existence of functions that [CANNOT be
represented
> > > that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
> > >
> > > Even if it is true that the limits of the left and right derivatives
> > > converge at every point, for any finite number of periods they are
> > finitely
> > > different for a finite number of points, which is an abomination
(from
> > the
> > > standpoint of people who want to stably represent functions in
discrete
> > > terms like those that computers can easily handle). At those points,
> > > $c^{\prime}$ is undefined.
> > >
> > > So, my view is that the user can specify a convergence criterion for
> the
> > > LEVEL of $c$ that (say) should apply at every gridpoint, or they
should
> > > supply a number of periods backwards (otherwise they should be
required
> > to
> > > define their own convergence criterion). But if they are supplying
the
> > > 'level' criterion there is no reason to require them also
(redundantly)
> > to
> > > incorporate aExtraGrid.
> > >
> > > PS. (I'm also on the side of Kronecker, who said "God made the
> integers;
> > > all else is the work of Man").
> > >
> > >
> > >
> > > This kind of gets into metaphysics realms of math.
> > >
> > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > ***@***.***>
> > > wrote:
> > >
> > > > You can't specify how many periods back to solve if it's an
infinite
> > > > horizon model-- it solves until the cFunc converges. If you try to
> run
> > an
> > > > infinite horizon model with a borrowing constraint and aXtraCount
set
> > to
> > > > None, then the solver will repeatedly add one more kink, over and
> over
> > > > again.
> > >
> > >
> > > Yay for it! That's the right thing to do!
> > >
> > >
> > > > The model is never considered "converged" because the number of
> > > > gridpoints in successive iterations isn't equal-- there's no way an
> > array
> > > > of size 258 and an array of size 259 can be "close"! Eventually,
the
> > top
> > > > gridpoint becomes so high that there's an overflow error and the
> > solution
> > > > collapses.
> > > >
> > >
> > > But, I think this is the right answer!
> > >
> > >
> > > >
> > > > So we need to either specify a maximum amount of gridpoints or a
> > highest
> > > > value (relative to the lowest value). I sense that you're going to
> > > suggest
> > > > that we change the distance criterion to mNrmSS, but that would
have
> > very
> > > > bad effects in the perfect foresight model. The consumption
function
> is
> > > > essentially constructed from "bottom upward" in the PF model, so
> mNrmSS
> > > > will very quickly return the same value on successive iterations...
> but
> > > the
> > > > consumption function above it is *way* off from the correct
solution.
> > > >
> > > > Note that you don't need to put this custom version into a notebook
> to
> > > test
> > > > it. Just use developer mode on your computer and change your branch
> to
> > > > mine. If your (locally run) notebook imports HARK, then it will use
> my
> > > > version!
> > > >
> > >
> > > Yes, but I want to SHARE this notebook with referees/editors/the
> > universe.
> > > If I could impose a requirements "econ-ark==" whatever in which I
could
> > > guarantee it would work, then that might be enough. To do that we'd
> need
> > > to create a new dev branch (containing the breaking changes) which
will
> > > exist in perpetuity that my code can insist upon.
> > >
> > > > -- mnw
> > > >
> > > >
> > > >
> > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > > > ***@***.***> wrote:
> > > >
> > > > > Just looked through the code -- it looks good (though haven't
> tested
> > > > until
> > > > > we resolve whether this should be a "breaking change". I don't
want
> > to
> > > do
> > > > > the thing of including a custom version of ConsIndShockModel.py
in
> a
> > > > > notebook until we make the new release.
> > > > >
> > > > > But one question: Don't see why the aXtraGrid parameter is
> necessary.
> > > The
> > > > > extra gridpoints are constructed on the fly, and there'll be one
of
> > > them
> > > > > added for each iteration, so the user doesn't need to specify
that
> > > number
> > > > > in advance, just needs to specify how many periods back to solve,
> > > right?
> > > > In
> > > > > fact, if aXtraGrid is fixed and they specify that the problem
> should
> > be
> > > > > solved one more period, there's no way to do that without adding
> more
> > > > > gridpoints?
> > > > >
> > > > > —
> > > > > You are receiving this because you authored the thread.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > > —
> > > > You are receiving this because you are subscribed to this thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > >
> > > --
> > > - Chris Carroll
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were assigned.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> >
> > .
> >
>
>
> --
> - Chris Carroll
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
It's called aXtraCount, not aXtraGrid. We can call it anything you want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would take
real effort/thought/work. If you want this ready to use on your project,
this is not something you should be asking for now.
…-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
[email protected]> wrote:
I see, so we are on the same page. But, I'm afraid that calling it
aXtraGrid might be confusing to users. Could we call it something else,
like "NumCnstPrds" or something like that?
PS. I take it that the terminal function is $c=m$? An alternative would
be for the terminal function to be the unconstrained analytical solution.
On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White ***@***.***
>
wrote:
> That's essentially what aXtraCount does; I just used that variable name
to
> be like the other models. You're specifying how many periods worth of
> kinks to care about, and throwing out everything beyond that. That's what
> generates "convergence".
>
> -- mnw
>
> On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > > If you prefer a different stopping condition, I can change it to
> > aXtraMax,
> > where you specify a (very large) aNrm beyond which you would never
> possibly
> > care about the consumption function, like 2000. Any kinks beyond that
are
> > considered irrelevant.
> >
> > I've thought about it a bit more and my view, translated from the
> > metaphysics, is that the right definition of convergence is that we
want
> to
> > say that a function has converged if at every $m$ both $c(m)$ and
$c'(m)$
> > converge. But every extra iteration back adds another point at which
> > $c'(m)$ is undefined, so the function never converges in that sense.
> >
> > So, I think the user of the constrained version of the solver function
> > should just be required to say how many periods from the end they want
to
> > solve, and the number of gridpoints is periods+2. Like, if they want to
> > solve zero periods back, we need only 2 gridpoints (to define the 45
> degree
> > line). If they want to solve 1 period, the function is piecewise linear
> > with two segments, so we need 3 gridpoints, and so on. Does that make
> > sense? If they want to define some convergence criterion themselves,
they
> > can do it by adding that to the specification of the function.
> >
> > Didn't want to get into a fight about this, just want to be able to
make
> a
> > DemARK notebook to illustrate some of this as a companion to the
> LiqConstr
> > REMARK.
> >
> > On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
> ***@***.***
> > >
> > wrote:
> >
> > > These "breaking changes" are incredibly minor. Fixing the problem
> merely
> > > requires anyone using PerfForesightConsumerType to add BoroCnstArt
and
> > > aXtraCount to their dictionaries. Actually, I'll just add this stupid
> > > feature. This isn't a fight worth having.
> > >
> > > If you prefer a different stopping condition, I can change it to
> > aXtraMax,
> > > where you specify a (very large) aNrm beyond which you would never
> > possibly
> > > care about the consumption function, like 2000. Any kinks beyond that
> are
> > > considered irrelevant.
> > >
> > > -- mnw
> > >
> > > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
***@***.***
> >
> > > wrote:
> > >
> > > > "until the cFunc converges" requires some convergence criterion. If
> > that
> > > > criterion includes the MPC $c^{\prime(m))$, there IS no interval
over
> > > which
> > > > "the cFunc converges"
> > > >
> > > > Of course there are many definitions of "converges" but because
> > > > $c^{\prime}(m)$ is crucial for so many questions, I'd say the
> question
> > is
> > > > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> > > >
> > > > It does not, because there are always these pesky points
> (corresponding
> > > to
> > > > future constraints) at which the right and left derivatives are
> > > different.
> > > > (Kink points).
> > > >
> > > > I hate such functions, and think that in polite society (by which I
> > mean
> > > by
> > > > computational modelers) they should [not be received]((
> > > > https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J
))
> > by
> > > > people doing computational work. (That is, we should not go out of
> our
> > > way
> > > > to try to accommodate them).
> > > >
> > > > PS. People remember Karl Weierstrass for his finding that any
> function
> > > > which "is" continuously differentiable (to arbitrarily many
> > derivatives)
> > > > over an interval can be (in the limit) represented with arbitrary
> > > accuracy
> > > > by polynomials (I think that's the gist of his theorem). I like him
> > > better
> > > > for pointing out the existence of functions that [CANNOT be
> represented
> > > > that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
> > > >
> > > > Even if it is true that the limits of the left and right
derivatives
> > > > converge at every point, for any finite number of periods they are
> > > finitely
> > > > different for a finite number of points, which is an abomination
> (from
> > > the
> > > > standpoint of people who want to stably represent functions in
> discrete
> > > > terms like those that computers can easily handle). At those
points,
> > > > $c^{\prime}$ is undefined.
> > > >
> > > > So, my view is that the user can specify a convergence criterion
for
> > the
> > > > LEVEL of $c$ that (say) should apply at every gridpoint, or they
> should
> > > > supply a number of periods backwards (otherwise they should be
> required
> > > to
> > > > define their own convergence criterion). But if they are supplying
> the
> > > > 'level' criterion there is no reason to require them also
> (redundantly)
> > > to
> > > > incorporate aExtraGrid.
> > > >
> > > > PS. (I'm also on the side of Kronecker, who said "God made the
> > integers;
> > > > all else is the work of Man").
> > > >
> > > >
> > > >
> > > > This kind of gets into metaphysics realms of math.
> > > >
> > > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > > ***@***.***>
> > > > wrote:
> > > >
> > > > > You can't specify how many periods back to solve if it's an
> infinite
> > > > > horizon model-- it solves until the cFunc converges. If you try
to
> > run
> > > an
> > > > > infinite horizon model with a borrowing constraint and aXtraCount
> set
> > > to
> > > > > None, then the solver will repeatedly add one more kink, over and
> > over
> > > > > again.
> > > >
> > > >
> > > > Yay for it! That's the right thing to do!
> > > >
> > > >
> > > > > The model is never considered "converged" because the number of
> > > > > gridpoints in successive iterations isn't equal-- there's no way
an
> > > array
> > > > > of size 258 and an array of size 259 can be "close"! Eventually,
> the
> > > top
> > > > > gridpoint becomes so high that there's an overflow error and the
> > > solution
> > > > > collapses.
> > > > >
> > > >
> > > > But, I think this is the right answer!
> > > >
> > > >
> > > > >
> > > > > So we need to either specify a maximum amount of gridpoints or a
> > > highest
> > > > > value (relative to the lowest value). I sense that you're going
to
> > > > suggest
> > > > > that we change the distance criterion to mNrmSS, but that would
> have
> > > very
> > > > > bad effects in the perfect foresight model. The consumption
> function
> > is
> > > > > essentially constructed from "bottom upward" in the PF model, so
> > mNrmSS
> > > > > will very quickly return the same value on successive
iterations...
> > but
> > > > the
> > > > > consumption function above it is *way* off from the correct
> solution.
> > > > >
> > > > > Note that you don't need to put this custom version into a
notebook
> > to
> > > > test
> > > > > it. Just use developer mode on your computer and change your
branch
> > to
> > > > > mine. If your (locally run) notebook imports HARK, then it will
use
> > my
> > > > > version!
> > > > >
> > > >
> > > > Yes, but I want to SHARE this notebook with referees/editors/the
> > > universe.
> > > > If I could impose a requirements "econ-ark==" whatever in which I
> could
> > > > guarantee it would work, then that might be enough. To do that we'd
> > need
> > > > to create a new dev branch (containing the breaking changes) which
> will
> > > > exist in perpetuity that my code can insist upon.
> > > >
> > > > > -- mnw
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > > > > ***@***.***> wrote:
> > > > >
> > > > > > Just looked through the code -- it looks good (though haven't
> > tested
> > > > > until
> > > > > > we resolve whether this should be a "breaking change". I don't
> want
> > > to
> > > > do
> > > > > > the thing of including a custom version of ConsIndShockModel.py
> in
> > a
> > > > > > notebook until we make the new release.
> > > > > >
> > > > > > But one question: Don't see why the aXtraGrid parameter is
> > necessary.
> > > > The
> > > > > > extra gridpoints are constructed on the fly, and there'll be
one
> of
> > > > them
> > > > > > added for each iteration, so the user doesn't need to specify
> that
> > > > number
> > > > > > in advance, just needs to specify how many periods back to
solve,
> > > > right?
> > > > > In
> > > > > > fact, if aXtraGrid is fixed and they specify that the problem
> > should
> > > be
> > > > > > solved one more period, there's no way to do that without
adding
> > more
> > > > > > gridpoints?
> > > > > >
> > > > > > —
> > > > > > You are receiving this because you authored the thread.
> > > > > > Reply to this email directly, view it on GitHub
> > > > > > <
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > > >,
> > > > > > or mute the thread
> > > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > > >
> > > > > > .
> > > > > >
> > > > >
> > > > > —
> > > > > You are receiving this because you are subscribed to this thread.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > >
> > > > --
> > > > - Chris Carroll
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were assigned.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> >
> > --
> > - Chris Carroll
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A>
.
|
|
MaxKinks is fine. Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White <[email protected]>
wrote:
… It's called aXtraCount, not aXtraGrid. We can call it anything you want,
but if we're going to use a new variable name, I'd prefer to be direct,
with MaxKinks or something like that.
The terminal period solution is c=m, yes. Making making the terminal
period solver "more clever" is a different topic entirely, and would take
real effort/thought/work. If you want this ready to use on your project,
this is not something you should be asking for now.
-- mnw
On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
***@***.***> wrote:
> I see, so we are on the same page. But, I'm afraid that calling it
> aXtraGrid might be confusing to users. Could we call it something else,
> like "NumCnstPrds" or something like that?
>
> PS. I take it that the terminal function is $c=m$? An alternative would
> be for the terminal function to be the unconstrained analytical solution.
>
> On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
***@***.***
> >
> wrote:
>
> > That's essentially what aXtraCount does; I just used that variable name
> to
> > be like the other models. You're specifying how many periods worth of
> > kinks to care about, and throwing out everything beyond that. That's
what
> > generates "convergence".
> >
> > -- mnw
> >
> > On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
> > ***@***.***> wrote:
> >
> > > > If you prefer a different stopping condition, I can change it to
> > > aXtraMax,
> > > where you specify a (very large) aNrm beyond which you would never
> > possibly
> > > care about the consumption function, like 2000. Any kinks beyond that
> are
> > > considered irrelevant.
> > >
> > > I've thought about it a bit more and my view, translated from the
> > > metaphysics, is that the right definition of convergence is that we
> want
> > to
> > > say that a function has converged if at every $m$ both $c(m)$ and
> $c'(m)$
> > > converge. But every extra iteration back adds another point at which
> > > $c'(m)$ is undefined, so the function never converges in that sense.
> > >
> > > So, I think the user of the constrained version of the solver
function
> > > should just be required to say how many periods from the end they
want
> to
> > > solve, and the number of gridpoints is periods+2. Like, if they want
to
> > > solve zero periods back, we need only 2 gridpoints (to define the 45
> > degree
> > > line). If they want to solve 1 period, the function is piecewise
linear
> > > with two segments, so we need 3 gridpoints, and so on. Does that make
> > > sense? If they want to define some convergence criterion themselves,
> they
> > > can do it by adding that to the specification of the function.
> > >
> > > Didn't want to get into a fight about this, just want to be able to
> make
> > a
> > > DemARK notebook to illustrate some of this as a companion to the
> > LiqConstr
> > > REMARK.
> > >
> > > On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
> > ***@***.***
> > > >
> > > wrote:
> > >
> > > > These "breaking changes" are incredibly minor. Fixing the problem
> > merely
> > > > requires anyone using PerfForesightConsumerType to add BoroCnstArt
> and
> > > > aXtraCount to their dictionaries. Actually, I'll just add this
stupid
> > > > feature. This isn't a fight worth having.
> > > >
> > > > If you prefer a different stopping condition, I can change it to
> > > aXtraMax,
> > > > where you specify a (very large) aNrm beyond which you would never
> > > possibly
> > > > care about the consumption function, like 2000. Any kinks beyond
that
> > are
> > > > considered irrelevant.
> > > >
> > > > -- mnw
> > > >
> > > > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
> ***@***.***
> > >
> > > > wrote:
> > > >
> > > > > "until the cFunc converges" requires some convergence criterion.
If
> > > that
> > > > > criterion includes the MPC $c^{\prime(m))$, there IS no interval
> over
> > > > which
> > > > > "the cFunc converges"
> > > > >
> > > > > Of course there are many definitions of "converges" but because
> > > > > $c^{\prime}(m)$ is crucial for so many questions, I'd say the
> > question
> > > is
> > > > > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> > > > >
> > > > > It does not, because there are always these pesky points
> > (corresponding
> > > > to
> > > > > future constraints) at which the right and left derivatives are
> > > > different.
> > > > > (Kink points).
> > > > >
> > > > > I hate such functions, and think that in polite society (by
which I
> > > mean
> > > > by
> > > > > computational modelers) they should [not be received]((
> > > > >
https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J
> ))
> > > by
> > > > > people doing computational work. (That is, we should not go out
of
> > our
> > > > way
> > > > > to try to accommodate them).
> > > > >
> > > > > PS. People remember Karl Weierstrass for his finding that any
> > function
> > > > > which "is" continuously differentiable (to arbitrarily many
> > > derivatives)
> > > > > over an interval can be (in the limit) represented with arbitrary
> > > > accuracy
> > > > > by polynomials (I think that's the gist of his theorem). I like
him
> > > > better
> > > > > for pointing out the existence of functions that [CANNOT be
> > represented
> > > > > that way](https://en.wikipedia.org/wiki/Weierstrass_function) .
> > > > >
> > > > > Even if it is true that the limits of the left and right
> derivatives
> > > > > converge at every point, for any finite number of periods they
are
> > > > finitely
> > > > > different for a finite number of points, which is an abomination
> > (from
> > > > the
> > > > > standpoint of people who want to stably represent functions in
> > discrete
> > > > > terms like those that computers can easily handle). At those
> points,
> > > > > $c^{\prime}$ is undefined.
> > > > >
> > > > > So, my view is that the user can specify a convergence criterion
> for
> > > the
> > > > > LEVEL of $c$ that (say) should apply at every gridpoint, or they
> > should
> > > > > supply a number of periods backwards (otherwise they should be
> > required
> > > > to
> > > > > define their own convergence criterion). But if they are
supplying
> > the
> > > > > 'level' criterion there is no reason to require them also
> > (redundantly)
> > > > to
> > > > > incorporate aExtraGrid.
> > > > >
> > > > > PS. (I'm also on the side of Kronecker, who said "God made the
> > > integers;
> > > > > all else is the work of Man").
> > > > >
> > > > >
> > > > >
> > > > > This kind of gets into metaphysics realms of math.
> > > > >
> > > > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > > > ***@***.***>
> > > > > wrote:
> > > > >
> > > > > > You can't specify how many periods back to solve if it's an
> > infinite
> > > > > > horizon model-- it solves until the cFunc converges. If you try
> to
> > > run
> > > > an
> > > > > > infinite horizon model with a borrowing constraint and
aXtraCount
> > set
> > > > to
> > > > > > None, then the solver will repeatedly add one more kink, over
and
> > > over
> > > > > > again.
> > > > >
> > > > >
> > > > > Yay for it! That's the right thing to do!
> > > > >
> > > > >
> > > > > > The model is never considered "converged" because the number of
> > > > > > gridpoints in successive iterations isn't equal-- there's no
way
> an
> > > > array
> > > > > > of size 258 and an array of size 259 can be "close"!
Eventually,
> > the
> > > > top
> > > > > > gridpoint becomes so high that there's an overflow error and
the
> > > > solution
> > > > > > collapses.
> > > > > >
> > > > >
> > > > > But, I think this is the right answer!
> > > > >
> > > > >
> > > > > >
> > > > > > So we need to either specify a maximum amount of gridpoints or
a
> > > > highest
> > > > > > value (relative to the lowest value). I sense that you're going
> to
> > > > > suggest
> > > > > > that we change the distance criterion to mNrmSS, but that would
> > have
> > > > very
> > > > > > bad effects in the perfect foresight model. The consumption
> > function
> > > is
> > > > > > essentially constructed from "bottom upward" in the PF model,
so
> > > mNrmSS
> > > > > > will very quickly return the same value on successive
> iterations...
> > > but
> > > > > the
> > > > > > consumption function above it is *way* off from the correct
> > solution.
> > > > > >
> > > > > > Note that you don't need to put this custom version into a
> notebook
> > > to
> > > > > test
> > > > > > it. Just use developer mode on your computer and change your
> branch
> > > to
> > > > > > mine. If your (locally run) notebook imports HARK, then it will
> use
> > > my
> > > > > > version!
> > > > > >
> > > > >
> > > > > Yes, but I want to SHARE this notebook with referees/editors/the
> > > > universe.
> > > > > If I could impose a requirements "econ-ark==" whatever in which I
> > could
> > > > > guarantee it would work, then that might be enough. To do that
we'd
> > > need
> > > > > to create a new dev branch (containing the breaking changes)
which
> > will
> > > > > exist in perpetuity that my code can insist upon.
> > > > >
> > > > > > -- mnw
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > > > > > ***@***.***> wrote:
> > > > > >
> > > > > > > Just looked through the code -- it looks good (though haven't
> > > tested
> > > > > > until
> > > > > > > we resolve whether this should be a "breaking change". I
don't
> > want
> > > > to
> > > > > do
> > > > > > > the thing of including a custom version of
ConsIndShockModel.py
> > in
> > > a
> > > > > > > notebook until we make the new release.
> > > > > > >
> > > > > > > But one question: Don't see why the aXtraGrid parameter is
> > > necessary.
> > > > > The
> > > > > > > extra gridpoints are constructed on the fly, and there'll be
> one
> > of
> > > > > them
> > > > > > > added for each iteration, so the user doesn't need to specify
> > that
> > > > > number
> > > > > > > in advance, just needs to specify how many periods back to
> solve,
> > > > > right?
> > > > > > In
> > > > > > > fact, if aXtraGrid is fixed and they specify that the problem
> > > should
> > > > be
> > > > > > > solved one more period, there's no way to do that without
> adding
> > > more
> > > > > > > gridpoints?
> > > > > > >
> > > > > > > —
> > > > > > > You are receiving this because you authored the thread.
> > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > > > >,
> > > > > > > or mute the thread
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > >
> > > > > > —
> > > > > > You are receiving this because you are subscribed to this
thread.
> > > > > > Reply to this email directly, view it on GitHub
> > > > > > <
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > > > >,
> > > > > > or mute the thread
> > > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > > > >
> > > > > > .
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > - Chris Carroll
> > > > >
> > > > > —
> > > > > You are receiving this because you authored the thread.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > > —
> > > > You are receiving this because you were assigned.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > >
> > > --
> > > - Chris Carroll
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were assigned.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
> >
> > .
> >
>
>
> --
> - Chris Carroll
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
Adding that capability has been on my backburner for a while. It's always
felt a little weird that the (unconstrained) perfect foresight model can
take longer to solve than the income shocks model... merely because it
takes so many periods for human wealth to converge, and thus for the linear
cFunc to stop "backing up"! I'd like for the terminal period solver to
check whether it's an infinite horizon model, in which case it will use the
unconstrained perfect foresight solution as its initial guess (in both
PerfForesight and ConsIndShock). That will make the PF model "converge" in
just 1 or 2 periods (I think HARK ignores the convergence check on the
first pass).
On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
[email protected]> wrote:
… MaxKinks is fine. Or MaxPrds.
I wasn't asking to add a new terminal function, just asking what it was.
It's not worth either of our time to add that option.
On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White ***@***.***
>
wrote:
> It's called aXtraCount, not aXtraGrid. We can call it anything you want,
> but if we're going to use a new variable name, I'd prefer to be direct,
> with MaxKinks or something like that.
>
> The terminal period solution is c=m, yes. Making making the terminal
> period solver "more clever" is a different topic entirely, and would take
> real effort/thought/work. If you want this ready to use on your project,
> this is not something you should be asking for now.
>
> -- mnw
>
> On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > I see, so we are on the same page. But, I'm afraid that calling it
> > aXtraGrid might be confusing to users. Could we call it something else,
> > like "NumCnstPrds" or something like that?
> >
> > PS. I take it that the terminal function is $c=m$? An alternative would
> > be for the terminal function to be the unconstrained analytical
solution.
> >
> > On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
> ***@***.***
> > >
> > wrote:
> >
> > > That's essentially what aXtraCount does; I just used that variable
name
> > to
> > > be like the other models. You're specifying how many periods worth of
> > > kinks to care about, and throwing out everything beyond that. That's
> what
> > > generates "convergence".
> > >
> > > -- mnw
> > >
> > > On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
> > > ***@***.***> wrote:
> > >
> > > > > If you prefer a different stopping condition, I can change it to
> > > > aXtraMax,
> > > > where you specify a (very large) aNrm beyond which you would never
> > > possibly
> > > > care about the consumption function, like 2000. Any kinks beyond
that
> > are
> > > > considered irrelevant.
> > > >
> > > > I've thought about it a bit more and my view, translated from the
> > > > metaphysics, is that the right definition of convergence is that we
> > want
> > > to
> > > > say that a function has converged if at every $m$ both $c(m)$ and
> > $c'(m)$
> > > > converge. But every extra iteration back adds another point at
which
> > > > $c'(m)$ is undefined, so the function never converges in that
sense.
> > > >
> > > > So, I think the user of the constrained version of the solver
> function
> > > > should just be required to say how many periods from the end they
> want
> > to
> > > > solve, and the number of gridpoints is periods+2. Like, if they
want
> to
> > > > solve zero periods back, we need only 2 gridpoints (to define the
45
> > > degree
> > > > line). If they want to solve 1 period, the function is piecewise
> linear
> > > > with two segments, so we need 3 gridpoints, and so on. Does that
make
> > > > sense? If they want to define some convergence criterion
themselves,
> > they
> > > > can do it by adding that to the specification of the function.
> > > >
> > > > Didn't want to get into a fight about this, just want to be able to
> > make
> > > a
> > > > DemARK notebook to illustrate some of this as a companion to the
> > > LiqConstr
> > > > REMARK.
> > > >
> > > > On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
> > > ***@***.***
> > > > >
> > > > wrote:
> > > >
> > > > > These "breaking changes" are incredibly minor. Fixing the problem
> > > merely
> > > > > requires anyone using PerfForesightConsumerType to add
BoroCnstArt
> > and
> > > > > aXtraCount to their dictionaries. Actually, I'll just add this
> stupid
> > > > > feature. This isn't a fight worth having.
> > > > >
> > > > > If you prefer a different stopping condition, I can change it to
> > > > aXtraMax,
> > > > > where you specify a (very large) aNrm beyond which you would
never
> > > > possibly
> > > > > care about the consumption function, like 2000. Any kinks beyond
> that
> > > are
> > > > > considered irrelevant.
> > > > >
> > > > > -- mnw
> > > > >
> > > > > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
> > ***@***.***
> > > >
> > > > > wrote:
> > > > >
> > > > > > "until the cFunc converges" requires some convergence
criterion.
> If
> > > > that
> > > > > > criterion includes the MPC $c^{\prime(m))$, there IS no
interval
> > over
> > > > > which
> > > > > > "the cFunc converges"
> > > > > >
> > > > > > Of course there are many definitions of "converges" but because
> > > > > > $c^{\prime}(m)$ is crucial for so many questions, I'd say the
> > > question
> > > > is
> > > > > > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> > > > > >
> > > > > > It does not, because there are always these pesky points
> > > (corresponding
> > > > > to
> > > > > > future constraints) at which the right and left derivatives are
> > > > > different.
> > > > > > (Kink points).
> > > > > >
> > > > > > I hate such functions, and think that in polite society (by
> which I
> > > > mean
> > > > > by
> > > > > > computational modelers) they should [not be received]((
> > > > > >
> https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J
> > ))
> > > > by
> > > > > > people doing computational work. (That is, we should not go out
> of
> > > our
> > > > > way
> > > > > > to try to accommodate them).
> > > > > >
> > > > > > PS. People remember Karl Weierstrass for his finding that any
> > > function
> > > > > > which "is" continuously differentiable (to arbitrarily many
> > > > derivatives)
> > > > > > over an interval can be (in the limit) represented with
arbitrary
> > > > > accuracy
> > > > > > by polynomials (I think that's the gist of his theorem). I like
> him
> > > > > better
> > > > > > for pointing out the existence of functions that [CANNOT be
> > > represented
> > > > > > that way](https://en.wikipedia.org/wiki/Weierstrass_function)
.
> > > > > >
> > > > > > Even if it is true that the limits of the left and right
> > derivatives
> > > > > > converge at every point, for any finite number of periods they
> are
> > > > > finitely
> > > > > > different for a finite number of points, which is an
abomination
> > > (from
> > > > > the
> > > > > > standpoint of people who want to stably represent functions in
> > > discrete
> > > > > > terms like those that computers can easily handle). At those
> > points,
> > > > > > $c^{\prime}$ is undefined.
> > > > > >
> > > > > > So, my view is that the user can specify a convergence
criterion
> > for
> > > > the
> > > > > > LEVEL of $c$ that (say) should apply at every gridpoint, or
they
> > > should
> > > > > > supply a number of periods backwards (otherwise they should be
> > > required
> > > > > to
> > > > > > define their own convergence criterion). But if they are
> supplying
> > > the
> > > > > > 'level' criterion there is no reason to require them also
> > > (redundantly)
> > > > > to
> > > > > > incorporate aExtraGrid.
> > > > > >
> > > > > > PS. (I'm also on the side of Kronecker, who said "God made the
> > > > integers;
> > > > > > all else is the work of Man").
> > > > > >
> > > > > >
> > > > > >
> > > > > > This kind of gets into metaphysics realms of math.
> > > > > >
> > > > > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > > > > ***@***.***>
> > > > > > wrote:
> > > > > >
> > > > > > > You can't specify how many periods back to solve if it's an
> > > infinite
> > > > > > > horizon model-- it solves until the cFunc converges. If you
try
> > to
> > > > run
> > > > > an
> > > > > > > infinite horizon model with a borrowing constraint and
> aXtraCount
> > > set
> > > > > to
> > > > > > > None, then the solver will repeatedly add one more kink, over
> and
> > > > over
> > > > > > > again.
> > > > > >
> > > > > >
> > > > > > Yay for it! That's the right thing to do!
> > > > > >
> > > > > >
> > > > > > > The model is never considered "converged" because the number
of
> > > > > > > gridpoints in successive iterations isn't equal-- there's no
> way
> > an
> > > > > array
> > > > > > > of size 258 and an array of size 259 can be "close"!
> Eventually,
> > > the
> > > > > top
> > > > > > > gridpoint becomes so high that there's an overflow error and
> the
> > > > > solution
> > > > > > > collapses.
> > > > > > >
> > > > > >
> > > > > > But, I think this is the right answer!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > So we need to either specify a maximum amount of gridpoints
or
> a
> > > > > highest
> > > > > > > value (relative to the lowest value). I sense that you're
going
> > to
> > > > > > suggest
> > > > > > > that we change the distance criterion to mNrmSS, but that
would
> > > have
> > > > > very
> > > > > > > bad effects in the perfect foresight model. The consumption
> > > function
> > > > is
> > > > > > > essentially constructed from "bottom upward" in the PF model,
> so
> > > > mNrmSS
> > > > > > > will very quickly return the same value on successive
> > iterations...
> > > > but
> > > > > > the
> > > > > > > consumption function above it is *way* off from the correct
> > > solution.
> > > > > > >
> > > > > > > Note that you don't need to put this custom version into a
> > notebook
> > > > to
> > > > > > test
> > > > > > > it. Just use developer mode on your computer and change your
> > branch
> > > > to
> > > > > > > mine. If your (locally run) notebook imports HARK, then it
will
> > use
> > > > my
> > > > > > > version!
> > > > > > >
> > > > > >
> > > > > > Yes, but I want to SHARE this notebook with
referees/editors/the
> > > > > universe.
> > > > > > If I could impose a requirements "econ-ark==" whatever in
which I
> > > could
> > > > > > guarantee it would work, then that might be enough. To do that
> we'd
> > > > need
> > > > > > to create a new dev branch (containing the breaking changes)
> which
> > > will
> > > > > > exist in perpetuity that my code can insist upon.
> > > > > >
> > > > > > > -- mnw
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc Carroll <
> > > > > > > ***@***.***> wrote:
> > > > > > >
> > > > > > > > Just looked through the code -- it looks good (though
haven't
> > > > tested
> > > > > > > until
> > > > > > > > we resolve whether this should be a "breaking change". I
> don't
> > > want
> > > > > to
> > > > > > do
> > > > > > > > the thing of including a custom version of
> ConsIndShockModel.py
> > > in
> > > > a
> > > > > > > > notebook until we make the new release.
> > > > > > > >
> > > > > > > > But one question: Don't see why the aXtraGrid parameter is
> > > > necessary.
> > > > > > The
> > > > > > > > extra gridpoints are constructed on the fly, and there'll
be
> > one
> > > of
> > > > > > them
> > > > > > > > added for each iteration, so the user doesn't need to
specify
> > > that
> > > > > > number
> > > > > > > > in advance, just needs to specify how many periods back to
> > solve,
> > > > > > right?
> > > > > > > In
> > > > > > > > fact, if aXtraGrid is fixed and they specify that the
problem
> > > > should
> > > > > be
> > > > > > > > solved one more period, there's no way to do that without
> > adding
> > > > more
> > > > > > > > gridpoints?
> > > > > > > >
> > > > > > > > —
> > > > > > > > You are receiving this because you authored the thread.
> > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > > > > >,
> > > > > > > > or mute the thread
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > > > > >
> > > > > > > > .
> > > > > > > >
> > > > > > >
> > > > > > > —
> > > > > > > You are receiving this because you are subscribed to this
> thread.
> > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > > > > >,
> > > > > > > or mute the thread
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > - Chris Carroll
> > > > > >
> > > > > > —
> > > > > > You are receiving this because you authored the thread.
> > > > > > Reply to this email directly, view it on GitHub
> > > > > > <
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > > > > >,
> > > > > > or mute the thread
> > > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > > > > >
> > > > > > .
> > > > > >
> > > > >
> > > > > —
> > > > > You are receiving this because you were assigned.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > >
> > > > --
> > > > - Chris Carroll
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were assigned.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> >
> > --
> > - Chris Carroll
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A>
.
|
|
Good point. Actually, generically, I think people don't think much about
what the terminal period solution should be, and (as you point out) it can
make a big difference in speed of convergence. It actually sped up
Shujaat's problem a lot when I told him to assume that the "terminal
period" should be the solution to a buffer stock model rather than to
$c=m$.
On Sat, Jun 8, 2019 at 11:49 AM Matthew N. White <[email protected]>
wrote:
… Adding that capability has been on my backburner for a while. It's always
felt a little weird that the (unconstrained) perfect foresight model can
take longer to solve than the income shocks model... merely because it
takes so many periods for human wealth to converge, and thus for the linear
cFunc to stop "backing up"! I'd like for the terminal period solver to
check whether it's an infinite horizon model, in which case it will use the
unconstrained perfect foresight solution as its initial guess (in both
PerfForesight and ConsIndShock). That will make the PF model "converge" in
just 1 or 2 periods (I think HARK ignores the convergence check on the
first pass).
On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
***@***.***> wrote:
> MaxKinks is fine. Or MaxPrds.
>
> I wasn't asking to add a new terminal function, just asking what it was.
> It's not worth either of our time to add that option.
>
>
> On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White <
***@***.***
> >
> wrote:
>
> > It's called aXtraCount, not aXtraGrid. We can call it anything you
want,
> > but if we're going to use a new variable name, I'd prefer to be direct,
> > with MaxKinks or something like that.
> >
> > The terminal period solution is c=m, yes. Making making the terminal
> > period solver "more clever" is a different topic entirely, and would
take
> > real effort/thought/work. If you want this ready to use on your
project,
> > this is not something you should be asking for now.
> >
> > -- mnw
> >
> > On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
> > ***@***.***> wrote:
> >
> > > I see, so we are on the same page. But, I'm afraid that calling it
> > > aXtraGrid might be confusing to users. Could we call it something
else,
> > > like "NumCnstPrds" or something like that?
> > >
> > > PS. I take it that the terminal function is $c=m$? An alternative
would
> > > be for the terminal function to be the unconstrained analytical
> solution.
> > >
> > > On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
> > ***@***.***
> > > >
> > > wrote:
> > >
> > > > That's essentially what aXtraCount does; I just used that variable
> name
> > > to
> > > > be like the other models. You're specifying how many periods worth
of
> > > > kinks to care about, and throwing out everything beyond that.
That's
> > what
> > > > generates "convergence".
> > > >
> > > > -- mnw
> > > >
> > > > On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
> > > > ***@***.***> wrote:
> > > >
> > > > > > If you prefer a different stopping condition, I can change it
to
> > > > > aXtraMax,
> > > > > where you specify a (very large) aNrm beyond which you would
never
> > > > possibly
> > > > > care about the consumption function, like 2000. Any kinks beyond
> that
> > > are
> > > > > considered irrelevant.
> > > > >
> > > > > I've thought about it a bit more and my view, translated from the
> > > > > metaphysics, is that the right definition of convergence is that
we
> > > want
> > > > to
> > > > > say that a function has converged if at every $m$ both $c(m)$ and
> > > $c'(m)$
> > > > > converge. But every extra iteration back adds another point at
> which
> > > > > $c'(m)$ is undefined, so the function never converges in that
> sense.
> > > > >
> > > > > So, I think the user of the constrained version of the solver
> > function
> > > > > should just be required to say how many periods from the end they
> > want
> > > to
> > > > > solve, and the number of gridpoints is periods+2. Like, if they
> want
> > to
> > > > > solve zero periods back, we need only 2 gridpoints (to define the
> 45
> > > > degree
> > > > > line). If they want to solve 1 period, the function is piecewise
> > linear
> > > > > with two segments, so we need 3 gridpoints, and so on. Does that
> make
> > > > > sense? If they want to define some convergence criterion
> themselves,
> > > they
> > > > > can do it by adding that to the specification of the function.
> > > > >
> > > > > Didn't want to get into a fight about this, just want to be able
to
> > > make
> > > > a
> > > > > DemARK notebook to illustrate some of this as a companion to the
> > > > LiqConstr
> > > > > REMARK.
> > > > >
> > > > > On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
> > > > ***@***.***
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > These "breaking changes" are incredibly minor. Fixing the
problem
> > > > merely
> > > > > > requires anyone using PerfForesightConsumerType to add
> BoroCnstArt
> > > and
> > > > > > aXtraCount to their dictionaries. Actually, I'll just add this
> > stupid
> > > > > > feature. This isn't a fight worth having.
> > > > > >
> > > > > > If you prefer a different stopping condition, I can change it
to
> > > > > aXtraMax,
> > > > > > where you specify a (very large) aNrm beyond which you would
> never
> > > > > possibly
> > > > > > care about the consumption function, like 2000. Any kinks
beyond
> > that
> > > > are
> > > > > > considered irrelevant.
> > > > > >
> > > > > > -- mnw
> > > > > >
> > > > > > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
> > > ***@***.***
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > "until the cFunc converges" requires some convergence
> criterion.
> > If
> > > > > that
> > > > > > > criterion includes the MPC $c^{\prime(m))$, there IS no
> interval
> > > over
> > > > > > which
> > > > > > > "the cFunc converges"
> > > > > > >
> > > > > > > Of course there are many definitions of "converges" but
because
> > > > > > > $c^{\prime}(m)$ is crucial for so many questions, I'd say the
> > > > question
> > > > > is
> > > > > > > whether $c^{\prime}(m)$ converges monotonically at every $m$.
> > > > > > >
> > > > > > > It does not, because there are always these pesky points
> > > > (corresponding
> > > > > > to
> > > > > > > future constraints) at which the right and left derivatives
are
> > > > > > different.
> > > > > > > (Kink points).
> > > > > > >
> > > > > > > I hate such functions, and think that in polite society (by
> > which I
> > > > > mean
> > > > > > by
> > > > > > > computational modelers) they should [not be received]((
> > > > > > >
> > https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J
> > > ))
> > > > > by
> > > > > > > people doing computational work. (That is, we should not go
out
> > of
> > > > our
> > > > > > way
> > > > > > > to try to accommodate them).
> > > > > > >
> > > > > > > PS. People remember Karl Weierstrass for his finding that any
> > > > function
> > > > > > > which "is" continuously differentiable (to arbitrarily many
> > > > > derivatives)
> > > > > > > over an interval can be (in the limit) represented with
> arbitrary
> > > > > > accuracy
> > > > > > > by polynomials (I think that's the gist of his theorem). I
like
> > him
> > > > > > better
> > > > > > > for pointing out the existence of functions that [CANNOT be
> > > > represented
> > > > > > > that way](https://en.wikipedia.org/wiki/Weierstrass_function
)
> .
> > > > > > >
> > > > > > > Even if it is true that the limits of the left and right
> > > derivatives
> > > > > > > converge at every point, for any finite number of periods
they
> > are
> > > > > > finitely
> > > > > > > different for a finite number of points, which is an
> abomination
> > > > (from
> > > > > > the
> > > > > > > standpoint of people who want to stably represent functions
in
> > > > discrete
> > > > > > > terms like those that computers can easily handle). At those
> > > points,
> > > > > > > $c^{\prime}$ is undefined.
> > > > > > >
> > > > > > > So, my view is that the user can specify a convergence
> criterion
> > > for
> > > > > the
> > > > > > > LEVEL of $c$ that (say) should apply at every gridpoint, or
> they
> > > > should
> > > > > > > supply a number of periods backwards (otherwise they should
be
> > > > required
> > > > > > to
> > > > > > > define their own convergence criterion). But if they are
> > supplying
> > > > the
> > > > > > > 'level' criterion there is no reason to require them also
> > > > (redundantly)
> > > > > > to
> > > > > > > incorporate aExtraGrid.
> > > > > > >
> > > > > > > PS. (I'm also on the side of Kronecker, who said "God made
the
> > > > > integers;
> > > > > > > all else is the work of Man").
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > This kind of gets into metaphysics realms of math.
> > > > > > >
> > > > > > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > > > > > ***@***.***>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > You can't specify how many periods back to solve if it's an
> > > > infinite
> > > > > > > > horizon model-- it solves until the cFunc converges. If you
> try
> > > to
> > > > > run
> > > > > > an
> > > > > > > > infinite horizon model with a borrowing constraint and
> > aXtraCount
> > > > set
> > > > > > to
> > > > > > > > None, then the solver will repeatedly add one more kink,
over
> > and
> > > > > over
> > > > > > > > again.
> > > > > > >
> > > > > > >
> > > > > > > Yay for it! That's the right thing to do!
> > > > > > >
> > > > > > >
> > > > > > > > The model is never considered "converged" because the
number
> of
> > > > > > > > gridpoints in successive iterations isn't equal-- there's
no
> > way
> > > an
> > > > > > array
> > > > > > > > of size 258 and an array of size 259 can be "close"!
> > Eventually,
> > > > the
> > > > > > top
> > > > > > > > gridpoint becomes so high that there's an overflow error
and
> > the
> > > > > > solution
> > > > > > > > collapses.
> > > > > > > >
> > > > > > >
> > > > > > > But, I think this is the right answer!
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > So we need to either specify a maximum amount of gridpoints
> or
> > a
> > > > > > highest
> > > > > > > > value (relative to the lowest value). I sense that you're
> going
> > > to
> > > > > > > suggest
> > > > > > > > that we change the distance criterion to mNrmSS, but that
> would
> > > > have
> > > > > > very
> > > > > > > > bad effects in the perfect foresight model. The consumption
> > > > function
> > > > > is
> > > > > > > > essentially constructed from "bottom upward" in the PF
model,
> > so
> > > > > mNrmSS
> > > > > > > > will very quickly return the same value on successive
> > > iterations...
> > > > > but
> > > > > > > the
> > > > > > > > consumption function above it is *way* off from the correct
> > > > solution.
> > > > > > > >
> > > > > > > > Note that you don't need to put this custom version into a
> > > notebook
> > > > > to
> > > > > > > test
> > > > > > > > it. Just use developer mode on your computer and change
your
> > > branch
> > > > > to
> > > > > > > > mine. If your (locally run) notebook imports HARK, then it
> will
> > > use
> > > > > my
> > > > > > > > version!
> > > > > > > >
> > > > > > >
> > > > > > > Yes, but I want to SHARE this notebook with
> referees/editors/the
> > > > > > universe.
> > > > > > > If I could impose a requirements "econ-ark==" whatever in
> which I
> > > > could
> > > > > > > guarantee it would work, then that might be enough. To do
that
> > we'd
> > > > > need
> > > > > > > to create a new dev branch (containing the breaking changes)
> > which
> > > > will
> > > > > > > exist in perpetuity that my code can insist upon.
> > > > > > >
> > > > > > > > -- mnw
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc
Carroll <
> > > > > > > > ***@***.***> wrote:
> > > > > > > >
> > > > > > > > > Just looked through the code -- it looks good (though
> haven't
> > > > > tested
> > > > > > > > until
> > > > > > > > > we resolve whether this should be a "breaking change". I
> > don't
> > > > want
> > > > > > to
> > > > > > > do
> > > > > > > > > the thing of including a custom version of
> > ConsIndShockModel.py
> > > > in
> > > > > a
> > > > > > > > > notebook until we make the new release.
> > > > > > > > >
> > > > > > > > > But one question: Don't see why the aXtraGrid parameter
is
> > > > > necessary.
> > > > > > > The
> > > > > > > > > extra gridpoints are constructed on the fly, and there'll
> be
> > > one
> > > > of
> > > > > > > them
> > > > > > > > > added for each iteration, so the user doesn't need to
> specify
> > > > that
> > > > > > > number
> > > > > > > > > in advance, just needs to specify how many periods back
to
> > > solve,
> > > > > > > right?
> > > > > > > > In
> > > > > > > > > fact, if aXtraGrid is fixed and they specify that the
> problem
> > > > > should
> > > > > > be
> > > > > > > > > solved one more period, there's no way to do that without
> > > adding
> > > > > more
> > > > > > > > > gridpoints?
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > You are receiving this because you authored the thread.
> > > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > > > > > >,
> > > > > > > > > or mute the thread
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > > > > > >
> > > > > > > > > .
> > > > > > > > >
> > > > > > > >
> > > > > > > > —
> > > > > > > > You are receiving this because you are subscribed to this
> > thread.
> > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > > > > > >,
> > > > > > > > or mute the thread
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > > > > > >
> > > > > > > > .
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > - Chris Carroll
> > > > > > >
> > > > > > > —
> > > > > > > You are receiving this because you authored the thread.
> > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > > > > > >,
> > > > > > > or mute the thread
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > >
> > > > > > —
> > > > > > You are receiving this because you were assigned.
> > > > > > Reply to this email directly, view it on GitHub
> > > > > > <
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> > > > > >,
> > > > > > or mute the thread
> > > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> > > > > >
> > > > > > .
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > - Chris Carroll
> > > > >
> > > > > —
> > > > > You are receiving this because you authored the thread.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > > —
> > > > You are receiving this because you were assigned.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > >
> > > --
> > > - Chris Carroll
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were assigned.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A
> >
> > .
> >
>
>
> --
> - Chris Carroll
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK7ZFDGTZYTRWNH4T7ZLPZPIILA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXD3Q#issuecomment-500134382>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK7Z4V7LFF5K4EAHEK7LPZPIILANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
Yes. It's another example of solving a "nearby" easier problem to get a hot
start on the big problem. The Bayer-Luetticke approach is analogous, for
me.
On Sat, Jun 8, 2019 at 2:57 PM Christopher Llorracc Carroll <
[email protected]> wrote:
… Good point. Actually, generically, I think people don't think much about
what the terminal period solution should be, and (as you point out) it can
make a big difference in speed of convergence. It actually sped up
Shujaat's problem a lot when I told him to assume that the "terminal
period" should be the solution to a buffer stock model rather than to
$c=m$.
On Sat, Jun 8, 2019 at 11:49 AM Matthew N. White ***@***.***
>
wrote:
> Adding that capability has been on my backburner for a while. It's always
> felt a little weird that the (unconstrained) perfect foresight model can
> take longer to solve than the income shocks model... merely because it
> takes so many periods for human wealth to converge, and thus for the
linear
> cFunc to stop "backing up"! I'd like for the terminal period solver to
> check whether it's an infinite horizon model, in which case it will use
the
> unconstrained perfect foresight solution as its initial guess (in both
> PerfForesight and ConsIndShock). That will make the PF model "converge"
in
> just 1 or 2 periods (I think HARK ignores the convergence check on the
> first pass).
>
> On Sat, Jun 8, 2019 at 11:37 AM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > MaxKinks is fine. Or MaxPrds.
> >
> > I wasn't asking to add a new terminal function, just asking what it
was.
> > It's not worth either of our time to add that option.
> >
> >
> > On Sat, Jun 8, 2019 at 11:25 AM Matthew N. White <
> ***@***.***
> > >
> > wrote:
> >
> > > It's called aXtraCount, not aXtraGrid. We can call it anything you
> want,
> > > but if we're going to use a new variable name, I'd prefer to be
direct,
> > > with MaxKinks or something like that.
> > >
> > > The terminal period solution is c=m, yes. Making making the terminal
> > > period solver "more clever" is a different topic entirely, and would
> take
> > > real effort/thought/work. If you want this ready to use on your
> project,
> > > this is not something you should be asking for now.
> > >
> > > -- mnw
> > >
> > > On Sat, Jun 8, 2019 at 11:19 AM Christopher Llorracc Carroll <
> > > ***@***.***> wrote:
> > >
> > > > I see, so we are on the same page. But, I'm afraid that calling it
> > > > aXtraGrid might be confusing to users. Could we call it something
> else,
> > > > like "NumCnstPrds" or something like that?
> > > >
> > > > PS. I take it that the terminal function is $c=m$? An alternative
> would
> > > > be for the terminal function to be the unconstrained analytical
> > solution.
> > > >
> > > > On Sat, Jun 8, 2019 at 11:06 AM Matthew N. White <
> > > ***@***.***
> > > > >
> > > > wrote:
> > > >
> > > > > That's essentially what aXtraCount does; I just used that
variable
> > name
> > > > to
> > > > > be like the other models. You're specifying how many periods
worth
> of
> > > > > kinks to care about, and throwing out everything beyond that.
> That's
> > > what
> > > > > generates "convergence".
> > > > >
> > > > > -- mnw
> > > > >
> > > > > On Sat, Jun 8, 2019 at 11:00 AM Christopher Llorracc Carroll <
> > > > > ***@***.***> wrote:
> > > > >
> > > > > > > If you prefer a different stopping condition, I can change it
> to
> > > > > > aXtraMax,
> > > > > > where you specify a (very large) aNrm beyond which you would
> never
> > > > > possibly
> > > > > > care about the consumption function, like 2000. Any kinks
beyond
> > that
> > > > are
> > > > > > considered irrelevant.
> > > > > >
> > > > > > I've thought about it a bit more and my view, translated from
the
> > > > > > metaphysics, is that the right definition of convergence is
that
> we
> > > > want
> > > > > to
> > > > > > say that a function has converged if at every $m$ both $c(m)$
and
> > > > $c'(m)$
> > > > > > converge. But every extra iteration back adds another point at
> > which
> > > > > > $c'(m)$ is undefined, so the function never converges in that
> > sense.
> > > > > >
> > > > > > So, I think the user of the constrained version of the solver
> > > function
> > > > > > should just be required to say how many periods from the end
they
> > > want
> > > > to
> > > > > > solve, and the number of gridpoints is periods+2. Like, if they
> > want
> > > to
> > > > > > solve zero periods back, we need only 2 gridpoints (to define
the
> > 45
> > > > > degree
> > > > > > line). If they want to solve 1 period, the function is
piecewise
> > > linear
> > > > > > with two segments, so we need 3 gridpoints, and so on. Does
that
> > make
> > > > > > sense? If they want to define some convergence criterion
> > themselves,
> > > > they
> > > > > > can do it by adding that to the specification of the function.
> > > > > >
> > > > > > Didn't want to get into a fight about this, just want to be
able
> to
> > > > make
> > > > > a
> > > > > > DemARK notebook to illustrate some of this as a companion to
the
> > > > > LiqConstr
> > > > > > REMARK.
> > > > > >
> > > > > > On Sat, Jun 8, 2019 at 12:16 AM Matthew N. White <
> > > > > ***@***.***
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > These "breaking changes" are incredibly minor. Fixing the
> problem
> > > > > merely
> > > > > > > requires anyone using PerfForesightConsumerType to add
> > BoroCnstArt
> > > > and
> > > > > > > aXtraCount to their dictionaries. Actually, I'll just add
this
> > > stupid
> > > > > > > feature. This isn't a fight worth having.
> > > > > > >
> > > > > > > If you prefer a different stopping condition, I can change it
> to
> > > > > > aXtraMax,
> > > > > > > where you specify a (very large) aNrm beyond which you would
> > never
> > > > > > possibly
> > > > > > > care about the consumption function, like 2000. Any kinks
> beyond
> > > that
> > > > > are
> > > > > > > considered irrelevant.
> > > > > > >
> > > > > > > -- mnw
> > > > > > >
> > > > > > > On Fri, Jun 7, 2019 at 11:21 PM llorracc-git <
> > > > ***@***.***
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > "until the cFunc converges" requires some convergence
> > criterion.
> > > If
> > > > > > that
> > > > > > > > criterion includes the MPC $c^{\prime(m))$, there IS no
> > interval
> > > > over
> > > > > > > which
> > > > > > > > "the cFunc converges"
> > > > > > > >
> > > > > > > > Of course there are many definitions of "converges" but
> because
> > > > > > > > $c^{\prime}(m)$ is crucial for so many questions, I'd say
the
> > > > > question
> > > > > > is
> > > > > > > > whether $c^{\prime}(m)$ converges monotonically at every
$m$.
> > > > > > > >
> > > > > > > > It does not, because there are always these pesky points
> > > > > (corresponding
> > > > > > > to
> > > > > > > > future constraints) at which the right and left derivatives
> are
> > > > > > > different.
> > > > > > > > (Kink points).
> > > > > > > >
> > > > > > > > I hate such functions, and think that in polite society (by
> > > which I
> > > > > > mean
> > > > > > > by
> > > > > > > > computational modelers) they should [not be received]((
> > > > > > > >
> > > https://answers.yahoo.com/question/index?qid=20140604141657AAPNB5J
> > > > ))
> > > > > > by
> > > > > > > > people doing computational work. (That is, we should not go
> out
> > > of
> > > > > our
> > > > > > > way
> > > > > > > > to try to accommodate them).
> > > > > > > >
> > > > > > > > PS. People remember Karl Weierstrass for his finding that
any
> > > > > function
> > > > > > > > which "is" continuously differentiable (to arbitrarily many
> > > > > > derivatives)
> > > > > > > > over an interval can be (in the limit) represented with
> > arbitrary
> > > > > > > accuracy
> > > > > > > > by polynomials (I think that's the gist of his theorem). I
> like
> > > him
> > > > > > > better
> > > > > > > > for pointing out the existence of functions that [CANNOT be
> > > > > represented
> > > > > > > > that way](
https://en.wikipedia.org/wiki/Weierstrass_function
> )
> > .
> > > > > > > >
> > > > > > > > Even if it is true that the limits of the left and right
> > > > derivatives
> > > > > > > > converge at every point, for any finite number of periods
> they
> > > are
> > > > > > > finitely
> > > > > > > > different for a finite number of points, which is an
> > abomination
> > > > > (from
> > > > > > > the
> > > > > > > > standpoint of people who want to stably represent functions
> in
> > > > > discrete
> > > > > > > > terms like those that computers can easily handle). At
those
> > > > points,
> > > > > > > > $c^{\prime}$ is undefined.
> > > > > > > >
> > > > > > > > So, my view is that the user can specify a convergence
> > criterion
> > > > for
> > > > > > the
> > > > > > > > LEVEL of $c$ that (say) should apply at every gridpoint, or
> > they
> > > > > should
> > > > > > > > supply a number of periods backwards (otherwise they should
> be
> > > > > required
> > > > > > > to
> > > > > > > > define their own convergence criterion). But if they are
> > > supplying
> > > > > the
> > > > > > > > 'level' criterion there is no reason to require them also
> > > > > (redundantly)
> > > > > > > to
> > > > > > > > incorporate aExtraGrid.
> > > > > > > >
> > > > > > > > PS. (I'm also on the side of Kronecker, who said "God made
> the
> > > > > > integers;
> > > > > > > > all else is the work of Man").
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > This kind of gets into metaphysics realms of math.
> > > > > > > >
> > > > > > > > On Fri, Jun 7, 2019 at 9:02 PM Matthew N. White <
> > > > > > > ***@***.***>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > You can't specify how many periods back to solve if it's
an
> > > > > infinite
> > > > > > > > > horizon model-- it solves until the cFunc converges. If
you
> > try
> > > > to
> > > > > > run
> > > > > > > an
> > > > > > > > > infinite horizon model with a borrowing constraint and
> > > aXtraCount
> > > > > set
> > > > > > > to
> > > > > > > > > None, then the solver will repeatedly add one more kink,
> over
> > > and
> > > > > > over
> > > > > > > > > again.
> > > > > > > >
> > > > > > > >
> > > > > > > > Yay for it! That's the right thing to do!
> > > > > > > >
> > > > > > > >
> > > > > > > > > The model is never considered "converged" because the
> number
> > of
> > > > > > > > > gridpoints in successive iterations isn't equal-- there's
> no
> > > way
> > > > an
> > > > > > > array
> > > > > > > > > of size 258 and an array of size 259 can be "close"!
> > > Eventually,
> > > > > the
> > > > > > > top
> > > > > > > > > gridpoint becomes so high that there's an overflow error
> and
> > > the
> > > > > > > solution
> > > > > > > > > collapses.
> > > > > > > > >
> > > > > > > >
> > > > > > > > But, I think this is the right answer!
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > So we need to either specify a maximum amount of
gridpoints
> > or
> > > a
> > > > > > > highest
> > > > > > > > > value (relative to the lowest value). I sense that you're
> > going
> > > > to
> > > > > > > > suggest
> > > > > > > > > that we change the distance criterion to mNrmSS, but that
> > would
> > > > > have
> > > > > > > very
> > > > > > > > > bad effects in the perfect foresight model. The
consumption
> > > > > function
> > > > > > is
> > > > > > > > > essentially constructed from "bottom upward" in the PF
> model,
> > > so
> > > > > > mNrmSS
> > > > > > > > > will very quickly return the same value on successive
> > > > iterations...
> > > > > > but
> > > > > > > > the
> > > > > > > > > consumption function above it is *way* off from the
correct
> > > > > solution.
> > > > > > > > >
> > > > > > > > > Note that you don't need to put this custom version into
a
> > > > notebook
> > > > > > to
> > > > > > > > test
> > > > > > > > > it. Just use developer mode on your computer and change
> your
> > > > branch
> > > > > > to
> > > > > > > > > mine. If your (locally run) notebook imports HARK, then
it
> > will
> > > > use
> > > > > > my
> > > > > > > > > version!
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, but I want to SHARE this notebook with
> > referees/editors/the
> > > > > > > universe.
> > > > > > > > If I could impose a requirements "econ-ark==" whatever in
> > which I
> > > > > could
> > > > > > > > guarantee it would work, then that might be enough. To do
> that
> > > we'd
> > > > > > need
> > > > > > > > to create a new dev branch (containing the breaking
changes)
> > > which
> > > > > will
> > > > > > > > exist in perpetuity that my code can insist upon.
> > > > > > > >
> > > > > > > > > -- mnw
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jun 7, 2019 at 8:45 PM Christopher Llorracc
> Carroll <
> > > > > > > > > ***@***.***> wrote:
> > > > > > > > >
> > > > > > > > > > Just looked through the code -- it looks good (though
> > haven't
> > > > > > tested
> > > > > > > > > until
> > > > > > > > > > we resolve whether this should be a "breaking change".
I
> > > don't
> > > > > want
> > > > > > > to
> > > > > > > > do
> > > > > > > > > > the thing of including a custom version of
> > > ConsIndShockModel.py
> > > > > in
> > > > > > a
> > > > > > > > > > notebook until we make the new release.
> > > > > > > > > >
> > > > > > > > > > But one question: Don't see why the aXtraGrid parameter
> is
> > > > > > necessary.
> > > > > > > > The
> > > > > > > > > > extra gridpoints are constructed on the fly, and
there'll
> > be
> > > > one
> > > > > of
> > > > > > > > them
> > > > > > > > > > added for each iteration, so the user doesn't need to
> > specify
> > > > > that
> > > > > > > > number
> > > > > > > > > > in advance, just needs to specify how many periods back
> to
> > > > solve,
> > > > > > > > right?
> > > > > > > > > In
> > > > > > > > > > fact, if aXtraGrid is fixed and they specify that the
> > problem
> > > > > > should
> > > > > > > be
> > > > > > > > > > solved one more period, there's no way to do that
without
> > > > adding
> > > > > > more
> > > > > > > > > > gridpoints?
> > > > > > > > > >
> > > > > > > > > > —
> > > > > > > > > > You are receiving this because you authored the thread.
> > > > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJ3DDLYMXPJIHAFEMLPZL6MHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJPPY#issuecomment-500078527
> > > > > > > > > >,
> > > > > > > > > > or mute the thread
> > > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJCORH4AU3H7Y4FH5DPZL6MHANCNFSM4HRRZV2A
> > > > > > > > > >
> > > > > > > > > > .
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > You are receiving this because you are subscribed to this
> > > thread.
> > > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ABSEEJE3QDVFMLIXXDD7F3LPZMAKHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJ27I#issuecomment-500079997
> > > > > > > > >,
> > > > > > > > > or mute the thread
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ABSEEJBOK6NA5K6BVXTHY23PZMAKHANCNFSM4HRRZV2A
> > > > > > > > >
> > > > > > > > > .
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > - Chris Carroll
> > > > > > > >
> > > > > > > > —
> > > > > > > > You are receiving this because you authored the thread.
> > > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFNED4LWDJC6J7GA5KTPZMQUZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHMHVQ#issuecomment-500089814
> > > > > > > >,
> > > > > > > > or mute the thread
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFP3RHIGLZCJ7GBXY6DPZMQUZANCNFSM4HRRZV2A
> > > > > > > >
> > > > > > > > .
> > > > > > > >
> > > > > > >
> > > > > > > —
> > > > > > > You are receiving this because you were assigned.
> > > > > > > Reply to this email directly, view it on GitHub
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK76YFIE5AHAGA7YQRRLPZMXCRA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHM46A#issuecomment-500092536
> > > > > > >,
> > > > > > > or mute the thread
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75OZ6NFXQ7N7TMHMWDPZMXCRANCNFSM4HRRZV2A
> > > > > > >
> > > > > > > .
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > - Chris Carroll
> > > > > >
> > > > > > —
> > > > > > You are receiving this because you authored the thread.
> > > > > > Reply to this email directly, view it on GitHub
> > > > > > <
> > > > >
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFMGDCUVHLLCCTDZFF3PZPCSDA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWH2Y#issuecomment-500130795
> > > > > >,
> > > > > > or mute the thread
> > > > > > <
> > > > >
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMDPZZIZRHZZGAP4NTPZPCSDANCNFSM4HRRZV2A
> > > > > >
> > > > > > .
> > > > > >
> > > > >
> > > > > —
> > > > > You are receiving this because you were assigned.
> > > > > Reply to this email directly, view it on GitHub
> > > > > <
> > > >
> > >
> >
>
#299?email_source=notifications&email_token=AAKCK74VRZ4DTDNJNSJSMW3PZPDFVA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWLGA#issuecomment-500131224
> > > > >,
> > > > > or mute the thread
> > > > > <
> > > >
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK75FG56YRHCVQRIVOU3PZPDFVANCNFSM4HRRZV2A
> > > > >
> > > > > .
> > > > >
> > > >
> > > >
> > > > --
> > > > - Chris Carroll
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFIBTBSDBCJQ2Y4IQ6LPZPEZXA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWSTI#issuecomment-500132173
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFKJBVGCCEIASDBT7MDPZPEZXANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were assigned.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=AAKCK734ZZHHQIC6UJSN3BDPZPFPHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHWVZQ#issuecomment-500132582
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK722RM5A7E4QLKJ4HNLPZPFPHANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> >
> > --
> > - Chris Carroll
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFN5FNGVCYHFWJP7EQDPZPGZZA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHW4NI#issuecomment-500133429
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFN7MMMWNDOBR6B4XRDPZPGZZANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK7ZFDGTZYTRWNH4T7ZLPZPIILA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHXD3Q#issuecomment-500134382
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK7Z4V7LFF5K4EAHEK7LPZPIILANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFKNHYHGSYC7JPXTKBTPZP6ITA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXH3IZQ#issuecomment-500151398>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFKMWH77FOBOLGL6XW3PZP6ITANCNFSM4HRRZV2A>
.
|
|
Sounds like you've worked out a plan here but some $.02 from me...
Unfortunately how we've got our notebooks set up now, they all use the same requirements.txt file, so you can only pin to one version across all notebooks. However in the long run we should definitely change that, and in the short run you can just do the This is not great practice, but a short term fix when you're not certain how you want to implement a feature is to implement it one way in a dev release and then revert or change it in the next dev release. Practically speaking it's not that different from when you accidentally release a bug in a dev release and revert the change in the next release. It's a little annoying for dev release users, but your dev release users are the subset of users who've actively selected into being annoyed in exchange for access to the latest features. |
|
Good point, notebooks get their versions from requirements.txt if they are being run by mybinder. So a good temporary solution might just be to pip install econ-ark==[] whatever on the dev branch and then revisit this when we are ready to do the next stable release. Matt, I hope changing this to be a non-breaking change is super easy? |
|
Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't know
what will be problematic.
…-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll < ***@***.***> wrote:
Good point, notebooks get their versions from requirements.txt if they are
being run by mybinder. So a good temporary solution might just be to pip
install econ-ark==[] whatever on the dev branch and then revisit this when
we are ready to do the next stable release.
Matt, I hope changing this to be a non-breaking change is super easy?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A>
.
|
|
I'm thinking we probably will need to rethink our approach to launching
notebooks, and I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White <[email protected]>
wrote:
… Dev branch or dev release?
I'm not particularly well-versed with notebooks and binder, so I don't know
what will be problematic.
-- mnw
On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
***@***.***> wrote:
> Good point, notebooks get their versions from requirements.txt if they
are
> being run by mybinder. So a good temporary solution might just be to pip
> install econ-ark==[] whatever on the dev branch and then revisit this
when
> we are ready to do the next stable release.
>
> Matt, I hope changing this to be a non-breaking change is super easy?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
If it's non-breaking, why do we need it on a separate branch?
On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
[email protected]> wrote:
… I'm thinking we probably will need to rethink our approach to launching
notebooks, and I have been communicating with Andrij about that.
In the meantime, the proposal is just to have a non-breaking version on the
dev branch, and revisit the issue when the new ideas for how to launch
notebooks have stabilized.
On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White ***@***.***
>
wrote:
> Dev branch or dev release?
>
> I'm not particularly well-versed with notebooks and binder, so I don't
know
> what will be problematic.
>
> -- mnw
>
> On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > Good point, notebooks get their versions from requirements.txt if they
> are
> > being run by mybinder. So a good temporary solution might just be to
pip
> > install econ-ark==[] whatever on the dev branch and then revisit this
> when
> > we are ready to do the next stable release.
> >
> > Matt, I hope changing this to be a non-breaking change is super easy?
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A>
.
|
|
Not a separate branch -- just put it on the current dev branch.
Shauna's point was that just because you put something on the dev branch
doesn't mean it necessarily will go into the next stable release -- that
can be litigated at the point where the stable release's final form is
agreed upon.
On Mon, Jun 10, 2019 at 9:19 PM Matthew N. White <[email protected]>
wrote:
… If it's non-breaking, why do we need it on a separate branch?
On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
***@***.***> wrote:
> I'm thinking we probably will need to rethink our approach to launching
> notebooks, and I have been communicating with Andrij about that.
>
> In the meantime, the proposal is just to have a non-breaking version on
the
> dev branch, and revisit the issue when the new ideas for how to launch
> notebooks have stabilized.
>
>
>
> On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White <
***@***.***
> >
> wrote:
>
> > Dev branch or dev release?
> >
> > I'm not particularly well-versed with notebooks and binder, so I don't
> know
> > what will be problematic.
> >
> > -- mnw
> >
> > On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
> > ***@***.***> wrote:
> >
> > > Good point, notebooks get their versions from requirements.txt if
they
> > are
> > > being run by mybinder. So a good temporary solution might just be to
> pip
> > > install econ-ark==[] whatever on the dev branch and then revisit this
> > when
> > > we are ready to do the next stable release.
> > >
> > > Matt, I hope changing this to be a non-breaking change is super easy?
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were assigned.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A
> >
> > .
> >
>
>
> --
> - Chris Carroll
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK74NAH6VU52I75ZX4KTPZ2SK3A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5SZA#issuecomment-500554084>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK73GJLG3B67H5NNY5G3PZ2SK3ANCNFSM4HRRZV2A>
.
--
- Chris Carroll
|
|
That discussion was about a dev *release*, not a dev *branch*. That's why
I asked before whether we were talking about a dev branch or a dev release.
The plan is to merge this PR into master, and then put it out in the next
dev release, with no breaking changes; is that correct?
On Mon, Jun 10, 2019 at 3:23 PM Christopher Llorracc Carroll <
[email protected]> wrote:
… Not a separate branch -- just put it on the current dev branch.
Shauna's point was that just because you put something on the dev branch
doesn't mean it necessarily will go into the next stable release -- that
can be litigated at the point where the stable release's final form is
agreed upon.
On Mon, Jun 10, 2019 at 9:19 PM Matthew N. White ***@***.***
>
wrote:
> If it's non-breaking, why do we need it on a separate branch?
>
> On Mon, Jun 10, 2019 at 3:17 PM Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > I'm thinking we probably will need to rethink our approach to launching
> > notebooks, and I have been communicating with Andrij about that.
> >
> > In the meantime, the proposal is just to have a non-breaking version on
> the
> > dev branch, and revisit the issue when the new ideas for how to launch
> > notebooks have stabilized.
> >
> >
> >
> > On Mon, Jun 10, 2019 at 7:32 PM Matthew N. White <
> ***@***.***
> > >
> > wrote:
> >
> > > Dev branch or dev release?
> > >
> > > I'm not particularly well-versed with notebooks and binder, so I
don't
> > know
> > > what will be problematic.
> > >
> > > -- mnw
> > >
> > > On Mon, Jun 10, 2019 at 1:25 PM Christopher Llorracc Carroll <
> > > ***@***.***> wrote:
> > >
> > > > Good point, notebooks get their versions from requirements.txt if
> they
> > > are
> > > > being run by mybinder. So a good temporary solution might just be
to
> > pip
> > > > install econ-ark==[] whatever on the dev branch and then revisit
this
> > > when
> > > > we are ready to do the next stable release.
> > > >
> > > > Matt, I hope changing this to be a non-breaking change is super
easy?
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFJHG7WXZNOFS4ZOZJTPZ2FCHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKROHQ#issuecomment-500504350
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFJO2LKKAJECUUTS76LPZ2FCHANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were assigned.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=AAKCK77KTXHJWUWMAR4EGJ3PZ2F4DA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKSBAA#issuecomment-500506752
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK725D7RCZ7W3TRSCUR3PZ2F4DANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> >
> > --
> > - Chris Carroll
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFKIJPFCYYAUD7VKXZDPZ2SETA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5OLY#issuecomment-500553519
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFMKJ7EFSKQVWZL4GPTPZ2SETANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK74NAH6VU52I75ZX4KTPZ2SK3A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK5SZA#issuecomment-500554084
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK73GJLG3B67H5NNY5G3PZ2SK3ANCNFSM4HRRZV2A
>
> .
>
--
- Chris Carroll
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFLWM6JGAO7DS3BVMW3PZ2S37A5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK63PQ#issuecomment-500559294>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFNWX4ES4OQPWNWAXQDPZ2S37ANCNFSM4HRRZV2A>
.
|
|
I don't know what a "dev branch" would even be. All branches other than master are arguably development branches. I assume he meant to say "dev release", but please confirm that Chris. |
|
Yes, that's what I'm asking. My confusion (and thus original question) are
about the use of the term "dev branch".
…On Mon, Jun 10, 2019 at 3:36 PM Shauna ***@***.***> wrote:
I don't know what a "dev branch" would even be. All branches other than
master are arguably development branches.
I assume he meant to say "dev release", but please confirm that Chris.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A>
.
|
|
My understanding is that we have now moved to a workflow where we are
basically always on a Dev branch; when current Dev branch gets to point
where we are ready to publish a new "stable" release, then 1 nanosecond
later After we publish on master we create the next dev branch in
sequence. Shauna, is that the right way to describe what we should be
doing things?
On Mon, Jun 10, 2019 at 21:39 Matthew N. White <[email protected]>
wrote:
… Yes, that's what I'm asking. My confusion (and thus original question) are
about the use of the term "dev branch".
On Mon, Jun 10, 2019 at 3:36 PM Shauna ***@***.***> wrote:
> I don't know what a "dev branch" would even be. All branches other than
> master are arguably development branches.
>
> I assume he meant to say "dev release", but please confirm that Chris.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=AAKCK754PQCGTZSS4C64UZDPZ2UXPA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLAFXA#issuecomment-500564700>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKCK7ZIPQT3NMEZMNVVNHDPZ2UXPANCNFSM4HRRZV2A>
.
|
|
Thinking this over more, I guess what I described is not what we have been
doing - master branch has been where we put updates. So I guess what I
should say is that when there is a no breaking version I want to push a Dev
release that I can reference ..
On Mon, Jun 10, 2019 at 21:51 Christopher Llorracc Carroll <
[email protected]> wrote:
… My understanding is that we have now moved to a workflow where we are
basically always on a Dev branch; when current Dev branch gets to point
where we are ready to publish a new "stable" release, then 1 nanosecond
later After we publish on master we create the next dev branch in
sequence. Shauna, is that the right way to describe what we should be
doing things?
On Mon, Jun 10, 2019 at 21:39 Matthew N. White ***@***.***>
wrote:
> Yes, that's what I'm asking. My confusion (and thus original question)
are
> about the use of the term "dev branch".
>
> On Mon, Jun 10, 2019 at 3:36 PM Shauna ***@***.***> wrote:
>
> > I don't know what a "dev branch" would even be. All branches other than
> > master are arguably development branches.
> >
> > I assume he meant to say "dev release", but please confirm that Chris.
> >
> > —
> > You are receiving this because you authored the thread.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=AAKCK754PQCGTZSS4C64UZDPZ2UXPA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLAFXA#issuecomment-500564700
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKCK7ZIPQT3NMEZMNVVNHDPZ2UXPANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ABSEEJGOF3CG7YPLGJTCXR3PZ2WCTA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLBFUI#issuecomment-500568785>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABSEEJDOBKIYQURVIFCIVALPZ2WCTANCNFSM4HRRZV2A>
.
|
|
That's correct, and now we're on the same page. (Previous email draft
deleted, as you worked out what I was going to explain.)
On Mon, Jun 10, 2019 at 3:56 PM llorracc-git <[email protected]>
wrote:
… Thinking this over more, I guess what I described is not what we have been
doing - master branch has been where we put updates. So I guess what I
should say is that when there is a no breaking version I want to push a Dev
release that I can reference ..
On Mon, Jun 10, 2019 at 21:51 Christopher Llorracc Carroll <
***@***.***> wrote:
> My understanding is that we have now moved to a workflow where we are
> basically always on a Dev branch; when current Dev branch gets to point
> where we are ready to publish a new "stable" release, then 1 nanosecond
> later After we publish on master we create the next dev branch in
> sequence. Shauna, is that the right way to describe what we should be
> doing things?
>
> On Mon, Jun 10, 2019 at 21:39 Matthew N. White ***@***.***
>
> wrote:
>
> > Yes, that's what I'm asking. My confusion (and thus original question)
> are
> > about the use of the term "dev branch".
> >
> > On Mon, Jun 10, 2019 at 3:36 PM Shauna ***@***.***>
wrote:
> >
> > > I don't know what a "dev branch" would even be. All branches other
than
> > > master are arguably development branches.
> > >
> > > I assume he meant to say "dev release", but please confirm that
Chris.
> > >
> > > —
> > > You are receiving this because you authored the thread.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you were assigned.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=AAKCK754PQCGTZSS4C64UZDPZ2UXPA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLAFXA#issuecomment-500564700
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAKCK7ZIPQT3NMEZMNVVNHDPZ2UXPANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ABSEEJGOF3CG7YPLGJTCXR3PZ2WCTA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLBFUI#issuecomment-500568785
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ABSEEJDOBKIYQURVIFCIVALPZ2WCTANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFLINQRQOI2G7L53ZD3PZ2WYHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLBWJA#issuecomment-500570916>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADKRAFMI5QSRW7OP2JAKJ5DPZ2WYHANCNFSM4HRRZV2A>
.
|
|
Great, sorry for the confusion
On Mon, Jun 10, 2019 at 21:58 Matthew N. White <[email protected]>
wrote:
… That's correct, and now we're on the same page. (Previous email draft
deleted, as you worked out what I was going to explain.)
On Mon, Jun 10, 2019 at 3:56 PM llorracc-git ***@***.***>
wrote:
> Thinking this over more, I guess what I described is not what we have
been
> doing - master branch has been where we put updates. So I guess what I
> should say is that when there is a no breaking version I want to push a
Dev
> release that I can reference ..
>
> On Mon, Jun 10, 2019 at 21:51 Christopher Llorracc Carroll <
> ***@***.***> wrote:
>
> > My understanding is that we have now moved to a workflow where we are
> > basically always on a Dev branch; when current Dev branch gets to point
> > where we are ready to publish a new "stable" release, then 1 nanosecond
> > later After we publish on master we create the next dev branch in
> > sequence. Shauna, is that the right way to describe what we should be
> > doing things?
> >
> > On Mon, Jun 10, 2019 at 21:39 Matthew N. White <
***@***.***
> >
> > wrote:
> >
> > > Yes, that's what I'm asking. My confusion (and thus original
question)
> > are
> > > about the use of the term "dev branch".
> > >
> > > On Mon, Jun 10, 2019 at 3:36 PM Shauna ***@***.***>
> wrote:
> > >
> > > > I don't know what a "dev branch" would even be. All branches other
> than
> > > > master are arguably development branches.
> > > >
> > > > I assume he meant to say "dev release", but please confirm that
> Chris.
> > > >
> > > > —
> > > > You are receiving this because you authored the thread.
> > > > Reply to this email directly, view it on GitHub
> > > > <
> > >
> >
>
#299?email_source=notifications&email_token=ADKRAFLAIBL5OB7H5XC3U6DPZ2ULNA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXK75AQ#issuecomment-500563586
> > > >,
> > > > or mute the thread
> > > > <
> > >
> >
>
https://github.com/notifications/unsubscribe-auth/ADKRAFINVEUYHBMKDEFTJBLPZ2ULNANCNFSM4HRRZV2A
> > > >
> > > > .
> > > >
> > >
> > > —
> > > You are receiving this because you were assigned.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#299?email_source=notifications&email_token=AAKCK754PQCGTZSS4C64UZDPZ2UXPA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLAFXA#issuecomment-500564700
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAKCK7ZIPQT3NMEZMNVVNHDPZ2UXPANCNFSM4HRRZV2A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <
>
#299?email_source=notifications&email_token=ABSEEJGOF3CG7YPLGJTCXR3PZ2WCTA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLBFUI#issuecomment-500568785
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ABSEEJDOBKIYQURVIFCIVALPZ2WCTANCNFSM4HRRZV2A
> >
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <
#299?email_source=notifications&email_token=ADKRAFLINQRQOI2G7L53ZD3PZ2WYHA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLBWJA#issuecomment-500570916
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/ADKRAFMI5QSRW7OP2JAKJ5DPZ2WYHANCNFSM4HRRZV2A
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ABSEEJAATSFFXVINLVRZ47LPZ2W6PA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLB27Q#issuecomment-500571518>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABSEEJAWL734JTJWAG5P3STPZ2W6PANCNFSM4HRRZV2A>
.
|
Renamed model input to be more direct, rather than use name for similar (but not same) thing in other models.
If BoroCnstArt is not specified in PerfForesight model, preSolve assumes user meant no artificial borrowing constraint (as the model has always been until now). If BoroCnstArt is specified (not None) *and* it's an infinite horizon model *and* MaxKinks is not specified, then an AttributeError is raised to notify the user.
Changes to PerfForesightModel required changes to test comparing PF and IndShock solutions when they should be the same. Test now specifies a dictionary rather than using deepcopy and swapping the solution method.
|
I've made the changes discussed here. All dictionaries that previously worked for PerfForesightConsumerType will still work now; if they don't specify BoroCnstArt, we assume they intended to use the old model where no such thing could exist (and thus set it to None). If the user tries to specify BoroCnstArt, do an infinite horizon model, but not set MaxKinks, the code raises an AttributeError telling them this explicitly. Also, the thing I was calling aXtraCount (to not make a new thing that is almost-but-not-quite the same as aXtraCount) is now MaxKinks. This branch should be ready to merge (please don't do a squash and merge). |
|
@llorracc I think you wanted this for one of your papers, and it's been ready to merge for two weeks. |
|
@mnwhite, I'm at the point of wanting this again, but see there is a merge conflict that you can probably fix in 30 sec. Could you take a look? |
|
I'll try.
…On Thu, Oct 17, 2019, 9:02 AM Christopher Llorracc Carroll < ***@***.***> wrote:
@mnwhite <https://github.com/mnwhite>, I'm at the point of wanting this
again, but see there is a merge conflict that you can probably fix in 30
sec. Could you take a look?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#299?email_source=notifications&email_token=ADKRAFIJNMOJQ5RPH6EAATTQPBO5RA5CNFSM4HRRZV2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQANDA#issuecomment-543164044>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADKRAFN4HLLT2CW5BS7G3ZLQPBO5RANCNFSM4HRRZV2A>
.
|
|
This PR is now broken because of other work that was done on ConsIndShockModel.py in the four months since this model extension was written and PR submitted. Attempting to fix. |
Some variable names were updated in the solver while this PR was outstanding; now fixed.
|
Okay, it runs again and all checks pass. If you want this feature added, merge soon. |
|
Release note: Added constrained perfect foresight model solution |
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.
Add liquidity constraint (BoroCnstArt) to the perfect foresight consumption-saving model. Doesn't calculate value function if BoroCnstArt is not None, as we don't have the property that vNvrsFunc is piecewise linear. True value function requires calculating value at a bunch of points and then constructing as usual. This would be additional computation (and would require more parameters), so I didn't write this bit.